From shade at openjdk.java.net Thu Apr 1 09:36:39 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 1 Apr 2021 09:36:39 GMT Subject: [jdk16u] RFR: 8264374: Shenandoah: Remove leftover parallel reference processing argument Message-ID: After JDK-8254315, Shenandoah no longer uses upstream weak reference processor, it should remove related ParallelRefProcEnabled setting. ------------- Commit messages: - Backport ac604a18c92d9d21ea5b5b14fea512642d33764f Changes: https://git.openjdk.java.net/jdk16u/pull/100/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=100&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264374 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/100.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/100/head:pull/100 PR: https://git.openjdk.java.net/jdk16u/pull/100 From github.com+12403364+alvdavi at openjdk.java.net Thu Apr 1 09:59:31 2021 From: github.com+12403364+alvdavi at openjdk.java.net (David Alvarez) Date: Thu, 1 Apr 2021 09:59:31 GMT Subject: [jdk13u-dev] Integrated: 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 16:12:45 GMT, David Alvarez wrote: > I'd like to backport 8202343 to jdk13u. All other jdk versions are disabling TLS 1.0 and TLS 1.1 in 2021 April CPU. > > The patch did not apply cleanly. I had to account for JDK-8235710 missing in 13u, affecting the java.security file. Additionally, JDK-8243029 is also missing, so some of the tests modified do not exist in 13u. This pull request has now been integrated. Changeset: fecca4ec Author: David Alvarez Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/fecca4ec Stats: 381 lines in 18 files changed: 260 ins; 97 del; 24 mod 8202343: Disable TLS 1.0 and 1.1 Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/143 From yan at openjdk.java.net Thu Apr 1 11:01:44 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 1 Apr 2021 11:01:44 GMT Subject: [jdk15u-dev] Integrated: 8257707: Fix incorrect format string in Http1HeaderParser Message-ID: A follow-up to JDK-8204679. Tests run well. ------------- Commit messages: - Backport c6f93ec9f21f6db64ad7c15c284b39ab6b0a676e Changes: https://git.openjdk.java.net/jdk15u-dev/pull/5/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=5&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257707 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/5/head:pull/5 PR: https://git.openjdk.java.net/jdk15u-dev/pull/5 From yan at openjdk.java.net Thu Apr 1 11:01:45 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 1 Apr 2021 11:01:45 GMT Subject: [jdk15u-dev] Integrated: 8257707: Fix incorrect format string in Http1HeaderParser In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 10:53:49 GMT, Yuri Nesterenko wrote: > A follow-up to JDK-8204679. Tests run well. This pull request has now been integrated. Changeset: f320db0c Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/f320db0c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8257707: Fix incorrect format string in Http1HeaderParser Backport-of: c6f93ec9f21f6db64ad7c15c284b39ab6b0a676e ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/5 From clanger at openjdk.java.net Thu Apr 1 11:22:35 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 1 Apr 2021 11:22:35 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl Message-ID: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl ------------- Commit messages: - Incorporate review comments by phh - Backport 63f8fc87cdf3edb828474bb4954b76721ba8f9e5 Changes: https://git.openjdk.java.net/jdk16u/pull/94/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=94&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259662 Stats: 205 lines in 7 files changed: 177 ins; 4 del; 24 mod Patch: https://git.openjdk.java.net/jdk16u/pull/94.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/94/head:pull/94 PR: https://git.openjdk.java.net/jdk16u/pull/94 From phh at openjdk.java.net Thu Apr 1 11:22:35 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Thu, 1 Apr 2021 11:22:35 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 21:26:30 GMT, Christoph Langer wrote: > 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In SSLSocketImpl.java, lines 1480-1484 are replaced by a single line 1488, but the original patch doesn't do that. SSLTransport.java needs a copyright update to 2021. Otherwise, lgtm. ------------- Changes requested by phh (Reviewer). PR: https://git.openjdk.java.net/jdk16u/pull/94 From clanger at openjdk.java.net Thu Apr 1 11:22:35 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 1 Apr 2021 11:22:35 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 20:16:55 GMT, Paul Hohensee wrote: > In SSLSocketImpl.java, lines 1480-1484 are replaced by a single line 1488, but the original patch doesn't do that. SSLTransport.java needs a copyright update to 2021. Otherwise, lgtm. OK, the change l 1480-1484 comes from https://bugs.openjdk.java.net/browse/JDK-8253635 which in itself probably makes sense to backport as well. But I took it out for this BP. I updated copyright years for both, SSLTransport and SSLSocketImpl. ------------- PR: https://git.openjdk.java.net/jdk16u/pull/94 From phh at openjdk.java.net Thu Apr 1 14:43:14 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Thu, 1 Apr 2021 14:43:14 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 21:26:30 GMT, Christoph Langer wrote: > 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl Marked as reviewed by phh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/94 From clanger at openjdk.java.net Thu Apr 1 20:41:13 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 1 Apr 2021 20:41:13 GMT Subject: [jdk16u] Integrated: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 21:26:30 GMT, Christoph Langer wrote: > 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl This pull request has now been integrated. Changeset: 27c84494 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk16u/commit/27c84494 Stats: 204 lines in 7 files changed: 177 ins; 4 del; 23 mod 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl Reviewed-by: phh Backport-of: 63f8fc87cdf3edb828474bb4954b76721ba8f9e5 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/94 From hohensee at amazon.com Thu Apr 1 21:29:46 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 1 Apr 2021 21:29:46 +0000 Subject: [11u] RFR (XS): 8243452: JFR: Could not create chunk in repository with over 200 recordings Message-ID: <44119E5E-1DA8-45F4-89DC-4D79B65A7032@amazon.com> Please review this small and low risk backport to 11u. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8243452 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/26dce8fa0588 Webrev: https://cr.openjdk.java.net/~phh/8243452/webrev.11u.00/ Copyright dates had to be updated to 2020, and the second hunk for RepositoryChunk.java uses ?name? instead of ?filename? on line 82. The jtreg test attached to the issue passes, but was not included in the original patch, nor is it in jdk tip. Thanks, Paul From christoph.langer at sap.com Thu Apr 1 21:49:49 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Apr 2021 21:49:49 +0000 Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE In-Reply-To: References: Message-ID: Hi Martin, looks good to me. Best regards Christoph From: Doerr, Martin Sent: Dienstag, 30. M?rz 2021 14:01 To: jdk-updates-dev ; security-dev Cc: Langer, Christoph Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE Hi, JDK-8254631 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but the javadoc parts don't compile with 11u. They are not compatible with 11u and are documented to be dropped in the CSR (linked below). As also documented in the CSR, the old behavior can get restored by specifying the property: jdk.tls.alpnCharset=UTF-8 Bug: https://bugs.openjdk.java.net/browse/JDK-8254631 Original change: https://git.openjdk.java.net/jdk/commit/fe5cccc1 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264177 11u backport: http://cr.openjdk.java.net/~mdoerr/8254631_ALPN_11u/webrev.00/ Please review. Best regards, Martin From vkempik at openjdk.java.net Fri Apr 2 07:17:45 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 07:17:45 GMT Subject: [jdk15u-dev] RFR: 8256501: libTestMainKeyWindow fails to build with Xcode 12.2 Message-ID: Backport-of: 4e5116c46e29977cccbe8c04cb5559ce345fa72e A very simple and safe fix, a prerequest for JNF removal to apply more cleanly. JavaVM is a pseudo framework for a long time already, linking with it has no meaning. ------------- Commit messages: - Backport 4e5116c46e29977cccbe8c04cb5559ce345fa72e Changes: https://git.openjdk.java.net/jdk15u-dev/pull/6/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=6&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256501 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/6/head:pull/6 PR: https://git.openjdk.java.net/jdk15u-dev/pull/6 From vkempik at openjdk.java.net Fri Apr 2 07:29:10 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 07:29:10 GMT Subject: [jdk15u-dev] Integrated: 8256501: libTestMainKeyWindow fails to build with Xcode 12.2 In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 07:11:01 GMT, Vladimir Kempik wrote: > Backport-of: 4e5116c46e29977cccbe8c04cb5559ce345fa72e > > A very simple and safe fix, a prerequest for JNF removal to apply more cleanly. > JavaVM is a pseudo framework for a long time already, linking with it has no meaning. This pull request has now been integrated. Changeset: c565a2b0 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/c565a2b0 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256501: libTestMainKeyWindow fails to build with Xcode 12.2 Backport-of: 4e5116c46e29977cccbe8c04cb5559ce345fa72e ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/6 From vkempik at openjdk.java.net Fri Apr 2 07:34:38 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 07:34:38 GMT Subject: [jdk15u-dev] RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m Message-ID: First patch of series (1/8) to remove JNF dependency from jdk15u-dev (for macos) Applies cleanly. ------------- Commit messages: - Backport 4a8b5c1602789e95457cbb080a64c56edaf81051 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/7/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=7&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257858 Stats: 805 lines in 12 files changed: 369 ins; 317 del; 119 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/7.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/7/head:pull/7 PR: https://git.openjdk.java.net/jdk15u-dev/pull/7 From vkempik at openjdk.java.net Fri Apr 2 07:46:25 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 07:46:25 GMT Subject: [jdk15u-dev] Integrated: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 07:28:03 GMT, Vladimir Kempik wrote: > First patch of series (1/8) to remove JNF dependency from jdk15u-dev (for macos) > Applies cleanly. This pull request has now been integrated. Changeset: 0da4bb80 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/0da4bb80 Stats: 805 lines in 12 files changed: 369 ins; 317 del; 119 mod 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m 8257860: [macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m Backport-of: 4a8b5c1602789e95457cbb080a64c56edaf81051 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/7 From vkempik at openjdk.java.net Fri Apr 2 07:57:34 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 07:57:34 GMT Subject: [jdk15u-dev] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Message-ID: Please review this patch for 15u-dev. applied almost cleanly, I have to remove last chunk in src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m from original [patch](https://github.com/VladimirKempik/jdk/commit/c32923e06fc94c2a2ad8b9dd803aad1ed5386505) as it was already present in jdk15u-dev and wasn't needed. Very safe, fomatting only change, needed for rest of JNF removal patches to apply more cleanly ------------- Commit messages: - 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Changes: https://git.openjdk.java.net/jdk15u-dev/pull/8/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=8&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240487 Stats: 183 lines in 21 files changed: 0 ins; 0 del; 183 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/8.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/8/head:pull/8 PR: https://git.openjdk.java.net/jdk15u-dev/pull/8 From yan at openjdk.java.net Fri Apr 2 08:00:20 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 2 Apr 2021 08:00:20 GMT Subject: [jdk15u-dev] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 07:52:47 GMT, Vladimir Kempik wrote: > Please review this patch for 15u-dev. > applied almost cleanly, I have to remove last chunk in src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m > from original [patch](https://github.com/VladimirKempik/jdk/commit/c32923e06fc94c2a2ad8b9dd803aad1ed5386505) as it was already present in jdk15u-dev and wasn't needed. > Very safe, fomatting only change, needed for rest of JNF removal patches to apply more cleanly Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/8 From yan at openjdk.java.net Fri Apr 2 08:17:19 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 2 Apr 2021 08:17:19 GMT Subject: [jdk15u-dev] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 07:52:47 GMT, Vladimir Kempik wrote: > Please review this patch for 15u-dev. > applied almost cleanly, I have to remove last chunk in src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m > from original [patch](https://github.com/VladimirKempik/jdk/commit/c32923e06fc94c2a2ad8b9dd803aad1ed5386505) as it was already present in jdk15u-dev and wasn't needed. > Very safe, fomatting only change, needed for rest of JNF removal patches to apply more cleanly Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/8 From vkempik at openjdk.java.net Fri Apr 2 08:21:23 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 08:21:23 GMT Subject: [jdk15u-dev] Integrated: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 07:52:47 GMT, Vladimir Kempik wrote: > Please review this patch for 15u-dev. > applied almost cleanly, I have to remove last chunk in src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m > from original [patch](https://github.com/VladimirKempik/jdk/commit/c32923e06fc94c2a2ad8b9dd803aad1ed5386505) as it was already present in jdk15u-dev and wasn't needed. > Very safe, fomatting only change, needed for rest of JNF removal patches to apply more cleanly This pull request has now been integrated. Changeset: e2453498 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/e2453498 Stats: 183 lines in 21 files changed: 0 ins; 0 del; 183 mod 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/8 From vkempik at openjdk.java.net Fri Apr 2 08:27:41 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 08:27:41 GMT Subject: [jdk15u-dev] RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code Message-ID: Please review this backport to jdk 15u-dev. Original patch didn't apply cleanly, most of issues were in CPrinterJob.m due to changes introduced int jdk16&17. Rest was mostly context code difference. ------------- Commit messages: - 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code Changes: https://git.openjdk.java.net/jdk15u-dev/pull/9/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=9&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257853 Stats: 1595 lines in 35 files changed: 859 ins; 194 del; 542 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/9/head:pull/9 PR: https://git.openjdk.java.net/jdk15u-dev/pull/9 From yan at openjdk.java.net Fri Apr 2 08:37:08 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 2 Apr 2021 08:37:08 GMT Subject: [jdk15u-dev] RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 08:22:15 GMT, Vladimir Kempik wrote: > Please review this backport to jdk 15u-dev. Original patch didn't apply cleanly, most of issues were in CPrinterJob.m > due to changes introduced int jdk16&17. Rest was mostly context code difference. Vladimir, that couple of printer-related bugfixes will be technical debt, and it will be upon you in 15! ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk15u-dev/pull/9 From vkempik at openjdk.java.net Fri Apr 2 08:37:08 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 08:37:08 GMT Subject: [jdk15u-dev] RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 08:32:40 GMT, Yuri Nesterenko wrote: >> Please review this backport to jdk 15u-dev. Original patch didn't apply cleanly, most of issues were in CPrinterJob.m >> due to changes introduced int jdk16&17. Rest was mostly context code difference. > > Vladimir, that couple of printer-related bugfixes will be technical debt, and it will be upon you in 15! Oh, well, if somebody will ask, we will look into it. Purpose of this backport is to remove deps on JNF, not fix the printers. ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/9 From akozlov at openjdk.java.net Fri Apr 2 08:51:46 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 2 Apr 2021 08:51:46 GMT Subject: [jdk13u-dev] RFR: 8264640: CMS ParScanClosure misses a barrier Message-ID: Hi, please review an original fix for a GC crash. The jdk13u is the latest supported version that still has buggy code, it was deleted in jdk14 as a part of JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector. So I'm proposing it here. The fix is low-risk, on x86-64 it just introduces a compiler barrier to prevent two reads to be reordered as intended by surrounding comments. On CPUs with weaker memory models it introduces CPU barriers as well. ------------- Commit messages: - Add missing barriers Changes: https://git.openjdk.java.net/jdk13u-dev/pull/165/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=165&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264640 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/165.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/165/head:pull/165 PR: https://git.openjdk.java.net/jdk13u-dev/pull/165 From vkempik at openjdk.java.net Fri Apr 2 08:59:13 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 08:59:13 GMT Subject: [jdk15u-dev] Integrated: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 08:22:15 GMT, Vladimir Kempik wrote: > Please review this backport to jdk 15u-dev. Original patch didn't apply cleanly, most of issues were in CPrinterJob.m > due to changes introduced int jdk16&17. Rest was mostly context code difference. This pull request has now been integrated. Changeset: 2798c728 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/2798c728 Stats: 1595 lines in 35 files changed: 859 ins; 194 del; 542 mod 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/9 From akozlov at azul.com Fri Apr 2 09:02:51 2021 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 2 Apr 2021 12:02:51 +0300 Subject: [jdk13u-dev] RFR: 8264640: CMS ParScanClosure misses a barrier In-Reply-To: References: Message-ID: Adding hotspot-gc-dev. It will be great to receive comments from GC experts, even the fix does not make sense for mainline jdk. Thanks, Anton On 4/2/21 11:51 AM, Anton Kozlov wrote: > Hi, please review an original fix for a GC crash. The jdk13u is the latest supported version that still has buggy code, it was deleted in jdk14 as a part of JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector. So I'm proposing it here. > > The fix is low-risk, on x86-64 it just introduces a compiler barrier to prevent two reads to be reordered as intended by surrounding comments. On CPUs with weaker memory models it introduces CPU barriers as well. > > ------------- > > Commit messages: > - Add missing barriers > > Changes: https://git.openjdk.java.net/jdk13u-dev/pull/165/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=165&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8264640 > Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jdk13u-dev/pull/165.diff > Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/165/head:pull/165 > > PR: https://git.openjdk.java.net/jdk13u-dev/pull/165 > From vkempik at openjdk.java.net Fri Apr 2 09:16:35 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 09:16:35 GMT Subject: [jdk15u-dev] Integrated: 8259343: [macOS] Update JNI error handling in Cocoa code. Message-ID: Important prerequest of JNF removal pacthes, patch 4/8 Applies cleanly ------------- Commit messages: - Backport d6a2105b5c9b44c04cac7385756ec9924c1310ab Changes: https://git.openjdk.java.net/jdk15u-dev/pull/10/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=10&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259343 Stats: 75 lines in 8 files changed: 60 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/10.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/10/head:pull/10 PR: https://git.openjdk.java.net/jdk15u-dev/pull/10 From vkempik at openjdk.java.net Fri Apr 2 09:16:36 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 09:16:36 GMT Subject: [jdk15u-dev] Integrated: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 09:07:26 GMT, Vladimir Kempik wrote: > Important prerequest of JNF removal pacthes, patch 4/8 > Applies cleanly This pull request has now been integrated. Changeset: e688dae9 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/e688dae9 Stats: 75 lines in 8 files changed: 60 ins; 1 del; 14 mod 8259343: [macOS] Update JNI error handling in Cocoa code. Backport-of: d6a2105b5c9b44c04cac7385756ec9924c1310ab ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/10 From vkempik at openjdk.java.net Fri Apr 2 09:32:37 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 09:32:37 GMT Subject: [jdk15u-dev] RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Message-ID: Part 5/8 of JNF removal patches, applies almost cleanly, only slight context code difference in one place ------------- Commit messages: - Backport 5855d52a2a670a49b7a968fd58404b5d1836a8e1 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/11/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=11&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259651 Stats: 600 lines in 48 files changed: 56 ins; 17 del; 527 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/11.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/11/head:pull/11 PR: https://git.openjdk.java.net/jdk15u-dev/pull/11 From vkempik at openjdk.java.net Fri Apr 2 10:25:20 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 10:25:20 GMT Subject: [jdk15u-dev] Integrated: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: <2T9VZPK6QYeBHHdsfaNs9oU9qi6SMdaNaZD8TlWcvxk=.ff743f3a-02e1-444b-a8a7-cc614c8049ee@github.com> On Fri, 2 Apr 2021 09:26:10 GMT, Vladimir Kempik wrote: > Part 5/8 of JNF removal patches, applies almost cleanly, only slight context code difference in one place This pull request has now been integrated. Changeset: efd22bb2 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/efd22bb2 Stats: 600 lines in 48 files changed: 56 ins; 17 del; 527 mod 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Reviewed-by: serb Backport-of: 5855d52a2a670a49b7a968fd58404b5d1836a8e1 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/11 From vkempik at openjdk.java.net Fri Apr 2 10:44:31 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 10:44:31 GMT Subject: [jdk15u-dev] Integrated: 8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs Message-ID: <-IO-pH3XmwEwtLGOmZ7zFxREC9LU943n4aB_t3Hyodg=.eead9952-f3e3-436e-a5b7-7314d0b93b3a@github.com> Clean backport to jdk15u-dev, part 6 of 8 JNF-removal patches ------------- Commit messages: - Backport 92c2f084a2d1eb4475ebce6c9c08312e5c4aea5e Changes: https://git.openjdk.java.net/jdk15u-dev/pull/12/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=12&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259869 Stats: 153 lines in 21 files changed: 19 ins; 7 del; 127 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/12/head:pull/12 PR: https://git.openjdk.java.net/jdk15u-dev/pull/12 From vkempik at openjdk.java.net Fri Apr 2 10:44:32 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 10:44:32 GMT Subject: [jdk15u-dev] Integrated: 8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs In-Reply-To: <-IO-pH3XmwEwtLGOmZ7zFxREC9LU943n4aB_t3Hyodg=.eead9952-f3e3-436e-a5b7-7314d0b93b3a@github.com> References: <-IO-pH3XmwEwtLGOmZ7zFxREC9LU943n4aB_t3Hyodg=.eead9952-f3e3-436e-a5b7-7314d0b93b3a@github.com> Message-ID: On Fri, 2 Apr 2021 10:36:36 GMT, Vladimir Kempik wrote: > Clean backport to jdk15u-dev, part 6 of 8 JNF-removal patches This pull request has now been integrated. Changeset: 1f140666 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/1f140666 Stats: 153 lines in 21 files changed: 19 ins; 7 del; 127 mod 8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs Backport-of: 92c2f084a2d1eb4475ebce6c9c08312e5c4aea5e ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/12 From vkempik at openjdk.java.net Fri Apr 2 11:02:41 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 11:02:41 GMT Subject: [jdk15u-dev] RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module Message-ID: This is part 7/8 of JNF removal patches Original [commit](https://github.com/openjdk/jdk/commit/8760688d213865eaf1bd675056eb809cdae67048) didn't apply cleanly due to: -Changes in CPrinterJob.m in jdk16/17 -Missing CommonTextAccessibility.m ( such functionality is missing in jdk15 completely) Please review this patch fo jdk15u-dev ------------- Commit messages: - 8260616: Removing remaining JNF dependencies in the java.desktop module Changes: https://git.openjdk.java.net/jdk15u-dev/pull/13/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=13&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260616 Stats: 572 lines in 73 files changed: 243 ins; 98 del; 231 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/13/head:pull/13 PR: https://git.openjdk.java.net/jdk15u-dev/pull/13 From yan at openjdk.java.net Fri Apr 2 11:08:17 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 2 Apr 2021 11:08:17 GMT Subject: [jdk15u-dev] RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 10:55:49 GMT, Vladimir Kempik wrote: > This is part 7/8 of JNF removal patches > > Original [commit](https://github.com/openjdk/jdk/commit/8760688d213865eaf1bd675056eb809cdae67048) didn't apply cleanly due to: > -Changes in CPrinterJob.m in jdk16/17 > -Missing CommonTextAccessibility.m ( such functionality is missing in jdk15 completely) > Please review this patch fo jdk15u-dev Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/13 From vkempik at openjdk.java.net Fri Apr 2 11:50:19 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 11:50:19 GMT Subject: [jdk15u-dev] Integrated: 8260616: Removing remaining JNF dependencies in the java.desktop module In-Reply-To: References: Message-ID: <5MIsOZFFgsxUHCh0kzRFbp2mzazLOy1WM-keZOUp4y4=.e072eb32-53a3-4ebc-8188-9fcf98717f7b@github.com> On Fri, 2 Apr 2021 10:55:49 GMT, Vladimir Kempik wrote: > This is part 7/8 of JNF removal patches > > Original [commit](https://github.com/openjdk/jdk/commit/8760688d213865eaf1bd675056eb809cdae67048) didn't apply cleanly due to: > -Changes in CPrinterJob.m in jdk16/17 > -Missing CommonTextAccessibility.m ( such functionality is missing in jdk15 completely) > Please review this patch fo jdk15u-dev This pull request has now been integrated. Changeset: 4c917209 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/4c917209 Stats: 572 lines in 73 files changed: 243 ins; 98 del; 231 mod 8260616: Removing remaining JNF dependencies in the java.desktop module Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/13 From vkempik at openjdk.java.net Fri Apr 2 11:57:35 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 11:57:35 GMT Subject: [jdk15u-dev] Integrated: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m Message-ID: Clean backport, part 8/8 of JNF removal ------------- Commit messages: - Backport 2be60e37e0e433141b2e3d3e32f8e638a4888e3a Changes: https://git.openjdk.java.net/jdk15u-dev/pull/14/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=14&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257988 Stats: 45 lines in 2 files changed: 35 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/14/head:pull/14 PR: https://git.openjdk.java.net/jdk15u-dev/pull/14 From vkempik at openjdk.java.net Fri Apr 2 11:57:36 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Apr 2021 11:57:36 GMT Subject: [jdk15u-dev] Integrated: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 11:48:46 GMT, Vladimir Kempik wrote: > Clean backport, part 8/8 of JNF removal This pull request has now been integrated. Changeset: 5bfa1547 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/5bfa1547 Stats: 45 lines in 2 files changed: 35 ins; 2 del; 8 mod 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m Backport-of: 2be60e37e0e433141b2e3d3e32f8e638a4888e3a ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/14 From yan at openjdk.java.net Fri Apr 2 15:55:38 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 2 Apr 2021 15:55:38 GMT Subject: [jdk13u-dev] RFR: 8256682: JDK-8202343 is incomplete Message-ID: Need to fix this test after 8202343, a small change ------------- Commit messages: - Backport b9db002fef47001ee599cce1978042d0e17a0e06 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/167/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=167&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256682 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/167.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/167/head:pull/167 PR: https://git.openjdk.java.net/jdk13u-dev/pull/167 From bae at openjdk.java.net Fri Apr 2 16:09:23 2021 From: bae at openjdk.java.net (Andrew Brygin) Date: Fri, 2 Apr 2021 16:09:23 GMT Subject: [jdk13u-dev] RFR: 8256682: JDK-8202343 is incomplete In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 15:50:17 GMT, Yuri Nesterenko wrote: > Need to fix this test after 8202343, a small change The change looks fine to me. Thanks, Andrew ------------- Marked as reviewed by bae (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/167 From yan at openjdk.java.net Fri Apr 2 16:18:27 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 2 Apr 2021 16:18:27 GMT Subject: [jdk13u-dev] Integrated: 8256682: JDK-8202343 is incomplete In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 15:50:17 GMT, Yuri Nesterenko wrote: > Need to fix this test after 8202343, a small change This pull request has now been integrated. Changeset: fa1b985c Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/fa1b985c Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod 8256682: JDK-8202343 is incomplete Reviewed-by: bae Backport-of: b9db002fef47001ee599cce1978042d0e17a0e06 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/167 From omikhaltcova at openjdk.java.net Fri Apr 2 16:21:30 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 2 Apr 2021 16:21:30 GMT Subject: [jdk13u-dev] Integrated: 8248552: C2 crashes with SIGFPE due to division by zero Message-ID: I'd like to backport JDK-8248552 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with the test attached to the corresponding issue and the test added in this patch. ------------- Commit messages: - Backport 417e8e449df569f593b82ecd640fa01b6b762832 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=166&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248552 Stats: 117 lines in 2 files changed: 110 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/166.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/166/head:pull/166 PR: https://git.openjdk.java.net/jdk13u-dev/pull/166 From omikhaltcova at openjdk.java.net Fri Apr 2 16:21:32 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 2 Apr 2021 16:21:32 GMT Subject: [jdk13u-dev] Integrated: 8248552: C2 crashes with SIGFPE due to division by zero In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 14:14:57 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8248552 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with the test attached to the corresponding issue and the test added in this patch. This pull request has now been integrated. Changeset: 079ecdbb Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/079ecdbb Stats: 117 lines in 2 files changed: 110 ins; 0 del; 7 mod 8248552: C2 crashes with SIGFPE due to division by zero Bail out in PhaseIdealLoop:split_thru_phi when trying to split a Div or ModNode iv phi whose zero check was removed but could potentially still be zero based on type information. Backport-of: 417e8e449df569f593b82ecd640fa01b6b762832 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/166 From mathiske at amazon.com Fri Apr 2 20:21:51 2021 From: mathiske at amazon.com (Mathiske, Bernd) Date: Fri, 2 Apr 2021 20:21:51 +0000 Subject: Defer disabling TLS 1.0/1.1 by default? Message-ID: We have recently been made aware of increasing concerns by customers that disabling TLS 1.0/1.1 in the upcoming round of OpenJDK updates on April 20, as is the plan of record, could still cause outages. So we are considering keeping TLS 1.0/1.1 enabled by default in Amazon Corretto for now. Can this default configuration change be deferred in general?? Are there any concerns regarding Amazon Corretto keeping TLS 1.0/1.1 enabled by default?? Should we offer an alternate build that conforms with disabling by default and have the two lines converge again at a later date? My understanding is that in principle TLS 1.2/1.3 is not more secure than 1.0/1.1 and therefore we are not looking at a security fix here, correct? We are aware that the default setting can be manually changed by every user, but considering automated intake of binary artifacts we anticipate that this will not always be applied and disruptions will still occur. (sent to jdk-updates-dev@, jdk8u-dev@, and security-dev@) Bernd From colm at apache.org Fri Apr 2 21:15:58 2021 From: colm at apache.org (=?UTF-8?Q?Colm_MacC=C3=A1rthaigh?=) Date: Fri, 2 Apr 2021 14:15:58 -0700 Subject: Defer disabling TLS 1.0/1.1 by default? In-Reply-To: References: Message-ID: I'm a mere Java user and developer, I'm not a JDK person. I'm also only on jdk-updates-dev, so if this message ended up in mod-queues, apologies! I'm replying as a TLS person. I work at AWS too, leading our TLS work, and we took a look at this as part of the upcoming changes for Amazon Corretto. The short version is this: we think about 1% of applications and traffic "out there" are still using TLS1.0/TLS1.1. Given where browsers are at, I think this percentage is an under-estimate of the usage on Java applications - I suspect it's even higher there. When we dig in with customers "Why are you still using TLS1.0 or TLS1.1" the most common reasons are legacy appliances and applications. Think of hardware load balancers that were never updated, or can't be, to support TLS1.2 or better. Compliance mandated traffic inspection devices that force TLS1.0 in certain industries are another reason. For these applications, the change will break them, and they'll get a low-level exception. The users can re-enable TLS1.0 and TLS1.1, but they may suffer an outage because they likely weren't expecting a breaking change low in the networking stack. Retiring TLS1.0 and TLS1.1 is worthy, but I'd suggest that doing it in one pass is premature right now. The browsers are each at different degrees of support, some have "nuisance" warnings, some have no warnings at all. They've all punted a few times on when TLS1.0 and TLS1.1 may be hard disabled, but so far it's available in some form in all of them. I don't know of any other programming language (e.g. Go, Python, etc) that's doing something similar either. I tend to be an absolute paranoid zealot about security, but I don't lose sleep terribly over the issues that are in TLS1.0 and TLS1.1. I do want to retire the protocols ... but ideally without breaking anyone. If there's a way instead to do multiple passes and ship a JDK that measures TLS1.0 and TLS1.1 usage - as the browsers do - I'd love that. Then I could work with users to identify workloads where they are relying on TLS1.0 as a last resort and be proactive about the change. This doesn't have to be spyware phone-home measurements, even a local counter would be valuable. When we make these kinds of changes to AWS services, we go through a similar process: we see who is still using the old protocols and reach out to customers to work with them to update and ensure they won't be impacted. OpenJDK isn't a managed service, but we could help consumers help themselves at least. Since it will likely come up - here's a summary of the known security issues that are in TLS1.0 and TLS1.1: 1. The BEAST attack, which is in TLS1.0 only. The BEAST attack is a sophisticated attack that utilizes both active traffic interception and manipulation of retries and responses to Browsers (the ?B? in BEAST stands for ?Browser?). In general, it?s not the kind of attack that Java applications are vulnerable to.Even so, OpenJDK actually includes mitigations for the BEAST attack, but the "other" side of a TLS connection may not. 2. The SHA1/MD5 Transcript hash. To ensure that a sender or receiver isn?t being tricked by any kind of attacker in the middle, TLS uses a secure record of all the data sent and received called a transcript hash. In TLSv1.0 and TLSv1.1 this hash uses either a novel combination of the MD5 and SHA1 algorithms, or the SHA1 algorithm alone. Both MD5 and SHA1 are considered broken. In Cryptography we like to have extremely generous security margins, and the bar for what is considered ?broken? and what is actually practical are often very different. In this case, researchers estimate that it takes about 150 trillion trillion (that?s 150 trillion, times a trillion) operations to brute-force a TLSv1.0 or TLSv1.1 transcript hash. These hashes aren?t fixed, like the hashes on a certificate, they are unique to every SSL/TLS session. To use this weakness an attacker first has to intercept all communications between the sender and receiver. They put themselves in the middle. Then, during the handshake, the attacker must perform 150 trillion trillion operations to ?crack? the hash before allowing either side to proceed past the handshake. This also must happen without either side timing out or noticing the delay. Advanced dedicated SHA1 crackers can crack approximately 100 billion SHA1 hashes per second per processor. Even with these devices, it would take about fifty thousand processor years to crack a single TLS transcript hash. Performing the attack within 30 seconds would require over 500 million such devices operating in parallel. There are also no commercial devices capable of targeting the novel MD5/SHA1 combination, which is much more typical in TLSv1.0 and TLSv1.1. In short, cryptographers are rightly concerned about this issue. Processors will only get faster, and at some point, this attack may fall within the capabilities of large actors such as nation states and organized crime. But this issue is not a serious risk or threat for most java applications. 3. TLS1.0 and TLS1.1 support only the CBC ciphers which are vulnerable to Lucky13 and Sweet32. Turning off TLS1.0 and TLS1.1 actually doesn't fully mitigate these - these ciphers can be used over TLS1.2 also. But TLS1.2 does have better alternatives (e.g. AES-GCM). Lucky13 isn't a practical attack against TLS, even in extremely favorable circumstances for an attacker. Regardless, OpenJDK includes mitigations and uses a constant-time padding algorithm which is what matters. That leaves Sweet32, which is specific to 3DES. This issue impacts applications that send very large amounts of data, and again requires an active interception from an attacker. Many large websites with great security teams continue to maintain 3DES as a last-resort for compatibility with legacy systems, and I can see the reasoning. Other background: My experience is that many Java applications use TLS for confidentiality, but often do not consider traffic interception important in their threat model. It's very common to see self-signed certificates being used, for example, which make any application vulnerable to interception. The kinds of places where TLS1.0 and TLS1.1 are still used tend by their nature to be private networks that have other security controls in place. There are no TLS1.0 or TLS1.1 differences relating to how certificates are handled. OpenJDK is also immune to downgrade attacks. An attacker can't make it choose TLS1.0 or 1.1 if the other end supports TLS1.2 or better. On the whole, with all of those trade-offs in balance, it feels risky to me to disable TLS1.0 and TLS1.1 right now. To be clear though: it is better to use TLS1.2 than to use TLS1.0 and TLS1.1, and I'm very glad that OpenJDK does it right. People should fix or remove those legacy appliances in their networks, and I know customers that are. We all know that attacks only improve over time. But I don't think there's quite any clearly exploitable or very concerning issue that rises to the level of "this shouldn't even be supported in the language right now". I also don't see it as a few "bad" users out there holding back the rest of us. Keeping TLS1.0 and TLS1.1 in the default set in no way prevents applications from using TLS1.2 or better. But opinions can differ here. Others may prefer to be more forceful with changes and to take on a mission of clearing cruft faster. We've been having internal discussions about this and wanted to bring it here to the community and be open about it. On Fri, Apr 2, 2021 at 1:22 PM Mathiske, Bernd wrote: > > We have recently been made aware of increasing concerns by customers that disabling TLS 1.0/1.1 in the upcoming round of OpenJDK updates on April 20, as is the plan of record, could still cause outages. So we are considering keeping TLS 1.0/1.1 enabled by default in Amazon Corretto for now. > > Can this default configuration change be deferred in general? > > Are there any concerns regarding Amazon Corretto keeping TLS 1.0/1.1 enabled by default? > > Should we offer an alternate build that conforms with disabling by default and have the two lines converge again at a later date? > > My understanding is that in principle TLS 1.2/1.3 is not more secure than 1.0/1.1 and therefore we are not looking at a security fix here, correct? > > We are aware that the default setting can be manually changed by every user, but considering automated intake of binary artifacts we anticipate that this will not always be applied and disruptions will still occur. > > (sent to jdk-updates-dev@, jdk8u-dev@, and security-dev@) > > Bernd > > -- Colm From martin.doerr at sap.com Sat Apr 3 14:11:55 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Sat, 3 Apr 2021 14:11:55 +0000 Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review and the approval! Best regards, Martin From: Langer, Christoph Sent: Donnerstag, 1. April 2021 23:50 To: Doerr, Martin ; jdk-updates-dev ; security-dev Subject: RE: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE Hi Martin, looks good to me. Best regards Christoph From: Doerr, Martin > Sent: Dienstag, 30. M?rz 2021 14:01 To: jdk-updates-dev >; security-dev > Cc: Langer, Christoph > Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE Hi, JDK-8254631 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but the javadoc parts don't compile with 11u. They are not compatible with 11u and are documented to be dropped in the CSR (linked below). As also documented in the CSR, the old behavior can get restored by specifying the property: jdk.tls.alpnCharset=UTF-8 Bug: https://bugs.openjdk.java.net/browse/JDK-8254631 Original change: https://git.openjdk.java.net/jdk/commit/fe5cccc1 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264177 11u backport: http://cr.openjdk.java.net/~mdoerr/8254631_ALPN_11u/webrev.00/ Please review. Best regards, Martin From florian.david at datadoghq.com Sun Apr 4 18:33:10 2021 From: florian.david at datadoghq.com (Florian David) Date: Sun, 4 Apr 2021 20:33:10 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: Hi Jaroslav, Thanks for the review. > - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > L287 - IMO, the TODO is not necessary > It's removed. > L293 - I think the comment `// caller needs ResourceMark` should > not be removed > I added it back. L303 - Not sure if using Module_lock instead of > ClassLoaderDataGraph_lock is correct. Also, this change seems to be > bringing in changes unrelated to the patch. > From what is happening in other places it would seem > that a safepoint should be asserted instead (or nothing should be > done). > I will let Markus weigh in on this. > No change for the moment. > - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp > L38 - can this be completely removed? > It's removed. > - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp > L30 - I think `class JfrThreadLocal;` can also be removed > > It's removed. Update webrev link: Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.01/ Original PR: https://github.com/openjdk/jdk/pull/2780 Florian On Mon, Mar 29, 2021 at 12:22 PM Jaroslav Bachor?k < jaroslav.bachorik at datadoghq.com> wrote: > Hi Florian, > > a few nits: > - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > L287 - IMO, the TODO is not necessary > L293 - I think the comment `// caller needs ResourceMark` should > not be removed > L303 - Not sure if using Module_lock instead of > ClassLoaderDataGraph_lock is correct. Also, this change seems to be > bringing in changes unrelated to the patch. > From what is happening in other places it would seem > that a safepoint should be asserted instead (or nothing should be > done). > I will let Markus weigh in on this. > - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp > L38 - can this be completely removed? > - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp > L30 - I think `class JfrThreadLocal;` can also be removed > > Cheers, > > -JB- > > > On Wed, Mar 24, 2021 at 8:42 PM Florian David > wrote: > > > > Hi, > > > > Please review this 11u backport. It's very similar to the original patch, > > except for the class loader data graph lock and JfrKlassUnloading::sort() > > method which are not available in 11u. > > > > The missing lock has been replaced by locking the module_lock instead, > > as it is done in jfrcheckpointManager.cpp:363. > > JfrKlassUnloading class does not exist and thus sort() method is not > replaced, > > I added a TODO instead. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ > > Original PR: https://github.com/openjdk/jdk/pull/2780 > > > > Testing: > > - Linux x86_64 tier1 tests > > - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is 75.12 > MB before the patch and 3.08 MB after the patch. > > > > Let me know what you think. > > > > Thanks, > > Florian > From yan at openjdk.java.net Mon Apr 5 08:55:48 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 5 Apr 2021 08:55:48 GMT Subject: [jdk15u-dev] RFR: 8261231: Windows IME was disabled after DnD operation Message-ID: bug reproduced in the current state jdk15u-dev (with JDK-8252470) and fix worked there as expected. ------------- Commit messages: - Backport d6d5d9bf2f1a3343af6cf30a9d06a1f1b5f764ad Changes: https://git.openjdk.java.net/jdk15u-dev/pull/15/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=15&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261231 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/15.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/15/head:pull/15 PR: https://git.openjdk.java.net/jdk15u-dev/pull/15 From yan at openjdk.java.net Mon Apr 5 15:43:24 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 5 Apr 2021 15:43:24 GMT Subject: [jdk15u-dev] Integrated: 8261231: Windows IME was disabled after DnD operation In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 08:49:06 GMT, Yuri Nesterenko wrote: > bug reproduced in the current state jdk15u-dev (with JDK-8252470) and fix worked there as expected. This pull request has now been integrated. Changeset: 0f9626c8 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/0f9626c8 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod 8261231: Windows IME was disabled after DnD operation Backport-of: d6d5d9bf2f1a3343af6cf30a9d06a1f1b5f764ad ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/15 From mbalao at redhat.com Mon Apr 5 15:51:50 2021 From: mbalao at redhat.com (Martin Balao) Date: Mon, 5 Apr 2021 12:51:50 -0300 Subject: Defer disabling TLS 1.0/1.1 by default? In-Reply-To: References: Message-ID: <4c392b9c-be96-2c87-7d1a-453f36dcc805@redhat.com> Hello, Thanks @Colm and @Bernd for raising these well-founded concerns. We at Red Hat are already disabling by default TLS 1.0 and 1.1 in our 8 & 11 OpenJDK builds. This is because of our strict security posture and a unified crypto policy management in RHEL, that goes across different products and libraries. Users can still re-enable these protocols making fairly easy configurations. I believe we will be more or less on the same side in regards to the technical arguments, the security assessment and the risks taken by keeping these protocols enabled. There is always a chance that something unknown emerges and old protocols are more likely to be affected. But it's clear that there is not an imminent, publicly-known and critical security risk at this moment; and, thus, the reason why the change was on Oracle's JDK crypto-roadmap since 2019 and has been postponed before [1]. It's the same discussion that browsers and other libraries/runtimes are having. I see this more of a product-management discussion. The protocols are old enough and, due to increasing security risks, need to be removed from a default configuration at some point. There will be users affected, always, and particularly with protocols so widely used in the past. I hope we are all on the same page there. The question is about timing and the balance between 1) the current security risk, 2) how many users will upgrade their applications in an extra time-frame if we postpone the change, and 3) how disruptive would be for a user to change a configuration property for backward compatibility. While I acknowledge that the change will disrupt some users, I tend to take that as part of the risk of keeping legacy systems running in production environments. With this change announced in advanced, I don't see it more disruptive than when OpenJDK vendors deprecate support for a legacy OpenJDK release and users are forced to upgrade. Contrary to that, there is backward compatibility workaround that looks fairly reasonable -users are already familiar to changing security properties-. I believe we are late on the release cycle to postpone now. I wouldn't have opposed if there were general agreement and a new target date later this year; but I personally think that, in terms of the disruption caused, the gain won't be significant. Martin.- -- [1] - https://java.com/en/jre-jdk-cryptoroadmap.html From Matthew.Carter at microsoft.com Mon Apr 5 16:28:09 2021 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Mon, 5 Apr 2021 16:28:09 +0000 Subject: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for loopback connections on Windows In-Reply-To: References: Message-ID: Bump!? I've been monitoring the jdk11u backports for the last 2 months and seen a number of items move past these two fixes (enhancements). I just wanted to check that I've not missed a step in the process as they've not been tagged as "request denied" Note that David Grieve submitted the requests on my behalf https://bugs.openjdk.java.net/browse/JDK-8250521 https://bugs.openjdk.java.net/browse/JDK-8255264 Cheers Mat Sent from Outlook From: jdk-updates-dev on behalf of Mat Carter Sent: Friday, January 22, 2021 5:18 PM To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for loopback connections on Windows ? I'd like to propose the backport of JDK-8250521 and subsequent JDK-8255264 to 11u. The patch applied cleanly but had no effect as 11u only used PlainSocketImpl whereas tip uses NIOSokectImpl, so I made comparable changes to PlainSocketImpl. I kept the original changes to support NIOSocketImpl in case its ever backported.? However, I don't foresee pushing the changes to PlanSocketImpl to tip as its not used by default. Passes all tier1 tests JBS : https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250521&data=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655279564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iFXbQOHEvBhOnkA6TlLy30Bxk8FXxIXRm8GNhQptQR8%3D&reserved=0 Original fix: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2F035cdb28aa4c&data=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655279564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7qBKPLtXpedIDcVk8rXoEHl8BZYQh5kOitWMNEjqG8Y%3D&reserved=0 Original webrev: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~adityam%2Fnikola%2Ffast_connect_loopback_3%2F&data=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655279564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SE65puvz3q6D4A04QEYIhze%2BzWfE3RLbNnUVpRkWM%2BA%3D&reserved=0 JBS : https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8255264&data=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MBxv58ht3VnIvMjfn4JzHXx7CNO6RKdCU25oO0JQ7dA%3D&reserved=0 Original fix: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fcommit%2F7e01bc96&data=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IWfdxpo06CJLxQRso1%2Fne%2FVW64f8GEIbKMS2Wdkrq3E%3D&reserved=0 Original PR: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fpull%2F1523&data=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eACOp2IEdvd6vEB4qPNjkYlufUGq6fgjF6kFeVky9rg%3D&reserved=0 webrev for 11u: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~adityam%2Fmat%2F8250521_jdk11%2F&data=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dvT%2FQBwf7Pv8%2FrOWCpuYNUbK%2Fu23qxAs5xKNf64O2%2FI%3D&reserved=0 Thanks in advance Mat From colm at apache.org Mon Apr 5 16:34:30 2021 From: colm at apache.org (=?UTF-8?Q?Colm_MacC=C3=A1rthaigh?=) Date: Mon, 5 Apr 2021 09:34:30 -0700 Subject: Defer disabling TLS 1.0/1.1 by default? In-Reply-To: <4c392b9c-be96-2c87-7d1a-453f36dcc805@redhat.com> References: <4c392b9c-be96-2c87-7d1a-453f36dcc805@redhat.com> Message-ID: You've got a great point that this is ultimately about product management. I think if the change is just postponed, the needle won't move much on its own, it is like kicking a can down a road. I'm sure that there's an organic rate of decline, but it's likely quite slow. On the current path (changing the default set) I suspect what would happen is that the change will get caught in inter-op testing, or it will cause some outages, and either way the operators will do some googling and revert the default set. I doubt it will nudge many of them to finally remove a legacy hardware appliance or whatever is sticking them on TLS1.0/1.1 (we know it isn't Java keeping them on it). They'll probably just go back to business and usual and leave it like that until a compliance standard or auditor really makes them change. I'm not sure it achieves much ... which seems dissatisfying for a change that will probably cause outages. This is why I'd much rather add a measurement of TLS1.0 / 1.1 usage. Today it's hard to measure these; you can run tcpdump and figure it out but that's not a great option for a lot of environments. So often they have no idea how much traffic may be using it, just guesses. I sent a link to my email to a few people I know in the security industry and so far their estimates of usage here are actually much higher than mine, maybe even tens of per-cents. That's a lot of uncertainty for me. I feel like with a measure in hand, a number they could get out of their JVM, there'd be a tool we could all use to a) better measure impact and b) better drive results. Does RedHat have any visibility or numbers here? If there were firm data, we could just resolve this easily, but absent data I always prefer to assume the worst than the hope for the best. I never think it's too late for a good idea. But it is bad timing, none of these changes were on my radar until a few weeks ago - it never occured to me that we would consider making a breaking change here right now. Coming back to product management, one of our principles of product management at AWS is that we never break customers or change an APIs behavior if we can avoid it, and that's what major version updates are for. Security is an exception to that, we do make breaking changes for security reasons when necessary, but this is definitely a case where personally I'd avoid making any breaking change until the data is there to show that the impact will be negligible. On Mon, Apr 5, 2021 at 8:52 AM Martin Balao wrote: > > Hello, > > Thanks @Colm and @Bernd for raising these well-founded concerns. > > We at Red Hat are already disabling by default TLS 1.0 and 1.1 in our 8 > & 11 OpenJDK builds. This is because of our strict security posture and > a unified crypto policy management in RHEL, that goes across different > products and libraries. Users can still re-enable these protocols making > fairly easy configurations. > > I believe we will be more or less on the same side in regards to the > technical arguments, the security assessment and the risks taken by > keeping these protocols enabled. There is always a chance that something > unknown emerges and old protocols are more likely to be affected. But > it's clear that there is not an imminent, publicly-known and critical > security risk at this moment; and, thus, the reason why the change was > on Oracle's JDK crypto-roadmap since 2019 and has been postponed before > [1]. It's the same discussion that browsers and other libraries/runtimes > are having. > > I see this more of a product-management discussion. The protocols are > old enough and, due to increasing security risks, need to be removed > from a default configuration at some point. There will be users > affected, always, and particularly with protocols so widely used in the > past. I hope we are all on the same page there. The question is about > timing and the balance between 1) the current security risk, 2) how many > users will upgrade their applications in an extra time-frame if we > postpone the change, and 3) how disruptive would be for a user to change > a configuration property for backward compatibility. > > While I acknowledge that the change will disrupt some users, I tend to > take that as part of the risk of keeping legacy systems running in > production environments. With this change announced in advanced, I don't > see it more disruptive than when OpenJDK vendors deprecate support for a > legacy OpenJDK release and users are forced to upgrade. Contrary to > that, there is backward compatibility workaround that looks fairly > reasonable -users are already familiar to changing security properties-. > > I believe we are late on the release cycle to postpone now. I wouldn't > have opposed if there were general agreement and a new target date later > this year; but I personally think that, in terms of the disruption > caused, the gain won't be significant. > > Martin.- > > -- > [1] - https://java.com/en/jre-jdk-cryptoroadmap.html > -- Colm From mbalao at redhat.com Mon Apr 5 18:11:01 2021 From: mbalao at redhat.com (Martin Balao) Date: Mon, 5 Apr 2021 15:11:01 -0300 Subject: Defer disabling TLS 1.0/1.1 by default? In-Reply-To: References: <4c392b9c-be96-2c87-7d1a-453f36dcc805@redhat.com> Message-ID: On 4/5/21 1:34 PM, Colm MacC?rthaigh wrote: > This is why I'd much rather add a measurement of TLS1.0 / 1.1 usage. > Today it's hard to measure these; you can run tcpdump and figure it > out but that's not a great option for a lot of environments. So often > they have no idea how much traffic may be using it, just guesses. I > sent a link to my email to a few people I know in the security > industry and so far their estimates of usage here are actually much > higher than mine, maybe even tens of per-cents. That's a lot of > uncertainty for me. I feel like with a measure in hand, a number they > could get out of their JVM, there'd be a tool we could all use to a) > better measure impact and b) better drive results. Does RedHat have > any visibility or numbers here? If there were firm data, we could just > resolve this easily, but absent data I always prefer to assume the > worst than the hope for the best. > I'll let others share their opinions but wanted to make a comment on this. While I agree to some extent on the benefit of having aggregated data of TLS 1.0/1.1 usage specific to OpenJDK, I don't see feasible to retrieve such usage stats from the OpenJDK side. In addition to privacy concerns, there would be the question of how representative the data is (for technical and non-technical reasons) and the infrastructure needed to handle it. Knowing if the reason for not upgrading is OpenJDK would be more beneficial and actionable to us. My understanding is that the latter is not the case: we have a well tested implementation of TLS 1.2. As you said, many users will decide to implement the backward-compatibility configuration and keep using it. Removing the protocols from a default configuration looks to me a middle ground between doing nothing and the auditor enforcing compliance. Security updates often require users to reassess decisions and, eventually, make changes. All of that for a good reason. The point that I want to make is not on the number of users affected but to nuance the disruption impact they may have: the change should be catch in testing environments and the backward-compatibility configuration should be well documented -and straight forward to apply, as in this case-. From colm at apache.org Mon Apr 5 23:44:41 2021 From: colm at apache.org (=?UTF-8?Q?Colm_MacC=C3=A1rthaigh?=) Date: Mon, 5 Apr 2021 16:44:41 -0700 Subject: Defer disabling TLS 1.0/1.1 by default? In-Reply-To: References: <4c392b9c-be96-2c87-7d1a-453f36dcc805@redhat.com> Message-ID: On Mon, Apr 5, 2021 at 11:11 AM Martin Balao wrote: > I'll let others share their opinions but wanted to make a comment on > this. While I agree to some extent on the benefit of having aggregated > data of TLS 1.0/1.1 usage specific to OpenJDK, I don't see feasible to > retrieve such usage stats from the OpenJDK side. In addition to privacy > concerns, there would be the question of how representative the data is > (for technical and non-technical reasons) and the infrastructure needed > to handle it. Knowing if the reason for not upgrading is OpenJDK would > be more beneficial and actionable to us. My understanding is that the > latter is not the case: we have a well tested implementation of TLS 1.2. Totally agree that a phone-home spyware metric is a bad idea, although some browsers have been able to do those while preserving privacy it's not the kind of thing that should happen in a JVM. I can only imagine the IDS's that it would trip. But I do think a local metric would be useful. I've been through a lot of deprecations; SSLv2, SSLv3, MD5, SHA1, RC4, 3DES, and I know from talking to other vendors and TLS teams that the approach of "measure first" is pretty standard. Every time I've been surprised by what I've found ... and I'm keen to work with people. It only makes things more clear. > As you said, many users will decide to implement the > backward-compatibility configuration and keep using it. Removing the > protocols from a default configuration looks to me a middle ground > between doing nothing and the auditor enforcing compliance. Security > updates often require users to reassess decisions and, eventually, make > changes. All of that for a good reason. The point that I want to make is > not on the number of users affected but to nuance the disruption impact > they may have: the change should be catch in testing environments and > the backward-compatibility configuration should be well documented -and > straight forward to apply, as in this case-. I do think it will cause outages; many don't read the release notes or roadmaps, even more don't have the expertise to even know that they are using TLS1.0 and 1.1. They trust that a vendor wouldn't do it lightly and won't be expecting a breaking change this low in the networking stack. Infrastructure in testing setups doesn't always match what's in production, so it's setting off my spidey-senses. I'm loath to cause outages without very compelling reasons and a lot of work to minimize the risk. -- Colm From denghui.ddh at alibaba-inc.com Tue Apr 6 06:43:57 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 06 Apr 2021 14:43:57 +0800 Subject: =?UTF-8?B?UElORyBbMTF1XSBSRlIgKFhTKTogODI2MTAyMDogV3JvbmcgZm9ybWF0IHBhcmFtZXRlciBp?= =?UTF-8?B?biBjcmVhdGVfZW1lcmdlbmN5X2NodW5rX3BhdGg=?= Message-ID: Gentle Ping. ------------------------------------------------------------------ From:???(??) Send Time:2021?2?3?(???) 16:22 To:jdk-updates-dev at openjdk.java.net Subject:[11u] RFR (XS): 8261020: Wrong format parameter in create_emergency_chunk_path Hi team, Could I have a review of this small fix? In create_emergency_chunk_path, the call to jio_snprintf used a wrong format parameter "repository_path_len". This bug was introduced in 8217362(Emergency dump does not work when disk=false is set) and fixed in 8226511(Implement JFR Event Streaming), It is currently unacceptable to fully backport 8226511 to 11u, so I filed a new issue to fix this problem. JBS: https://bugs.openjdk.java.net/browse/JDK-8261020 webrev: http://cr.openjdk.java.net/~ddong/8261020/webrev.00/ Thanks, Denghui Dong From christoph.goettschkes at microdoc.com Tue Apr 6 07:20:42 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Tue, 6 Apr 2021 09:20:42 +0200 Subject: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls In-Reply-To: <37d6exsq9c-1@aserp2030.oracle.com> References: <37d6exsq9c-1@aserp2030.oracle.com> Message-ID: <37q2qxkswc-1@userp2060.oracle.com> Gentle reminder. On 3/23/21 9:49 AM, Christoph G?ttschkes wrote: > Hi, > > please review this backport of JDK-8213845 to 11u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/2d795829f39f > > Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.00/ > > This patch fixes the conversion between C and Java boolean types, which value is > not 0 or 1 in C on aarch32. This also fixes the test case > "runtime/BoolReturn/JNIBooleanTest.java", which is testing this conversion. > > The backport is not clean, because in 11u, the arm64 CPU type is still present. > Adjusting the backport was fairly straight forward. Because of the arm64 CPU type, > there are some additional #ifdef present and the changes had to be incoporated > into the arm64 port as well. No additional changes have been made, only slight > adjustments. > > I am not able to test the arm64 port, since it doesn't compile anymore and I don't > know if this CPU type is still supported, or if the code remains there because it > is deemed to complicated to remove it. > > Tested: > ?* Hotspot tier1 on linux aarch32 > ?* Hotspot tier1 on linux aarch32 with -XX:+VerifyOops and -Xcheck:jni > ?* Hotspot tier1 on linux ARMv7-A > > Thanks, > Christoph > From vkempik at openjdk.java.net Tue Apr 6 07:56:44 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 6 Apr 2021 07:56:44 GMT Subject: [jdk13u-dev] RFR: 8256501: libTestMainKeyWindow fails to build with Xcode 12.2 Message-ID: Clean backport to jdk13u-dev. A prerequest for the jnf_removal patches to apply more cleanly. ------------- Commit messages: - Backport 4e5116c46e29977cccbe8c04cb5559ce345fa72e Changes: https://git.openjdk.java.net/jdk13u-dev/pull/168/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=168&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256501 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/168.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/168/head:pull/168 PR: https://git.openjdk.java.net/jdk13u-dev/pull/168 From vkempik at openjdk.java.net Tue Apr 6 08:32:17 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 6 Apr 2021 08:32:17 GMT Subject: [jdk13u-dev] Integrated: 8256501: libTestMainKeyWindow fails to build with Xcode 12.2 In-Reply-To: References: Message-ID: <48Inj_hoBXvBg1uU3KiJD2mR6l0_2EtyvI5DyiS80R4=.03a18b84-a5d6-4cf4-a200-7d9b8b98b0d1@github.com> On Tue, 6 Apr 2021 07:48:03 GMT, Vladimir Kempik wrote: > Clean backport to jdk13u-dev. A prerequest for the jnf_removal patches to apply more cleanly. This pull request has now been integrated. Changeset: 039003d3 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/039003d3 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256501: libTestMainKeyWindow fails to build with Xcode 12.2 Backport-of: 4e5116c46e29977cccbe8c04cb5559ce345fa72e ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/168 From vkempik at openjdk.java.net Tue Apr 6 08:57:41 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 6 Apr 2021 08:57:41 GMT Subject: [jdk13u-dev] RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m Message-ID: Backport to jdk13u-dev. Applies almost clean, few gmk files had different filename and few copyright year issues. ------------- Commit messages: - 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m 8257860: [macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m Changes: https://git.openjdk.java.net/jdk13u-dev/pull/169/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=169&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257858 Stats: 805 lines in 12 files changed: 369 ins; 317 del; 119 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/169.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/169/head:pull/169 PR: https://git.openjdk.java.net/jdk13u-dev/pull/169 From yan at openjdk.java.net Tue Apr 6 10:02:44 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 6 Apr 2021 10:02:44 GMT Subject: [jdk15u-dev] Integrated: 8262446: DragAndDrop hangs on Windows Message-ID: backporting as follow-up to 8232114. Applies clean. ------------- Commit messages: - Backport bf9b74d18767619f0765ed1435e35e28077a4220 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/16/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=16&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262446 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/16/head:pull/16 PR: https://git.openjdk.java.net/jdk15u-dev/pull/16 From yan at openjdk.java.net Tue Apr 6 10:02:45 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 6 Apr 2021 10:02:45 GMT Subject: [jdk15u-dev] Integrated: 8262446: DragAndDrop hangs on Windows In-Reply-To: References: Message-ID: <0bhF4wMVJKsuj2ewPdwM1Vt4Awhp3T4m0xgMRNhF9h8=.685c09f8-aac0-4be2-9845-d359cc95874b@github.com> On Tue, 6 Apr 2021 09:54:56 GMT, Yuri Nesterenko wrote: > backporting as follow-up to 8232114. Applies clean. This pull request has now been integrated. Changeset: 8009faf4 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/8009faf4 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod 8262446: DragAndDrop hangs on Windows Backport-of: bf9b74d18767619f0765ed1435e35e28077a4220 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/16 From shade at redhat.com Tue Apr 6 10:58:50 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 6 Apr 2021 12:58:50 +0200 Subject: [11u] RFR (S) 8238175: CTW: Class.getDeclaredMethods fails with assert(k->is_subclass_of(SystemDictionary::Throwable_klass())) failed: invalid exception class Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8238175 https://hg.openjdk.java.net/jdk/jdk/rev/b7f4baa47fe2 This should improve cleanliness for CTW runs: the patch relaxes the assert to warning. Unfortunately, the test does not run on 11u, because .jcod sets too high class version. I reduced the class version to the one JDK 11 accepts. There are no other changes. 11u webrev: https://cr.openjdk.java.net/~shade/8238175/webrev.11u.01/ Testing: new regression test (fails before, passes now); tier{1,2} -- Thanks, -Aleksey From shade at redhat.com Tue Apr 6 11:05:04 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 6 Apr 2021 13:05:04 +0200 Subject: [11u] RFR (XS) 8262465: Very long compilation times and high memory consumption in C2 debug builds Message-ID: <8503ad1e-6bfd-f530-3fc2-588769a09330@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8262465 https://git.openjdk.java.net/jdk/commit/2da882c0 This effectively guards the verification block with C2 testing flag. Unfortunately, the patch does not apply cleanly due to protected block being a bit different. 11u variant: https://cr.openjdk.java.net/~shade/8262465/webrev.11u.01/ Testing: tier{1,2} -- Thanks, -Aleksey From yan at openjdk.java.net Tue Apr 6 12:17:38 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 6 Apr 2021 12:17:38 GMT Subject: [jdk15u-dev] RFR: 8255086: Update the root locale display names Message-ID: applies totally clean. Relevant tests do pass. ------------- Commit messages: - Backport ff5f2265d20d2a462691b332eb5dfcca91a22fe4 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=17&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255086 Stats: 234 lines in 5 files changed: 111 ins; 0 del; 123 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/17/head:pull/17 PR: https://git.openjdk.java.net/jdk15u-dev/pull/17 From yan at openjdk.java.net Tue Apr 6 12:22:19 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 6 Apr 2021 12:22:19 GMT Subject: [jdk15u-dev] Integrated: 8255086: Update the root locale display names In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 12:12:13 GMT, Yuri Nesterenko wrote: > applies totally clean. Relevant tests do pass. This pull request has now been integrated. Changeset: de458f9f Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/de458f9f Stats: 234 lines in 5 files changed: 111 ins; 0 del; 123 mod 8255086: Update the root locale display names Backport-of: ff5f2265d20d2a462691b332eb5dfcca91a22fe4 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/17 From hseigel at openjdk.java.net Tue Apr 6 13:45:28 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 6 Apr 2021 13:45:28 GMT Subject: [jdk16u] Integrated: 8263558: Possible NULL dereference in fast path arena free if ZapResourceArea is true Message-ID: This is the backport of JDK-8263558 to JDK-16u. The original bug fix patch applied cleanly. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS and Mach5 tiers 3-5 on Linux x64. ------------- Commit messages: - Backport d2c137d408b9c44f8f8d71e62dfea24a4279300e Changes: https://git.openjdk.java.net/jdk16u/pull/102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263558 Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk16u/pull/102 From hseigel at openjdk.java.net Tue Apr 6 13:45:28 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 6 Apr 2021 13:45:28 GMT Subject: [jdk16u] Integrated: 8263558: Possible NULL dereference in fast path arena free if ZapResourceArea is true In-Reply-To: References: Message-ID: <234X20SsEayRibpwNYaZf8VGggIMXW154C--M7j8kYo=.1ab6e185-26c1-47f6-9b3c-27a803f35026@github.com> On Tue, 6 Apr 2021 13:37:57 GMT, Harold Seigel wrote: > This is the backport of JDK-8263558 to JDK-16u. The original bug fix patch applied cleanly. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS and Mach5 tiers 3-5 on Linux x64. This pull request has now been integrated. Changeset: 426cb6ad Author: Harold Seigel URL: https://git.openjdk.java.net/jdk16u/commit/426cb6ad Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 mod 8263558: Possible NULL dereference in fast path arena free if ZapResourceArea is true Backport-of: d2c137d408b9c44f8f8d71e62dfea24a4279300e ------------- PR: https://git.openjdk.java.net/jdk16u/pull/102 From hohensee at amazon.com Tue Apr 6 15:14:52 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 6 Apr 2021 15:14:52 +0000 Subject: [11u] RFR (XS) 8262465: Very long compilation times and high memory consumption in C2 debug builds Message-ID: The check for (!liveout->is_empty()) comes from https://bugs.openjdk.java.net/browse/JDK-8234003. Backport that first? Not strictly necessary because it's minor optimizations and format changes, but makes the 11u code closer to tip in case of future backports. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Aleksey Shipilev Date: Tuesday, April 6, 2021 at 4:05 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (XS) 8262465: Very long compilation times and high memory consumption in C2 debug builds Original bug: https://bugs.openjdk.java.net/browse/JDK-8262465 https://git.openjdk.java.net/jdk/commit/2da882c0 This effectively guards the verification block with C2 testing flag. Unfortunately, the patch does not apply cleanly due to protected block being a bit different. 11u variant: https://cr.openjdk.java.net/~shade/8262465/webrev.11u.01/ Testing: tier{1,2} -- Thanks, -Aleksey From hohensee at amazon.com Tue Apr 6 15:18:53 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 6 Apr 2021 15:18:53 +0000 Subject: [11u] RFR (S) 8238175: CTW: Class.getDeclaredMethods fails with assert(k->is_subclass_of(SystemDictionary::Throwable_klass())) failed: invalid exception class Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Aleksey Shipilev Date: Tuesday, April 6, 2021 at 3:59 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (S) 8238175: CTW: Class.getDeclaredMethods fails with assert(k->is_subclass_of(SystemDictionary::Throwable_klass())) failed: invalid exception class Original bug: https://bugs.openjdk.java.net/browse/JDK-8238175 https://hg.openjdk.java.net/jdk/jdk/rev/b7f4baa47fe2 This should improve cleanliness for CTW runs: the patch relaxes the assert to warning. Unfortunately, the test does not run on 11u, because .jcod sets too high class version. I reduced the class version to the one JDK 11 accepts. There are no other changes. 11u webrev: https://cr.openjdk.java.net/~shade/8238175/webrev.11u.01/ Testing: new regression test (fails before, passes now); tier{1,2} -- Thanks, -Aleksey From snazarki at openjdk.java.net Tue Apr 6 15:27:33 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Tue, 6 Apr 2021 15:27:33 GMT Subject: [jdk13u-dev] RFR: 8254790: SIGSEGV in string_indexof_char and stringL_indexof_char intrinsics Message-ID: Hi! Please review the backport of JDK-8254790. The patch fixes SIGSEGV and is required for code sync with jdk11,15. The patch is taken from jdk15 since the original one can't be applied cleanly due to reasons described https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-October/040943.html ------------- Commit messages: - Backport afcf14912e9e37499444108e4b9c08d9bd6ef64f Changes: https://git.openjdk.java.net/jdk13u-dev/pull/170/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=170&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254790 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/170/head:pull/170 PR: https://git.openjdk.java.net/jdk13u-dev/pull/170 From yan at openjdk.java.net Tue Apr 6 15:29:38 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 6 Apr 2021 15:29:38 GMT Subject: [jdk15u-dev] RFR: 8251549: Update docs on building for Git Message-ID: jdk15u is in process of migrating to Git (jdk15u-dev is already there), so we would need a variant of this document in 15u, too. This exact patch applies clean. Yes, clean with some chunks shifted the uniform 42 lines. These lines, it seems to me, belong mostly to updates JDK-8256182 and JDK-8247591 and are irrelevant to this task. I have plan for making building.html as a separate task -- a backport of JDK-8257224 if possible but maybe not. ------------- Commit messages: - Backport 042734cc5b17302a8f2ecdf577511bd6d5ec5e22 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/18/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=18&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251549 Stats: 68 lines in 1 file changed: 12 ins; 37 del; 19 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/18.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/18/head:pull/18 PR: https://git.openjdk.java.net/jdk15u-dev/pull/18 From zgu at redhat.com Tue Apr 6 18:01:26 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 6 Apr 2021 14:01:26 -0400 Subject: [11u] RFR 8263558: Possible NULL dereference in fast path arena free if ZapResourceArea is true Message-ID: I would like to backport this patch to 11u for parity with Oracle 11.0.12-oracle. The original bug: https://bugs.openjdk.java.net/browse/JDK-8263558 The original patch: https://github.com/openjdk/jdk/commit/d2c137d4 The original patch does not apply cleanly. The conflict is due to JDK-8195100 [1], which changed Afree() method signature. diff -r 490ba2d4ad94 src/hotspot/share/memory/arena.hpp --- a/src/hotspot/share/memory/arena.hpp Sat Mar 20 09:06:53 2021 +0000 +++ b/src/hotspot/share/memory/arena.hpp Tue Apr 06 13:53:44 2021 -0400 @@ -201,7 +201,7 @@ // Fast delete in area. Common case is: NOP (except for storage reclaimed) void Afree(void *ptr, size_t size) { if (ptr == NULL) { - return true; // as with free(3), freeing NULL is a noop. + return; // as with free(3), freeing NULL is a noop. } 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8263558-11u/webrev.00/ Thanks, -Zhengyu [1] https://bugs.openjdk.java.net/browse/JDK-8195100 From hohensee at amazon.com Tue Apr 6 18:31:16 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 6 Apr 2021 18:31:16 +0000 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining Message-ID: <7AC4CB7A-B8EE-4C29-80AC-0AEA23DB89C5@amazon.com> Hi, Andrew, We backported this patch because we noticed increased compilation overhead after we increased MaxInlineDepth to 15. We've been running with it (and the follow-on patches) in production starting with 11.0.9 (last October) with no issues. At our scale, even relatively small improvements help reduce fleet costs. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Andrew Haley Date: Monday, March 29, 2021 at 7:46 AM To: Roland Westrelin , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining On 3/29/21 12:03 PM, Roland Westrelin wrote: > >> Okay. Will you review this, please? And please consider the likely >> performance gain v.s churn and risk. > > I reviewed it. I think we would need to know what motivates the > backport to make a judgement. OK, thanks. Over to you, Dan. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Tue Apr 6 18:51:25 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 6 Apr 2021 18:51:25 +0000 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining In-Reply-To: <7AC4CB7A-B8EE-4C29-80AC-0AEA23DB89C5@amazon.com> References: <7AC4CB7A-B8EE-4C29-80AC-0AEA23DB89C5@amazon.com> Message-ID: <71F29E65-197A-42A7-915B-E1A17AA1FBB2@amazon.com> It's also been in Corretto (our public distro) since 11.0.9. ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Tuesday, April 6, 2021 at 11:31 AM To: Andrew Haley , Roland Westrelin , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining Hi, Andrew, We backported this patch because we noticed increased compilation overhead after we increased MaxInlineDepth to 15. We've been running with it (and the follow-on patches) in production starting with 11.0.9 (last October) with no issues. At our scale, even relatively small improvements help reduce fleet costs. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of Andrew Haley Date: Monday, March 29, 2021 at 7:46 AM To: Roland Westrelin , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining On 3/29/21 12:03 PM, Roland Westrelin wrote: > >> Okay. Will you review this, please? And please consider the likely >> performance gain v.s churn and risk. > > I reviewed it. I think we would need to know what motivates the > backport to make a judgement. OK, thanks. Over to you, Dan. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From snazarki at openjdk.java.net Tue Apr 6 19:12:59 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Tue, 6 Apr 2021 19:12:59 GMT Subject: [jdk13u-dev] RFR: 8261585: Restore HandleArea used in Deoptimization::uncommon_trap Message-ID: <22I42Un6A20waaHYC5rN9TpjATR1MuVr79pf8KPANSY=.2c951313-eca3-4c2f-b79e-8b1acac536af@github.com> Low risk minor patch required for parity with odjk11. Applies cleanly. Get RuntimeException from newly added UncommonTrapLeak.java:45 without the patch, pass the test with the patch. ------------- Commit messages: - Baclport 95d73129ce5074d3510710e7e238761a9af9ef3a Changes: https://git.openjdk.java.net/jdk13u-dev/pull/171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=171&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261585 Stats: 64 lines in 2 files changed: 64 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/171.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/171/head:pull/171 PR: https://git.openjdk.java.net/jdk13u-dev/pull/171 From zgu at redhat.com Tue Apr 6 19:52:44 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 6 Apr 2021 15:52:44 -0400 Subject: [11u] RFR 8262739: String inflation C2 intrinsic prevents insertion of anti-dependencies Message-ID: <70d5e48b-7628-60d3-c698-a4e6ba4c5b34@redhat.com> I would like to backport this patch to 11u for parity with Oracle 11.0.12-oracle. The original bug: https://bugs.openjdk.java.net/browse/JDK-8262739 The original patch: https://github.com/openjdk/jdk/commit/3caea470 The original patch does not apply cleanly, due to slight different context with 11u, as it does not have "!strcmp(_matrule->_rChild->_opType,"VectorMaskGen")||" line in formssel.cpp. 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8262739-11u/webrev.00/ Test: Passed new test in patch. Thanks, -Zhengyu From denghui.ddh at alibaba-inc.com Wed Apr 7 07:44:47 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 07 Apr 2021 15:44:47 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlIgODI2NDgxNjogV2VhayBoYW5kbGVzIGxlYWsgY2F1c2VzIEdDIHRvIHRha2Ug?= =?UTF-8?B?bG9uZ2Vy?= Message-ID: <07897f72-21fe-45da-846a-3d5cdf088d32.denghui.ddh@alibaba-inc.com> Hi, Could I have a review of this small fix that solve the weak handles leak problem that exists in MembernameTable. JBS: https://bugs.openjdk.java.net/browse/JDK-8264816 webrev: http://cr.openjdk.java.net/~ddong/8264816/webrev.00 Testing: Linux x86_64 jdk/test/java/lang/invoke Other information: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013618.html Thanks, Denghui From sgehwolf at redhat.com Wed Apr 7 08:43:44 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 07 Apr 2021 10:43:44 +0200 Subject: [11u] RFR 8263558: Possible NULL dereference in fast path arena free if ZapResourceArea is true In-Reply-To: References: Message-ID: <7863864387a8661466b4afacd21af055e53ebb67.camel@redhat.com> Hi Zhengyu, On Tue, 2021-04-06 at 14:01 -0400, Zhengyu Gu wrote: > I would like to backport this patch to 11u for parity with Oracle > 11.0.12-oracle. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8263558 > The original patch: https://github.com/openjdk/jdk/commit/d2c137d4 > > The original patch does not apply cleanly. The conflict is due to > JDK-8195100 [1], which changed Afree() method signature. > > diff -r 490ba2d4ad94 src/hotspot/share/memory/arena.hpp > --- a/src/hotspot/share/memory/arena.hpp??????? Sat Mar 20 09:06:53 > 2021 > +0000 > +++ b/src/hotspot/share/memory/arena.hpp??????? Tue Apr 06 13:53:44 > 2021 > -0400 > @@ -201,7 +201,7 @@ > ??? // Fast delete in area.? Common case is: NOP (except for storage > reclaimed) > ??? void Afree(void *ptr, size_t size) { > ????? if (ptr == NULL) { > -????? return true; // as with free(3), freeing NULL is a noop. > +????? return; // as with free(3), freeing NULL is a noop. > ????? } > > > 11u webrev: > http://cr.openjdk.java.net/~zgu/JDK-8263558-11u/webrev.00/ Looks fine to me. Thanks, Severin From yan at openjdk.java.net Wed Apr 7 09:30:19 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 7 Apr 2021 09:30:19 GMT Subject: [jdk15u-dev] Integrated: 8251549: Update docs on building for Git In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 15:12:10 GMT, Yuri Nesterenko wrote: > jdk15u is in process of migrating to Git (jdk15u-dev is already there), so we would need a variant of this document in 15u, too. > This exact patch applies clean. > Yes, clean with some chunks shifted the uniform 42 lines. These lines, it seems to me, belong mostly to updates JDK-8256182 and JDK-8247591 and are irrelevant to this task. > > I have plan for making building.html as a separate task -- a backport of JDK-8257224 if possible but maybe not. This pull request has now been integrated. Changeset: 6cf1c0dc Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/6cf1c0dc Stats: 68 lines in 1 file changed: 12 ins; 37 del; 19 mod 8251549: Update docs on building for Git Backport-of: 042734cc5b17302a8f2ecdf577511bd6d5ec5e22 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/18 From yan at openjdk.java.net Wed Apr 7 11:09:36 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 7 Apr 2021 11:09:36 GMT Subject: [jdk15u-dev] RFR: 8264823: Update building.html document for Git in jdk15u Message-ID: <6PJbNlKkkoawa1O9Cm6Ktu7brctbUnMBIKSYjUZI3Vg=.6da5ba26-5fe0-464a-8b0a-a680b2867234@github.com> To generate this HTML version of .md original, we had to install locally Pandoc v. 2.3.1 using make/devkit/createPandocBundle.sh, configure with PANDOC=path-to-pandoc-executable flag remove building.html and make update-build-docs New version has only necessary changes for Git transition, I think. See also a backport of JDK-8251549. ------------- Commit messages: - 8264823: Update building.html document for Git in jdk15u Changes: https://git.openjdk.java.net/jdk15u-dev/pull/19/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=19&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264823 Stats: 39 lines in 1 file changed: 4 ins; 23 del; 12 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/19/head:pull/19 PR: https://git.openjdk.java.net/jdk15u-dev/pull/19 From shade at redhat.com Wed Apr 7 11:10:18 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 7 Apr 2021 13:10:18 +0200 Subject: [11u] RFR (S) 8238175: CTW: Class.getDeclaredMethods fails with assert(k->is_subclass_of(SystemDictionary::Throwable_klass())) failed: invalid exception class In-Reply-To: References: Message-ID: On 4/6/21 5:18 PM, Hohensee, Paul wrote: > Lgtm. Thanks, tagged for approval. -- Thanks, -Aleksey From shade at redhat.com Wed Apr 7 11:11:45 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 7 Apr 2021 13:11:45 +0200 Subject: [11u] RFR (XS) 8262465: Very long compilation times and high memory consumption in C2 debug builds In-Reply-To: References: Message-ID: <22e36e08-e0fa-f3d6-21cd-329ccc93582a@redhat.com> On 4/6/21 5:14 PM, Hohensee, Paul wrote: > The check for (!liveout->is_empty()) comes from https://bugs.openjdk.java.net/browse/JDK-8234003. Backport that first? Not strictly necessary because it's minor optimizations and format changes, but makes the 11u code closer to tip in case of future backports. I would prefer not to backport JDK-8234003. It does not seem worthwhile at this point... -- Thanks, -Aleksey From yan at openjdk.java.net Wed Apr 7 12:00:26 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 7 Apr 2021 12:00:26 GMT Subject: [jdk13u-dev] RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 08:46:33 GMT, Vladimir Kempik wrote: > Backport to jdk13u-dev. > Applies almost clean, few gmk files had different filename and few copyright year issues. > Original commit - https://github.com/VladimirKempik/jdk/commit/4a8b5c1602789e95457cbb080a64c56edaf81051 Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/169 From zgu at redhat.com Wed Apr 7 12:14:52 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 7 Apr 2021 08:14:52 -0400 Subject: [11u] RFR 8263558: Possible NULL dereference in fast path arena free if ZapResourceArea is true In-Reply-To: <7863864387a8661466b4afacd21af055e53ebb67.camel@redhat.com> References: <7863864387a8661466b4afacd21af055e53ebb67.camel@redhat.com> Message-ID: Thanks, Severin. Tagged for an approval. -Zhengyu On 4/7/21 4:43 AM, Severin Gehwolf wrote: > Hi Zhengyu, > > On Tue, 2021-04-06 at 14:01 -0400, Zhengyu Gu wrote: >> I would like to backport this patch to 11u for parity with Oracle >> 11.0.12-oracle. >> >> The original bug: https://bugs.openjdk.java.net/browse/JDK-8263558 >> The original patch: https://github.com/openjdk/jdk/commit/d2c137d4 >> >> The original patch does not apply cleanly. The conflict is due to >> JDK-8195100 [1], which changed Afree() method signature. >> >> diff -r 490ba2d4ad94 src/hotspot/share/memory/arena.hpp >> --- a/src/hotspot/share/memory/arena.hpp??????? Sat Mar 20 09:06:53 >> 2021 >> +0000 >> +++ b/src/hotspot/share/memory/arena.hpp??????? Tue Apr 06 13:53:44 >> 2021 >> -0400 >> @@ -201,7 +201,7 @@ >> ??? // Fast delete in area.? Common case is: NOP (except for storage >> reclaimed) >> ??? void Afree(void *ptr, size_t size) { >> ????? if (ptr == NULL) { >> -????? return true; // as with free(3), freeing NULL is a noop. >> +????? return; // as with free(3), freeing NULL is a noop. >> ????? } >> >> >> 11u webrev: >> http://cr.openjdk.java.net/~zgu/JDK-8263558-11u/webrev.00/ > > Looks fine to me. > > Thanks, > Severin > From vkempik at openjdk.java.net Wed Apr 7 12:19:27 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Wed, 7 Apr 2021 12:19:27 GMT Subject: [jdk13u-dev] Integrated: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 08:46:33 GMT, Vladimir Kempik wrote: > Backport to jdk13u-dev. > Applies almost clean, few gmk files had different filename and few copyright year issues. > Original commit - https://github.com/VladimirKempik/jdk/commit/4a8b5c1602789e95457cbb080a64c56edaf81051 This pull request has now been integrated. Changeset: 9d0d73e9 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/9d0d73e9 Stats: 805 lines in 12 files changed: 369 ins; 317 del; 119 mod 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m 8257860: [macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m Reviewed-by: yan Backport-of: 4a8b5c1602789e95457cbb080a64c56edaf81051 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/169 From snazarki at openjdk.java.net Wed Apr 7 12:25:29 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 7 Apr 2021 12:25:29 GMT Subject: [jdk13u-dev] Integrated: 8261585: Restore HandleArea used in Deoptimization::uncommon_trap In-Reply-To: <22I42Un6A20waaHYC5rN9TpjATR1MuVr79pf8KPANSY=.2c951313-eca3-4c2f-b79e-8b1acac536af@github.com> References: <22I42Un6A20waaHYC5rN9TpjATR1MuVr79pf8KPANSY=.2c951313-eca3-4c2f-b79e-8b1acac536af@github.com> Message-ID: On Tue, 6 Apr 2021 18:59:15 GMT, Sergey Nazarkin wrote: > Low risk minor patch required for parity with odjk11. Applies cleanly. Get RuntimeException from newly added UncommonTrapLeak.java:45 without the patch, pass the test with the patch. This pull request has now been integrated. Changeset: 4d5f2ab4 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/4d5f2ab4 Stats: 64 lines in 2 files changed: 64 ins; 0 del; 0 mod 8261585: Restore HandleArea used in Deoptimization::uncommon_trap Backport-of: 95d73129ce5074d3510710e7e238761a9af9ef3a ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/171 From vkempik at openjdk.java.net Wed Apr 7 12:35:04 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Wed, 7 Apr 2021 12:35:04 GMT Subject: [jdk13u-dev] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Message-ID: Clean backport from 15u-dev to 13u-dev. Backport from 17 to 15 wasn't clean, review - https://github.com/openjdk/jdk15u-dev/pull/8 ------------- Commit messages: - Backport e2453498fb336430a80bdb38559942e3292cf18a Changes: https://git.openjdk.java.net/jdk13u-dev/pull/172/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=172&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240487 Stats: 183 lines in 21 files changed: 0 ins; 0 del; 183 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/172/head:pull/172 PR: https://git.openjdk.java.net/jdk13u-dev/pull/172 From yan at openjdk.java.net Wed Apr 7 12:35:04 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 7 Apr 2021 12:35:04 GMT Subject: [jdk13u-dev] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 12:22:08 GMT, Vladimir Kempik wrote: > Clean backport from 15u-dev to 13u-dev. > Backport from 17 to 15 wasn't clean, review - https://github.com/openjdk/jdk15u-dev/pull/8 Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/172 From vkempik at openjdk.java.net Wed Apr 7 12:49:19 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Wed, 7 Apr 2021 12:49:19 GMT Subject: [jdk13u-dev] Integrated: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files In-Reply-To: References: Message-ID: <24cziv20l-YZFPy3N8EOQ66YOD7eQuUqFFzvIJy9AkQ=.6ea341e8-7606-48d3-9309-1f4b76c5dbad@github.com> On Wed, 7 Apr 2021 12:22:08 GMT, Vladimir Kempik wrote: > Clean backport from 15u-dev to 13u-dev. > Backport from 17 to 15 wasn't clean, review - https://github.com/openjdk/jdk15u-dev/pull/8 This pull request has now been integrated. Changeset: 98baf882 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/98baf882 Stats: 183 lines in 21 files changed: 0 ins; 0 del; 183 mod 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Reviewed-by: yan Backport-of: c32923e06fc94c2a2ad8b9dd803aad1ed5386505 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/172 From shade at openjdk.java.net Wed Apr 7 13:04:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 7 Apr 2021 13:04:52 GMT Subject: [jdk16u] Integrated: 8264374: Shenandoah: Remove leftover parallel reference processing argument In-Reply-To: References: Message-ID: <6Gav34eROXjJEWReLOCi5lO_6j4dzeDDlcewvD3UzDQ=.26397b77-83cf-41f7-9eea-e1981115610b@github.com> On Thu, 1 Apr 2021 09:29:11 GMT, Aleksey Shipilev wrote: > After JDK-8254315, Shenandoah no longer uses upstream weak reference processor, it should remove related ParallelRefProcEnabled setting. This pull request has now been integrated. Changeset: 048040fe Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/048040fe Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8264374: Shenandoah: Remove leftover parallel reference processing argument Backport-of: ac604a18c92d9d21ea5b5b14fea512642d33764f ------------- PR: https://git.openjdk.java.net/jdk16u/pull/100 From vkempik at openjdk.java.net Wed Apr 7 13:06:07 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Wed, 7 Apr 2021 13:06:07 GMT Subject: [jdk13u-dev] RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code Message-ID: Clean backport from 15u-dev to 13u-dev. review of backrot from 17 to 15 - https://github.com/openjdk/jdk15u-dev/pull/9 ------------- Commit messages: - Backport 2798c72822dae92884fb305c1f74bbe5f22d3e18 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/173/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=173&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257853 Stats: 1595 lines in 35 files changed: 859 ins; 194 del; 542 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/173/head:pull/173 PR: https://git.openjdk.java.net/jdk13u-dev/pull/173 From rwestrel at redhat.com Wed Apr 7 13:32:46 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 07 Apr 2021 15:32:46 +0200 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining In-Reply-To: <7AC4CB7A-B8EE-4C29-80AC-0AEA23DB89C5@amazon.com> References: <7AC4CB7A-B8EE-4C29-80AC-0AEA23DB89C5@amazon.com> Message-ID: <877dlep6dd.fsf@redhat.com> > We backported this patch because we noticed increased compilation > overhead after we increased MaxInlineDepth to 15. We've been running > with it (and the follow-on patches) in production starting with 11.0.9 > (last October) with no issues. At our scale, even relatively small > improvements help reduce fleet costs. FWIW, backporting the patch seems reasonable to me. Roland. From rwestrel at redhat.com Wed Apr 7 13:33:38 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 07 Apr 2021 15:33:38 +0200 Subject: [11u] RFR 8262739: String inflation C2 intrinsic prevents insertion of anti-dependencies In-Reply-To: <70d5e48b-7628-60d3-c698-a4e6ba4c5b34@redhat.com> References: <70d5e48b-7628-60d3-c698-a4e6ba4c5b34@redhat.com> Message-ID: <874kgip6bx.fsf@redhat.com> > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8262739-11u/webrev.00/ Looks good to me. Roland. From zgu at redhat.com Wed Apr 7 13:37:44 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 7 Apr 2021 09:37:44 -0400 Subject: [11u] RFR 8262739: String inflation C2 intrinsic prevents insertion of anti-dependencies In-Reply-To: <874kgip6bx.fsf@redhat.com> References: <70d5e48b-7628-60d3-c698-a4e6ba4c5b34@redhat.com> <874kgip6bx.fsf@redhat.com> Message-ID: <1b7bd78f-b4e4-cf93-f246-7ba2117e41ba@redhat.com> Thanks, Roland. -Zhengyu On 4/7/21 9:33 AM, Roland Westrelin wrote: > >> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8262739-11u/webrev.00/ > > Looks good to me. > > Roland. > From yan at openjdk.java.net Wed Apr 7 15:27:58 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 7 Apr 2021 15:27:58 GMT Subject: [jdk13u-dev] RFR: 8251549: Update docs on building for Git Message-ID: It is long overdue update for jdk13u. Patch of original JDK-8251549 applies clean. In addition, I'm putting in the same jdk13u commit also building.html generated from the updated version of building.md. ------------- Commit messages: - Backport 042734cc5b17302a8f2ecdf577511bd6d5ec5e22 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/174/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=174&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251549 Stats: 108 lines in 2 files changed: 16 ins; 61 del; 31 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/174/head:pull/174 PR: https://git.openjdk.java.net/jdk13u-dev/pull/174 From zgu at redhat.com Wed Apr 7 15:41:19 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 7 Apr 2021 11:41:19 -0400 Subject: [11u] RFR 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION Message-ID: I would like to backport this patch to 11u for parity with Oracle 11.0.12-oracle. The original bug: https://bugs.openjdk.java.net/browse/JDK-8261262 The original patch: https://github.com/openjdk/jdk/commit/7b9d2562 The original patch does not apply cleanly. 11u still uses VM operation for getting current location, while the original patch uses handshake (via. JDK 8242427) 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8261262-11u/webrev.00/ Test: vmTestbase_nsk_jvmti Thanks, -Zhengyu From martin.doerr at sap.com Wed Apr 7 16:10:00 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Apr 2021 16:10:00 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Message-ID: Hi, JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. I've taken the 13u backport as source because it resolves the wrong backport order with JDK-8242141. Bug: https://bugs.openjdk.java.net/browse/JDK-8226374 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264555 Original change (JDK14): https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 13u backport: https://github.com/openjdk/jdk13u-dev/commit/384445d2 11u rejected hunks (integrated manually): http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt my new 11u backport: http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ Please review. Best regards, Martin From hohensee at amazon.com Wed Apr 7 16:59:09 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Apr 2021 16:59:09 +0000 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining Message-ID: Thank you, Roland. ?-----Original Message----- From: Roland Westrelin Date: Wednesday, April 7, 2021 at 6:33 AM To: "Hohensee, Paul" , Andrew Haley , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining > We backported this patch because we noticed increased compilation > overhead after we increased MaxInlineDepth to 15. We've been running > with it (and the follow-on patches) in production starting with 11.0.9 > (last October) with no issues. At our scale, even relatively small > improvements help reduce fleet costs. FWIW, backporting the patch seems reasonable to me. Roland. From hohensee at amazon.com Wed Apr 7 17:02:01 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Apr 2021 17:02:01 +0000 Subject: [11u] RFR (XS) 8262465: Very long compilation times and high memory consumption in C2 debug builds Message-ID: <44DEBE79-126E-4B88-AF63-D178C56BED7E@amazon.com> Then lgtm. ?-----Original Message----- From: Aleksey Shipilev Date: Wednesday, April 7, 2021 at 4:12 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR (XS) 8262465: Very long compilation times and high memory consumption in C2 debug builds On 4/6/21 5:14 PM, Hohensee, Paul wrote: > The check for (!liveout->is_empty()) comes from https://bugs.openjdk.java.net/browse/JDK-8234003. Backport that first? Not strictly necessary because it's minor optimizations and format changes, but makes the 11u code closer to tip in case of future backports. I would prefer not to backport JDK-8234003. It does not seem worthwhile at this point... -- Thanks, -Aleksey From hohensee at amazon.com Wed Apr 7 21:41:30 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Apr 2021 21:41:30 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Message-ID: The backport looks fine, except there's a missing blank line after FFDHE_2048 in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be one for the 13u backport: perhaps Yan will add one after the fact). I'm not a security person, so it would be great if someone who is reviews the CSR to see if there are any 11u-specific issues with it. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Doerr, Martin" Date: Wednesday, April 7, 2021 at 9:10 AM To: jdk-updates-dev , security-dev Cc: "Lindenmaier, Goetz" , "Langer, Christoph" Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Hi, JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. I've taken the 13u backport as source because it resolves the wrong backport order with JDK-8242141. Bug: https://bugs.openjdk.java.net/browse/JDK-8226374 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264555 Original change (JDK14): https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 13u backport: https://github.com/openjdk/jdk13u-dev/commit/384445d2 11u rejected hunks (integrated manually): http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt my new 11u backport: http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ Please review. Best regards, Martin From hohensee at amazon.com Wed Apr 7 21:58:53 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Apr 2021 21:58:53 +0000 Subject: ReE: [11u] RFR 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION Message-ID: <0110ABED-41E7-4F31-8DEE-2ED6E409726E@amazon.com> Copyright date needs an update to 2021, otherwise lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Zhengyu Gu Date: Wednesday, April 7, 2021 at 8:41 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION I would like to backport this patch to 11u for parity with Oracle 11.0.12-oracle. The original bug: https://bugs.openjdk.java.net/browse/JDK-8261262 The original patch: https://github.com/openjdk/jdk/commit/7b9d2562 The original patch does not apply cleanly. 11u still uses VM operation for getting current location, while the original patch uses handshake (via. JDK 8242427) 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8261262-11u/webrev.00/ Test: vmTestbase_nsk_jvmti Thanks, -Zhengyu From christoph.langer at sap.com Wed Apr 7 22:15:43 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 7 Apr 2021 22:15:43 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups In-Reply-To: References: Message-ID: Hi Paul, thanks for the review. The CSR that Martin mentions is the one that Oracle has filed for 11.0.12-oracle. so we can simply reuse it. As for 13, there exists a CSR as well: JDK-8256335 Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Mittwoch, 7. April 2021 23:42 > To: Doerr, Martin ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > The backport looks fine, except there's a missing blank line after FFDHE_2048 > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be one > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > security person, so it would be great if someone who is reviews the CSR to > see if there are any 11u-specific issues with it. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Wednesday, April 7, 2021 at 9:10 AM > To: jdk-updates-dev , security-dev > > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi, > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. > It doesn't apply cleanly. I've taken the 13u backport as source because it > resolves the wrong backport order with JDK-8242141. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8226374 > > 11u CSR: > https://bugs.openjdk.java.net/browse/JDK-8264555 > > Original change (JDK14): > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > 13u backport: > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > 11u rejected hunks (integrated manually): > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > my new 11u backport: > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From hohensee at amazon.com Wed Apr 7 23:00:36 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Apr 2021 23:00:36 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Message-ID: Hmm, could have sworn... Thanks, Paul ?-----Original Message----- From: "Langer, Christoph" Date: Wednesday, April 7, 2021 at 3:16 PM To: "Hohensee, Paul" , "Doerr, Martin" , jdk-updates-dev , security-dev Cc: "Lindenmaier, Goetz" Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Hi Paul, thanks for the review. The CSR that Martin mentions is the one that Oracle has filed for 11.0.12-oracle. so we can simply reuse it. As for 13, there exists a CSR as well: JDK-8256335 Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Mittwoch, 7. April 2021 23:42 > To: Doerr, Martin ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > The backport looks fine, except there's a missing blank line after FFDHE_2048 > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be one > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > security person, so it would be great if someone who is reviews the CSR to > see if there are any 11u-specific issues with it. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Wednesday, April 7, 2021 at 9:10 AM > To: jdk-updates-dev , security-dev > > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi, > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. > It doesn't apply cleanly. I've taken the 13u backport as source because it > resolves the wrong backport order with JDK-8242141. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8226374 > > 11u CSR: > https://bugs.openjdk.java.net/browse/JDK-8264555 > > Original change (JDK14): > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > 13u backport: > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > 11u rejected hunks (integrated manually): > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > my new 11u backport: > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From hohensee at amazon.com Wed Apr 7 23:42:42 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Apr 2021 23:42:42 +0000 Subject: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls Message-ID: <87211FF1-854A-444C-8B0A-7B622F68ADDA@amazon.com> Lgtm. The Oracle arm64 port was removed in JDK 12 in favor of the Red Hat aarch64 port, and afaik has not been maintained since. Imo it's not worth the effort to either keep it building or remove it from 11u. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Christoph G?ttschkes Date: Tuesday, April 6, 2021 at 12:21 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls Gentle reminder. On 3/23/21 9:49 AM, Christoph G?ttschkes wrote: > Hi, > > please review this backport of JDK-8213845 to 11u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/2d795829f39f > > Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.00/ > > This patch fixes the conversion between C and Java boolean types, which value is > not 0 or 1 in C on aarch32. This also fixes the test case > "runtime/BoolReturn/JNIBooleanTest.java", which is testing this conversion. > > The backport is not clean, because in 11u, the arm64 CPU type is still present. > Adjusting the backport was fairly straight forward. Because of the arm64 CPU type, > there are some additional #ifdef present and the changes had to be incoporated > into the arm64 port as well. No additional changes have been made, only slight > adjustments. > > I am not able to test the arm64 port, since it doesn't compile anymore and I don't > know if this CPU type is still supported, or if the code remains there because it > is deemed to complicated to remove it. > > Tested: > * Hotspot tier1 on linux aarch32 > * Hotspot tier1 on linux aarch32 with -XX:+VerifyOops and -Xcheck:jni > * Hotspot tier1 on linux ARMv7-A > > Thanks, > Christoph > From christoph.goettschkes at microdoc.com Thu Apr 8 07:39:38 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Thu, 8 Apr 2021 09:39:38 +0200 Subject: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls In-Reply-To: <87211FF1-854A-444C-8B0A-7B622F68ADDA@amazon.com> References: <87211FF1-854A-444C-8B0A-7B622F68ADDA@amazon.com> Message-ID: <37sqpewurp-1@aserp2020.oracle.com> Thanks for the review and the explanation, Paul. I knew, that it has been removed, but didn't know the state of it in 11u. I will ignore it then as well. -- Christoph On 4/8/21 1:42 AM, Hohensee, Paul wrote: > Lgtm. The Oracle arm64 port was removed in JDK 12 in favor of the Red Hat aarch64 port, and afaik has not been maintained since. Imo it's not worth the effort to either keep it building or remove it from 11u. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Christoph G?ttschkes > Date: Tuesday, April 6, 2021 at 12:21 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: RE: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls > > Gentle reminder. > > On 3/23/21 9:49 AM, Christoph G?ttschkes wrote: >> Hi, >> >> please review this backport of JDK-8213845 to 11u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 >> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/2d795829f39f >> >> Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.00/ >> >> This patch fixes the conversion between C and Java boolean types, which value is >> not 0 or 1 in C on aarch32. This also fixes the test case >> "runtime/BoolReturn/JNIBooleanTest.java", which is testing this conversion. >> >> The backport is not clean, because in 11u, the arm64 CPU type is still present. >> Adjusting the backport was fairly straight forward. Because of the arm64 CPU type, >> there are some additional #ifdef present and the changes had to be incoporated >> into the arm64 port as well. No additional changes have been made, only slight >> adjustments. >> >> I am not able to test the arm64 port, since it doesn't compile anymore and I don't >> know if this CPU type is still supported, or if the code remains there because it >> is deemed to complicated to remove it. >> >> Tested: >> * Hotspot tier1 on linux aarch32 >> * Hotspot tier1 on linux aarch32 with -XX:+VerifyOops and -Xcheck:jni >> * Hotspot tier1 on linux ARMv7-A >> >> Thanks, >> Christoph >> > > From yan at openjdk.java.net Thu Apr 8 07:59:54 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 8 Apr 2021 07:59:54 GMT Subject: [jdk13u-dev] RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code In-Reply-To: References: Message-ID: <713A3Moi8Vxl4NLyfXzo80nDMfmC9vHz2ChItRl3zWM=.58ebe284-6fc2-4f37-acc2-60720dfe9104@github.com> On Wed, 7 Apr 2021 12:53:42 GMT, Vladimir Kempik wrote: > Clean backport from 15u-dev to 13u-dev. review of backrot from 17 to 15 - https://github.com/openjdk/jdk15u-dev/pull/9 Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/173 From vkempik at openjdk.java.net Thu Apr 8 08:14:22 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 08:14:22 GMT Subject: [jdk13u-dev] Integrated: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 12:53:42 GMT, Vladimir Kempik wrote: > Clean backport from 15u-dev to 13u-dev. review of backrot from 17 to 15 - https://github.com/openjdk/jdk15u-dev/pull/9 This pull request has now been integrated. Changeset: ad45c982 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/ad45c982 Stats: 1595 lines in 35 files changed: 859 ins; 194 del; 542 mod 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code Reviewed-by: yan Backport-of: fa50877c2e86d1a4e00724dd29d934f52d51f42c ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/173 From rrich at openjdk.java.net Thu Apr 8 08:14:30 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 8 Apr 2021 08:14:30 GMT Subject: [jdk16u] RFR: 8262295: C2: Out-of-Bounds Array Load from Clone Source Message-ID: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> This is the jdk16u backport of the fix for JDK-8262295. The fix applies cleanly. The test required trivial adaptation: I had to remove the package from the class ClassFileInstaller. ------------- Commit messages: - Remove package from ClassFileInstaller in regression test. - Backport 9689863ac0bac8c542162d4af30fec078e9c91b4 Changes: https://git.openjdk.java.net/jdk16u/pull/101/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=101&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262295 Stats: 120 lines in 2 files changed: 119 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/101.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/101/head:pull/101 PR: https://git.openjdk.java.net/jdk16u/pull/101 From clanger at openjdk.java.net Thu Apr 8 08:14:31 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 8 Apr 2021 08:14:31 GMT Subject: [jdk16u] RFR: 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> References: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> Message-ID: On Thu, 1 Apr 2021 11:07:44 GMT, Richard Reingruber wrote: > This is the jdk16u backport of the fix for JDK-8262295. > The fix applies cleanly. > The test required trivial adaptation: I had to remove the package from the class ClassFileInstaller. Hi Rich, I had issues with non clean backports as well... To get this accepted by the bots, try to set the PR title to "Backport of 9689863ac0bac8c542162d4af30fec078e9c91b4". If that doesn't help, you need to manipulate your git commit message that way... ------------- PR: https://git.openjdk.java.net/jdk16u/pull/101 From rrich at openjdk.java.net Thu Apr 8 08:14:31 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 8 Apr 2021 08:14:31 GMT Subject: [jdk16u] RFR: 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: References: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> Message-ID: On Thu, 1 Apr 2021 11:25:27 GMT, Christoph Langer wrote: > > Hi Rich, I had issues with non clean backports as well... Hi Christoph, I wasn't even aware that there are still issues (besides the message "Issue is not open"). > To get this accepted by the bots, try to set the PR title to "Backport of 9689863ac0bac8c542162d4af30fec078e9c91b4". I've done that now. jcheck complained about the _commit_ message. Now I changed the title back again to : jcheck succeeds with this. Do you still see issues? > If that doesn't help, you need to manipulate your git commit message that way... ------------- PR: https://git.openjdk.java.net/jdk16u/pull/101 From clanger at openjdk.java.net Thu Apr 8 08:14:31 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 8 Apr 2021 08:14:31 GMT Subject: [jdk16u] RFR: 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: References: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> Message-ID: On Thu, 1 Apr 2021 11:35:18 GMT, Richard Reingruber wrote: >> Hi Rich, I had issues with non clean backports as well... >> >> To get this accepted by the bots, try to set the PR title to "Backport of 9689863ac0bac8c542162d4af30fec078e9c91b4". >> >> If that doesn't help, you need to manipulate your git commit message that way... > >> >> Hi Rich, I had issues with non clean backports as well... > > Hi Christoph, > I wasn't even aware that there are still issues (besides the message "Issue is not open"). > >> To get this accepted by the bots, try to set the PR title to "Backport of 9689863ac0bac8c542162d4af30fec078e9c91b4". > > I've done that now. jcheck complained about the _commit_ message. > > Now I changed the title back again to : > jcheck succeeds with this. Do you still see issues? > >> If that doesn't help, you need to manipulate your git commit message that way... > > Hi Rich, I had issues with non clean backports as well... > > Hi Christoph, > I wasn't even aware that there are still issues (besides the message "Issue is not open"). > > > To get this accepted by the bots, try to set the PR title to "Backport of 9689863ac0bac8c542162d4af30fec078e9c91b4". > > I've done that now. jcheck complained about the _commit_ message. > > Now I changed the title back again to : > jcheck succeeds with this. Do you still see issues? > > > If that doesn't help, you need to manipulate your git commit message that way... Ah, I didn't see that the PR was still in draft. Let's see what happens when you open it... ------------- PR: https://git.openjdk.java.net/jdk16u/pull/101 From martin.doerr at sap.com Thu Apr 8 09:52:29 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 8 Apr 2021 09:52:29 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups In-Reply-To: References: Message-ID: Hi Paul and Christoph, thank you for the review and the approval. I've added the blank line. In addition, I've reviewed the whole change again and found a copy & paste bug in my webrev.00: SECT283_K1(0x0009, "sect283k1", true, NamedGroupSpec.NAMED_GROUP_ECDHE, ProtocolVersion.PROTOCOLS_TO_12, - CurveDB.lookup("sect163k1")), + CurveDB.lookup("sect283k1")), This is the version I'm planning to push: http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.01/ Tests have passed. Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 8. April 2021 01:01 > To: Langer, Christoph ; Doerr, Martin > ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hmm, could have sworn... > > Thanks, > Paul > > ?-----Original Message----- > From: "Langer, Christoph" > Date: Wednesday, April 7, 2021 at 3:16 PM > To: "Hohensee, Paul" , "Doerr, Martin" > , jdk-updates-dev dev at openjdk.java.net>, security-dev > Cc: "Lindenmaier, Goetz" > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi Paul, > > thanks for the review. The CSR that Martin mentions is the one that Oracle > has filed for 11.0.12-oracle. so we can simply reuse it. > > As for 13, there exists a CSR as well: JDK-8256335 > > Best regards > Christoph > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Mittwoch, 7. April 2021 23:42 > > To: Doerr, Martin ; jdk-updates-dev updates- > > dev at openjdk.java.net>; security-dev > > Cc: Lindenmaier, Goetz ; Langer, Christoph > > > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > The backport looks fine, except there's a missing blank line after > FFDHE_2048 > > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be > one > > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > > security person, so it would be great if someone who is reviews the CSR to > > see if there are any 11u-specific issues with it. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on > > behalf of "Doerr, Martin" > > Date: Wednesday, April 7, 2021 at 9:10 AM > > To: jdk-updates-dev , security-dev > > > > Cc: "Lindenmaier, Goetz" , "Langer, > > Christoph" > > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > Hi, > > > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. > > It doesn't apply cleanly. I've taken the 13u backport as source because it > > resolves the wrong backport order with JDK-8242141. > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8226374 > > > > 11u CSR: > > https://bugs.openjdk.java.net/browse/JDK-8264555 > > > > Original change (JDK14): > > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > > > 13u backport: > > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > > > 11u rejected hunks (integrated manually): > > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > > > my new 11u backport: > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > > > Please review. > > > > Best regards, > > Martin > > > From vkempik at openjdk.java.net Thu Apr 8 11:15:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 11:15:47 GMT Subject: [jdk13u-dev] RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. Message-ID: clean backport from jdk15 to jdk13, only gmk file needed to be renamed. not a clean backport from 17 to 13. jdk15u review - https://github.com/openjdk/jdk15u-dev/pull/10 ------------- Commit messages: - 8259343: [macOS] Update JNI error handling in Cocoa code. Changes: https://git.openjdk.java.net/jdk13u-dev/pull/175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=175&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259343 Stats: 75 lines in 8 files changed: 60 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/175.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/175/head:pull/175 PR: https://git.openjdk.java.net/jdk13u-dev/pull/175 From yan at openjdk.java.net Thu Apr 8 11:34:14 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 8 Apr 2021 11:34:14 GMT Subject: [jdk13u-dev] RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 11:09:36 GMT, Vladimir Kempik wrote: > clean backport from jdk15 to jdk13, only gmk file needed to be renamed. > > not a clean backport from 17 to 13. > > jdk15u review - https://github.com/openjdk/jdk15u-dev/pull/10 Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/175 From vkempik at openjdk.java.net Thu Apr 8 11:45:33 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 11:45:33 GMT Subject: [jdk13u-dev] Integrated: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 11:09:36 GMT, Vladimir Kempik wrote: > clean backport from jdk15 to jdk13, only gmk file needed to be renamed. > > not a clean backport from 17 to 13. > > jdk15u review - https://github.com/openjdk/jdk15u-dev/pull/10 This pull request has now been integrated. Changeset: cdb993e9 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/cdb993e9 Stats: 75 lines in 8 files changed: 60 ins; 1 del; 14 mod 8259343: [macOS] Update JNI error handling in Cocoa code. Reviewed-by: yan Backport-of: d6a2105b5c9b44c04cac7385756ec9924c1310ab ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/175 From vkempik at openjdk.java.net Thu Apr 8 11:58:35 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 11:58:35 GMT Subject: [jdk13u-dev] RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Message-ID: Almost clean backport from 15 to 13 (it was clean from 17 to 15). no getMultiClickTime on jdk13,so removed part of patch. context code difference in CGLGraphicsConfig.m ------------- Commit messages: - 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Changes: https://git.openjdk.java.net/jdk13u-dev/pull/176/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=176&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259651 Stats: 602 lines in 48 files changed: 56 ins; 17 del; 529 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/176.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/176/head:pull/176 PR: https://git.openjdk.java.net/jdk13u-dev/pull/176 From yan at openjdk.java.net Thu Apr 8 12:03:11 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 8 Apr 2021 12:03:11 GMT Subject: [jdk13u-dev] RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 11:52:08 GMT, Vladimir Kempik wrote: > Almost clean backport from 15 to 13 (it was clean from 17 to 15). > no getMultiClickTime on jdk13,so removed part of patch. context code difference in CGLGraphicsConfig.m Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/176 From vkempik at openjdk.java.net Thu Apr 8 12:09:28 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 12:09:28 GMT Subject: [jdk13u-dev] Integrated: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 11:52:08 GMT, Vladimir Kempik wrote: > Almost clean backport from 15 to 13 (it was clean from 17 to 15). > no getMultiClickTime on jdk13,so removed part of patch. context code difference in CGLGraphicsConfig.m This pull request has now been integrated. Changeset: 47ec3b80 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/47ec3b80 Stats: 602 lines in 48 files changed: 56 ins; 17 del; 529 mod 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Reviewed-by: yan Backport-of: 5855d52a2a670a49b7a968fd58404b5d1836a8e1 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/176 From vkempik at openjdk.java.net Thu Apr 8 12:15:39 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 12:15:39 GMT Subject: [jdk13u-dev] RFR: 8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs Message-ID: <6-6dag5-Tv0W3Ue4srCBgcYsezzOrzOBul4xIKKqHlM=.bcc548be-dc83-4e76-986c-2450e56fac13@github.com> backport to jdk13u-dev, part of JNF removal patches, applies cleanly ------------- Commit messages: - Backport 92c2f084a2d1eb4475ebce6c9c08312e5c4aea5e Changes: https://git.openjdk.java.net/jdk13u-dev/pull/177/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=177&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259869 Stats: 153 lines in 21 files changed: 19 ins; 7 del; 127 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/177.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/177/head:pull/177 PR: https://git.openjdk.java.net/jdk13u-dev/pull/177 From vkempik at openjdk.java.net Thu Apr 8 12:26:17 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 12:26:17 GMT Subject: [jdk13u-dev] Integrated: 8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs In-Reply-To: <6-6dag5-Tv0W3Ue4srCBgcYsezzOrzOBul4xIKKqHlM=.bcc548be-dc83-4e76-986c-2450e56fac13@github.com> References: <6-6dag5-Tv0W3Ue4srCBgcYsezzOrzOBul4xIKKqHlM=.bcc548be-dc83-4e76-986c-2450e56fac13@github.com> Message-ID: <2Ey5YAnDK34TK2FocKNEZMwIj9GlBYFPpJz1AdDibOM=.7d004268-36fd-4df4-a90e-ca5d905c7fd3@github.com> On Thu, 8 Apr 2021 12:08:29 GMT, Vladimir Kempik wrote: > backport to jdk13u-dev, part of JNF removal patches, applies cleanly This pull request has now been integrated. Changeset: df2818b9 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/df2818b9 Stats: 153 lines in 21 files changed: 19 ins; 7 del; 127 mod 8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs Backport-of: 92c2f084a2d1eb4475ebce6c9c08312e5c4aea5e ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/177 From vkempik at openjdk.java.net Thu Apr 8 12:36:42 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 12:36:42 GMT Subject: [jdk13u-dev] RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module Message-ID: not a clean backport from 15u to 13u. main points: some context code differences getMultiClickTime missing on jdk13 white space patches in CGLGraphicsConfig.m not needed in 13 ------------- Commit messages: - 8260616: Removing remaining JNF dependencies in the java.desktop module Changes: https://git.openjdk.java.net/jdk13u-dev/pull/178/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=178&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260616 Stats: 569 lines in 73 files changed: 241 ins; 98 del; 230 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/178.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/178/head:pull/178 PR: https://git.openjdk.java.net/jdk13u-dev/pull/178 From yan at openjdk.java.net Thu Apr 8 12:42:19 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 8 Apr 2021 12:42:19 GMT Subject: [jdk13u-dev] RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 12:30:28 GMT, Vladimir Kempik wrote: > not a clean backport from 15u to 13u. main points: > > some context code differences > getMultiClickTime missing on jdk13 > white space patches in CGLGraphicsConfig.m not needed in 13 Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/178 From vkempik at openjdk.java.net Thu Apr 8 12:50:11 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 12:50:11 GMT Subject: [jdk13u-dev] Integrated: 8260616: Removing remaining JNF dependencies in the java.desktop module In-Reply-To: References: Message-ID: <-0XgQhn_1t9i3UMLBrCLuxb-EHUDk5kj0JG7UHDI5sA=.f8fab74b-a663-4bed-bfd1-0ea734c6f269@github.com> On Thu, 8 Apr 2021 12:30:28 GMT, Vladimir Kempik wrote: > not a clean backport from 15u to 13u. main points: > > some context code differences > getMultiClickTime missing on jdk13 > white space patches in CGLGraphicsConfig.m not needed in 13 This pull request has now been integrated. Changeset: 2e9b3a09 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/2e9b3a09 Stats: 569 lines in 73 files changed: 241 ins; 98 del; 230 mod 8260616: Removing remaining JNF dependencies in the java.desktop module Reviewed-by: yan Backport-of: 8760688d213865eaf1bd675056eb809cdae67048 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/178 From vkempik at openjdk.java.net Thu Apr 8 12:56:41 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 12:56:41 GMT Subject: [jdk13u-dev] RFR: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m Message-ID: Almost clean backport from 15u to 13u ( 17 to 15u was clean) one gmk file renaming and context code difference ------------- Commit messages: - 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m Changes: https://git.openjdk.java.net/jdk13u-dev/pull/179/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=179&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257988 Stats: 45 lines in 2 files changed: 35 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/179.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/179/head:pull/179 PR: https://git.openjdk.java.net/jdk13u-dev/pull/179 From yan at openjdk.java.net Thu Apr 8 13:02:15 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 8 Apr 2021 13:02:15 GMT Subject: [jdk13u-dev] RFR: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 12:51:52 GMT, Vladimir Kempik wrote: > Almost clean backport from 15u to 13u ( 17 to 15u was clean) > one gmk file renaming and context code difference Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/179 From vkempik at openjdk.java.net Thu Apr 8 13:14:27 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 8 Apr 2021 13:14:27 GMT Subject: [jdk13u-dev] Integrated: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 12:51:52 GMT, Vladimir Kempik wrote: > Almost clean backport from 15u to 13u ( 17 to 15u was clean) > one gmk file renaming and context code difference This pull request has now been integrated. Changeset: f1e4e0b6 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/f1e4e0b6 Stats: 45 lines in 2 files changed: 35 ins; 2 del; 8 mod 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m Reviewed-by: yan Backport-of: 2be60e37e0e433141b2e3d3e32f8e638a4888e3a ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/179 From zgu at redhat.com Thu Apr 8 13:45:32 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 8 Apr 2021 09:45:32 -0400 Subject: ReE: [11u] RFR 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION In-Reply-To: <0110ABED-41E7-4F31-8DEE-2ED6E409726E@amazon.com> References: <0110ABED-41E7-4F31-8DEE-2ED6E409726E@amazon.com> Message-ID: <0fbedcc3-64d4-742c-62ae-668912dcca04@redhat.com> Thanks, Paul. Updated: http://cr.openjdk.java.net/~zgu/JDK-8261262-11u/webrev.01/ -Zhengyu On 4/7/21 5:58 PM, Hohensee, Paul wrote: > Copyright date needs an update to 2021, otherwise lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Zhengyu Gu > Date: Wednesday, April 7, 2021 at 8:41 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION > > I would like to backport this patch to 11u for parity with Oracle > 11.0.12-oracle. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8261262 > The original patch: https://github.com/openjdk/jdk/commit/7b9d2562 > > The original patch does not apply cleanly. 11u still uses VM operation > for getting current location, while the original patch uses handshake > (via. JDK 8242427) > > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8261262-11u/webrev.00/ > > Test: > vmTestbase_nsk_jvmti > > Thanks, > > -Zhengyu > > From dmitry.chuyko at bell-sw.com Thu Apr 8 14:13:46 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 8 Apr 2021 17:13:46 +0300 Subject: [11u] 8242429: Better implementation for sign extract Message-ID: <34596d09-4c57-c168-16d3-e689e0e6a0dd@bell-sw.com> Hello, Original bug: https://bugs.openjdk.java.net/browse/JDK-8242429 Original patch applies almost cleanly except the copyright year update in mulnode.cpp - re-done. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8242429/webrev.11u.00/ Testing: compiler/c2/TestSignExtract.java, tier1, tier2 (aarch64 build). -- Thanks, -Dmitry From hohensee at amazon.com Thu Apr 8 16:16:59 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 8 Apr 2021 16:16:59 +0000 Subject: ReE: [11u] RFR 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION Message-ID: <268C8EAD-DCDB-4E51-880E-763C12E50087@amazon.com> Lgtm. ?-----Original Message----- From: Zhengyu Gu Date: Thursday, April 8, 2021 at 6:45 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: ReE: [11u] RFR 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION Thanks, Paul. Updated: http://cr.openjdk.java.net/~zgu/JDK-8261262-11u/webrev.01/ -Zhengyu On 4/7/21 5:58 PM, Hohensee, Paul wrote: > Copyright date needs an update to 2021, otherwise lgtm. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of Zhengyu Gu > Date: Wednesday, April 7, 2021 at 8:41 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION > > I would like to backport this patch to 11u for parity with Oracle > 11.0.12-oracle. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8261262 > The original patch: https://github.com/openjdk/jdk/commit/7b9d2562 > > The original patch does not apply cleanly. 11u still uses VM operation > for getting current location, while the original patch uses handshake > (via. JDK 8242427) > > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8261262-11u/webrev.00/ > > Test: > vmTestbase_nsk_jvmti > > Thanks, > > -Zhengyu > > From johnc at azul.com Thu Apr 8 18:33:55 2021 From: johnc at azul.com (John Cuthbertson) Date: Thu, 8 Apr 2021 18:33:55 +0000 Subject: [jdk13u-dev] RFR: 8264640: CMS ParScanClosure misses a barrier In-Reply-To: References: Message-ID: <1512B9D3-78B4-4AB1-8B4C-D2BAA6344EFC@azul.com> Hi Anton, This looks good to me. I think I?m still a reviewer for the jdk-updates project. For the benefit of everyone else... We were seeing this as a crash when obtaining the size of an object to be copied. The klass was observed to be transiently NULL. We found that the object, reached through another reference path, had already been copied and the from-space oop placed on the task queue for subsequent reference field scanning. The task queue, however, had overflowed and the from-space oop was placed on the shared overflow queue where objects are chained together through their klass field. If the reads are ordered as they are in the code then everything is OK as per the comment at line 105 (in ParScanClosure::do_oop_work) but we found that gcc had reordered the reads in the non-compressed oops case. So the mark word is read and the object is observed to not forwarded (yet). Then, via another reference path, the object is copied, forwarded, and placed on the overflow task queue ? over writing the from-space object?s klass. Then in the original path the klass is read and observed to be NULL or the next overflow entry ? leading to the crash. When the from-space oop is dequeued, its klass is restored ? which is what was observed in the core file. Using worker thread local queues, -XX:+ParGCUseLocalOverflow, seems to workaround the problem. Thanks, John Cuthbertson > On Apr 2, 2021, at 2:02 AM, Anton Kozlov wrote: > > Adding hotspot-gc-dev. It will be great to receive comments from GC experts, even the fix does not make sense for mainline jdk. > > Thanks, > Anton > > On 4/2/21 11:51 AM, Anton Kozlov wrote: >> Hi, please review an original fix for a GC crash. The jdk13u is the latest supported version that still has buggy code, it was deleted in jdk14 as a part of JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector. So I'm proposing it here. >> The fix is low-risk, on x86-64 it just introduces a compiler barrier to prevent two reads to be reordered as intended by surrounding comments. On CPUs with weaker memory models it introduces CPU barriers as well. >> ------------- >> Commit messages: >> - Add missing barriers >> Changes: https://git.openjdk.java.net/jdk13u-dev/pull/165/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=165&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8264640 >> Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod >> Patch: https://git.openjdk.java.net/jdk13u-dev/pull/165.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/165/head:pull/165 >> PR: https://git.openjdk.java.net/jdk13u-dev/pull/165 From omikhaltcova at openjdk.java.net Thu Apr 8 21:25:35 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 8 Apr 2021 21:25:35 GMT Subject: [jdk13u-dev] RFR: 8241948: enhance list of environment variables printed in hs_err file Message-ID: I'd like to backport JDK-8241948 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested via build. ------------- Commit messages: - Backport fc806b67063fb23c7cd2b3ecdf85d13b42e45448 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/180/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=180&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241948 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/180.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/180/head:pull/180 PR: https://git.openjdk.java.net/jdk13u-dev/pull/180 From hohensee at amazon.com Thu Apr 8 21:35:32 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 8 Apr 2021 21:35:32 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Message-ID: <281326AC-22CC-4EF0-8250-3BA00BCD9221@amazon.com> Ouch, missed that. Good to go. Thanks, Paul ?-----Original Message----- From: "Doerr, Martin" Date: Thursday, April 8, 2021 at 2:53 AM To: "Hohensee, Paul" , "Langer, Christoph" , jdk-updates-dev , security-dev Cc: "Lindenmaier, Goetz" Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Hi Paul and Christoph, thank you for the review and the approval. I've added the blank line. In addition, I've reviewed the whole change again and found a copy & paste bug in my webrev.00: SECT283_K1(0x0009, "sect283k1", true, NamedGroupSpec.NAMED_GROUP_ECDHE, ProtocolVersion.PROTOCOLS_TO_12, - CurveDB.lookup("sect163k1")), + CurveDB.lookup("sect283k1")), This is the version I'm planning to push: http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.01/ Tests have passed. Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 8. April 2021 01:01 > To: Langer, Christoph ; Doerr, Martin > ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hmm, could have sworn... > > Thanks, > Paul > > -----Original Message----- > From: "Langer, Christoph" > Date: Wednesday, April 7, 2021 at 3:16 PM > To: "Hohensee, Paul" , "Doerr, Martin" > , jdk-updates-dev dev at openjdk.java.net>, security-dev > Cc: "Lindenmaier, Goetz" > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi Paul, > > thanks for the review. The CSR that Martin mentions is the one that Oracle > has filed for 11.0.12-oracle. so we can simply reuse it. > > As for 13, there exists a CSR as well: JDK-8256335 > > Best regards > Christoph > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Mittwoch, 7. April 2021 23:42 > > To: Doerr, Martin ; jdk-updates-dev updates- > > dev at openjdk.java.net>; security-dev > > Cc: Lindenmaier, Goetz ; Langer, Christoph > > > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > The backport looks fine, except there's a missing blank line after > FFDHE_2048 > > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be > one > > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > > security person, so it would be great if someone who is reviews the CSR to > > see if there are any 11u-specific issues with it. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on > > behalf of "Doerr, Martin" > > Date: Wednesday, April 7, 2021 at 9:10 AM > > To: jdk-updates-dev , security-dev > > > > Cc: "Lindenmaier, Goetz" , "Langer, > > Christoph" > > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > Hi, > > > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. > > It doesn't apply cleanly. I've taken the 13u backport as source because it > > resolves the wrong backport order with JDK-8242141. > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8226374 > > > > 11u CSR: > > https://bugs.openjdk.java.net/browse/JDK-8264555 > > > > Original change (JDK14): > > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > > > 13u backport: > > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > > > 11u rejected hunks (integrated manually): > > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > > > my new 11u backport: > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > > > Please review. > > > > Best regards, > > Martin > > > From hohensee at amazon.com Thu Apr 8 21:57:49 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 8 Apr 2021 21:57:49 +0000 Subject: [11u] 8242429: Better implementation for sign extract Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Thursday, April 8, 2021 at 7:15 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] 8242429: Better implementation for sign extract Hello, Original bug: https://bugs.openjdk.java.net/browse/JDK-8242429 Original patch applies almost cleanly except the copyright year update in mulnode.cpp - re-done. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8242429/webrev.11u.00/ Testing: compiler/c2/TestSignExtract.java, tier1, tier2 (aarch64 build). -- Thanks, -Dmitry From christoph.goettschkes at microdoc.com Fri Apr 9 07:04:17 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Fri, 9 Apr 2021 09:04:17 +0200 Subject: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls In-Reply-To: <87211FF1-854A-444C-8B0A-7B622F68ADDA@amazon.com> References: <87211FF1-854A-444C-8B0A-7B622F68ADDA@amazon.com> Message-ID: <37thfsrhjj-1@userp2060.oracle.com> Hi Paul, the change got approved, would you mind sponsoring it? I updated the webrev and added you as a reviewer to the changset: Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.01/ Thanks, Christoph On 4/8/21 1:42 AM, Hohensee, Paul wrote: > Lgtm. The Oracle arm64 port was removed in JDK 12 in favor of the Red Hat aarch64 port, and afaik has not been maintained since. Imo it's not worth the effort to either keep it building or remove it from 11u. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Christoph G?ttschkes > Date: Tuesday, April 6, 2021 at 12:21 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: RE: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls > > Gentle reminder. > > On 3/23/21 9:49 AM, Christoph G?ttschkes wrote: >> Hi, >> >> please review this backport of JDK-8213845 to 11u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 >> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/2d795829f39f >> >> Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.00/ >> >> This patch fixes the conversion between C and Java boolean types, which value is >> not 0 or 1 in C on aarch32. This also fixes the test case >> "runtime/BoolReturn/JNIBooleanTest.java", which is testing this conversion. >> >> The backport is not clean, because in 11u, the arm64 CPU type is still present. >> Adjusting the backport was fairly straight forward. Because of the arm64 CPU type, >> there are some additional #ifdef present and the changes had to be incoporated >> into the arm64 port as well. No additional changes have been made, only slight >> adjustments. >> >> I am not able to test the arm64 port, since it doesn't compile anymore and I don't >> know if this CPU type is still supported, or if the code remains there because it >> is deemed to complicated to remove it. >> >> Tested: >> * Hotspot tier1 on linux aarch32 >> * Hotspot tier1 on linux aarch32 with -XX:+VerifyOops and -Xcheck:jni >> * Hotspot tier1 on linux ARMv7-A >> >> Thanks, >> Christoph >> > > From martin.doerr at sap.com Fri Apr 9 09:19:05 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 9 Apr 2021 09:19:05 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups In-Reply-To: <281326AC-22CC-4EF0-8250-3BA00BCD9221@amazon.com> References: <281326AC-22CC-4EF0-8250-3BA00BCD9221@amazon.com> Message-ID: That one was hard to see. Pushed. Thanks, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 8. April 2021 23:36 > To: Doerr, Martin ; Langer, Christoph > ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Ouch, missed that. Good to go. > > Thanks, > Paul > > ?-----Original Message----- > From: "Doerr, Martin" > Date: Thursday, April 8, 2021 at 2:53 AM > To: "Hohensee, Paul" , "Langer, Christoph" > , jdk-updates-dev dev at openjdk.java.net>, security-dev > Cc: "Lindenmaier, Goetz" > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi Paul and Christoph, > > thank you for the review and the approval. > > I've added the blank line. > In addition, I've reviewed the whole change again and found a copy & paste > bug in my webrev.00: > SECT283_K1(0x0009, "sect283k1", true, > NamedGroupSpec.NAMED_GROUP_ECDHE, > ProtocolVersion.PROTOCOLS_TO_12, > - CurveDB.lookup("sect163k1")), > + CurveDB.lookup("sect283k1")), > > This is the version I'm planning to push: > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.01/ > > Tests have passed. > > Best regards, > Martin > > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Donnerstag, 8. April 2021 01:01 > > To: Langer, Christoph ; Doerr, Martin > > ; jdk-updates-dev > dev at openjdk.java.net>; security-dev > > Cc: Lindenmaier, Goetz > > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > Hmm, could have sworn... > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: "Langer, Christoph" > > Date: Wednesday, April 7, 2021 at 3:16 PM > > To: "Hohensee, Paul" , "Doerr, Martin" > > , jdk-updates-dev > dev at openjdk.java.net>, security-dev > > Cc: "Lindenmaier, Goetz" > > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > Hi Paul, > > > > thanks for the review. The CSR that Martin mentions is the one that Oracle > > has filed for 11.0.12-oracle. so we can simply reuse it. > > > > As for 13, there exists a CSR as well: JDK-8256335 > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Hohensee, Paul > > > Sent: Mittwoch, 7. April 2021 23:42 > > > To: Doerr, Martin ; jdk-updates-dev > updates- > > > dev at openjdk.java.net>; security-dev > > > Cc: Lindenmaier, Goetz ; Langer, > Christoph > > > > > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and > named > > > groups > > > > > > The backport looks fine, except there's a missing blank line after > > FFDHE_2048 > > > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be > > one > > > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > > > security person, so it would be great if someone who is reviews the CSR > to > > > see if there are any 11u-specific issues with it. > > > > > > Thanks, > > > Paul > > > > > > -----Original Message----- > > > From: jdk-updates-dev on > > > behalf of "Doerr, Martin" > > > Date: Wednesday, April 7, 2021 at 9:10 AM > > > To: jdk-updates-dev , security-dev > > > > > > Cc: "Lindenmaier, Goetz" , "Langer, > > > Christoph" > > > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > > groups > > > > > > Hi, > > > > > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for > parity. > > > It doesn't apply cleanly. I've taken the 13u backport as source because it > > > resolves the wrong backport order with JDK-8242141. > > > > > > Bug: > > > https://bugs.openjdk.java.net/browse/JDK-8226374 > > > > > > 11u CSR: > > > https://bugs.openjdk.java.net/browse/JDK-8264555 > > > > > > Original change (JDK14): > > > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > > > > > 13u backport: > > > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > > > > > 11u rejected hunks (integrated manually): > > > > > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > > > > > my new 11u backport: > > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > > > > > Please review. > > > > > > Best regards, > > > Martin > > > > > > From sgehwolf at openjdk.java.net Fri Apr 9 09:46:40 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Apr 2021 09:46:40 GMT Subject: [jdk16u] RFR: 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt Message-ID: 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt ------------- Commit messages: - Backport eb6330e4f0366878e7ec8a606ddc717622cbdaea Changes: https://git.openjdk.java.net/jdk16u/pull/103/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=103&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264047 Stats: 14 lines in 2 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk16u/pull/103.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/103/head:pull/103 PR: https://git.openjdk.java.net/jdk16u/pull/103 From akozlov at azul.com Fri Apr 9 11:35:34 2021 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 9 Apr 2021 14:35:34 +0300 Subject: [jdk13u-dev] RFR: 8264640: CMS ParScanClosure misses a barrier In-Reply-To: <1512B9D3-78B4-4AB1-8B4C-D2BAA6344EFC@azul.com> References: <1512B9D3-78B4-4AB1-8B4C-D2BAA6344EFC@azul.com> Message-ID: John, thank you for review and the comment! Thanks, Anton On 4/8/21 9:33 PM, John Cuthbertson wrote: > Hi Anton, > > This looks good to me. I think I?m still a reviewer for the jdk-updates project. > > For the benefit of everyone else... > > We were seeing this as a crash when obtaining the size of an object to be copied. The klass was observed to be transiently NULL. We found that the object, reached through another reference path, had already been copied and the from-space oop placed on the task queue for subsequent reference field scanning. The task queue, however, had overflowed and the from-space oop was placed on the shared overflow queue where objects are chained together through their klass field. If the reads are ordered as they are in the code then everything is OK as per the comment at line 105 (in ParScanClosure::do_oop_work) but we found that gcc had reordered the reads in the non-compressed oops case. So the mark word is read and the object is observed to not forwarded (yet). Then, via another reference path, the object is copied, forwarded, and placed on the overflow task queue ? over writing the from-space object?s klass. Then in the original path the klass is read and observed to be NULL or the next overflow entry ? leading to the crash. When the from-space oop is dequeued, its klass is restored ? which is what was observed in the core file. > > Using worker thread local queues, -XX:+ParGCUseLocalOverflow, seems to workaround the problem. > > Thanks, > > John Cuthbertson > >> On Apr 2, 2021, at 2:02 AM, Anton Kozlov wrote: >> >> Adding hotspot-gc-dev. It will be great to receive comments from GC experts, even the fix does not make sense for mainline jdk. >> >> Thanks, >> Anton >> >> On 4/2/21 11:51 AM, Anton Kozlov wrote: >>> Hi, please review an original fix for a GC crash. The jdk13u is the latest supported version that still has buggy code, it was deleted in jdk14 as a part of JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector. So I'm proposing it here. >>> The fix is low-risk, on x86-64 it just introduces a compiler barrier to prevent two reads to be reordered as intended by surrounding comments. On CPUs with weaker memory models it introduces CPU barriers as well. >>> ------------- >>> Commit messages: >>> - Add missing barriers >>> Changes: https://git.openjdk.java.net/jdk13u-dev/pull/165/files >>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=165&range=00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8264640 >>> Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod >>> Patch: https://git.openjdk.java.net/jdk13u-dev/pull/165.diff >>> Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/165/head:pull/165 >>> PR: https://git.openjdk.java.net/jdk13u-dev/pull/165 > From yan at openjdk.java.net Fri Apr 9 11:49:20 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 9 Apr 2021 11:49:20 GMT Subject: [jdk13u-dev] RFR: 8264640: CMS ParScanClosure misses a barrier In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 08:46:21 GMT, Anton Kozlov wrote: > Hi, please review an original fix for a GC crash. The jdk13u is the latest supported version that still has buggy code, it was deleted in jdk14 as a part of JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector. So I'm proposing it here. > > The fix is low-risk, on x86-64 it just introduces a compiler barrier to prevent two reads to be reordered as intended by surrounding comments. On CPUs with weaker memory models it introduces CPU barriers as well. After John, it's easy to say lgtm! ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/165 From christoph.goettschkes at microdoc.com Fri Apr 9 11:51:50 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Fri, 9 Apr 2021 13:51:50 +0200 Subject: [Ping] [11u] 8207247: AARCH64: Enable Minimal and Client VM builds In-Reply-To: <37hw4wck0y-1@userp2050.oracle.com> References: <37hw4wck0y-1@userp2050.oracle.com> Message-ID: <37thfsum98-1@userp2060.oracle.com> Gentle reminder. On 3/29/21 12:00 PM, Christoph G?ttschkes wrote: > Hi, > > could someone please sponsor this clean and already approved backport of 8207247 to 11u? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8207247 > Webrev: https://cr.openjdk.java.net/~cgo/8207247/webrev.11u.00/ > > Thanks, > Christoph > From shade at redhat.com Fri Apr 9 11:59:43 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 9 Apr 2021 13:59:43 +0200 Subject: [11u] 8207247: AARCH64: Enable Minimal and Client VM builds In-Reply-To: <37hw4wck0y-1@userp2050.oracle.com> References: <37hw4wck0y-1@userp2050.oracle.com> Message-ID: <83a0d416-2633-b965-8752-e8ce7d5c3254@redhat.com> On 3/29/21 12:00 PM, Christoph G?ttschkes wrote: > Hi, > > could someone please sponsor this clean and already approved backport of 8207247 to 11u? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8207247 > Webrev: https://cr.openjdk.java.net/~cgo/8207247/webrev.11u.00/ I'll do it. -- Thanks, -Aleksey From akozlov at openjdk.java.net Fri Apr 9 12:26:15 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 9 Apr 2021 12:26:15 GMT Subject: [jdk13u-dev] RFR: 8264640: CMS ParScanClosure misses a barrier In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 11:46:37 GMT, Yuri Nesterenko wrote: >> Hi, please review an original fix for a GC crash. The jdk13u is the latest supported version that still has buggy code, it was deleted in jdk14 as a part of JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector. So I'm proposing it here. >> >> The fix is low-risk, on x86-64 it just introduces a compiler barrier to prevent two reads to be reordered as intended by surrounding comments. On CPUs with weaker memory models it introduces CPU barriers as well. > > After John, it's easy to say lgtm! Yura, thanks! ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/165 From christoph.goettschkes at microdoc.com Fri Apr 9 12:28:29 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Fri, 9 Apr 2021 14:28:29 +0200 Subject: [11u] 8207247: AARCH64: Enable Minimal and Client VM builds In-Reply-To: <7f0a518e-ea0a-79de-d836-7a8de7277f84@redhat.com> References: <37hw4wck0y-1@userp2050.oracle.com> <83a0d416-2633-b965-8752-e8ce7d5c3254@redhat.com> <7f0a518e-ea0a-79de-d836-7a8de7277f84@redhat.com> Message-ID: <37tmhg1yvc-1@aserp2050.oracle.com> Thanks a lot, Aleksey. I can't wait for 11u to migrate to Skara. The process is much less painful, especially if one isn't a committer. -- Christoph On 4/9/21 2:26 PM, Aleksey Shipilev wrote: > On 4/9/21 1:59 PM, Aleksey Shipilev wrote: >> On 3/29/21 12:00 PM, Christoph G?ttschkes wrote: >>> Hi, >>> >>> could someone please sponsor this clean and already approved backport of8207247 to 11u? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8207247 >>> Webrev: https://cr.openjdk.java.net/~cgo/8207247/webrev.11u.00/ >> >> I'll do it. > > There you go: > ?https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/11dcad575f79 > > (I also checked it builds server/client/minimal) > From shade at redhat.com Fri Apr 9 12:26:19 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 9 Apr 2021 14:26:19 +0200 Subject: [11u] 8207247: AARCH64: Enable Minimal and Client VM builds In-Reply-To: <83a0d416-2633-b965-8752-e8ce7d5c3254@redhat.com> References: <37hw4wck0y-1@userp2050.oracle.com> <83a0d416-2633-b965-8752-e8ce7d5c3254@redhat.com> Message-ID: <7f0a518e-ea0a-79de-d836-7a8de7277f84@redhat.com> On 4/9/21 1:59 PM, Aleksey Shipilev wrote: > On 3/29/21 12:00 PM, Christoph G?ttschkes wrote: >> Hi, >> >> could someone please sponsor this clean and already approved backport of 8207247 to 11u? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8207247 >> Webrev: https://cr.openjdk.java.net/~cgo/8207247/webrev.11u.00/ > > I'll do it. There you go: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/11dcad575f79 (I also checked it builds server/client/minimal) -- Thanks, -Aleksey From akozlov at openjdk.java.net Fri Apr 9 12:33:13 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 9 Apr 2021 12:33:13 GMT Subject: [jdk13u-dev] Integrated: 8264640: CMS ParScanClosure misses a barrier In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 08:46:21 GMT, Anton Kozlov wrote: > Hi, please review an original fix for a GC crash. The jdk13u is the latest supported version that still has buggy code, it was deleted in jdk14 as a part of JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector. So I'm proposing it here. > > The fix is low-risk, on x86-64 it just introduces a compiler barrier to prevent two reads to be reordered as intended by surrounding comments. On CPUs with weaker memory models it introduces CPU barriers as well. This pull request has now been integrated. Changeset: efc81a3d Author: Anton Kozlov URL: https://git.openjdk.java.net/jdk13u-dev/commit/efc81a3d Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8264640: CMS ParScanClosure misses a barrier Reviewed-by: yan, johnc ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/165 From omikhaltcova at openjdk.java.net Fri Apr 9 14:42:21 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 9 Apr 2021 14:42:21 GMT Subject: [jdk13u-dev] Integrated: 8241948: enhance list of environment variables printed in hs_err file In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 19:42:52 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8241948 to jdk13u for parity with jdk11u. > The original patch applied cleanly. Tested via build. This pull request has now been integrated. Changeset: 7daf6808 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/7daf6808 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8241948: enhance list of environment variables printed in hs_err file Backport-of: fc806b67063fb23c7cd2b3ecdf85d13b42e45448 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/180 From sean.coffey at oracle.com Fri Apr 9 14:45:57 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 9 Apr 2021 15:45:57 +0100 Subject: CFV: New JDK-Updates Committer: Kiran Ravikumar Message-ID: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Updates Project Committer. Kiran is already a Committer in the JDK Project and has been working primarily in the core-libs areas of the JDK. He has contributed a range of fixes to the JDK Updates Project [0]. Votes are due by 15:00 GMT on April 23rd 2021. Only current JDK Updates Project Committers [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. regards, Sean. [0] https://github.com/openjdk/jdk16u/search?p=1&q=author-name%3AKiran&type=commits [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote From hohensee at amazon.com Fri Apr 9 14:47:15 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 9 Apr 2021 14:47:15 +0000 Subject: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls Message-ID: Done. ?-----Original Message----- From: Christoph G?ttschkes Date: Friday, April 9, 2021 at 12:06 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls Hi Paul, the change got approved, would you mind sponsoring it? I updated the webrev and added you as a reviewer to the changset: Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.01/ Thanks, Christoph On 4/8/21 1:42 AM, Hohensee, Paul wrote: > Lgtm. The Oracle arm64 port was removed in JDK 12 in favor of the Red Hat aarch64 port, and afaik has not been maintained since. Imo it's not worth the effort to either keep it building or remove it from 11u. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of Christoph G?ttschkes > Date: Tuesday, April 6, 2021 at 12:21 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: RE: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls > > Gentle reminder. > > On 3/23/21 9:49 AM, Christoph G?ttschkes wrote: >> Hi, >> >> please review this backport of JDK-8213845 to 11u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 >> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/2d795829f39f >> >> Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.00/ >> >> This patch fixes the conversion between C and Java boolean types, which value is >> not 0 or 1 in C on aarch32. This also fixes the test case >> "runtime/BoolReturn/JNIBooleanTest.java", which is testing this conversion. >> >> The backport is not clean, because in 11u, the arm64 CPU type is still present. >> Adjusting the backport was fairly straight forward. Because of the arm64 CPU type, >> there are some additional #ifdef present and the changes had to be incoporated >> into the arm64 port as well. No additional changes have been made, only slight >> adjustments. >> >> I am not able to test the arm64 port, since it doesn't compile anymore and I don't >> know if this CPU type is still supported, or if the code remains there because it >> is deemed to complicated to remove it. >> >> Tested: >> * Hotspot tier1 on linux aarch32 >> * Hotspot tier1 on linux aarch32 with -XX:+VerifyOops and -Xcheck:jni >> * Hotspot tier1 on linux ARMv7-A >> >> Thanks, >> Christoph >> > > From harold.seigel at oracle.com Fri Apr 9 14:49:13 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Fri, 9 Apr 2021 10:49:13 -0400 Subject: CFV: New JDK-Updates Committer: Kiran Ravikumar In-Reply-To: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> References: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> Message-ID: <339906b2-f152-d610-6c7e-89bf3d99cfc6@oracle.com> Vote: Yes Harold On 4/9/2021 10:45 AM, Se?n Coffey wrote: > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Updates Project > Committer. > > Kiran is already a Committer in the JDK Project and has been working > primarily in the core-libs areas of the JDK. He has contributed a > range of fixes to the JDK Updates Project [0]. > > Votes are due by 15:00 GMT on April 23rd 2021. > > Only current JDK Updates Project Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying to > this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > regards, > Sean. > > [0] > https://github.com/openjdk/jdk16u/search?p=1&q=author-name%3AKiran&type=commits > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From omikhaltcova at openjdk.java.net Fri Apr 9 14:52:39 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 9 Apr 2021 14:52:39 GMT Subject: [jdk15u-dev] RFR: 8248552: C2 crashes with SIGFPE due to division by zero Message-ID: I'd like to backport JDK-8248552 to jdk15u for parity with jdk11u. The original patch applied cleanly. Tested with the test attached to the corresponding issue and the test added in this patch. ------------- Commit messages: - Backport 417e8e449df569f593b82ecd640fa01b6b762832 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/20/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=20&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248552 Stats: 117 lines in 2 files changed: 110 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/20/head:pull/20 PR: https://git.openjdk.java.net/jdk15u-dev/pull/20 From sean.coffey at oracle.com Fri Apr 9 14:54:03 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 9 Apr 2021 15:54:03 +0100 Subject: CFV: New JDK-Updates Committer: Kiran Ravikumar In-Reply-To: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> References: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> Message-ID: <63962330-9fe9-43b8-886b-ddec2e50dfc6@oracle.com> vote: yes regards, Sean. On 09/04/2021 15:45, Se?n Coffey wrote: > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Updates Project > Committer. > > Kiran is already a Committer in the JDK Project and has been working > primarily in the core-libs areas of the JDK. He has contributed a > range of fixes to the JDK Updates Project [0]. > > Votes are due by 15:00 GMT on April 23rd 2021. > > Only current JDK Updates Project Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying to > this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > regards, > Sean. > > [0] > https://github.com/openjdk/jdk16u/search?p=1&q=author-name%3AKiran&type=commits > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From christoph.goettschkes at microdoc.com Fri Apr 9 14:56:05 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Fri, 9 Apr 2021 16:56:05 +0200 Subject: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls In-Reply-To: References: Message-ID: <37thfsx08j-1@userp2060.oracle.com> Thanks a lot, Paul. Very much appreciated. -- Christoph On 4/9/21 4:47 PM, Hohensee, Paul wrote: > Done. > > ?-----Original Message----- > From: Christoph G?ttschkes > Date: Friday, April 9, 2021 at 12:06 AM > To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" > Subject: RE: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls > > Hi Paul, > > the change got approved, would you mind sponsoring it? I updated the webrev and added you as a reviewer to the changset: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 > Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.01/ > > Thanks, > Christoph > > On 4/8/21 1:42 AM, Hohensee, Paul wrote: >> Lgtm. The Oracle arm64 port was removed in JDK 12 in favor of the Red Hat aarch64 port, and afaik has not been maintained since. Imo it's not worth the effort to either keep it building or remove it from 11u. >> >> Thanks, >> Paul >> >> -----Original Message----- >> From: jdk-updates-dev on behalf of Christoph G?ttschkes >> Date: Tuesday, April 6, 2021 at 12:21 AM >> To: "jdk-updates-dev at openjdk.java.net" >> Subject: RE: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls >> >> Gentle reminder. >> >> On 3/23/21 9:49 AM, Christoph G?ttschkes wrote: >>> Hi, >>> >>> please review this backport of JDK-8213845 to 11u: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 >>> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/2d795829f39f >>> >>> Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.00/ >>> >>> This patch fixes the conversion between C and Java boolean types, which value is >>> not 0 or 1 in C on aarch32. This also fixes the test case >>> "runtime/BoolReturn/JNIBooleanTest.java", which is testing this conversion. >>> >>> The backport is not clean, because in 11u, the arm64 CPU type is still present. >>> Adjusting the backport was fairly straight forward. Because of the arm64 CPU type, >>> there are some additional #ifdef present and the changes had to be incoporated >>> into the arm64 port as well. No additional changes have been made, only slight >>> adjustments. >>> >>> I am not able to test the arm64 port, since it doesn't compile anymore and I don't >>> know if this CPU type is still supported, or if the code remains there because it >>> is deemed to complicated to remove it. >>> >>> Tested: >>> * Hotspot tier1 on linux aarch32 >>> * Hotspot tier1 on linux aarch32 with -XX:+VerifyOops and -Xcheck:jni >>> * Hotspot tier1 on linux ARMv7-A >>> >>> Thanks, >>> Christoph >>> >> >> > > From omikhaltcova at openjdk.java.net Fri Apr 9 16:58:20 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 9 Apr 2021 16:58:20 GMT Subject: [jdk15u-dev] Integrated: 8248552: C2 crashes with SIGFPE due to division by zero In-Reply-To: References: Message-ID: <67FZ4704KH1t3iXBQYBx49Tbycjic5eg-4sXaiMswSw=.fe7976ed-6ed1-4b38-b2d1-f8dfcc667c51@github.com> On Fri, 9 Apr 2021 14:45:56 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8248552 to jdk15u for parity with jdk11u. > The original patch applied cleanly. > Tested with the test attached to the corresponding issue and the test added in this patch. > In addition tested with jtreg:test/hotspot/jtreg/compiler, no regression. This pull request has now been integrated. Changeset: 73788921 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/73788921 Stats: 117 lines in 2 files changed: 110 ins; 0 del; 7 mod 8248552: C2 crashes with SIGFPE due to division by zero Bail out in PhaseIdealLoop:split_thru_phi when trying to split a Div or ModNode iv phi whose zero check was removed but could potentially still be zero based on type information. Backport-of: 417e8e449df569f593b82ecd640fa01b6b762832 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/20 From aleksej.efimov at oracle.com Fri Apr 9 18:22:19 2021 From: aleksej.efimov at oracle.com (Aleksei Efimov) Date: Fri, 9 Apr 2021 19:22:19 +0100 Subject: CFV: New JDK-Updates Committer: Kiran Ravikumar In-Reply-To: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> References: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> Message-ID: <847d8bd7-b50d-7e13-cb9d-134e9d01c08a@oracle.com> Vote: yes On 09/04/2021 15:45, Se?n Coffey wrote: > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Updates Project > Committer. > > Kiran is already a Committer in the JDK Project and has been working > primarily in the core-libs areas of the JDK. He has contributed a > range of fixes to the JDK Updates Project [0]. > > Votes are due by 15:00 GMT on April 23rd 2021. > > Only current JDK Updates Project Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying to > this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > regards, > Sean. > > [0] > https://github.com/openjdk/jdk16u/search?p=1&q=author-name%3AKiran&type=commits > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From florian.david at datadoghq.com Fri Apr 9 21:49:40 2021 From: florian.david at datadoghq.com (Florian David) Date: Fri, 9 Apr 2021 23:49:40 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: After receiving feedback from Markus stating that: > There is no need to attempt a lock replacement, because in 11, there is no concurrent class unloading. There, unloading only happens at a safepoint. > With concurrent class unloading, there is a need to protect this list, but in 11 it is mutually exclusive and cannot be modified concurrently with the JFR Recorder thread calling "install_stack_traces(sampler"). I removed the module lock and added an is_at_safepoint() assert. Update webrev link: Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.02/ Original PR: https://github.com/openjdk/jdk/pull/2780 Florian On Sun, Apr 4, 2021 at 8:33 PM Florian David wrote: > Hi Jaroslav, > > Thanks for the review. > > >> - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> L287 - IMO, the TODO is not necessary >> > It's removed. > > >> L293 - I think the comment `// caller needs ResourceMark` should >> not be removed >> > I added it back. > > L303 - Not sure if using Module_lock instead of >> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >> bringing in changes unrelated to the patch. >> From what is happening in other places it would seem >> that a safepoint should be asserted instead (or nothing should be >> done). >> I will let Markus weigh in on this. >> > No change for the moment. > > >> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >> L38 - can this be completely removed? >> > It's removed. > > >> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >> L30 - I think `class JfrThreadLocal;` can also be removed >> >> It's removed. > > Update webrev link: > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.01/ > Original PR: https://github.com/openjdk/jdk/pull/2780 > > Florian > > On Mon, Mar 29, 2021 at 12:22 PM Jaroslav Bachor?k < > jaroslav.bachorik at datadoghq.com> wrote: > >> Hi Florian, >> >> a few nits: >> - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> L287 - IMO, the TODO is not necessary >> L293 - I think the comment `// caller needs ResourceMark` should >> not be removed >> L303 - Not sure if using Module_lock instead of >> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >> bringing in changes unrelated to the patch. >> From what is happening in other places it would seem >> that a safepoint should be asserted instead (or nothing should be >> done). >> I will let Markus weigh in on this. >> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >> L38 - can this be completely removed? >> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >> L30 - I think `class JfrThreadLocal;` can also be removed >> >> Cheers, >> >> -JB- >> >> >> On Wed, Mar 24, 2021 at 8:42 PM Florian David >> wrote: >> > >> > Hi, >> > >> > Please review this 11u backport. It's very similar to the original >> patch, >> > except for the class loader data graph lock and >> JfrKlassUnloading::sort() >> > method which are not available in 11u. >> > >> > The missing lock has been replaced by locking the module_lock instead, >> > as it is done in jfrcheckpointManager.cpp:363. >> > JfrKlassUnloading class does not exist and thus sort() method is not >> replaced, >> > I added a TODO instead. >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >> > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ >> > Original PR: https://github.com/openjdk/jdk/pull/2780 >> > >> > Testing: >> > - Linux x86_64 tier1 tests >> > - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is 75.12 >> MB before the patch and 3.08 MB after the patch. >> > >> > Let me know what you think. >> > >> > Thanks, >> > Florian >> > From david.buck at oracle.com Sat Apr 10 00:03:26 2021 From: david.buck at oracle.com (David Buck) Date: Sat, 10 Apr 2021 00:03:26 +0000 Subject: CFV: New JDK-Updates Committer: Kiran Ravikumar In-Reply-To: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> References: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> Message-ID: Vote: Yes Cheers, -Buck -----Original Message----- From: jdk-updates-dev On Behalf Of Sean Coffey Sent: Friday, April 9, 2021 11:46 PM To: jdk-updates-dev Subject: CFV: New JDK-Updates Committer: Kiran Ravikumar I hereby nominate Kiran Ravikumar (kravikumar) to JDK Updates Project Committer. Kiran is already a Committer in the JDK Project and has been working primarily in the core-libs areas of the JDK. He has contributed a range of fixes to the JDK Updates Project [0]. Votes are due by 15:00 GMT on April 23rd 2021. Only current JDK Updates Project Committers [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. regards, Sean. [0] https://github.com/openjdk/jdk16u/search?p=1&q=author-name%3AKiran&type=commits [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote From omikhaltcova at openjdk.java.net Mon Apr 12 06:58:48 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 12 Apr 2021 06:58:48 GMT Subject: [jdk15u-dev] RFR: 8257414: Drag n Drop target area is wrong on high DPI systems Message-ID: I'd like to backport JDK-8257414 to jdk15u for parity with jdk11u. The original patch applied cleanly. Tested manually. ------------- Commit messages: - Backport d3398324e9c3944d2f1558ff1becea9ed1d4e8a2 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/21/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=21&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257414 Stats: 31 lines in 2 files changed: 26 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/21.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/21/head:pull/21 PR: https://git.openjdk.java.net/jdk15u-dev/pull/21 From thartmann at openjdk.java.net Mon Apr 12 07:41:20 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 12 Apr 2021 07:41:20 GMT Subject: [jdk16u] RFR: 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> References: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> Message-ID: <69MhVrNawLDAwsBYalZamAXd92tt2FzwIVkYOAyc6PQ=.c8f1e7b2-41da-42ea-823f-0ca827bc002b@github.com> On Thu, 1 Apr 2021 11:07:44 GMT, Richard Reingruber wrote: > This is the jdk16u backport of the fix for JDK-8262295. > The fix applies cleanly. > The test required trivial adaptation: I had to remove the package from the class ClassFileInstaller. > > The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms. Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/101 From omikhaltcova at openjdk.java.net Mon Apr 12 08:01:39 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 12 Apr 2021 08:01:39 GMT Subject: [jdk15u-dev] Integrated: 8257414: Drag n Drop target area is wrong on high DPI systems In-Reply-To: References: Message-ID: <5myUNHC1G8iTv05ronB8K5LZVMVGNwfb5aaBbkEzNOg=.4d7ab3cf-78d1-45e3-9901-fc8a5cd297fb@github.com> On Mon, 12 Apr 2021 06:47:18 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8257414 to jdk15u for parity with jdk11u. > The original patch applied cleanly. > Tested manually. This pull request has now been integrated. Changeset: 44c196aa Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/44c196aa Stats: 31 lines in 2 files changed: 26 ins; 0 del; 5 mod 8257414: Drag n Drop target area is wrong on high DPI systems Backport-of: d3398324e9c3944d2f1558ff1becea9ed1d4e8a2 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/21 From yan at azul.com Mon Apr 12 08:06:23 2021 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 12 Apr 2021 11:06:23 +0300 Subject: CFV: New JDK-Updates Committer: Kiran Ravikumar In-Reply-To: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> References: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> Message-ID: <4aa3615a-438f-5d74-1b26-fc5a1386c92f@azul.com> Vote: yes --yan On 09.04.2021 17:45, Se?n Coffey wrote: > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Updates Project Committer. > > Kiran is already a Committer in the JDK Project and has been working primarily in the core-libs areas > of the JDK. He has contributed a range of fixes to the JDK Updates Project [0]. > > Votes are due by 15:00 GMT on April 23rd 2021. > > Only current JDK Updates Project Committers [1] are eligible to vote on this nomination.? Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > regards, > Sean. > > [0] https://github.com/openjdk/jdk16u/search?p=1&q=author-name%3AKiran&type=commits > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote From dmitry.markov at oracle.com Mon Apr 12 08:14:30 2021 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 12 Apr 2021 08:14:30 +0000 Subject: CFV: New JDK-Updates Committer: Kiran Ravikumar In-Reply-To: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> References: <1f196d54-ab78-207a-9f82-e8496503297f@oracle.com> Message-ID: Vote: Yes Regards, Dmitry > On 9 Apr 2021, at 15:45, Se?n Coffey wrote: > > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Updates Project Committer. > > Kiran is already a Committer in the JDK Project and has been working primarily in the core-libs areas of the JDK. He has contributed a range of fixes to the JDK Updates Project [0]. > > Votes are due by 15:00 GMT on April 23rd 2021. > > Only current JDK Updates Project Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > regards, > Sean. > > [0] https://github.com/openjdk/jdk16u/search?p=1&q=author-name%3AKiran&type=commits > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From jaroslav.bachorik at datadoghq.com Mon Apr 12 08:38:37 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 12 Apr 2021 10:38:37 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: Great, thanks! Reviewed! -JB- On Fri, Apr 9, 2021 at 11:49 PM Florian David wrote: > > After receiving feedback from Markus stating that: > > There is no need to attempt a lock replacement, because in 11, there is no concurrent class unloading. There, unloading only happens at a safepoint. > > With concurrent class unloading, there is a need to protect this list, but in 11 it is mutually exclusive and cannot be modified concurrently with the JFR Recorder thread calling "install_stack_traces(sampler"). > > I removed the module lock and added an is_at_safepoint() assert. > > Update webrev link: > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.02/ > Original PR: https://github.com/openjdk/jdk/pull/2780 > > Florian > > On Sun, Apr 4, 2021 at 8:33 PM Florian David wrote: >> >> Hi Jaroslav, >> >> Thanks for the review. >> >>> >>> - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >>> L287 - IMO, the TODO is not necessary >> >> It's removed. >> >>> >>> L293 - I think the comment `// caller needs ResourceMark` should >>> not be removed >> >> I added it back. >> >>> L303 - Not sure if using Module_lock instead of >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >>> bringing in changes unrelated to the patch. >>> From what is happening in other places it would seem >>> that a safepoint should be asserted instead (or nothing should be >>> done). >>> I will let Markus weigh in on this. >> >> No change for the moment. >> >>> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >>> L38 - can this be completely removed? >> >> It's removed. >> >>> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >>> L30 - I think `class JfrThreadLocal;` can also be removed >>> >> It's removed. >> >> Update webrev link: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >> webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.01/ >> Original PR: https://github.com/openjdk/jdk/pull/2780 >> >> Florian >> >> On Mon, Mar 29, 2021 at 12:22 PM Jaroslav Bachor?k wrote: >>> >>> Hi Florian, >>> >>> a few nits: >>> - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >>> L287 - IMO, the TODO is not necessary >>> L293 - I think the comment `// caller needs ResourceMark` should >>> not be removed >>> L303 - Not sure if using Module_lock instead of >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >>> bringing in changes unrelated to the patch. >>> From what is happening in other places it would seem >>> that a safepoint should be asserted instead (or nothing should be >>> done). >>> I will let Markus weigh in on this. >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >>> L38 - can this be completely removed? >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >>> L30 - I think `class JfrThreadLocal;` can also be removed >>> >>> Cheers, >>> >>> -JB- >>> >>> >>> On Wed, Mar 24, 2021 at 8:42 PM Florian David >>> wrote: >>> > >>> > Hi, >>> > >>> > Please review this 11u backport. It's very similar to the original patch, >>> > except for the class loader data graph lock and JfrKlassUnloading::sort() >>> > method which are not available in 11u. >>> > >>> > The missing lock has been replaced by locking the module_lock instead, >>> > as it is done in jfrcheckpointManager.cpp:363. >>> > JfrKlassUnloading class does not exist and thus sort() method is not replaced, >>> > I added a TODO instead. >>> > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >>> > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ >>> > Original PR: https://github.com/openjdk/jdk/pull/2780 >>> > >>> > Testing: >>> > - Linux x86_64 tier1 tests >>> > - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is 75.12 MB before the patch and 3.08 MB after the patch. >>> > >>> > Let me know what you think. >>> > >>> > Thanks, >>> > Florian From richard.reingruber at sap.com Mon Apr 12 09:44:38 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Mon, 12 Apr 2021 09:44:38 +0000 Subject: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Message-ID: Hi, Please help review this XXS backport of JDK-8244847 to 11u. Original bug (JDK16): https://bugs.openjdk.java.net/browse/JDK-8244847 https://git.openjdk.java.net/jdk/commit/4a267f1b 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8244847_11u_Linux_PPC__runtime_CompressedOops_CompressedClassPointers__smallHeapTest_fails/webrev.0/ Adaptations: In both codelines, JDK16 and JDK11u, the fix reuses code for AARCH64 to search for a free address block below 32g that can be used for a zerobased compressed class space also on PPC64. In JDK16 the method Metaspace::reserve_address_space_for_compressed_classes() holds that code. In JDK11u it is the method Metaspace::allocate_metaspace_compressed_klass_ptrs(). The test (CompressedClassPointers.java) is not changed because it's not disabled in 11u. Testing: CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From rrich at openjdk.java.net Mon Apr 12 10:06:39 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 12 Apr 2021 10:06:39 GMT Subject: [jdk16u] RFR: 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: <69MhVrNawLDAwsBYalZamAXd92tt2FzwIVkYOAyc6PQ=.c8f1e7b2-41da-42ea-823f-0ca827bc002b@github.com> References: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> <69MhVrNawLDAwsBYalZamAXd92tt2FzwIVkYOAyc6PQ=.c8f1e7b2-41da-42ea-823f-0ca827bc002b@github.com> Message-ID: <9Mpvq6D4X1I6ynJ8n5Y_jl7DnAtYvqARsReHZG6z8BY=.b80198cc-90f0-4097-a26c-76633aad1b03@github.com> On Mon, 12 Apr 2021 07:38:41 GMT, Tobias Hartmann wrote: >> This is the jdk16u backport of the fix for JDK-8262295. >> The fix applies cleanly. >> The test required trivial adaptation: I had to remove the package from the class ClassFileInstaller. >> >> The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, >> SAP specific tests with fastdebug and release builds on all platforms. > > Marked as reviewed by thartmann (Reviewer). Thanks for the review @TobiHartmann ------------- PR: https://git.openjdk.java.net/jdk16u/pull/101 From kravikumar at openjdk.java.net Mon Apr 12 11:45:13 2021 From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar) Date: Mon, 12 Apr 2021 11:45:13 GMT Subject: [jdk16u] RFR: 8262110: DST starts from incorrect time in 2038 Message-ID: Backport to 16u as it is a long-standing bug in Calendar API. Passed regression ------------- Commit messages: - Backport 7284f013ea3064b2aa643658938ccaafdfa1c885 Changes: https://git.openjdk.java.net/jdk16u/pull/104/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=104&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262110 Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/104.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/104/head:pull/104 PR: https://git.openjdk.java.net/jdk16u/pull/104 From kravikumar at openjdk.java.net Mon Apr 12 11:49:49 2021 From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar) Date: Mon, 12 Apr 2021 11:49:49 GMT Subject: [jdk16u] Integrated: 8262110: DST starts from incorrect time in 2038 In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 11:35:49 GMT, Kiran Sidhartha Ravikumar wrote: > Backport to 16u as it is a long-standing bug in Calendar API. Passed regression This pull request has now been integrated. Changeset: 4f5421ef Author: Kiran Sidhartha Ravikumar Committer: Sean Coffey URL: https://git.openjdk.java.net/jdk16u/commit/4f5421ef Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod 8262110: DST starts from incorrect time in 2038 8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137 Backport-of: 7284f013ea3064b2aa643658938ccaafdfa1c885 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/104 From yan at openjdk.java.net Mon Apr 12 15:16:08 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 12 Apr 2021 15:16:08 GMT Subject: [jdk15u-dev] RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes Message-ID: The original patch applies clean. No regressions in jdk/sun/security/pkcs11 tests. ------------- Commit messages: - Backport 4be2173478bd1e84946bd903b350ce466bddb36b Changes: https://git.openjdk.java.net/jdk15u-dev/pull/22/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=22&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259319 Stats: 122 lines in 4 files changed: 115 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/22/head:pull/22 PR: https://git.openjdk.java.net/jdk15u-dev/pull/22 From yan at openjdk.java.net Mon Apr 12 15:20:51 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 12 Apr 2021 15:20:51 GMT Subject: [jdk15u-dev] Integrated: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 15:09:13 GMT, Yuri Nesterenko wrote: > The original patch applies clean. No regressions in jdk/sun/security/pkcs11 tests. This pull request has now been integrated. Changeset: ace2b56d Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/ace2b56d Stats: 122 lines in 4 files changed: 115 ins; 0 del; 7 mod 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes Backport-of: 4be2173478bd1e84946bd903b350ce466bddb36b ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/22 From martin.doerr at sap.com Mon Apr 12 15:45:47 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 12 Apr 2021 15:45:47 +0000 Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy fails with NPE In-Reply-To: References: Message-ID: Hi all, unfortunately, this backport seems to cause many test failures: java/net/httpclient/websocket/WebSocketProxyTest.java java/net/httpclient/websocket/WebSocketTest.java java/net/httpclient/whitebox/AuthenticationFilterTestDriver.java java/net/httpclient/BasicAuthTest.java java/net/httpclient/DigestEchoClient.java java/net/httpclient/DigestEchoClientSSL.java java/net/httpclient/MultiAuthTest.java java/net/httpclient/ProxyAuthDisabledSchemes.java java/net/httpclient/ProxyAuthDisabledSchemesSSL.java java/net/httpclient/UnauthorizedTest.java With error messages like: Error. can't find jdk.test.lib.net.SimpleSSLContext in test directory or libraries Sent 401 Authentication response java.nio.channels.SocketChannel[connected local=/127.0.0.1:40237 remote=/127.0.0.1:53354] Error in connection: java.nio.channels.SocketChannel[connected local=/127.0.0.1:40237 remote=/127.0.0.1:53354], java.io.IOException: Bad request:[] Does anybody know what is going wrong? Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Freitag, 26. M?rz 2021 22:53 > To: Ilarion Nakonechnyy ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: JDK-8236859 backport: WebSocket over > authenticating proxy fails with NPE > > Lgtm, except in HttpResponseImpl.java, the new closeRawChannel method > looks like it needs its indentation fixed. > > In AuthenticationFilter.java, "return null" is in the scope of > "PROXY_AUTHORIZED" rather than the scope of "UNAUTHORIZED". That's > what I'd expect from looking at the existing 11u code, but the original patch > does more checking later on. There may be more backports that should be > done to incorporate that checking. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of Ilarion Nakonechnyy > Date: Friday, March 26, 2021 at 1:26 PM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: FW: [11u] RFR: JDK-8236859 backport: WebSocket over > authenticating proxy fails with NPE > > Dear Sirs, kindly reminder about following review request. > > From: Ilarion Nakonechnyy > Date: Friday, 19 February 2021, 21:18 > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating > proxy fails with NPE > > > Dear sirs, I?d like to backport JDK-8236859 to JDK11. > > The bug causes jtreg test > java/net/httpclient/websocket/WebSocketProxyTest.java to fail with > timeout. > Was caught on x86_64 platform, but seems that it?s platform independent. > > Patch applied unclear, manually merged files > src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.j > ava and > src/java.net.http/share/classes/jdk/internal/net/http/HttpResponseImpl.jav > a > Jdk was built on Ubuntu x86_64 and tested with tier1 > > Could you please review my changes? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236859 > Webrev: http://cr.openjdk.java.net/~yan/8236859/webrev.11.0/ > > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 > > From ilarion at azul.com Mon Apr 12 17:16:32 2021 From: ilarion at azul.com (Ilarion Nakonechnyy) Date: Mon, 12 Apr 2021 17:16:32 +0000 Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy fails with NPE In-Reply-To: References: Message-ID: <15925337-3422-48DD-8E10-10EAD099D57F@azul.com> I've just run tier2 on ubuntu, get same results, looking into it. ?On 12.04.2021, 18:46, "Doerr, Martin" wrote: Hi all, unfortunately, this backport seems to cause many test failures: java/net/httpclient/websocket/WebSocketProxyTest.java java/net/httpclient/websocket/WebSocketTest.java java/net/httpclient/whitebox/AuthenticationFilterTestDriver.java java/net/httpclient/BasicAuthTest.java java/net/httpclient/DigestEchoClient.java java/net/httpclient/DigestEchoClientSSL.java java/net/httpclient/MultiAuthTest.java java/net/httpclient/ProxyAuthDisabledSchemes.java java/net/httpclient/ProxyAuthDisabledSchemesSSL.java java/net/httpclient/UnauthorizedTest.java With error messages like: Error. can't find jdk.test.lib.net.SimpleSSLContext in test directory or libraries Sent 401 Authentication response java.nio.channels.SocketChannel[connected local=/127.0.0.1:40237 remote=/127.0.0.1:53354] Error in connection: java.nio.channels.SocketChannel[connected local=/127.0.0.1:40237 remote=/127.0.0.1:53354], java.io.IOException: Bad request:[] Does anybody know what is going wrong? Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Freitag, 26. M?rz 2021 22:53 > To: Ilarion Nakonechnyy ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: JDK-8236859 backport: WebSocket over > authenticating proxy fails with NPE > > Lgtm, except in HttpResponseImpl.java, the new closeRawChannel method > looks like it needs its indentation fixed. > > In AuthenticationFilter.java, "return null" is in the scope of > "PROXY_AUTHORIZED" rather than the scope of "UNAUTHORIZED". That's > what I'd expect from looking at the existing 11u code, but the original patch > does more checking later on. There may be more backports that should be > done to incorporate that checking. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on > behalf of Ilarion Nakonechnyy > Date: Friday, March 26, 2021 at 1:26 PM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: FW: [11u] RFR: JDK-8236859 backport: WebSocket over > authenticating proxy fails with NPE > > Dear Sirs, kindly reminder about following review request. > > From: Ilarion Nakonechnyy > Date: Friday, 19 February 2021, 21:18 > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating > proxy fails with NPE > > > Dear sirs, I?d like to backport JDK-8236859 to JDK11. > > The bug causes jtreg test > java/net/httpclient/websocket/WebSocketProxyTest.java to fail with > timeout. > Was caught on x86_64 platform, but seems that it?s platform independent. > > Patch applied unclear, manually merged files > src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.j > ava and > src/java.net.http/share/classes/jdk/internal/net/http/HttpResponseImpl.jav > a > Jdk was built on Ubuntu x86_64 and tested with tier1 > > Could you please review my changes? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236859 > Webrev: http://cr.openjdk.java.net/~yan/8236859/webrev.11.0/ > > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 > > From hohensee at amazon.com Mon Apr 12 21:31:21 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 12 Apr 2021 21:31:21 +0000 Subject: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE Message-ID: <54B82370-E894-464C-ADBB-D083DB1708CA@amazon.com> The recent backport of 8236859 to 11.0.12 causes tier2 failures in java/net/httpclient. I?d like to revert the backport for now. Original issue: https://bugs.openjdk.java.net/browse/JDK-8236859 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 11.0.12 backport issue: https://bugs.openjdk.java.net/browse/JDK-8264988 11.0.12 patch: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/57e3fa3574ec Reversion issue: https://bugs.openjdk.java.net/browse/JDK-8265099 Reversion webrev: https://cr.openjdk.java.net/~phh/8265099/webrev.11u.00/ Thanks, Paul From christoph.langer at sap.com Mon Apr 12 21:56:40 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 12 Apr 2021 21:56:40 +0000 Subject: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE In-Reply-To: <54B82370-E894-464C-ADBB-D083DB1708CA@amazon.com> References: <54B82370-E894-464C-ADBB-D083DB1708CA@amazon.com> Message-ID: Hi Paul, I think reverting is fine. However, I don't know whether Ilarion will be able to provide a fix on short call. The error "can't find jdk.test.lib.net.SimpleSSLContext in test directory or libraries" sounds a bit like an infrastructure thing which maybe isn't too hard to repair? Maybe we want to give him a day or two and then just push a fix? What do you think (also @Ilarion...)? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Montag, 12. April 2021 23:31 > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] [11u] RFR: 8265099: Revert backport to 11u of > 8236859: WebSocket over authenticating proxy fails with NPE > > The recent backport of 8236859 to 11.0.12 causes tier2 failures in > java/net/httpclient. I?d like to revert the backport for now. > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8236859 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 > > 11.0.12 backport issue: https://bugs.openjdk.java.net/browse/JDK-8264988 > 11.0.12 patch: https://hg.openjdk.java.net/jdk-updates/jdk11u- > dev/rev/57e3fa3574ec > > Reversion issue: https://bugs.openjdk.java.net/browse/JDK-8265099 > Reversion webrev: > https://cr.openjdk.java.net/~phh/8265099/webrev.11u.00/ > > Thanks, > Paul From hohensee at amazon.com Mon Apr 12 21:59:49 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 12 Apr 2021 21:59:49 +0000 Subject: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Message-ID: <9E35908F-4234-426A-8F8C-BAF84FFCDE08@amazon.com> The corresponding #endif should have its comment updated to "// AARCH64 || PPC64". Otherwise lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Reingruber, Richard" Date: Monday, April 12, 2021 at 2:45 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Hi, Please help review this XXS backport of JDK-8244847 to 11u. Original bug (JDK16): https://bugs.openjdk.java.net/browse/JDK-8244847 https://git.openjdk.java.net/jdk/commit/4a267f1b 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8244847_11u_Linux_PPC__runtime_CompressedOops_CompressedClassPointers__smallHeapTest_fails/webrev.0/ Adaptations: In both codelines, JDK16 and JDK11u, the fix reuses code for AARCH64 to search for a free address block below 32g that can be used for a zerobased compressed class space also on PPC64. In JDK16 the method Metaspace::reserve_address_space_for_compressed_classes() holds that code. In JDK11u it is the method Metaspace::allocate_metaspace_compressed_klass_ptrs(). The test (CompressedClassPointers.java) is not changed because it's not disabled in 11u. Testing: CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From hohensee at amazon.com Mon Apr 12 22:03:28 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 12 Apr 2021 22:03:28 +0000 Subject: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE Message-ID: <853B0B47-E53B-4F14-A844-A6CDB069C2E2@amazon.com> I'd rather revert it now and file a redo issue. We don't know who might be doing 11u nightlies that are currently broken, and fixing the infrastructure may need another backport (or several). If the fix is just referencing a library that's in a different place, then the redo patch can include it. Thanks, Paul ?-----Original Message----- From: "Langer, Christoph" Date: Monday, April 12, 2021 at 2:57 PM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" , Ilarion Nakonechnyy Cc: "Doerr, Martin" Subject: RE: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE Hi Paul, I think reverting is fine. However, I don't know whether Ilarion will be able to provide a fix on short call. The error "can't find jdk.test.lib.net.SimpleSSLContext in test directory or libraries" sounds a bit like an infrastructure thing which maybe isn't too hard to repair? Maybe we want to give him a day or two and then just push a fix? What do you think (also @Ilarion...)? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Montag, 12. April 2021 23:31 > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] [11u] RFR: 8265099: Revert backport to 11u of > 8236859: WebSocket over authenticating proxy fails with NPE > > The recent backport of 8236859 to 11.0.12 causes tier2 failures in > java/net/httpclient. I?d like to revert the backport for now. > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8236859 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 > > 11.0.12 backport issue: https://bugs.openjdk.java.net/browse/JDK-8264988 > 11.0.12 patch: https://hg.openjdk.java.net/jdk-updates/jdk11u- > dev/rev/57e3fa3574ec > > Reversion issue: https://bugs.openjdk.java.net/browse/JDK-8265099 > Reversion webrev: > https://cr.openjdk.java.net/~phh/8265099/webrev.11u.00/ > > Thanks, > Paul From hohensee at amazon.com Mon Apr 12 22:04:24 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 12 Apr 2021 22:04:24 +0000 Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy fails with NPE Message-ID: And see my reversion RFR thread. Thanks, Paul ?-----Original Message----- From: Ilarion Nakonechnyy Date: Monday, April 12, 2021 at 10:17 AM To: "Doerr, Martin" , "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy fails with NPE I've just run tier2 on ubuntu, get same results, looking into it. On 12.04.2021, 18:46, "Doerr, Martin" wrote: Hi all, unfortunately, this backport seems to cause many test failures: java/net/httpclient/websocket/WebSocketProxyTest.java java/net/httpclient/websocket/WebSocketTest.java java/net/httpclient/whitebox/AuthenticationFilterTestDriver.java java/net/httpclient/BasicAuthTest.java java/net/httpclient/DigestEchoClient.java java/net/httpclient/DigestEchoClientSSL.java java/net/httpclient/MultiAuthTest.java java/net/httpclient/ProxyAuthDisabledSchemes.java java/net/httpclient/ProxyAuthDisabledSchemesSSL.java java/net/httpclient/UnauthorizedTest.java With error messages like: Error. can't find jdk.test.lib.net.SimpleSSLContext in test directory or libraries Sent 401 Authentication response java.nio.channels.SocketChannel[connected local=/127.0.0.1:40237 remote=/127.0.0.1:53354] Error in connection: java.nio.channels.SocketChannel[connected local=/127.0.0.1:40237 remote=/127.0.0.1:53354], java.io.IOException: Bad request:[] Does anybody know what is going wrong? Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Freitag, 26. M?rz 2021 22:53 > To: Ilarion Nakonechnyy ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: JDK-8236859 backport: WebSocket over > authenticating proxy fails with NPE > > Lgtm, except in HttpResponseImpl.java, the new closeRawChannel method > looks like it needs its indentation fixed. > > In AuthenticationFilter.java, "return null" is in the scope of > "PROXY_AUTHORIZED" rather than the scope of "UNAUTHORIZED". That's > what I'd expect from looking at the existing 11u code, but the original patch > does more checking later on. There may be more backports that should be > done to incorporate that checking. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on > behalf of Ilarion Nakonechnyy > Date: Friday, March 26, 2021 at 1:26 PM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: FW: [11u] RFR: JDK-8236859 backport: WebSocket over > authenticating proxy fails with NPE > > Dear Sirs, kindly reminder about following review request. > > From: Ilarion Nakonechnyy > Date: Friday, 19 February 2021, 21:18 > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating > proxy fails with NPE > > > Dear sirs, I?d like to backport JDK-8236859 to JDK11. > > The bug causes jtreg test > java/net/httpclient/websocket/WebSocketProxyTest.java to fail with > timeout. > Was caught on x86_64 platform, but seems that it?s platform independent. > > Patch applied unclear, manually merged files > src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.j > ava and > src/java.net.http/share/classes/jdk/internal/net/http/HttpResponseImpl.jav > a > Jdk was built on Ubuntu x86_64 and tested with tier1 > > Could you please review my changes? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236859 > Webrev: http://cr.openjdk.java.net/~yan/8236859/webrev.11.0/ > > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 > > From hohensee at amazon.com Mon Apr 12 22:08:01 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 12 Apr 2021 22:08:01 +0000 Subject: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE In-Reply-To: <853B0B47-E53B-4F14-A844-A6CDB069C2E2@amazon.com> References: <853B0B47-E53B-4F14-A844-A6CDB069C2E2@amazon.com> Message-ID: <3A104E2C-4B80-461D-A4F3-FBCC82F8344F@amazon.com> Also, reversion and redo is the tip dev process, which, having been subject to it :), imo is the right way to handle it for update releases. ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Monday, April 12, 2021 at 3:04 PM To: "Langer, Christoph" , "jdk-updates-dev at openjdk.java.net" , Ilarion Nakonechnyy Cc: "Doerr, Martin" Subject: Re: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE I'd rather revert it now and file a redo issue. We don't know who might be doing 11u nightlies that are currently broken, and fixing the infrastructure may need another backport (or several). If the fix is just referencing a library that's in a different place, then the redo patch can include it. Thanks, Paul -----Original Message----- From: "Langer, Christoph" Date: Monday, April 12, 2021 at 2:57 PM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" , Ilarion Nakonechnyy Cc: "Doerr, Martin" Subject: RE: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE Hi Paul, I think reverting is fine. However, I don't know whether Ilarion will be able to provide a fix on short call. The error "can't find jdk.test.lib.net.SimpleSSLContext in test directory or libraries" sounds a bit like an infrastructure thing which maybe isn't too hard to repair? Maybe we want to give him a day or two and then just push a fix? What do you think (also @Ilarion...)? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Montag, 12. April 2021 23:31 > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] [11u] RFR: 8265099: Revert backport to 11u of > 8236859: WebSocket over authenticating proxy fails with NPE > > The recent backport of 8236859 to 11.0.12 causes tier2 failures in > java/net/httpclient. I?d like to revert the backport for now. > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8236859 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 > > 11.0.12 backport issue: https://bugs.openjdk.java.net/browse/JDK-8264988 > 11.0.12 patch: https://hg.openjdk.java.net/jdk-updates/jdk11u- > dev/rev/57e3fa3574ec > > Reversion issue: https://bugs.openjdk.java.net/browse/JDK-8265099 > Reversion webrev: > https://cr.openjdk.java.net/~phh/8265099/webrev.11u.00/ > > Thanks, > Paul From christoph.langer at sap.com Mon Apr 12 22:15:33 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 12 Apr 2021 22:15:33 +0000 Subject: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE In-Reply-To: <3A104E2C-4B80-461D-A4F3-FBCC82F8344F@amazon.com> References: <853B0B47-E53B-4F14-A844-A6CDB069C2E2@amazon.com> <3A104E2C-4B80-461D-A4F3-FBCC82F8344F@amazon.com> Message-ID: OK, I agree. The reversion looks correct to me. I've also approved the issue in JBS. Cheers Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Dienstag, 13. April 2021 00:08 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; Ilarion Nakonechnyy > Cc: Doerr, Martin > Subject: Re: [11u] RFR: 8265099: Revert backport to 11u of 8236859: > WebSocket over authenticating proxy fails with NPE > > Also, reversion and redo is the tip dev process, which, having been subject to > it :), imo is the right way to handle it for update releases. > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Hohensee, Paul" > Date: Monday, April 12, 2021 at 3:04 PM > To: "Langer, Christoph" , "jdk-updates- > dev at openjdk.java.net" , Ilarion > Nakonechnyy > Cc: "Doerr, Martin" > Subject: Re: [11u] RFR: 8265099: Revert backport to 11u of 8236859: > WebSocket over authenticating proxy fails with NPE > > I'd rather revert it now and file a redo issue. We don't know who might be > doing 11u nightlies that are currently broken, and fixing the infrastructure > may need another backport (or several). If the fix is just referencing a library > that's in a different place, then the redo patch can include it. > > Thanks, > Paul > > -----Original Message----- > From: "Langer, Christoph" > Date: Monday, April 12, 2021 at 2:57 PM > To: "Hohensee, Paul" , "jdk-updates- > dev at openjdk.java.net" , Ilarion > Nakonechnyy > Cc: "Doerr, Martin" > Subject: RE: [11u] RFR: 8265099: Revert backport to 11u of 8236859: > WebSocket over authenticating proxy fails with NPE > > Hi Paul, > > I think reverting is fine. However, I don't know whether Ilarion will be able to > provide a fix on short call. The error "can't find > jdk.test.lib.net.SimpleSSLContext in test directory or libraries" sounds a bit > like an infrastructure thing which maybe isn't too hard to repair? Maybe we > want to give him a day or two and then just push a fix? What do you think > (also @Ilarion...)? > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Hohensee, Paul > > Sent: Montag, 12. April 2021 23:31 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [DMARC FAILURE] [11u] RFR: 8265099: Revert backport to 11u of > > 8236859: WebSocket over authenticating proxy fails with NPE > > > > The recent backport of 8236859 to 11.0.12 causes tier2 failures in > > java/net/httpclient. I?d like to revert the backport for now. > > > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8236859 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 > > > > 11.0.12 backport issue: https://bugs.openjdk.java.net/browse/JDK- > 8264988 > > 11.0.12 patch: https://hg.openjdk.java.net/jdk-updates/jdk11u- > > dev/rev/57e3fa3574ec > > > > Reversion issue: https://bugs.openjdk.java.net/browse/JDK-8265099 > > Reversion webrev: > > https://cr.openjdk.java.net/~phh/8265099/webrev.11u.00/ > > > > Thanks, > > Paul > > From hohensee at amazon.com Mon Apr 12 22:32:10 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 12 Apr 2021 22:32:10 +0000 Subject: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE Message-ID: <9298BEB7-FCE4-484D-A505-C8237974FCED@amazon.com> Thanks, Christoph. Pushed. ?-----Original Message----- From: "Langer, Christoph" Date: Monday, April 12, 2021 at 3:16 PM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" , Ilarion Nakonechnyy Cc: "Doerr, Martin" Subject: RE: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE OK, I agree. The reversion looks correct to me. I've also approved the issue in JBS. Cheers Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Dienstag, 13. April 2021 00:08 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; Ilarion Nakonechnyy > Cc: Doerr, Martin > Subject: Re: [11u] RFR: 8265099: Revert backport to 11u of 8236859: > WebSocket over authenticating proxy fails with NPE > > Also, reversion and redo is the tip dev process, which, having been subject to > it :), imo is the right way to handle it for update releases. > > -----Original Message----- > From: jdk-updates-dev on > behalf of "Hohensee, Paul" > Date: Monday, April 12, 2021 at 3:04 PM > To: "Langer, Christoph" , "jdk-updates- > dev at openjdk.java.net" , Ilarion > Nakonechnyy > Cc: "Doerr, Martin" > Subject: Re: [11u] RFR: 8265099: Revert backport to 11u of 8236859: > WebSocket over authenticating proxy fails with NPE > > I'd rather revert it now and file a redo issue. We don't know who might be > doing 11u nightlies that are currently broken, and fixing the infrastructure > may need another backport (or several). If the fix is just referencing a library > that's in a different place, then the redo patch can include it. > > Thanks, > Paul > > -----Original Message----- > From: "Langer, Christoph" > Date: Monday, April 12, 2021 at 2:57 PM > To: "Hohensee, Paul" , "jdk-updates- > dev at openjdk.java.net" , Ilarion > Nakonechnyy > Cc: "Doerr, Martin" > Subject: RE: [11u] RFR: 8265099: Revert backport to 11u of 8236859: > WebSocket over authenticating proxy fails with NPE > > Hi Paul, > > I think reverting is fine. However, I don't know whether Ilarion will be able to > provide a fix on short call. The error "can't find > jdk.test.lib.net.SimpleSSLContext in test directory or libraries" sounds a bit > like an infrastructure thing which maybe isn't too hard to repair? Maybe we > want to give him a day or two and then just push a fix? What do you think > (also @Ilarion...)? > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Hohensee, Paul > > Sent: Montag, 12. April 2021 23:31 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [DMARC FAILURE] [11u] RFR: 8265099: Revert backport to 11u of > > 8236859: WebSocket over authenticating proxy fails with NPE > > > > The recent backport of 8236859 to 11.0.12 causes tier2 failures in > > java/net/httpclient. I?d like to revert the backport for now. > > > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8236859 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 > > > > 11.0.12 backport issue: https://bugs.openjdk.java.net/browse/JDK- > 8264988 > > 11.0.12 patch: https://hg.openjdk.java.net/jdk-updates/jdk11u- > > dev/rev/57e3fa3574ec > > > > Reversion issue: https://bugs.openjdk.java.net/browse/JDK-8265099 > > Reversion webrev: > > https://cr.openjdk.java.net/~phh/8265099/webrev.11u.00/ > > > > Thanks, > > Paul > > From lutz.schmidt at sap.com Tue Apr 13 07:51:04 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 13 Apr 2021 07:51:04 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Message-ID: <12835CAD-871B-4B8E-8719-8E09D8AF1F0A@sap.com> Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From richard.reingruber at sap.com Tue Apr 13 08:59:04 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 13 Apr 2021 08:59:04 +0000 Subject: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails In-Reply-To: <9E35908F-4234-426A-8F8C-BAF84FFCDE08@amazon.com> References: <9E35908F-4234-426A-8F8C-BAF84FFCDE08@amazon.com> Message-ID: > The corresponding #endif should have its comment updated to "// AARCH64 || PPC64". Otherwise lgtm. Done. http://cr.openjdk.java.net/~rrich/webrevs/8244847_11u_Linux_PPC__runtime_CompressedOops_CompressedClassPointers__smallHeapTest_fails/webrev.1/ Thanks for the review! Richard. -----Original Message----- From: Hohensee, Paul Sent: Dienstag, 13. April 2021 00:00 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: Re: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails The corresponding #endif should have its comment updated to "// AARCH64 || PPC64". Otherwise lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Reingruber, Richard" Date: Monday, April 12, 2021 at 2:45 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Hi, Please help review this XXS backport of JDK-8244847 to 11u. Original bug (JDK16): https://bugs.openjdk.java.net/browse/JDK-8244847 https://git.openjdk.java.net/jdk/commit/4a267f1b 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8244847_11u_Linux_PPC__runtime_CompressedOops_CompressedClassPointers__smallHeapTest_fails/webrev.0/ Adaptations: In both codelines, JDK16 and JDK11u, the fix reuses code for AARCH64 to search for a free address block below 32g that can be used for a zerobased compressed class space also on PPC64. In JDK16 the method Metaspace::reserve_address_space_for_compressed_classes() holds that code. In JDK11u it is the method Metaspace::allocate_metaspace_compressed_klass_ptrs(). The test (CompressedClassPointers.java) is not changed because it's not disabled in 11u. Testing: CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From daniel.fuchs at oracle.com Tue Apr 13 09:11:35 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Apr 2021 10:11:35 +0100 Subject: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE In-Reply-To: References: <54B82370-E894-464C-ADBB-D083DB1708CA@amazon.com> Message-ID: Hi Christoph, On 12/04/2021 22:56, Langer, Christoph wrote: > I think reverting is fine. However, I don't know whether Ilarion will be able to provide a fix on short call. The error "can't find jdk.test.lib.net.SimpleSSLContext in test directory or libraries" sounds a bit like an infrastructure thing which maybe isn't too hard to repair? Maybe we want to give him a day or two and then just push a fix? What do you think (also @Ilarion...)? FWIW: I suspect SimpleSSLContext may have been relocated in the mainline, it might have a different package name / may need a different @library tag to build it in 11u. `find test -name SimpleSSLContext.java` should reveal its location. Other HttpClient tests that make use of HTTPS in the 11u test base should reveal the proper incantation to build it. best regards, -- daniel From christoph.langer at sap.com Tue Apr 13 11:57:19 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 13 Apr 2021 11:57:19 +0000 Subject: [11u] RFR: 8265099: Revert backport to 11u of 8236859: WebSocket over authenticating proxy fails with NPE In-Reply-To: References: <54B82370-E894-464C-ADBB-D083DB1708CA@amazon.com> Message-ID: Hi Daniel, thanks for your help, I'm sure it will be of use for Ilarion. Best regards Christoph > -----Original Message----- > From: Daniel Fuchs > Sent: Dienstag, 13. April 2021 11:12 > To: Langer, Christoph ; Hohensee, Paul > ; jdk-updates-dev at openjdk.java.net; Ilarion > Nakonechnyy > Cc: Doerr, Martin > Subject: Re: [11u] RFR: 8265099: Revert backport to 11u of 8236859: > WebSocket over authenticating proxy fails with NPE > > Hi Christoph, > > On 12/04/2021 22:56, Langer, Christoph wrote: > > I think reverting is fine. However, I don't know whether Ilarion will be able > to provide a fix on short call. The error "can't find > jdk.test.lib.net.SimpleSSLContext in test directory or libraries" sounds a bit > like an infrastructure thing which maybe isn't too hard to repair? Maybe we > want to give him a day or two and then just push a fix? What do you think > (also @Ilarion...)? > > FWIW: I suspect SimpleSSLContext may have been relocated in > the mainline, it might have a different package name / may > need a different @library tag to build it in 11u. > > `find test -name SimpleSSLContext.java` should reveal its > location. > > Other HttpClient tests that make use of HTTPS in the 11u test > base should reveal the proper incantation to build it. > > best regards, > > -- daniel From hohensee at amazon.com Tue Apr 13 14:31:42 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 13 Apr 2021 14:31:42 +0000 Subject: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Message-ID: Looks good! ?-----Original Message----- From: "Reingruber, Richard" Date: Tuesday, April 13, 2021 at 1:59 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails > The corresponding #endif should have its comment updated to "// AARCH64 || PPC64". Otherwise lgtm. Done. http://cr.openjdk.java.net/~rrich/webrevs/8244847_11u_Linux_PPC__runtime_CompressedOops_CompressedClassPointers__smallHeapTest_fails/webrev.1/ Thanks for the review! Richard. -----Original Message----- From: Hohensee, Paul Sent: Dienstag, 13. April 2021 00:00 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: Re: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails The corresponding #endif should have its comment updated to "// AARCH64 || PPC64". Otherwise lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Reingruber, Richard" Date: Monday, April 12, 2021 at 2:45 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Hi, Please help review this XXS backport of JDK-8244847 to 11u. Original bug (JDK16): https://bugs.openjdk.java.net/browse/JDK-8244847 https://git.openjdk.java.net/jdk/commit/4a267f1b 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8244847_11u_Linux_PPC__runtime_CompressedOops_CompressedClassPointers__smallHeapTest_fails/webrev.0/ Adaptations: In both codelines, JDK16 and JDK11u, the fix reuses code for AARCH64 to search for a free address block below 32g that can be used for a zerobased compressed class space also on PPC64. In JDK16 the method Metaspace::reserve_address_space_for_compressed_classes() holds that code. In JDK11u it is the method Metaspace::allocate_metaspace_compressed_klass_ptrs(). The test (CompressedClassPointers.java) is not changed because it's not disabled in 11u. Testing: CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From richard.reingruber at sap.com Tue Apr 13 14:32:36 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 13 Apr 2021 14:32:36 +0000 Subject: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails In-Reply-To: References: Message-ID: Thanks! :) -----Original Message----- From: Hohensee, Paul Sent: Dienstag, 13. April 2021 16:32 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: Re: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Looks good! ?-----Original Message----- From: "Reingruber, Richard" Date: Tuesday, April 13, 2021 at 1:59 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails > The corresponding #endif should have its comment updated to "// AARCH64 || PPC64". Otherwise lgtm. Done. http://cr.openjdk.java.net/~rrich/webrevs/8244847_11u_Linux_PPC__runtime_CompressedOops_CompressedClassPointers__smallHeapTest_fails/webrev.1/ Thanks for the review! Richard. -----Original Message----- From: Hohensee, Paul Sent: Dienstag, 13. April 2021 00:00 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: Re: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails The corresponding #endif should have its comment updated to "// AARCH64 || PPC64". Otherwise lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Reingruber, Richard" Date: Monday, April 12, 2021 at 2:45 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Hi, Please help review this XXS backport of JDK-8244847 to 11u. Original bug (JDK16): https://bugs.openjdk.java.net/browse/JDK-8244847 https://git.openjdk.java.net/jdk/commit/4a267f1b 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8244847_11u_Linux_PPC__runtime_CompressedOops_CompressedClassPointers__smallHeapTest_fails/webrev.0/ Adaptations: In both codelines, JDK16 and JDK11u, the fix reuses code for AARCH64 to search for a free address block below 32g that can be used for a zerobased compressed class space also on PPC64. In JDK16 the method Metaspace::reserve_address_space_for_compressed_classes() holds that code. In JDK11u it is the method Metaspace::allocate_metaspace_compressed_klass_ptrs(). The test (CompressedClassPointers.java) is not changed because it's not disabled in 11u. Testing: CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From sgehwolf at openjdk.java.net Tue Apr 13 16:06:06 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 13 Apr 2021 16:06:06 GMT Subject: [jdk16u] Integrated: 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 09:39:24 GMT, Severin Gehwolf wrote: > 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt This pull request has now been integrated. Changeset: 2826d304 Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk16u/commit/2826d304 Stats: 14 lines in 2 files changed: 0 ins; 0 del; 14 mod 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt Backport-of: eb6330e4f0366878e7ec8a606ddc717622cbdaea ------------- PR: https://git.openjdk.java.net/jdk16u/pull/103 From zgu at redhat.com Tue Apr 13 16:07:30 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 13 Apr 2021 12:07:30 -0400 Subject: [11u] RFR 8262110: DST starts from incorrect time in 2038 Message-ID: Please review this 11u backport for parity with Oracle 11.0.12. The original bug: https://bugs.openjdk.java.net/browse/JDK-8073446 The original patch: https://github.com/openjdk/jdk/commit/7284f013 The original patch does not apply cleanly. The only conflict is the copyright year of ZoneInfo.java file. 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8262110-11u/webrev.00/ Test: Passed the new test in the patch. Thanks, -Zhengyu From zgu at redhat.com Tue Apr 13 16:20:41 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 13 Apr 2021 12:20:41 -0400 Subject: [11u] RFR 8262110: DST starts from incorrect time in 2038 In-Reply-To: References: Message-ID: It looks like that it is a duplicate of JDK-8073446 [1]. [1] https://bugs.openjdk.java.net/browse/JDK-8073446 On 4/13/21 12:07 PM, Zhengyu Gu wrote: > Please review this 11u backport for parity with Oracle 11.0.12. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8073446 > The original patch: https://github.com/openjdk/jdk/commit/7284f013 > > The original patch does not apply cleanly. The only conflict is the > copyright year of ZoneInfo.java file. > > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8262110-11u/webrev.00/ > > Test: > ? Passed the new test in the patch. > > Thanks, > > -Zhengyu From lutz.schmidt at sap.com Tue Apr 13 20:02:27 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 13 Apr 2021 20:02:27 +0000 Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use Compile_lock in favour of fancy checks In-Reply-To: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com> References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com> Message-ID: <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com> Sorry for spamming, forgot jdk-updates-dev. Lutz ?On 13.04.21, 21:43, "Schmidt, Lutz" wrote: Dear Community, I would appreciate receiving reviews for this downport change. It is a small change in one file only. Unfortunately, it did not apply clean. Original bug: https://bugs.openjdk.java.net/browse/JDK-8250635 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/ Tests: SAP's internal build and test farm. Results pending. Thank you! Lutz From hohensee at amazon.com Tue Apr 13 23:05:56 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 13 Apr 2021 23:05:56 +0000 Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use Compile_lock in favour of fancy checks Message-ID: <5C8796FB-7411-42B6-BE8B-96A9DC9E8107@amazon.com> Lgtm, assuming tests pass. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 1:03 PM To: "hotspot-compiler-dev at openjdk.java.net" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use Compile_lock in favour of fancy checks Sorry for spamming, forgot jdk-updates-dev. Lutz On 13.04.21, 21:43, "Schmidt, Lutz" wrote: Dear Community, I would appreciate receiving reviews for this downport change. It is a small change in one file only. Unfortunately, it did not apply clean. Original bug: https://bugs.openjdk.java.net/browse/JDK-8250635 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/ Tests: SAP's internal build and test farm. Results pending. Thank you! Lutz From rrich at openjdk.java.net Wed Apr 14 07:43:09 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 14 Apr 2021 07:43:09 GMT Subject: [jdk16u] Integrated: 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> References: <2bA7WHvRUvahdKslg3shsMexkblkQOpKSx354KZ82po=.48c81ae3-86cb-4e87-94f9-0d71cd7c225f@github.com> Message-ID: <6yzDc0V3Bk3rScdNaF-Obwf916LVdcmG7kRvfmkP7Wg=.dce8f864-aaba-491f-9a13-c4d4103861b9@github.com> On Thu, 1 Apr 2021 11:07:44 GMT, Richard Reingruber wrote: > This is the jdk16u backport of the fix for JDK-8262295. > The fix applies cleanly. > The test required trivial adaptation: I had to remove the package from the class ClassFileInstaller. > > The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms. This pull request has now been integrated. Changeset: 8ddb1d84 Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk16u/commit/8ddb1d84 Stats: 120 lines in 2 files changed: 119 ins; 0 del; 1 mod 8262295: C2: Out-of-Bounds Array Load from Clone Source Reviewed-by: thartmann Backport-of: 9689863ac0bac8c542162d4af30fec078e9c91b4 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/101 From yan at openjdk.java.net Wed Apr 14 07:43:26 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 14 Apr 2021 07:43:26 GMT Subject: [jdk15u-dev] Integrated: 8262110: DST starts from incorrect time in 2038 Message-ID: Fix is surprisingly small, the patch applies without shifts, regtest do pass ------------- Commit messages: - Backport 7284f013ea3064b2aa643658938ccaafdfa1c885 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/23/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=23&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262110 Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/23.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/23/head:pull/23 PR: https://git.openjdk.java.net/jdk15u-dev/pull/23 From yan at openjdk.java.net Wed Apr 14 07:43:28 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 14 Apr 2021 07:43:28 GMT Subject: [jdk15u-dev] Integrated: 8262110: DST starts from incorrect time in 2038 In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 07:33:01 GMT, Yuri Nesterenko wrote: > Fix is surprisingly small, the patch applies without shifts, regtest do pass This pull request has now been integrated. Changeset: 698dd44f Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/698dd44f Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod 8262110: DST starts from incorrect time in 2038 8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137 Backport-of: 7284f013ea3064b2aa643658938ccaafdfa1c885 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/23 From sgehwolf at redhat.com Wed Apr 14 07:57:09 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 14 Apr 2021 09:57:09 +0200 Subject: [11u] RFR 8262110: DST starts from incorrect time in 2038 In-Reply-To: References: Message-ID: <7896535f45938cddfe892cb3559e9af22ddbbf85.camel@redhat.com> On Tue, 2021-04-13 at 12:20 -0400, Zhengyu Gu wrote: > > 11u webrev: > > http://cr.openjdk.java.net/~zgu/JDK-8262110-11u/webrev.00/ This looks fine. Thanks, Severin From martin.doerr at sap.com Wed Apr 14 09:06:52 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 14 Apr 2021 09:06:52 +0000 Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use Compile_lock in favour of fancy checks In-Reply-To: <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com> References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com> <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com> Message-ID: Hi Lutz, your backport looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Schmidt, Lutz > Sent: Dienstag, 13. April 2021 22:02 > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram should > use Compile_lock in favour of fancy checks > > Sorry for spamming, forgot jdk-updates-dev. > Lutz > > ?On 13.04.21, 21:43, "Schmidt, Lutz" wrote: > > Dear Community, > > I would appreciate receiving reviews for this downport change. It is a small > change in one file only. Unfortunately, it did not apply clean. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8250635 > Downport webrev: > https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/ > > Tests: > SAP's internal build and test farm. Results pending. > > Thank you! > Lutz > > From lutz.schmidt at sap.com Wed Apr 14 09:18:18 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 14 Apr 2021 09:18:18 +0000 Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use Compile_lock in favour of fancy checks In-Reply-To: References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com> <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com> Message-ID: <40507412-5F59-4623-BA39-728CA14F9C64@sap.com> Thank you, Martin and Paul, for your reviews. Submit will have to wait another day. I was too late for testing last night. I will need a sponsor anyway. Is it ok to contact you, Martin, once the tests are done successfully? Thanks, Lutz ?On 14.04.21, 11:06, "Doerr, Martin" wrote: Hi Lutz, your backport looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Schmidt, Lutz > Sent: Dienstag, 13. April 2021 22:02 > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram should > use Compile_lock in favour of fancy checks > > Sorry for spamming, forgot jdk-updates-dev. > Lutz > > On 13.04.21, 21:43, "Schmidt, Lutz" wrote: > > Dear Community, > > I would appreciate receiving reviews for this downport change. It is a small > change in one file only. Unfortunately, it did not apply clean. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8250635 > Downport webrev: > https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/ > > Tests: > SAP's internal build and test farm. Results pending. > > Thank you! > Lutz > > From martin.doerr at sap.com Wed Apr 14 09:21:31 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 14 Apr 2021 09:21:31 +0000 Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use Compile_lock in favour of fancy checks In-Reply-To: <40507412-5F59-4623-BA39-728CA14F9C64@sap.com> References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com> <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com> <40507412-5F59-4623-BA39-728CA14F9C64@sap.com> Message-ID: Yes. Just let me know when it's ready. Best regards, Martin > -----Original Message----- > From: Schmidt, Lutz > Sent: Mittwoch, 14. April 2021 11:18 > To: Doerr, Martin ; hotspot-compiler- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Hohensee, > Paul > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram should > use Compile_lock in favour of fancy checks > > Thank you, Martin and Paul, for your reviews. > > Submit will have to wait another day. I was too late for testing last night. > > I will need a sponsor anyway. Is it ok to contact you, Martin, once the tests > are done successfully? > > Thanks, > Lutz > > ?On 14.04.21, 11:06, "Doerr, Martin" wrote: > > Hi Lutz, > > your backport looks good. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Schmidt, Lutz > > Sent: Dienstag, 13. April 2021 22:02 > > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > > dev at openjdk.java.net > > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram > should > > use Compile_lock in favour of fancy checks > > > > Sorry for spamming, forgot jdk-updates-dev. > > Lutz > > > > On 13.04.21, 21:43, "Schmidt, Lutz" wrote: > > > > Dear Community, > > > > I would appreciate receiving reviews for this downport change. It is a > small > > change in one file only. Unfortunately, it did not apply clean. > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8250635 > > Downport webrev: > > https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/ > > > > Tests: > > SAP's internal build and test farm. Results pending. > > > > Thank you! > > Lutz > > > > > From lutz.schmidt at sap.com Wed Apr 14 09:41:27 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 14 Apr 2021 09:41:27 +0000 Subject: [11u] 8264848 backport: [macos] libjvm.dylib linker warning due to macOS version mismatch Message-ID: <6F59178E-F5AB-496E-ADAB-5D8C26B06B27@sap.com> Hi, I need a sponsor to bring the fix to jdk11u-dev. Would someone volunteer, please? The patch applied cleanly to jdk11u-dev and the downport was approved. Original Bug: https://bugs.openjdk.java.net/browse/JDK-8264848 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8264848.11u.01/ Thank you! Lutz From goetz.lindenmaier at sap.com Wed Apr 14 10:01:10 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Apr 2021 10:01:10 +0000 Subject: [11u] 8264848 backport: [macos] libjvm.dylib linker warning due to macOS version mismatch In-Reply-To: <6F59178E-F5AB-496E-ADAB-5D8C26B06B27@sap.com> References: <6F59178E-F5AB-496E-ADAB-5D8C26B06B27@sap.com> Message-ID: Hi Lutz, Sure, I can sponsor this. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Schmidt, Lutz > Sent: Wednesday, April 14, 2021 11:41 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] 8264848 backport: [macos] libjvm.dylib linker warning due to > macOS version mismatch > > Hi, > > I need a sponsor to bring the fix to jdk11u-dev. Would someone volunteer, > please? > > The patch applied cleanly to jdk11u-dev and the downport was approved. > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8264848 > Downport webrev: > https://cr.openjdk.java.net/~lucy/webrevs/8264848.11u.01/ > > Thank you! > Lutz > > From christoph.goettschkes at microdoc.com Wed Apr 14 10:01:05 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Wed, 14 Apr 2021 12:01:05 +0200 Subject: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode Message-ID: <37wx4h84x6-1@userp2050.oracle.com> Hi, could someone please sponsor this clean and already approved backport of 8208061 to 11u? Bug: https://bugs.openjdk.java.net/browse/JDK-8208061 Original commit (OpenJDK 12): https://hg.openjdk.java.net/jdk/jdk/rev/73523d329966 Webrev: https://cr.openjdk.java.net/~cgo/8208061/webrev.11u.00/ Thanks, Christoph From lutz.schmidt at sap.com Wed Apr 14 10:02:44 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 14 Apr 2021 10:02:44 +0000 Subject: [11u] 8264848 backport: [macos] libjvm.dylib linker warning due to macOS version mismatch In-Reply-To: References: <6F59178E-F5AB-496E-ADAB-5D8C26B06B27@sap.com> Message-ID: <9A883184-5676-4914-8FB0-0539EBE01D87@sap.com> Thank you, Goetz! Cheers, Lutz ?On 14.04.21, 12:01, "Lindenmaier, Goetz" wrote: Hi Lutz, Sure, I can sponsor this. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Schmidt, Lutz > Sent: Wednesday, April 14, 2021 11:41 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] 8264848 backport: [macos] libjvm.dylib linker warning due to > macOS version mismatch > > Hi, > > I need a sponsor to bring the fix to jdk11u-dev. Would someone volunteer, > please? > > The patch applied cleanly to jdk11u-dev and the downport was approved. > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8264848 > Downport webrev: > https://cr.openjdk.java.net/~lucy/webrevs/8264848.11u.01/ > > Thank you! > Lutz > > From zgu at redhat.com Wed Apr 14 12:18:07 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 14 Apr 2021 08:18:07 -0400 Subject: [11u] RFR 8262110: DST starts from incorrect time in 2038 In-Reply-To: <7896535f45938cddfe892cb3559e9af22ddbbf85.camel@redhat.com> References: <7896535f45938cddfe892cb3559e9af22ddbbf85.camel@redhat.com> Message-ID: <22f0926b-9505-3c81-b3d7-fcde2e5696a6@redhat.com> Thanks, Severin. Tagged for approval. -Zhengyu On 4/14/21 3:57 AM, Severin Gehwolf wrote: > On Tue, 2021-04-13 at 12:20 -0400, Zhengyu Gu wrote: >>> 11u webrev: >>> http://cr.openjdk.java.net/~zgu/JDK-8262110-11u/webrev.00/ > > This looks fine. > > Thanks, > Severin > > From hohensee at amazon.com Wed Apr 14 15:22:22 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Apr 2021 15:22:22 +0000 Subject: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode Message-ID: I'll sponsor it. Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Christoph G?ttschkes Date: Wednesday, April 14, 2021 at 3:03 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode Hi, could someone please sponsor this clean and already approved backport of 8208061 to 11u? Bug: https://bugs.openjdk.java.net/browse/JDK-8208061 Original commit (OpenJDK 12): https://hg.openjdk.java.net/jdk/jdk/rev/73523d329966 Webrev: https://cr.openjdk.java.net/~cgo/8208061/webrev.11u.00/ Thanks, Christoph From hohensee at amazon.com Wed Apr 14 15:28:32 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Apr 2021 15:28:32 +0000 Subject: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode In-Reply-To: References: Message-ID: Pushed. ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Wednesday, April 14, 2021 at 8:23 AM To: Christoph G?ttschkes , "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode I'll sponsor it. Paul -----Original Message----- From: jdk-updates-dev on behalf of Christoph G?ttschkes Date: Wednesday, April 14, 2021 at 3:03 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode Hi, could someone please sponsor this clean and already approved backport of 8208061 to 11u? Bug: https://bugs.openjdk.java.net/browse/JDK-8208061 Original commit (OpenJDK 12): https://hg.openjdk.java.net/jdk/jdk/rev/73523d329966 Webrev: https://cr.openjdk.java.net/~cgo/8208061/webrev.11u.00/ Thanks, Christoph From lutz.schmidt at sap.com Wed Apr 14 16:08:40 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 14 Apr 2021 16:08:40 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Message-ID: Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From vkempik at azul.com Wed Apr 14 16:24:36 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 14 Apr 2021 16:24:36 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: <12835CAD-871B-4B8E-8719-8E09D8AF1F0A@sap.com> References: <12835CAD-871B-4B8E-8719-8E09D8AF1F0A@sap.com> Message-ID: Hello this backport is pretty much needed in jdk11u-dev as it?s one of prerequests (soft one tho) for jep-391 to apply more cleanly. I was doing this backport multiple times (including to zulu11) and know what a PITA it is. Looking forward for integration of this into 11u. Regards, Vladimir. > 13 ???. 2021 ?., ? 10:51, Schmidt, Lutz ???????(?): > > Dear Community, > > I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 > Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ > Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts > Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve > > Tests: > SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. > > Your effort is very much appreciated! > > Thanks, > Lutz > > P.S.: build-dev on CC: because a small build change is included. > From hohensee at amazon.com Wed Apr 14 17:01:20 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Apr 2021 17:01:20 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Message-ID: <275E669F-DFF5-45ED-AE2D-F691CA6D07EC@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From lutz.schmidt at sap.com Wed Apr 14 17:05:26 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 14 Apr 2021 17:05:26 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: <275E669F-DFF5-45ED-AE2D-F691CA6D07EC@amazon.com> References: <275E669F-DFF5-45ED-AE2D-F691CA6D07EC@amazon.com> Message-ID: Thanks for reviewing, Paul! Best, Lutz ?On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From jianglizhou at google.com Wed Apr 14 17:41:11 2021 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 14 Apr 2021 10:41:11 -0700 Subject: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode In-Reply-To: <37wx4h84x6-1@userp2050.oracle.com> References: <37wx4h84x6-1@userp2050.oracle.com> Message-ID: Hi Christoph, I'll sponsor you. Will try committing later today. Best, Jiangli On Wed, Apr 14, 2021 at 3:02 AM Christoph G?ttschkes < christoph.goettschkes at microdoc.com> wrote: > Hi, > > could someone please sponsor this clean and already approved backport of > 8208061 to 11u? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208061 > Original commit (OpenJDK 12): > https://hg.openjdk.java.net/jdk/jdk/rev/73523d329966 > Webrev: https://cr.openjdk.java.net/~cgo/8208061/webrev.11u.00/ > > Thanks, > Christoph > > From jianglizhou at google.com Wed Apr 14 18:45:15 2021 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 14 Apr 2021 11:45:15 -0700 Subject: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode In-Reply-To: References: <37wx4h84x6-1@userp2050.oracle.com> Message-ID: I see it's already done early this morning: :) URL: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/f1c95ed33ee9 User: phh Date: 2021-04-14 15:28:17 +0000 Best, Jiangli On Wed, Apr 14, 2021 at 10:41 AM Jiangli Zhou wrote: > > Hi Christoph, > > I'll sponsor you. Will try committing later today. > > Best, > Jiangli > > On Wed, Apr 14, 2021 at 3:02 AM Christoph G?ttschkes wrote: >> >> Hi, >> >> could someone please sponsor this clean and already approved backport of 8208061 to 11u? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8208061 >> Original commit (OpenJDK 12): https://hg.openjdk.java.net/jdk/jdk/rev/73523d329966 >> Webrev: https://cr.openjdk.java.net/~cgo/8208061/webrev.11u.00/ >> >> Thanks, >> Christoph >> From clanger at openjdk.java.net Thu Apr 15 05:59:07 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 15 Apr 2021 05:59:07 GMT Subject: [jdk16u] RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding Message-ID: Backport of 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding ------------- Commit messages: - Backport 1ee80e03adfae5f428519f7c134e78a0f277a0a5 Changes: https://git.openjdk.java.net/jdk16u/pull/105/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=105&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261355 Stats: 245 lines in 2 files changed: 163 ins; 29 del; 53 mod Patch: https://git.openjdk.java.net/jdk16u/pull/105.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/105/head:pull/105 PR: https://git.openjdk.java.net/jdk16u/pull/105 From christoph.goettschkes at microdoc.com Thu Apr 15 07:33:41 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Thu, 15 Apr 2021 09:33:41 +0200 Subject: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode In-Reply-To: References: <37wx4h84x6-1@userp2050.oracle.com> Message-ID: <37xgyu07wx-1@userp2050.oracle.com> On 4/14/21 8:45 PM, Jiangli Zhou wrote: > I see it's already done early this morning: :) > > URL: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/f1c95ed33ee9 > User: phh > Date: 2021-04-14 15:28:17 +0000 Thanks for looking into this. Yes, Paul already sponsor this change. From christoph.goettschkes at microdoc.com Thu Apr 15 07:32:45 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Thu, 15 Apr 2021 09:32:45 +0200 Subject: [11u] 8208061: runtime/LoadClass/TestResize.java fails with "Load factor too high" when running in CDS mode In-Reply-To: References: Message-ID: <37x9hq6ycp-1@userp2030.oracle.com> On 4/14/21 5:28 PM, Hohensee, Paul wrote: > Pushed. Thanks a lot, very much appreciated. From vkempik at azul.com Thu Apr 15 07:40:43 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 15 Apr 2021 07:40:43 +0000 Subject: [11u] 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Message-ID: Hello please review this backport of JDK-8240487 to jdk11u I?m working on a series of patches for JNF dependency removal for macos and this backport will allow it to apply a lot more cleanly. Very safe, white-space only changes. Applies almost cleanly, I only removed second part of patch for src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m as it wasn?t needed. The bug - https://bugs.openjdk.java.net/browse/JDK-8240487 The original commit - https://hg.openjdk.java.net/jdk/jdk/rev/f532ef5561c3 The webrev - http://cr.openjdk.java.net/~vkempik/8240487/webrev.01/ Regards, Vladimir From lutz.schmidt at sap.com Thu Apr 15 07:46:08 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 15 Apr 2021 07:46:08 +0000 Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use Compile_lock in favour of fancy checks In-Reply-To: References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com> <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com> <40507412-5F59-4623-BA39-728CA14F9C64@sap.com> Message-ID: <9967BB60-EF86-4EC7-9F56-B8E3E7A5D02D@sap.com> Tests did not reveal any issues. From this end, downport is ready to be pushed. Bug was updated accordingly. Thanks, Lutz ?On 14.04.21, 11:21, "Doerr, Martin" wrote: Yes. Just let me know when it's ready. Best regards, Martin > -----Original Message----- > From: Schmidt, Lutz > Sent: Mittwoch, 14. April 2021 11:18 > To: Doerr, Martin ; hotspot-compiler- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Hohensee, > Paul > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram should > use Compile_lock in favour of fancy checks > > Thank you, Martin and Paul, for your reviews. > > Submit will have to wait another day. I was too late for testing last night. > > I will need a sponsor anyway. Is it ok to contact you, Martin, once the tests > are done successfully? > > Thanks, > Lutz > > On 14.04.21, 11:06, "Doerr, Martin" wrote: > > Hi Lutz, > > your backport looks good. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Schmidt, Lutz > > Sent: Dienstag, 13. April 2021 22:02 > > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > > dev at openjdk.java.net > > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram > should > > use Compile_lock in favour of fancy checks > > > > Sorry for spamming, forgot jdk-updates-dev. > > Lutz > > > > On 13.04.21, 21:43, "Schmidt, Lutz" wrote: > > > > Dear Community, > > > > I would appreciate receiving reviews for this downport change. It is a > small > > change in one file only. Unfortunately, it did not apply clean. > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8250635 > > Downport webrev: > > https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/ > > > > Tests: > > SAP's internal build and test farm. Results pending. > > > > Thank you! > > Lutz > > > > > From lutz.schmidt at sap.com Thu Apr 15 08:18:21 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 15 Apr 2021 08:18:21 +0000 Subject: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow Message-ID: Dear Community, I would happily accept reviews for this downport change. The change creates more meaningful output. ? Merge conflicts were only "technical". No complicated semantical considerations necessary. Original bug:??????????https://bugs.openjdk.java.net/browse/JDK-8261447 Downport webrev:???????https://cr.openjdk.java.net/~lucy/webrevs/8261447.11u.01/ Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues detected that are attributable to this change. Thanks, Lutz From vkempik at azul.com Thu Apr 15 08:26:36 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 15 Apr 2021 08:26:36 +0000 Subject: [11u] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files In-Reply-To: References: Message-ID: Correcting the title > 15 ???. 2021 ?., ? 10:40, Vladimir Kempik ???????(?): > > Hello > please review this backport of JDK-8240487 to jdk11u > I?m working on a series of patches for JNF dependency removal for macos and this backport will allow it to apply a lot more cleanly. > Very safe, white-space only changes. > Applies almost cleanly, I only removed second part of patch for src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m > as it wasn?t needed. > > The bug - https://bugs.openjdk.java.net/browse/JDK-8240487 > The original commit - https://hg.openjdk.java.net/jdk/jdk/rev/f532ef5561c3 > The webrev - http://cr.openjdk.java.net/~vkempik/8240487/webrev.01/ > > Regards, Vladimir From martin.doerr at sap.com Thu Apr 15 10:19:05 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Apr 2021 10:19:05 +0000 Subject: [11u] Apple Silicon and 8257852: Remove JNF dependencies from java.desktop module Message-ID: Hi, JDK-8257852 removed JNF usage in JDK17. It consists of 8 individual changes and a bunch of follow-up fixes. https://bugs.openjdk.java.net/browse/JDK-8257852 It is already backported to 15, 13 and 11.0.12-oracle, but not to OpenJDK 11u. I believe this change is a preparation for MacOS on Apple Silicon which doesn't support JNF with MacOS BigSur. We are currently not planning to backport it to 11u. Does anybody need it and is willing to take care of the backport work? Best regards, Martin From vkempik at azul.com Thu Apr 15 10:29:45 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 15 Apr 2021 10:29:45 +0000 Subject: [11u] Apple Silicon and 8257852: Remove JNF dependencies from java.desktop module In-Reply-To: References: Message-ID: <299C3338-DE57-434F-8956-0CFA660CF8AE@azul.com> Hello I?m in a process of preparing the backports, 7/8 done already I have sent one of prerequestes out for review already today. Regards, Vladimir > 15 ???. 2021 ?., ? 13:19, Doerr, Martin ???????(?): > > Hi, > > JDK-8257852 removed JNF usage in JDK17. It consists of 8 individual changes and a bunch of follow-up fixes. > https://bugs.openjdk.java.net/browse/JDK-8257852 > It is already backported to 15, 13 and 11.0.12-oracle, but not to OpenJDK 11u. > > I believe this change is a preparation for MacOS on Apple Silicon which doesn't support JNF with MacOS BigSur. > > We are currently not planning to backport it to 11u. Does anybody need it and is willing to take care of the backport work? > > Best regards, > Martin From martin.doerr at sap.com Thu Apr 15 10:31:40 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Apr 2021 10:31:40 +0000 Subject: [11u] RFR: 8076190 Customizing the generation of a PKCS12 keystore In-Reply-To: References: Message-ID: Hi Alexey, looks good. Thanks for backporting. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Alexey Bakhtin > Sent: Donnerstag, 3. Dezember 2020 15:58 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8076190 Customizing the generation of a PKCS12 keystore > > Hello All, > > I would like to backport JDK-8076190 to 11u. CSR for 11u is filed: JDK-8257680. > > The patch applies cleanly except of > test/lib/jdk/test/lib/security/DerUtils.java which is already backported to 11u > as part of JDK-8215694 (see https://hg.openjdk.java.net/jdk- > updates/jdk11u/rev/551bc745f05d#l9.1) > > This feature minimizes behaviour differences between JKS and PKCS12 > keystores. Also, it fixes issue with incorrectly decoded KDF algorithm as > described in JDK-8245169 > > Webrev: http://cr.openjdk.java.net/~abakhtin/8076190/webrev.v0/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8076190 > CSR for 11u: https://bugs.openjdk.java.net/browse/JDK-8257680 > > [1] https://bugs.openjdk.java.net/browse/JDK-8245169 > [2] https://bugs.openjdk.java.net/browse/JDK-8215694 > [3] https://bugs.openjdk.java.net/browse/JDK-8228455 > > > Regards > Alexey From vkempik at azul.com Thu Apr 15 10:46:08 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 15 Apr 2021 10:46:08 +0000 Subject: [11u] Apple Silicon and 8257852: Remove JNF dependencies from java.desktop module In-Reply-To: References: <299C3338-DE57-434F-8956-0CFA660CF8AE@azul.com> Message-ID: <25C83AB4-47FC-488F-B7AD-567220AE5BA4@azul.com> Thanks for the list will do it as well and try to prepare all patches in one review request for 12 commits. > 15 ???. 2021 ?., ? 13:44, Doerr, Martin ???????(?): > > Hi Vladimir, > > thanks for your quick reply and for doing all the work! > > We noticed that there are quite some follow-up MacOS changes besides the 8 parts. At least: > https://bugs.openjdk.java.net/browse/JDK-8259232 > https://bugs.openjdk.java.net/browse/JDK-8259585 > https://bugs.openjdk.java.net/browse/JDK-8259729 > https://bugs.openjdk.java.net/browse/JDK-8261198 > https://bugs.openjdk.java.net/browse/JDK-8263846 > > We'll have to check we're not missing anything before the release. > > Best regards, > Martin > > >> -----Original Message----- >> From: Vladimir Kempik >> Sent: Donnerstag, 15. April 2021 12:30 >> To: Doerr, Martin >> Cc: jdk-updates-dev at openjdk.java.net >> Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies >> from java.desktop module >> >> Hello >> I?m in a process of preparing the backports, 7/8 done already >> I have sent one of prerequestes out for review already today. >> Regards, Vladimir >>> 15 ???. 2021 ?., ? 13:19, Doerr, Martin >> ???????(?): >>> >>> Hi, >>> >>> JDK-8257852 removed JNF usage in JDK17. It consists of 8 individual changes >> and a bunch of follow-up fixes. >>> https://bugs.openjdk.java.net/browse/JDK-8257852 >>> It is already backported to 15, 13 and 11.0.12-oracle, but not to OpenJDK >> 11u. >>> >>> I believe this change is a preparation for MacOS on Apple Silicon which >> doesn't support JNF with MacOS BigSur. >>> >>> We are currently not planning to backport it to 11u. Does anybody need it >> and is willing to take care of the backport work? >>> >>> Best regards, >>> Martin > From martin.doerr at sap.com Thu Apr 15 10:44:14 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Apr 2021 10:44:14 +0000 Subject: [11u] Apple Silicon and 8257852: Remove JNF dependencies from java.desktop module In-Reply-To: <299C3338-DE57-434F-8956-0CFA660CF8AE@azul.com> References: <299C3338-DE57-434F-8956-0CFA660CF8AE@azul.com> Message-ID: Hi Vladimir, thanks for your quick reply and for doing all the work! We noticed that there are quite some follow-up MacOS changes besides the 8 parts. At least: https://bugs.openjdk.java.net/browse/JDK-8259232 https://bugs.openjdk.java.net/browse/JDK-8259585 https://bugs.openjdk.java.net/browse/JDK-8259729 https://bugs.openjdk.java.net/browse/JDK-8261198 https://bugs.openjdk.java.net/browse/JDK-8263846 We'll have to check we're not missing anything before the release. Best regards, Martin > -----Original Message----- > From: Vladimir Kempik > Sent: Donnerstag, 15. April 2021 12:30 > To: Doerr, Martin > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies > from java.desktop module > > Hello > I?m in a process of preparing the backports, 7/8 done already > I have sent one of prerequestes out for review already today. > Regards, Vladimir > > 15 ???. 2021 ?., ? 13:19, Doerr, Martin > ???????(?): > > > > Hi, > > > > JDK-8257852 removed JNF usage in JDK17. It consists of 8 individual changes > and a bunch of follow-up fixes. > > https://bugs.openjdk.java.net/browse/JDK-8257852 > > It is already backported to 15, 13 and 11.0.12-oracle, but not to OpenJDK > 11u. > > > > I believe this change is a preparation for MacOS on Apple Silicon which > doesn't support JNF with MacOS BigSur. > > > > We are currently not planning to backport it to 11u. Does anybody need it > and is willing to take care of the backport work? > > > > Best regards, > > Martin From martin.doerr at sap.com Thu Apr 15 10:50:00 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Apr 2021 10:50:00 +0000 Subject: [11u] Apple Silicon and 8257852: Remove JNF dependencies from java.desktop module In-Reply-To: <25C83AB4-47FC-488F-B7AD-567220AE5BA4@azul.com> References: <299C3338-DE57-434F-8956-0CFA660CF8AE@azul.com> <25C83AB4-47FC-488F-B7AD-567220AE5BA4@azul.com> Message-ID: Awesome! Thanks a lot! > -----Original Message----- > From: Vladimir Kempik > Sent: Donnerstag, 15. April 2021 12:46 > To: Doerr, Martin > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies > from java.desktop module > > Thanks for the list > will do it as well and try to prepare all patches in one review request for 12 > commits. > > > > 15 ???. 2021 ?., ? 13:44, Doerr, Martin > ???????(?): > > > > Hi Vladimir, > > > > thanks for your quick reply and for doing all the work! > > > > We noticed that there are quite some follow-up MacOS changes besides > the 8 parts. At least: > > https://bugs.openjdk.java.net/browse/JDK-8259232 > > https://bugs.openjdk.java.net/browse/JDK-8259585 > > https://bugs.openjdk.java.net/browse/JDK-8259729 > > https://bugs.openjdk.java.net/browse/JDK-8261198 > > https://bugs.openjdk.java.net/browse/JDK-8263846 > > > > We'll have to check we're not missing anything before the release. > > > > Best regards, > > Martin > > > > > >> -----Original Message----- > >> From: Vladimir Kempik > >> Sent: Donnerstag, 15. April 2021 12:30 > >> To: Doerr, Martin > >> Cc: jdk-updates-dev at openjdk.java.net > >> Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies > >> from java.desktop module > >> > >> Hello > >> I?m in a process of preparing the backports, 7/8 done already > >> I have sent one of prerequestes out for review already today. > >> Regards, Vladimir > >>> 15 ???. 2021 ?., ? 13:19, Doerr, Martin > >> ???????(?): > >>> > >>> Hi, > >>> > >>> JDK-8257852 removed JNF usage in JDK17. It consists of 8 individual > changes > >> and a bunch of follow-up fixes. > >>> https://bugs.openjdk.java.net/browse/JDK-8257852 > >>> It is already backported to 15, 13 and 11.0.12-oracle, but not to OpenJDK > >> 11u. > >>> > >>> I believe this change is a preparation for MacOS on Apple Silicon which > >> doesn't support JNF with MacOS BigSur. > >>> > >>> We are currently not planning to backport it to 11u. Does anybody need > it > >> and is willing to take care of the backport work? > >>> > >>> Best regards, > >>> Martin > > From vkempik at azul.com Thu Apr 15 11:03:09 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 15 Apr 2021 11:03:09 +0000 Subject: [11u] Apple Silicon and 8257852: Remove JNF dependencies from java.desktop module In-Reply-To: References: <299C3338-DE57-434F-8956-0CFA660CF8AE@azul.com> <25C83AB4-47FC-488F-B7AD-567220AE5BA4@azul.com> Message-ID: <1BAFD641-50A4-4E42-9D22-99C31E5ED167@azul.com> Btw, about JDK-8259729 When I was doing a series of 8 patches, I accidentially fixed 8259729 too as the build got broken after one of 8 patches. We will probably closed JDK-8259729 as not affecting ojdk11u then. example for 13u is here https://github.com/VladimirKempik/jdk13u-dev/commit/2e9b3a090ad75597c64b2c9a8cdf0fe02fc8fc7d#r49551444 > 15 ???. 2021 ?., ? 13:50, Doerr, Martin ???????(?): > > Awesome! > Thanks a lot! > >> -----Original Message----- >> From: Vladimir Kempik >> Sent: Donnerstag, 15. April 2021 12:46 >> To: Doerr, Martin >> Cc: jdk-updates-dev at openjdk.java.net >> Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies >> from java.desktop module >> >> Thanks for the list >> will do it as well and try to prepare all patches in one review request for 12 >> commits. >> >> >>> 15 ???. 2021 ?., ? 13:44, Doerr, Martin >> ???????(?): >>> >>> Hi Vladimir, >>> >>> thanks for your quick reply and for doing all the work! >>> >>> We noticed that there are quite some follow-up MacOS changes besides >> the 8 parts. At least: >>> https://bugs.openjdk.java.net/browse/JDK-8259232 >>> https://bugs.openjdk.java.net/browse/JDK-8259585 >>> https://bugs.openjdk.java.net/browse/JDK-8259729 >>> https://bugs.openjdk.java.net/browse/JDK-8261198 >>> https://bugs.openjdk.java.net/browse/JDK-8263846 >>> >>> We'll have to check we're not missing anything before the release. >>> >>> Best regards, >>> Martin >>> >>> >>>> -----Original Message----- >>>> From: Vladimir Kempik >>>> Sent: Donnerstag, 15. April 2021 12:30 >>>> To: Doerr, Martin >>>> Cc: jdk-updates-dev at openjdk.java.net >>>> Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies >>>> from java.desktop module >>>> >>>> Hello >>>> I?m in a process of preparing the backports, 7/8 done already >>>> I have sent one of prerequestes out for review already today. >>>> Regards, Vladimir >>>>> 15 ???. 2021 ?., ? 13:19, Doerr, Martin >>>> ???????(?): >>>>> >>>>> Hi, >>>>> >>>>> JDK-8257852 removed JNF usage in JDK17. It consists of 8 individual >> changes >>>> and a bunch of follow-up fixes. >>>>> https://bugs.openjdk.java.net/browse/JDK-8257852 >>>>> It is already backported to 15, 13 and 11.0.12-oracle, but not to OpenJDK >>>> 11u. >>>>> >>>>> I believe this change is a preparation for MacOS on Apple Silicon which >>>> doesn't support JNF with MacOS BigSur. >>>>> >>>>> We are currently not planning to backport it to 11u. Does anybody need >> it >>>> and is willing to take care of the backport work? >>>>> >>>>> Best regards, >>>>> Martin >>> > From martin.doerr at sap.com Thu Apr 15 11:13:27 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Apr 2021 11:13:27 +0000 Subject: [11u] Apple Silicon and 8257852: Remove JNF dependencies from java.desktop module In-Reply-To: <1BAFD641-50A4-4E42-9D22-99C31E5ED167@azul.com> References: <299C3338-DE57-434F-8956-0CFA660CF8AE@azul.com> <25C83AB4-47FC-488F-B7AD-567220AE5BA4@azul.com> <1BAFD641-50A4-4E42-9D22-99C31E5ED167@azul.com> Message-ID: Ok. I guess Oracle has backported some parts differently and fixed it by backport of JDK-8259729. If your backport doesn't need JDK-8259729 as follow-up that will be also fine. We can mark JDK-8259729 as backported to 11.0.12 and link it to your new backport. Note that it's possible to fix several issues by one change. You only need to add both bug ids to the commit message. > -----Original Message----- > From: Vladimir Kempik > Sent: Donnerstag, 15. April 2021 13:03 > To: Doerr, Martin > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies > from java.desktop module > > Btw, about JDK-8259729 > When I was doing a series of 8 patches, I accidentially fixed 8259729 too as > the build got broken after one of 8 patches. > We will probably closed JDK-8259729 as not affecting ojdk11u then. > example for 13u is here https://github.com/VladimirKempik/jdk13u- > dev/commit/2e9b3a090ad75597c64b2c9a8cdf0fe02fc8fc7d#r49551444 > > > 15 ???. 2021 ?., ? 13:50, Doerr, Martin > ???????(?): > > > > Awesome! > > Thanks a lot! > > > >> -----Original Message----- > >> From: Vladimir Kempik > >> Sent: Donnerstag, 15. April 2021 12:46 > >> To: Doerr, Martin > >> Cc: jdk-updates-dev at openjdk.java.net > >> Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies > >> from java.desktop module > >> > >> Thanks for the list > >> will do it as well and try to prepare all patches in one review request for 12 > >> commits. > >> > >> > >>> 15 ???. 2021 ?., ? 13:44, Doerr, Martin > >> ???????(?): > >>> > >>> Hi Vladimir, > >>> > >>> thanks for your quick reply and for doing all the work! > >>> > >>> We noticed that there are quite some follow-up MacOS changes besides > >> the 8 parts. At least: > >>> https://bugs.openjdk.java.net/browse/JDK-8259232 > >>> https://bugs.openjdk.java.net/browse/JDK-8259585 > >>> https://bugs.openjdk.java.net/browse/JDK-8259729 > >>> https://bugs.openjdk.java.net/browse/JDK-8261198 > >>> https://bugs.openjdk.java.net/browse/JDK-8263846 > >>> > >>> We'll have to check we're not missing anything before the release. > >>> > >>> Best regards, > >>> Martin > >>> > >>> > >>>> -----Original Message----- > >>>> From: Vladimir Kempik > >>>> Sent: Donnerstag, 15. April 2021 12:30 > >>>> To: Doerr, Martin > >>>> Cc: jdk-updates-dev at openjdk.java.net > >>>> Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF > dependencies > >>>> from java.desktop module > >>>> > >>>> Hello > >>>> I?m in a process of preparing the backports, 7/8 done already > >>>> I have sent one of prerequestes out for review already today. > >>>> Regards, Vladimir > >>>>> 15 ???. 2021 ?., ? 13:19, Doerr, Martin > >>>> ???????(?): > >>>>> > >>>>> Hi, > >>>>> > >>>>> JDK-8257852 removed JNF usage in JDK17. It consists of 8 individual > >> changes > >>>> and a bunch of follow-up fixes. > >>>>> https://bugs.openjdk.java.net/browse/JDK-8257852 > >>>>> It is already backported to 15, 13 and 11.0.12-oracle, but not to > OpenJDK > >>>> 11u. > >>>>> > >>>>> I believe this change is a preparation for MacOS on Apple Silicon which > >>>> doesn't support JNF with MacOS BigSur. > >>>>> > >>>>> We are currently not planning to backport it to 11u. Does anybody > need > >> it > >>>> and is willing to take care of the backport work? > >>>>> > >>>>> Best regards, > >>>>> Martin > >>> > > From vkempik at azul.com Thu Apr 15 11:16:42 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 15 Apr 2021 11:16:42 +0000 Subject: [11u] Apple Silicon and 8257852: Remove JNF dependencies from java.desktop module In-Reply-To: References: <299C3338-DE57-434F-8956-0CFA660CF8AE@azul.com> <25C83AB4-47FC-488F-B7AD-567220AE5BA4@azul.com> <1BAFD641-50A4-4E42-9D22-99C31E5ED167@azul.com> Message-ID: <3370A040-D41B-4720-8ACC-7A9235474F93@azul.com> Ok, i have added 8259729 to the header of patch for 8260616 # HG changeset patch # User vkempik # Date 1618483337 -10800 # Thu Apr 15 13:42:17 2021 +0300 # Node ID 0f10de1bcc8fb68045f70ea12498cec17ed5c7db # Parent cf3f50dad3d1b8c0f2412ae56e060b756d2c86b8 8260616: Removing remaining JNF dependencies in the java.desktop module 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion > 15 ???. 2021 ?., ? 14:13, Doerr, Martin ???????(?): > > Ok. I guess Oracle has backported some parts differently and fixed it by backport of JDK-8259729. > If your backport doesn't need JDK-8259729 as follow-up that will be also fine. > We can mark JDK-8259729 as backported to 11.0.12 and link it to your new backport. > Note that it's possible to fix several issues by one change. You only need to add both bug ids to the commit message. > > >> -----Original Message----- >> From: Vladimir Kempik >> Sent: Donnerstag, 15. April 2021 13:03 >> To: Doerr, Martin >> Cc: jdk-updates-dev at openjdk.java.net >> Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies >> from java.desktop module >> >> Btw, about JDK-8259729 >> When I was doing a series of 8 patches, I accidentially fixed 8259729 too as >> the build got broken after one of 8 patches. >> We will probably closed JDK-8259729 as not affecting ojdk11u then. >> example for 13u is here https://github.com/VladimirKempik/jdk13u- >> dev/commit/2e9b3a090ad75597c64b2c9a8cdf0fe02fc8fc7d#r49551444 >> >>> 15 ???. 2021 ?., ? 13:50, Doerr, Martin >> ???????(?): >>> >>> Awesome! >>> Thanks a lot! >>> >>>> -----Original Message----- >>>> From: Vladimir Kempik >>>> Sent: Donnerstag, 15. April 2021 12:46 >>>> To: Doerr, Martin >>>> Cc: jdk-updates-dev at openjdk.java.net >>>> Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF dependencies >>>> from java.desktop module >>>> >>>> Thanks for the list >>>> will do it as well and try to prepare all patches in one review request for 12 >>>> commits. >>>> >>>> >>>>> 15 ???. 2021 ?., ? 13:44, Doerr, Martin >>>> ???????(?): >>>>> >>>>> Hi Vladimir, >>>>> >>>>> thanks for your quick reply and for doing all the work! >>>>> >>>>> We noticed that there are quite some follow-up MacOS changes besides >>>> the 8 parts. At least: >>>>> https://bugs.openjdk.java.net/browse/JDK-8259232 >>>>> https://bugs.openjdk.java.net/browse/JDK-8259585 >>>>> https://bugs.openjdk.java.net/browse/JDK-8259729 >>>>> https://bugs.openjdk.java.net/browse/JDK-8261198 >>>>> https://bugs.openjdk.java.net/browse/JDK-8263846 >>>>> >>>>> We'll have to check we're not missing anything before the release. >>>>> >>>>> Best regards, >>>>> Martin >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kempik >>>>>> Sent: Donnerstag, 15. April 2021 12:30 >>>>>> To: Doerr, Martin >>>>>> Cc: jdk-updates-dev at openjdk.java.net >>>>>> Subject: Re: [11u] Apple Silicon and 8257852: Remove JNF >> dependencies >>>>>> from java.desktop module >>>>>> >>>>>> Hello >>>>>> I?m in a process of preparing the backports, 7/8 done already >>>>>> I have sent one of prerequestes out for review already today. >>>>>> Regards, Vladimir >>>>>>> 15 ???. 2021 ?., ? 13:19, Doerr, Martin >>>>>> ???????(?): >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> JDK-8257852 removed JNF usage in JDK17. It consists of 8 individual >>>> changes >>>>>> and a bunch of follow-up fixes. >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8257852 >>>>>>> It is already backported to 15, 13 and 11.0.12-oracle, but not to >> OpenJDK >>>>>> 11u. >>>>>>> >>>>>>> I believe this change is a preparation for MacOS on Apple Silicon which >>>>>> doesn't support JNF with MacOS BigSur. >>>>>>> >>>>>>> We are currently not planning to backport it to 11u. Does anybody >> need >>>> it >>>>>> and is willing to take care of the backport work? >>>>>>> >>>>>>> Best regards, >>>>>>> Martin >>>>> >>> > From shade at redhat.com Thu Apr 15 11:56:12 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 15 Apr 2021 13:56:12 +0200 Subject: [11u] RFR (S) 8207779: Method::is_valid_method() compares 'this' with NULL Message-ID: <3293cfb8-5988-ae71-10be-46d89f9a28b6@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8207779 https://hg.openjdk.java.net/jdk/jdk/rev/b5aac518b097 I was looking at backporting this to 8u as the pre-requisite for JDK-8231949. 11u backported JDK-8231949 without this fix. But, I think the fix is actually simple enough to backport and it dodges UB as a good bonus. The patch does not apply to 11u cleanly, and requires adjustments to fit the context differences. I grepped the source for is_valid_method to catch all other places where this needs to be adjusted. 11u webrev: https://cr.openjdk.java.net/~shade/8207779/webrev.11u.01 Testing: Linux x86_64 fastdebug, {tier1, jdk_jfr} -- Thanks, -Aleksey From zgu at redhat.com Thu Apr 15 12:18:42 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 15 Apr 2021 08:18:42 -0400 Subject: [11u] RFR (S) 8207779: Method::is_valid_method() compares 'this' with NULL In-Reply-To: <3293cfb8-5988-ae71-10be-46d89f9a28b6@redhat.com> References: <3293cfb8-5988-ae71-10be-46d89f9a28b6@redhat.com> Message-ID: <0ad4eaff-ec64-5d84-2b20-a2512944273d@redhat.com> Looks good. -Zhengyu On 4/15/21 7:56 AM, Aleksey Shipilev wrote: > Original bug: > ? https://bugs.openjdk.java.net/browse/JDK-8207779 > ? https://hg.openjdk.java.net/jdk/jdk/rev/b5aac518b097 > > I was looking at backporting this to 8u as the pre-requisite for > JDK-8231949. 11u backported JDK-8231949 without this fix. But, I think > the fix is actually simple enough to backport and it dodges UB as a good > bonus. The patch does not apply to 11u cleanly, and requires adjustments > to fit the context differences. I grepped the source for is_valid_method > to catch all other places where this needs to be adjusted. > > 11u webrev: > ? https://cr.openjdk.java.net/~shade/8207779/webrev.11u.01 > > Testing: Linux x86_64 fastdebug, {tier1, jdk_jfr} > From omikhaltcova at openjdk.java.net Thu Apr 15 13:03:02 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 15 Apr 2021 13:03:02 GMT Subject: [jdk13u-dev] RFR: 8259232: Bad JNI lookup during printing Message-ID: <11ul0LNkwqa28VVVwoZXGYe0Lt1N9H1M4bUkLI9IHRk=.51e0632c-288b-4383-bd17-a23410655d46@github.com> I'd like to backport JDK-8259232 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested via jtreg with test/jdk/java/awt/print/bug8023392 pointed in the issue. ------------- Commit messages: - Backport 940b053065de788e44ef0d7f6fab901f8f0dfb40 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/181/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=181&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259232 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/181.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/181/head:pull/181 PR: https://git.openjdk.java.net/jdk13u-dev/pull/181 From omikhaltcova at openjdk.java.net Thu Apr 15 13:33:45 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 15 Apr 2021 13:33:45 GMT Subject: [jdk13u-dev] Integrated: 8259232: Bad JNI lookup during printing In-Reply-To: <11ul0LNkwqa28VVVwoZXGYe0Lt1N9H1M4bUkLI9IHRk=.51e0632c-288b-4383-bd17-a23410655d46@github.com> References: <11ul0LNkwqa28VVVwoZXGYe0Lt1N9H1M4bUkLI9IHRk=.51e0632c-288b-4383-bd17-a23410655d46@github.com> Message-ID: On Thu, 15 Apr 2021 12:54:45 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8259232 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested via jtreg with test/jdk/java/awt/print/bug8023392 pointed in the issue. This pull request has now been integrated. Changeset: c32180e7 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/c32180e7 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8259232: Bad JNI lookup during printing Backport-of: 940b053065de788e44ef0d7f6fab901f8f0dfb40 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/181 From omikhaltcova at openjdk.java.net Thu Apr 15 13:48:48 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 15 Apr 2021 13:48:48 GMT Subject: [jdk15u-dev] RFR: 8259232: Bad JNI lookup during printing Message-ID: I'd like to backport JDK-8259232 to jdk15u for parity with jdk11u. The original patch applied cleanly. Tested via jtreg with test/jdk/java/awt/print/bug8023392 pointed in the issue. ------------- Commit messages: - Backport 940b053065de788e44ef0d7f6fab901f8f0dfb40 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/24/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=24&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259232 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/24.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/24/head:pull/24 PR: https://git.openjdk.java.net/jdk15u-dev/pull/24 From yan at openjdk.java.net Thu Apr 15 14:03:12 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 15 Apr 2021 14:03:12 GMT Subject: [jdk13u-dev] Integrated: 8244853: The static build of libextnet is missing the JNI_OnLoad_extnet function Message-ID: I'd like to port this fix for general alignment with other release trains. The patch goes clean. ------------- Commit messages: - Backport 3d50f242c2172c05b74e533962195bc8d9ea2997 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/182/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=182&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244853 Stats: 15 lines in 3 files changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/182.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/182/head:pull/182 PR: https://git.openjdk.java.net/jdk13u-dev/pull/182 From yan at openjdk.java.net Thu Apr 15 14:03:12 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 15 Apr 2021 14:03:12 GMT Subject: [jdk13u-dev] Integrated: 8244853: The static build of libextnet is missing the JNI_OnLoad_extnet function In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 13:52:21 GMT, Yuri Nesterenko wrote: > I'd like to port this fix for general alignment with other release trains. The patch goes clean. This pull request has now been integrated. Changeset: 2b18941f Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/2b18941f Stats: 15 lines in 3 files changed: 15 ins; 0 del; 0 mod 8244853: The static build of libextnet is missing the JNI_OnLoad_extnet function Backport-of: 3d50f242c2172c05b74e533962195bc8d9ea2997 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/182 From lutz.schmidt at sap.com Thu Apr 15 14:14:41 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 15 Apr 2021 14:14:41 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: References: <275E669F-DFF5-45ED-AE2D-F691CA6D07EC@amazon.com> Message-ID: <192F3A84-7CDC-4A3F-90CC-68BA8900E60A@sap.com> Dear all, would somebody please be willing to sponsor this backport patch? Thank you, Lutz ?On 14.04.21, 19:05, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Thanks for reviewing, Paul! Best, Lutz On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From omikhaltcova at openjdk.java.net Thu Apr 15 14:15:46 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 15 Apr 2021 14:15:46 GMT Subject: [jdk15u-dev] Integrated: 8259232: Bad JNI lookup during printing In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 13:41:31 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8259232 to jdk15u for parity with jdk11u. > The original patch applied cleanly. > Tested via jtreg with test/jdk/java/awt/print/bug8023392 pointed in the issue. This pull request has now been integrated. Changeset: 847c0e34 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/847c0e34 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8259232: Bad JNI lookup during printing Backport-of: 940b053065de788e44ef0d7f6fab901f8f0dfb40 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/24 From christoph.goettschkes at microdoc.com Thu Apr 15 14:30:15 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Thu, 15 Apr 2021 16:30:15 +0200 Subject: [11u] 8214128: ARM32: wrong stack alignment on Deoptimization::unpack_frames Message-ID: <37wv3qn5fg-1@userp2060.oracle.com> Hi, could someone please sponsor this clean and already approved backport of 8214128 to 11u? Bug: https://bugs.openjdk.java.net/browse/JDK-8214128 Original commit (OpenJDK 12): http://hg.openjdk.java.net/jdk/jdk/rev/420ff459906f Webrev: https://cr.openjdk.java.net/~cgo/8214128/webrev.11u.00/ Thanks, Christoph From shade at redhat.com Thu Apr 15 14:34:04 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 15 Apr 2021 16:34:04 +0200 Subject: [11u] 8214128: ARM32: wrong stack alignment on Deoptimization::unpack_frames In-Reply-To: <37wv3qn5fg-1@userp2060.oracle.com> References: <37wv3qn5fg-1@userp2060.oracle.com> Message-ID: <657ff62d-d2f5-a5aa-3109-9da0ac16e975@redhat.com> On 4/15/21 4:30 PM, Christoph G?ttschkes wrote: > Hi, > > could someone please sponsor this clean and already approved backport of 8214128 to 11u? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214128 > Original commit (OpenJDK 12): http://hg.openjdk.java.net/jdk/jdk/rev/420ff459906f > Webrev: https://cr.openjdk.java.net/~cgo/8214128/webrev.11u.00/ I'll do it. -- Thanks, -Aleksey From shade at redhat.com Thu Apr 15 14:38:40 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 15 Apr 2021 16:38:40 +0200 Subject: [11u] 8214128: ARM32: wrong stack alignment on Deoptimization::unpack_frames In-Reply-To: <657ff62d-d2f5-a5aa-3109-9da0ac16e975@redhat.com> References: <37wv3qn5fg-1@userp2060.oracle.com> <657ff62d-d2f5-a5aa-3109-9da0ac16e975@redhat.com> Message-ID: On 4/15/21 4:34 PM, Aleksey Shipilev wrote: > On 4/15/21 4:30 PM, Christoph G?ttschkes wrote: >> Hi, >> >> could someone please sponsor this clean and already approved backport of 8214128 to 11u? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214128 >> Original commit (OpenJDK 12): http://hg.openjdk.java.net/jdk/jdk/rev/420ff459906f >> Webrev: https://cr.openjdk.java.net/~cgo/8214128/webrev.11u.00/ > > I'll do it. Done: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d95eca1122b1 -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Thu Apr 15 14:40:40 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Thu, 15 Apr 2021 16:40:40 +0200 Subject: [11u] 8214128: ARM32: wrong stack alignment on Deoptimization::unpack_frames In-Reply-To: References: <37wv3qn5fg-1@userp2060.oracle.com> <657ff62d-d2f5-a5aa-3109-9da0ac16e975@redhat.com> Message-ID: <37xgyu6631-1@userp2050.oracle.com> On 4/15/21 4:38 PM, Aleksey Shipilev wrote: > On 4/15/21 4:34 PM, Aleksey Shipilev wrote: >> On 4/15/21 4:30 PM, Christoph G?ttschkes wrote: >>> Hi, >>> >>> could someone please sponsor this clean and already approved backport of8214128 to 11u? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214128 >>> Original commit (OpenJDK 12): http://hg.openjdk.java.net/jdk/jdk/rev/420ff459906f >>> Webrev: https://cr.openjdk.java.net/~cgo/8214128/webrev.11u.00/ >> >> I'll do it. > > Done: > ?http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d95eca1122b1 > > Thanks. From yan at openjdk.java.net Thu Apr 15 14:56:09 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 15 Apr 2021 14:56:09 GMT Subject: [jdk13u-dev] RFR: 8262110: DST starts from incorrect time in 2038 Message-ID: <5nJMXFZBqLLBo95hf1_M9enzpGDVAG-JlHS4BvsacAc=.4adc9f99-302b-4408-af1d-275e6847db32@github.com> Old copyright year differs in 13u code! Other than that, no surprises. ------------- Commit messages: - Backport 7284f013ea3064b2aa643658938ccaafdfa1c885 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/183/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=183&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262110 Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/183/head:pull/183 PR: https://git.openjdk.java.net/jdk13u-dev/pull/183 From yan at openjdk.java.net Thu Apr 15 15:55:47 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 15 Apr 2021 15:55:47 GMT Subject: [jdk13u-dev] RFR: 8254790: SIGSEGV in string_indexof_char and stringL_indexof_char intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 15:11:29 GMT, Sergey Nazarkin wrote: > Hi! Please review the backport of JDK-8254790. The patch fixes SIGSEGV and is required for code sync with jdk11,15. The patch is taken from jdk15 since the original one can't be applied cleanly due to reasons described https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-October/040943.html Fine with me! ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/170 From rwestrel at redhat.com Thu Apr 15 15:59:39 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 15 Apr 2021 17:59:39 +0200 Subject: [11u] 8263361: Incorrect arraycopy stub selected by C2 for SATB collectors Message-ID: <87fszro7x0.fsf@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8263361 https://github.com/openjdk/jdk/commit/5d87a219 Original patch does not apply cleanly to 11u, because context differs for some files but patch is otherwise identical. Failed hunks are below. 11u webrev: https://cr.openjdk.java.net/~roland/8263361.11u/webrev.00/ Testing: x86_64 build, tier1 Thanks, Roland. src/hotspot/share/opto/library_call.cpp.rej --- library_call.cpp +++ library_call.cpp @@ -4143,8 +4143,8 @@ bool LibraryCallKit::inline_native_clone(bool is_virtual) { PreserveJVMState pjvms2(this); set_control(is_obja); // Generate a direct call to the right arraycopy function(s). - Node* alloc = tightly_coupled_allocation(alloc_obj, NULL); - ArrayCopyNode* ac = ArrayCopyNode::make(this, true, obj, intcon(0), alloc_obj, intcon(0), obj_length, alloc != NULL, false); + // Clones are always tightly coupled. + ArrayCopyNode* ac = ArrayCopyNode::make(this, true, obj, intcon(0), alloc_obj, intcon(0), obj_length, true, false); ac->set_clone_oop_array(); Node* n = _gvn.transform(ac); assert(n == ac, "cannot disappear"); src/hotspot/share/opto/macroArrayCopy.cpp.rej --- macroArrayCopy.cpp +++ macroArrayCopy.cpp @@ -660,11 +670,10 @@ Node* PhaseMacroExpand::generate_arraycopy(ArrayCopyNode *ac, AllocateArrayNode* Node* local_ctrl = *ctrl; MergeMemNode* local_mem = MergeMemNode::make(mem); transform_later(local_mem); - is_partial_array_copy = generate_unchecked_arraycopy(&local_ctrl, &local_mem, adr_type, copy_type, disjoint_bases, src, src_offset, dest, dest_offset, - ConvI2X(copy_length), dest_uninitialized); + ConvI2X(copy_length), acopy_to_uninitialized); // Present the results of the fast call. result_region->init_req(fast_path, local_ctrl); From dmitry.chuyko at bell-sw.com Thu Apr 15 17:14:25 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 15 Apr 2021 20:14:25 +0300 Subject: [11u] RFR (M) 8251525: AARCH64: Faster Math.signum(fp) Message-ID: <2b7517a1-adc6-b9b7-76bc-c9b1cefdfc36@bell-sw.com> Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8251525 Original post-fix: https://bugs.openjdk.java.net/browse/JDK-8252779 The patch required minor adjustments: src/hotspot/share/opto/intrinsicnode.hpp Copyright change. src/hotspot/share/opto/library_call.cpp Case additions with missing context are reproduced in LibraryCallKit::inline_double_math() (JDK-8231649 is missing). src/hotspot/share/opto/matcher.cpp Additions with missing context are reproduced in Matcher::find_shared() (Matcher::find_shared_post_visit(), JDK-8213746 is missing) Initial post-fix for CheckGraalIntrinsics (HotspotTest) Graal test was changed to mark new intrinsics as toBeInvestigated in JDK 11+. 11u webrev signum: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.11u.00/ 11u webrev post-fix: http://cr.openjdk.java.net/~dchuyko/8252779/webrev.11u.00/ Testing: compiler/intrinsics/math/TestSignumIntrinsic.java, tier1, tier2; compiler/graalunit with Graal on - CheckGraalIntrinsics fails because of ECB intrinsics (JDK-8229848). -- Thanks, -Dmitry From hohensee at amazon.com Thu Apr 15 17:55:12 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 17:55:12 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Message-ID: I'll sponsor. ?-----Original Message----- From: "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 7:16 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear all, would somebody please be willing to sponsor this backport patch? Thank you, Lutz On 14.04.21, 19:05, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Thanks for reviewing, Paul! Best, Lutz On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From omikhaltcova at openjdk.java.net Thu Apr 15 18:00:00 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 15 Apr 2021 18:00:00 GMT Subject: [jdk13u-dev] RFR: 8259585: [macos] Bad JNI lookup error : Accessible actions do not work on macOS Message-ID: <9btSzxjQKw86SBoPt6FBxYPpgZoe7_75nB-u16-URiw=.fe923090-05de-462f-b74d-91124a6fdc77@github.com> I'd like to backport JDK-8259585 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with SwingSet2 demo as described in the comment to the issue. ------------- Commit messages: - Backport b6d51e15549e11be583625d908192d9f7f049489 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/184/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=184&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259585 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/184.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/184/head:pull/184 PR: https://git.openjdk.java.net/jdk13u-dev/pull/184 From hohensee at amazon.com Thu Apr 15 19:02:40 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 19:02:40 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: References: Message-ID: <5A04F6E7-CEF3-479E-BE6C-9EDCFD563098@amazon.com> Pushed. ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Thursday, April 15, 2021 at 10:55 AM To: "Schmidt, Lutz" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes I'll sponsor. -----Original Message----- From: "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 7:16 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear all, would somebody please be willing to sponsor this backport patch? Thank you, Lutz On 14.04.21, 19:05, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Thanks for reviewing, Paul! Best, Lutz On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From hohensee at amazon.com Thu Apr 15 20:19:57 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 20:19:57 +0000 Subject: [11u] RFR (M) 8251525: AARCH64: Faster Math.signum(fp) Message-ID: <2AC288E5-D454-4D95-931D-A24D45CFA5D3@amazon.com> Lgtm to both. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Thursday, April 15, 2021 at 10:15 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (M) 8251525: AARCH64: Faster Math.signum(fp) Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8251525 Original post-fix: https://bugs.openjdk.java.net/browse/JDK-8252779 The patch required minor adjustments: src/hotspot/share/opto/intrinsicnode.hpp Copyright change. src/hotspot/share/opto/library_call.cpp Case additions with missing context are reproduced in LibraryCallKit::inline_double_math() (JDK-8231649 is missing). src/hotspot/share/opto/matcher.cpp Additions with missing context are reproduced in Matcher::find_shared() (Matcher::find_shared_post_visit(), JDK-8213746 is missing) Initial post-fix for CheckGraalIntrinsics (HotspotTest) Graal test was changed to mark new intrinsics as toBeInvestigated in JDK 11+. 11u webrev signum: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.11u.00/ 11u webrev post-fix: http://cr.openjdk.java.net/~dchuyko/8252779/webrev.11u.00/ Testing: compiler/intrinsics/math/TestSignumIntrinsic.java, tier1, tier2; compiler/graalunit with Graal on - CheckGraalIntrinsics fails because of ECB intrinsics (JDK-8229848). -- Thanks, -Dmitry From hohensee at amazon.com Thu Apr 15 20:26:38 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 20:26:38 +0000 Subject: [11u] 8263361: Incorrect arraycopy stub selected by C2 for SATB collectors Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Roland Westrelin Date: Thursday, April 15, 2021 at 9:00 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] 8263361: Incorrect arraycopy stub selected by C2 for SATB collectors Original bug: https://bugs.openjdk.java.net/browse/JDK-8263361 https://github.com/openjdk/jdk/commit/5d87a219 Original patch does not apply cleanly to 11u, because context differs for some files but patch is otherwise identical. Failed hunks are below. 11u webrev: https://cr.openjdk.java.net/~roland/8263361.11u/webrev.00/ Testing: x86_64 build, tier1 Thanks, Roland. src/hotspot/share/opto/library_call.cpp.rej --- library_call.cpp +++ library_call.cpp @@ -4143,8 +4143,8 @@ bool LibraryCallKit::inline_native_clone(bool is_virtual) { PreserveJVMState pjvms2(this); set_control(is_obja); // Generate a direct call to the right arraycopy function(s). - Node* alloc = tightly_coupled_allocation(alloc_obj, NULL); - ArrayCopyNode* ac = ArrayCopyNode::make(this, true, obj, intcon(0), alloc_obj, intcon(0), obj_length, alloc != NULL, false); + // Clones are always tightly coupled. + ArrayCopyNode* ac = ArrayCopyNode::make(this, true, obj, intcon(0), alloc_obj, intcon(0), obj_length, true, false); ac->set_clone_oop_array(); Node* n = _gvn.transform(ac); assert(n == ac, "cannot disappear"); src/hotspot/share/opto/macroArrayCopy.cpp.rej --- macroArrayCopy.cpp +++ macroArrayCopy.cpp @@ -660,11 +670,10 @@ Node* PhaseMacroExpand::generate_arraycopy(ArrayCopyNode *ac, AllocateArrayNode* Node* local_ctrl = *ctrl; MergeMemNode* local_mem = MergeMemNode::make(mem); transform_later(local_mem); - is_partial_array_copy = generate_unchecked_arraycopy(&local_ctrl, &local_mem, adr_type, copy_type, disjoint_bases, src, src_offset, dest, dest_offset, - ConvI2X(copy_length), dest_uninitialized); + ConvI2X(copy_length), acopy_to_uninitialized); // Present the results of the fast call. result_region->init_req(fast_path, local_ctrl); From hohensee at amazon.com Thu Apr 15 20:38:19 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 20:38:19 +0000 Subject: [11u] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Message-ID: The webrev is empty (i.e., reports the changed files, but not the changes). Use "webrev -b". Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Vladimir Kempik Date: Thursday, April 15, 2021 at 1:27 AM To: jdk-updates-dev Subject: RE: [11u] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Correcting the title > 15 ???. 2021 ?., ? 10:40, Vladimir Kempik ???????(?): > > Hello > please review this backport of JDK-8240487 to jdk11u > I?m working on a series of patches for JNF dependency removal for macos and this backport will allow it to apply a lot more cleanly. > Very safe, white-space only changes. > Applies almost cleanly, I only removed second part of patch for src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m > as it wasn?t needed. > > The bug - https://bugs.openjdk.java.net/browse/JDK-8240487 > The original commit - https://hg.openjdk.java.net/jdk/jdk/rev/f532ef5561c3 > The webrev - http://cr.openjdk.java.net/~vkempik/8240487/webrev.01/ > > Regards, Vladimir From hohensee at amazon.com Thu Apr 15 20:45:34 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 20:45:34 +0000 Subject: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: serviceability-dev on behalf of "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 1:19 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "serviceability-dev at openjdk.java.net" Subject: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow Dear Community, I would happily accept reviews for this downport change. The change creates more meaningful output. Merge conflicts were only "technical". No complicated semantical considerations necessary. Original bug: https://bugs.openjdk.java.net/browse/JDK-8261447 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8261447.11u.01/ Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues detected that are attributable to this change. Thanks, Lutz From vkempik at azul.com Thu Apr 15 20:52:07 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 15 Apr 2021 20:52:07 +0000 Subject: [11u] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files In-Reply-To: References: Message-ID: <45CF0B54-A959-4319-9B77-DD37101EB4C3@azul.com> Hello thanks for notice, updated webrev - http://cr.openjdk.java.net/~vkempik/8240487/webrev.02/ still the webrev isn?t the best tool for whitespace patches, to see white spaces need to select that area, and I can?t tell that webrev displays them correctly all the time. Regards, Vladimir > 15 ???. 2021 ?., ? 23:38, Hohensee, Paul ???????(?): > > The webrev is empty (i.e., reports the changed files, but not the changes). Use "webrev -b". > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Vladimir Kempik > Date: Thursday, April 15, 2021 at 1:27 AM > To: jdk-updates-dev > Subject: RE: [11u] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files > > Correcting the title > >> 15 ???. 2021 ?., ? 10:40, Vladimir Kempik ???????(?): >> >> Hello >> please review this backport of JDK-8240487 to jdk11u >> I?m working on a series of patches for JNF dependency removal for macos and this backport will allow it to apply a lot more cleanly. >> Very safe, white-space only changes. >> Applies almost cleanly, I only removed second part of patch for src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m >> as it wasn?t needed. >> >> The bug - https://bugs.openjdk.java.net/browse/JDK-8240487 >> The original commit - https://hg.openjdk.java.net/jdk/jdk/rev/f532ef5561c3 >> The webrev - http://cr.openjdk.java.net/~vkempik/8240487/webrev.01/ >> >> Regards, Vladimir > > From hohensee at amazon.com Thu Apr 15 21:44:27 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 21:44:27 +0000 Subject: [11u] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Message-ID: Lgtm. Just realized that the fact that the first webrev was empty was enough to prove that the changes are whitespace-only. And that the changeset has all the whitespace changes. :) From: Vladimir Kempik Date: Thursday, April 15, 2021 at 1:52 PM To: "Hohensee, Paul" Cc: jdk-updates-dev Subject: RE: [11u] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Hello thanks for notice, updated webrev - http://cr.openjdk.java.net/~vkempik/8240487/webrev.02/ still the webrev isn?t the best tool for whitespace patches, to see white spaces need to select that area, and I can?t tell that webrev displays them correctly all the time. Regards, Vladimir 15 ???. 2021 ?., ? 23:38, Hohensee, Paul > ???????(?): The webrev is empty (i.e., reports the changed files, but not the changes). Use "webrev -b". Thanks, Paul ?-----Original Message----- From: jdk-updates-dev > on behalf of Vladimir Kempik > Date: Thursday, April 15, 2021 at 1:27 AM To: jdk-updates-dev > Subject: RE: [11u] RFR: 8240487: Cleanup whitespace in .cc, .hh, .m, and .mm files Correcting the title 15 ???. 2021 ?., ? 10:40, Vladimir Kempik > ???????(?): Hello please review this backport of JDK-8240487 to jdk11u I?m working on a series of patches for JNF dependency removal for macos and this backport will allow it to apply a lot more cleanly. Very safe, white-space only changes. Applies almost cleanly, I only removed second part of patch for src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m as it wasn?t needed. The bug - https://bugs.openjdk.java.net/browse/JDK-8240487 The original commit - https://hg.openjdk.java.net/jdk/jdk/rev/f532ef5561c3 The webrev - http://cr.openjdk.java.net/~vkempik/8240487/webrev.01/ Regards, Vladimir From omikhaltcova at openjdk.java.net Fri Apr 16 07:01:39 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 16 Apr 2021 07:01:39 GMT Subject: [jdk13u-dev] Integrated: 8259585: [macos] Bad JNI lookup error : Accessible actions do not work on macOS In-Reply-To: <9btSzxjQKw86SBoPt6FBxYPpgZoe7_75nB-u16-URiw=.fe923090-05de-462f-b74d-91124a6fdc77@github.com> References: <9btSzxjQKw86SBoPt6FBxYPpgZoe7_75nB-u16-URiw=.fe923090-05de-462f-b74d-91124a6fdc77@github.com> Message-ID: On Thu, 15 Apr 2021 17:53:04 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8259585 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with SwingSet2 demo as described in the comment to the issue. This pull request has now been integrated. Changeset: 8de0239f Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/8de0239f Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8259585: [macos] Bad JNI lookup error : Accessible actions do not work on macOS Backport-of: b6d51e15549e11be583625d908192d9f7f049489 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/184 From rwestrel at redhat.com Fri Apr 16 07:45:35 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 16 Apr 2021 09:45:35 +0200 Subject: [11u] 8263361: Incorrect arraycopy stub selected by C2 for SATB collectors In-Reply-To: References: Message-ID: <87czuuoeow.fsf@redhat.com> Thanks for the review. Roland. From shade at redhat.com Fri Apr 16 08:21:23 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 16 Apr 2021 10:21:23 +0200 Subject: [11u] RFR (S) 8207779: Method::is_valid_method() compares 'this' with NULL In-Reply-To: <0ad4eaff-ec64-5d84-2b20-a2512944273d@redhat.com> References: <3293cfb8-5988-ae71-10be-46d89f9a28b6@redhat.com> <0ad4eaff-ec64-5d84-2b20-a2512944273d@redhat.com> Message-ID: On 4/15/21 2:18 PM, Zhengyu Gu wrote: > Looks good. Thanks, tagged for approval. -- Thanks, -Aleksey From snazarki at openjdk.java.net Fri Apr 16 08:32:42 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Fri, 16 Apr 2021 08:32:42 GMT Subject: [jdk13u-dev] Integrated: 8254790: SIGSEGV in string_indexof_char and stringL_indexof_char intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 15:11:29 GMT, Sergey Nazarkin wrote: > Hi! Please review the backport of JDK-8254790. The patch fixes SIGSEGV and is required for code sync with jdk11,15. The patch is taken from jdk15 since the original one can't be applied cleanly due to reasons described https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-October/040943.html This pull request has now been integrated. Changeset: 8a7c9d77 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/8a7c9d77 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8254790: SIGSEGV in string_indexof_char and stringL_indexof_char intrinsics Reviewed-by: yan Backport-of: 365f19c8e1833fb4b64d961b51ce9d586acf13ce ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/170 From omikhaltcova at openjdk.java.net Fri Apr 16 09:27:07 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 16 Apr 2021 09:27:07 GMT Subject: [jdk15u-dev] RFR: 8259585: [macos] Bad JNI lookup error : Accessible actions do not work on macOS Message-ID: I'd like to backport JDK-8259585 to jdk15u for parity with jdk11u. The original patch applied cleanly. Tested with SwingSet2 demo as described in the comments to the issue. ------------- Commit messages: - Backport b6d51e15549e11be583625d908192d9f7f049489 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/25/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=25&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259585 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/25/head:pull/25 PR: https://git.openjdk.java.net/jdk15u-dev/pull/25 From omikhaltcova at openjdk.java.net Fri Apr 16 09:41:46 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 16 Apr 2021 09:41:46 GMT Subject: [jdk15u-dev] Integrated: 8259585: [macos] Bad JNI lookup error : Accessible actions do not work on macOS In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 09:19:41 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8259585 to jdk15u for parity with jdk11u. > The original patch applied cleanly. > Tested with SwingSet2 demo as described in the comments to the issue. This pull request has now been integrated. Changeset: 14e56d14 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/14e56d14 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8259585: [macos] Bad JNI lookup error : Accessible actions do not work on macOS Backport-of: b6d51e15549e11be583625d908192d9f7f049489 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/25 From omikhaltcova at openjdk.java.net Fri Apr 16 10:11:09 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 16 Apr 2021 10:11:09 GMT Subject: [jdk15u-dev] RFR: 8261198: [macOS] Incorrect JNI parameters in number conversion in A11Y code Message-ID: I'd like to backport JDK-8261198 to jdk15u for parity with jdk11u. The original patch applied cleanly. Tested with SwingSet2 demo using voiceover. ------------- Commit messages: - Backport 4a89733e700c3e55bb50997984b9f89a81f0af8f Changes: https://git.openjdk.java.net/jdk15u-dev/pull/26/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=26&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261198 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/26.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/26/head:pull/26 PR: https://git.openjdk.java.net/jdk15u-dev/pull/26 From lutz.schmidt at sap.com Fri Apr 16 10:15:34 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 16 Apr 2021 10:15:34 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: <5A04F6E7-CEF3-479E-BE6C-9EDCFD563098@amazon.com> References: <5A04F6E7-CEF3-479E-BE6C-9EDCFD563098@amazon.com> Message-ID: Wonderful! Thank you, Paul. Regards, Lutz ?On 15.04.21, 21:02, "Hohensee, Paul" wrote: Pushed. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Thursday, April 15, 2021 at 10:55 AM To: "Schmidt, Lutz" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes I'll sponsor. -----Original Message----- From: "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 7:16 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear all, would somebody please be willing to sponsor this backport patch? Thank you, Lutz On 14.04.21, 19:05, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Thanks for reviewing, Paul! Best, Lutz On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From omikhaltcova at openjdk.java.net Fri Apr 16 10:42:03 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 16 Apr 2021 10:42:03 GMT Subject: [jdk13u-dev] RFR: 8261198: [macOS] Incorrect JNI parameters in number conversion in A11Y code Message-ID: I'd like to backport JDK-8261198 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with SwingSet2 demo using voiceover. ------------- Commit messages: - Backport 4a89733e700c3e55bb50997984b9f89a81f0af8f Changes: https://git.openjdk.java.net/jdk13u-dev/pull/185/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=185&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261198 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/185.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/185/head:pull/185 PR: https://git.openjdk.java.net/jdk13u-dev/pull/185 From omikhaltcova at openjdk.java.net Fri Apr 16 10:57:41 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 16 Apr 2021 10:57:41 GMT Subject: [jdk15u-dev] Integrated: 8261198: [macOS] Incorrect JNI parameters in number conversion in A11Y code In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 10:04:22 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8261198 to jdk15u for parity with jdk11u. > The original patch applied cleanly. > Tested with SwingSet2 demo using voiceover. This pull request has now been integrated. Changeset: 5e897559 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/5e897559 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8261198: [macOS] Incorrect JNI parameters in number conversion in A11Y code Backport-of: 4a89733e700c3e55bb50997984b9f89a81f0af8f ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/26 From omikhaltcova at openjdk.java.net Fri Apr 16 10:57:41 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 16 Apr 2021 10:57:41 GMT Subject: [jdk13u-dev] Integrated: 8261198: [macOS] Incorrect JNI parameters in number conversion in A11Y code In-Reply-To: References: Message-ID: <2hu1ynvuGmzZLVLa-j2FXoSCVsv1vQcJBV4N_on1FLw=.2a90d341-6433-4bea-89da-f27f134ab4ca@github.com> On Fri, 16 Apr 2021 10:31:37 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8261198 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with SwingSet2 demo using voiceover. This pull request has now been integrated. Changeset: 862af192 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/862af192 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8261198: [macOS] Incorrect JNI parameters in number conversion in A11Y code Backport-of: 4a89733e700c3e55bb50997984b9f89a81f0af8f ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/185 From vkempik at azul.com Fri Apr 16 11:39:38 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 16 Apr 2021 11:39:38 +0000 Subject: [11u] RFR: jnf_removal, series of patches Message-ID: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> Hello Please review this backport of 11 patches from jdk17 to jdk11, they remove dependendy on JavaNativeFoundation.framework on macos It?s 7 original patches fo jnf removal and 4 postmortem items to fix bugs. I have created one collated webrev for 11 changesets, please let me know if it?s not the best way to do it. Brief summary for backports: 1_8257858 & 8257860 - Applies almost clean, few gmk files had different filename and few copyright year issues, context difference in gmk files. 2_8257853 - Not clean, most of issues were in CPrinterJob and JavaAccessibility due to changes in jdk12+. Rest was mostly context code difference. 3_8259343 - Clean, only gmk files renames were needed 4_8259651 - Not clean, have to remove some changes to parts which are missing in jdk11: CMenuBar: ActivateDefaultMenuBar, Accessebility: titleChanged, getMultiClickTime 5_8259869 - Almost Clean, slight Context code difference in CGLLayer.h 6_8260616 & 8259729 - not clean, Missing CommonTextAccessibility.m in jdk11. Some Context code difference. Two changes in one patch to not break the build 7_8257988 - Clean 8_8259232 - clean 9_8259585 - clean 10_8261198 - Clean 11_8263846 - clean So I need review for patches #1 #2 #4 #5 #6 and maybe (not sure) #3 #1 the bug - https://bugs.openjdk.java.net/browse/JDK-8257858 Original changeset - https://github.com/openjdk/jdk/commit/4a8b5c16 #2 the bug - https://bugs.openjdk.java.net/browse/JDK-8257853 Original changeset - https://github.com/openjdk/jdk/commit/fa50877c #3 the bug - https://bugs.openjdk.java.net/browse/JDK-8259343 Original changeset - https://git.openjdk.java.net/jdk/commit/d6a2105b #4 the bug - https://bugs.openjdk.java.net/browse/JDK-8259651 Original changeset - https://github.com/openjdk/jdk/commit/5855d52a #5 the bug - https://bugs.openjdk.java.net/browse/JDK-8259869 Original changeset - https://github.com/openjdk/jdk/commit/92c2f084 #6 the bug - https://bugs.openjdk.java.net/browse/JDK-8260616 Original changeset - https://github.com/openjdk/jdk/commit/8760688d Regards, Vladimir From vkempik at azul.com Fri Apr 16 12:12:15 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 16 Apr 2021 12:12:15 +0000 Subject: [11u] RFR: jnf_removal, series of patches In-Reply-To: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> Message-ID: The collated webrev: http://cr.openjdk.java.net/~vkempik/jnf_removal/webrev.01/ Testing - tier1, will soon update on tier2. > 16 ???. 2021 ?., ? 14:39, Vladimir Kempik ???????(?): > > Hello > Please review this backport of 11 patches from jdk17 to jdk11, they remove dependendy on JavaNativeFoundation.framework on macos > It?s 7 original patches fo jnf removal and 4 postmortem items to fix bugs. > I have created one collated webrev for 11 changesets, please let me know if it?s not the best way to do it. > Brief summary for backports: > 1_8257858 & 8257860 - Applies almost clean, few gmk files had different filename and few copyright year issues, context difference in gmk files. > 2_8257853 - Not clean, most of issues were in CPrinterJob and JavaAccessibility due to changes in jdk12+. Rest was mostly context code difference. > 3_8259343 - Clean, only gmk files renames were needed > 4_8259651 - Not clean, have to remove some changes to parts which are missing in jdk11: CMenuBar: ActivateDefaultMenuBar, Accessebility: titleChanged, getMultiClickTime > 5_8259869 - Almost Clean, slight Context code difference in CGLLayer.h > 6_8260616 & 8259729 - not clean, Missing CommonTextAccessibility.m in jdk11. Some Context code difference. Two changes in one patch to not break the build > 7_8257988 - Clean > 8_8259232 - clean > 9_8259585 - clean > 10_8261198 - Clean > 11_8263846 - clean > > So I need review for patches #1 #2 #4 #5 #6 and maybe (not sure) #3 > > #1 the bug - https://bugs.openjdk.java.net/browse/JDK-8257858 > Original changeset - https://github.com/openjdk/jdk/commit/4a8b5c16 > > #2 the bug - https://bugs.openjdk.java.net/browse/JDK-8257853 > Original changeset - https://github.com/openjdk/jdk/commit/fa50877c > > #3 the bug - https://bugs.openjdk.java.net/browse/JDK-8259343 > Original changeset - https://git.openjdk.java.net/jdk/commit/d6a2105b > > #4 the bug - https://bugs.openjdk.java.net/browse/JDK-8259651 > Original changeset - https://github.com/openjdk/jdk/commit/5855d52a > > #5 the bug - https://bugs.openjdk.java.net/browse/JDK-8259869 > Original changeset - https://github.com/openjdk/jdk/commit/92c2f084 > > #6 the bug - https://bugs.openjdk.java.net/browse/JDK-8260616 > Original changeset - https://github.com/openjdk/jdk/commit/8760688d > > Regards, Vladimir > From vkempik at azul.com Fri Apr 16 12:43:50 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 16 Apr 2021 12:43:50 +0000 Subject: [11u] RFR: jnf_removal, series of patches In-Reply-To: References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> Message-ID: <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com> Tier2 testing is good as well. > 16 ???. 2021 ?., ? 15:12, Vladimir Kempik ???????(?): > > The collated webrev: > http://cr.openjdk.java.net/~vkempik/jnf_removal/webrev.01/ > > Testing - tier1, will soon update on tier2. > >> 16 ???. 2021 ?., ? 14:39, Vladimir Kempik ???????(?): >> >> Hello >> Please review this backport of 11 patches from jdk17 to jdk11, they remove dependendy on JavaNativeFoundation.framework on macos >> It?s 7 original patches fo jnf removal and 4 postmortem items to fix bugs. >> I have created one collated webrev for 11 changesets, please let me know if it?s not the best way to do it. >> Brief summary for backports: >> 1_8257858 & 8257860 - Applies almost clean, few gmk files had different filename and few copyright year issues, context difference in gmk files. >> 2_8257853 - Not clean, most of issues were in CPrinterJob and JavaAccessibility due to changes in jdk12+. Rest was mostly context code difference. >> 3_8259343 - Clean, only gmk files renames were needed >> 4_8259651 - Not clean, have to remove some changes to parts which are missing in jdk11: CMenuBar: ActivateDefaultMenuBar, Accessebility: titleChanged, getMultiClickTime >> 5_8259869 - Almost Clean, slight Context code difference in CGLLayer.h >> 6_8260616 & 8259729 - not clean, Missing CommonTextAccessibility.m in jdk11. Some Context code difference. Two changes in one patch to not break the build >> 7_8257988 - Clean >> 8_8259232 - clean >> 9_8259585 - clean >> 10_8261198 - Clean >> 11_8263846 - clean >> >> So I need review for patches #1 #2 #4 #5 #6 and maybe (not sure) #3 >> >> #1 the bug - https://bugs.openjdk.java.net/browse/JDK-8257858 >> Original changeset - https://github.com/openjdk/jdk/commit/4a8b5c16 >> >> #2 the bug - https://bugs.openjdk.java.net/browse/JDK-8257853 >> Original changeset - https://github.com/openjdk/jdk/commit/fa50877c >> >> #3 the bug - https://bugs.openjdk.java.net/browse/JDK-8259343 >> Original changeset - https://git.openjdk.java.net/jdk/commit/d6a2105b >> >> #4 the bug - https://bugs.openjdk.java.net/browse/JDK-8259651 >> Original changeset - https://github.com/openjdk/jdk/commit/5855d52a >> >> #5 the bug - https://bugs.openjdk.java.net/browse/JDK-8259869 >> Original changeset - https://github.com/openjdk/jdk/commit/92c2f084 >> >> #6 the bug - https://bugs.openjdk.java.net/browse/JDK-8260616 >> Original changeset - https://github.com/openjdk/jdk/commit/8760688d >> >> Regards, Vladimir >> > From lutz.schmidt at sap.com Fri Apr 16 13:09:42 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 16 Apr 2021 13:09:42 +0000 Subject: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow In-Reply-To: References: Message-ID: <1AC58C53-381C-4230-8B46-437608651107@sap.com> Hi Paul, thank you for the review. @All: It's annoying, I know. I need somebody to sponsor this change as well. Thanks, Lutz ?On 15.04.21, 22:45, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: serviceability-dev on behalf of "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 1:19 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "serviceability-dev at openjdk.java.net" Subject: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow Dear Community, I would happily accept reviews for this downport change. The change creates more meaningful output. Merge conflicts were only "technical". No complicated semantical considerations necessary. Original bug: https://bugs.openjdk.java.net/browse/JDK-8261447 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8261447.11u.01/ Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues detected that are attributable to this change. Thanks, Lutz From hohensee at amazon.com Fri Apr 16 15:38:11 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 16 Apr 2021 15:38:11 +0000 Subject: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow Message-ID: <3B3457EF-81F9-4A90-B1A1-D018FB1A06CA@amazon.com> I'll sponsor. ?-----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 6:10 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: "serviceability-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow Hi Paul, thank you for the review. @All: It's annoying, I know. I need somebody to sponsor this change as well. Thanks, Lutz On 15.04.21, 22:45, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: serviceability-dev on behalf of "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 1:19 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "serviceability-dev at openjdk.java.net" Subject: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow Dear Community, I would happily accept reviews for this downport change. The change creates more meaningful output. Merge conflicts were only "technical". No complicated semantical considerations necessary. Original bug: https://bugs.openjdk.java.net/browse/JDK-8261447 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8261447.11u.01/ Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues detected that are attributable to this change. Thanks, Lutz From lutz.schmidt at sap.com Fri Apr 16 15:39:20 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 16 Apr 2021 15:39:20 +0000 Subject: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow In-Reply-To: <3B3457EF-81F9-4A90-B1A1-D018FB1A06CA@amazon.com> References: <3B3457EF-81F9-4A90-B1A1-D018FB1A06CA@amazon.com> Message-ID: <88BA86AA-A615-433B-8727-C1C62D945FF2@sap.com> Hey Paul, you are my hero! Thanks and have a great weekend, Lutz ?On 16.04.21, 17:38, "Hohensee, Paul" wrote: I'll sponsor. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 6:10 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: "serviceability-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow Hi Paul, thank you for the review. @All: It's annoying, I know. I need somebody to sponsor this change as well. Thanks, Lutz On 15.04.21, 22:45, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: serviceability-dev on behalf of "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 1:19 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "serviceability-dev at openjdk.java.net" Subject: [11u] RFR(M): 8261447 backport: MethodInvocationCounters frequently run into overflow Dear Community, I would happily accept reviews for this downport change. The change creates more meaningful output. Merge conflicts were only "technical". No complicated semantical considerations necessary. Original bug: https://bugs.openjdk.java.net/browse/JDK-8261447 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8261447.11u.01/ Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues detected that are attributable to this change. Thanks, Lutz From hohensee at amazon.com Fri Apr 16 16:06:22 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 16 Apr 2021 16:06:22 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Message-ID: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From lutz.schmidt at sap.com Fri Apr 16 16:47:38 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 16 Apr 2021 16:47:38 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: References: Message-ID: <275D81B4-48CF-48B7-A55D-88938E8EAED5@sap.com> Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz ?On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From hohensee at amazon.com Fri Apr 16 16:58:19 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 16 Apr 2021 16:58:19 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Message-ID: <7FF068E8-BDC9-4945-A263-72613C31A461@amazon.com> If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. ?-----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From hohensee at amazon.com Fri Apr 16 17:28:45 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 16 Apr 2021 17:28:45 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: <7FF068E8-BDC9-4945-A263-72613C31A461@amazon.com> References: <7FF068E8-BDC9-4945-A263-72613C31A461@amazon.com> Message-ID: Forgot to write I agree with you on not including 8214526. ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From rhalade at openjdk.java.net Fri Apr 16 18:51:03 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 16 Apr 2021 18:51:03 GMT Subject: [jdk16u] RFR: 8225081: Remove Telia Company CA certificate expiring in April 2021 Message-ID: <9EZDwMVc745_v65zhhfTzynaYUs7H5-Cxco5UnrQSik=.4e40e975-9b9e-4f1e-a89e-2a46ae520bcf@github.com> Backport is not clean as HexFormat changes are not in JDK 16. ------------- Commit messages: - 8225081: Remove Telia Company CA certificate expiring in April 2021 Changes: https://git.openjdk.java.net/jdk16u/pull/106/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=106&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225081 Stats: 33 lines in 2 files changed: 0 ins; 30 del; 3 mod Patch: https://git.openjdk.java.net/jdk16u/pull/106.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/106/head:pull/106 PR: https://git.openjdk.java.net/jdk16u/pull/106 From rhalade at openjdk.java.net Sat Apr 17 19:28:41 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Sat, 17 Apr 2021 19:28:41 GMT Subject: [jdk16u] Integrated: 8225081: Remove Telia Company CA certificate expiring in April 2021 In-Reply-To: <9EZDwMVc745_v65zhhfTzynaYUs7H5-Cxco5UnrQSik=.4e40e975-9b9e-4f1e-a89e-2a46ae520bcf@github.com> References: <9EZDwMVc745_v65zhhfTzynaYUs7H5-Cxco5UnrQSik=.4e40e975-9b9e-4f1e-a89e-2a46ae520bcf@github.com> Message-ID: On Fri, 16 Apr 2021 18:44:06 GMT, Rajan Halade wrote: > Backport is not clean as HexFormat changes are not in JDK 16. This pull request has now been integrated. Changeset: 71e6dab1 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk16u/commit/71e6dab1 Stats: 33 lines in 2 files changed: 0 ins; 30 del; 3 mod 8225081: Remove Telia Company CA certificate expiring in April 2021 Backport-of: ef7ee3f44e4dbdde28406ac813e2e3ad20aec849 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/106 From thomas.stuefe at gmail.com Mon Apr 19 09:43:45 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 19 Apr 2021 11:43:45 +0200 Subject: RFR[11u]: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist Message-ID: Hi, may I have reviews for this trivial downport. It does not apply cleanly since the code diverged too much since JDK11. JNI_ArgumentPusherVaArg keeps a copy of a va-arg pointer, but does not free it when going out of scope. Depending on how the libc implements va, this may be a leak. Original patch: https://github.com/openjdk/jdk/commit/ae1eb286 Modified for 11u (I removed the irrelevant protection modifier change from this downport): diff -r 530d75a38b9b -r 22ccf5b00e12 src/hotspot/share/prims/jni.cpp --- a/src/hotspot/share/prims/jni.cpp Mon Jul 30 16:35:54 2018 -0400 +++ b/src/hotspot/share/prims/jni.cpp Mon Apr 19 11:35:58 2021 +0200 @@ -953,6 +953,10 @@ set_ap(rap); } + ~JNI_ArgumentPusherVaArg() { + va_end(_ap); + } + // Optimized path if we have the bitvector form of signature void iterate( uint64_t fingerprint ) { if (fingerprint == (uint64_t)CONST64(-1)) { Thanks, Thomas From christoph.goettschkes at microdoc.com Mon Apr 19 10:56:07 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Mon, 19 Apr 2021 12:56:07 +0200 Subject: [11u] RFR: 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM Message-ID: <38129jy9pv-1@aserp2020.oracle.com> Hi, please review this backport of JDK-8214512 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8214512 Original commit: https://hg.openjdk.java.net/jdk/jdk12/rev/5da72d7e0e80 Webrev: https://cr.openjdk.java.net/~cgo/8214512/webrev.11u.00/ As already mentioned by Aleksey in the bug report, this test case also fails on 11u, which is fixed by this backport. The backport is not clean, because in 11u, the arm64 CPU type is still present. Adjusting the backport was fairly straight forward. Tested tier1 on Linux/ARMv7-A Thanks, Christoph From eastig at amazon.co.uk Mon Apr 19 11:02:47 2021 From: eastig at amazon.co.uk (Astigeevich, Evgeny) Date: Mon, 19 Apr 2021 11:02:47 +0000 Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow In-Reply-To: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com> References: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com> Message-ID: <14294007-A41E-4A5C-86BB-1E616ECCDA1C@amazon.com> Hi, Please review the backport of JDK-8177068 to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8177068 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a3c63a9dfb2c The original patch does not apply cleanly to 11u. In the original patch, file DeferredAttr.java, calls of ?attribSpeculative? to be changed have the argument AttributionMode.SPECULATIVE. The original patch does not change this. In 11u ?attribSpeculative? does not have the parameter AttributionMode. I changed the affected calls to 11u API. 11u webrev: http://cr.openjdk.java.net/~eastigeevich/8177068/webrev.00/ Tested: Amazon Linux 2 x86_64, tier1, tier2, langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153 Thanks, Evgeny Astigeevich Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. From eastig at amazon.co.uk Mon Apr 19 11:49:36 2021 From: eastig at amazon.co.uk (Astigeevich, Evgeny) Date: Mon, 19 Apr 2021 11:49:36 +0000 Subject: [11u] RFR: 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM Message-ID: Lgtm. ?On 19/04/2021, 11:58, "jdk-updates-dev on behalf of Christoph G?ttschkes" wrote: Hi, please review this backport of JDK-8214512 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8214512 Original commit: https://hg.openjdk.java.net/jdk/jdk12/rev/5da72d7e0e80 Webrev: https://cr.openjdk.java.net/~cgo/8214512/webrev.11u.00/ As already mentioned by Aleksey in the bug report, this test case also fails on 11u, which is fixed by this backport. The backport is not clean, because in 11u, the arm64 CPU type is still present. Adjusting the backport was fairly straight forward. Tested tier1 on Linux/ARMv7-A Thanks, Christoph Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. From ramanand.patil at in.ibm.com Mon Apr 19 13:54:29 2021 From: ramanand.patil at in.ibm.com (Ramanand Patil) Date: Mon, 19 Apr 2021 13:54:29 +0000 Subject: [11u] RFR: JDK-8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 In-Reply-To: <539f75e37eeb240a9b51e9de54888e995fd30db5.camel@redhat.com> References: <539f75e37eeb240a9b51e9de54888e995fd30db5.camel@redhat.com>, Message-ID: Hi Severin and all, Sorry for the delays. I have adjusted the code as per the suggestions, please review the v2 webrev. http://cr.openjdk.java.net/~rpatil/8247753/webrev.01/ Regards, Ramanand. -----Severin Gehwolf wrote: ----- To: Ramanand Patil , jdk-updates-dev at openjdk.java.net From: Severin Gehwolf Date: 02/22/2021 06:44PM Subject: [EXTERNAL] Re: [11u] RFR: JDK-8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 Hi, On Mon, 2021-02-22 at 06:02 +0000, Ramanand Patil wrote: > Hi all, > Please review the JDK11u backport of JDK-8247753: > UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora > 32 > Bug Link: https://bugs.openjdk.java.net/browse/JDK-8247753 > Webrev: http://cr.openjdk.java.net/~rpatil/8247753/webrev.00/ 461 if (getenv("GNOME_DESKTOP_SESSION_ID") != NULL 462 || getenv("XDG_CURRENT_DESKTOP") != NULL) { 463 sprops.desktop = "gnome"; 464 } This doesn't match the functionality in jdk/jdk, which only returns a desktop value of "gnome" if XDG_CURRENT_DESKTOP contains the string, ignoring case, "gnome". The current patch actually fails the test if XDG_CURRENT_DESKTOP=FOO. Suggested change: diff --git a/src/java.base/unix/native/libjava/java_props_md.c b/src/java.base/unix/native/libjava/java_props_md.c --- a/src/java.base/unix/native/libjava/java_props_md.c +++ b/src/java.base/unix/native/libjava/java_props_md.c @@ -457,9 +457,10 @@ #endif /* MACOSX */ sprops.os_arch = ARCHPROPNAME; + char* curr_desktop = getenv("XDG_CURRENT_DESKTOP"); if (getenv("GNOME_DESKTOP_SESSION_ID") != NULL - || getenv("XDG_CURRENT_DESKTOP") != NULL) { + || (curr_desktop != NULL && strcasestr(curr_desktop, "gnome") != NULL)) { sprops.desktop = "gnome"; } else { Thanks, Severin From shade at redhat.com Mon Apr 19 14:30:19 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Apr 2021 16:30:19 +0200 Subject: [11u] RFR (S) 8225081: Remove Telia Company CA certificate expiring in April 2021 Message-ID: <17922688-88a1-f7fd-a02e-13891284a3db@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8225081 https://git.openjdk.java.net/jdk/commit/ef7ee3f4 The patch applies to 11u nearly exactly, except the @bug line in the test. I believe it was mistakenly omitted during JDK-8256421 backport, so I just added its ID there as well. 11u variant: https://cr.openjdk.java.net/~shade/8225081/webrev.11u.01/ Testing: VerifyCA tests, tier{1,2} -- Thanks, -Aleksey From martin.doerr at sap.com Mon Apr 19 14:32:16 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 19 Apr 2021 14:32:16 +0000 Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance Message-ID: Hi, JDK-8261812 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8261812 Original change: https://git.openjdk.java.net/jdk/commit/2c0507ec Resolution steps: compile.hpp: - push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry, - BasicType bt); + static bool push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry, + BasicType bt); This cleanup is not applicable. Skipped. macro.cpp: + if (is_subword_type(ft)) { + n = Compile::narrow_value(ft, n, phi_type, &_igvn, true); + } The surrounding code is different in 11u because of GC related changes. I had to adapt it. 11u backport: http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/ Please review. Best regards, Martin From shade at redhat.com Mon Apr 19 14:32:49 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Apr 2021 16:32:49 +0200 Subject: [11u] RFR: 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM In-Reply-To: <38129jy9pv-1@aserp2020.oracle.com> References: <38129jy9pv-1@aserp2020.oracle.com> Message-ID: <1ebdcf3f-3e3c-b27c-c77e-18298b5c3e54@redhat.com> On 4/19/21 12:56 PM, Christoph G?ttschkes wrote: > Webrev: https://cr.openjdk.java.net/~cgo/8214512/webrev.11u.00/ This looks fine to me. -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Mon Apr 19 14:48:33 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Mon, 19 Apr 2021 16:48:33 +0200 Subject: [11u] RFR: 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM In-Reply-To: <1ebdcf3f-3e3c-b27c-c77e-18298b5c3e54@redhat.com> References: <38129jy9pv-1@aserp2020.oracle.com> <1ebdcf3f-3e3c-b27c-c77e-18298b5c3e54@redhat.com> Message-ID: <381bf40mq9-1@aserp2050.oracle.com> Thanks for the review, Aleksey. I will make the fix request and report back, since I need a sponsor for this change. -- Christoph On 4/19/21 4:32 PM, Aleksey Shipilev wrote: > On 4/19/21 12:56 PM, Christoph G?ttschkes wrote: >> Webrev: https://cr.openjdk.java.net/~cgo/8214512/webrev.11u.00/ > > This looks fine to me. > From lutz.schmidt at sap.com Mon Apr 19 15:53:42 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 19 Apr 2021 15:53:42 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: <34EE065E-8B6F-4307-82D2-448BD3C5561E@sap.com> References: <7FF068E8-BDC9-4945-A263-72613C31A461@amazon.com> <34EE065E-8B6F-4307-82D2-448BD3C5561E@sap.com> Message-ID: Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz ?On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From martin.doerr at sap.com Mon Apr 19 15:53:52 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 19 Apr 2021 15:53:52 +0000 Subject: [11u] RFR (S) 8225081: Remove Telia Company CA certificate expiring in April 2021 In-Reply-To: <17922688-88a1-f7fd-a02e-13891284a3db@redhat.com> References: <17922688-88a1-f7fd-a02e-13891284a3db@redhat.com> Message-ID: Hi Aleksey, looks good. Thanks for backporting! Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Montag, 19. April 2021 16:30 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR (S) 8225081: Remove Telia Company CA certificate expiring > in April 2021 > > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8225081 > https://git.openjdk.java.net/jdk/commit/ef7ee3f4 > > The patch applies to 11u nearly exactly, except the @bug line in the test. I > believe it was > mistakenly omitted during JDK-8256421 backport, so I just added its ID there > as well. > > 11u variant: > https://cr.openjdk.java.net/~shade/8225081/webrev.11u.01/ > > Testing: VerifyCA tests, tier{1,2} > > -- > Thanks, > -Aleksey From ilarion at azul.com Mon Apr 19 19:21:28 2021 From: ilarion at azul.com (Ilarion Nakonechnyy) Date: Mon, 19 Apr 2021 19:21:28 +0000 Subject: FW: question about JDK-8172231: SPARC CPU features detection In-Reply-To: <82F0DDEB-9103-4280-A7BC-1C67916DFDAA@azul.com> References: <82F0DDEB-9103-4280-A7BC-1C67916DFDAA@azul.com> Message-ID: <69C42B8E-5761-4216-A572-3E3BC3D6226E@azul.com> Dear sirs, good day. My name is Ilarion, I?m new contributor for OpenJDK project. I have some questions about implementation of fix for bug JDK-8172231: SPARC CPU features detection, probably somebody may shed some lights on it. I?m doing my exercises on JDK 11 and noticed that on exact SPARC CPU block zeroing detection feature determines wrong. Having system with SPARC64-X CPU, java fails with segmentation violation error, on the very beginning of the java run. My investigations lead me to MacroAssembler::bis_zeroing() routine. Where begin and end of memory area is cleared by stx instruction, and the rest ? via stxa(G0, to, G0, Assembler::ASI_ST_BLKINIT_PRIMARY), that supposed to zeroing memory, but it doesn?t. Turning off block zeroing feature via flag -XX:-UseBlockZeroing helps to avoid the crash. Decision if CPU has the CPU_blk_zeroing_msk feature based on determining another cpu flag, ISA_ima_msk + // Niagara Core S3 supports fast RDPC and block zeroing. + if (has_ima()) { + synthetic |= (CPU_fast_rdpc_msk | CPU_blk_zeroing_msk); + } But there is also mentioned special flag, that corresponds to Block initialization feature: ISA_blk_init_msk. That actually isn?t checked at all. ( Other than in reporting ) I looked in JDK 8, and figured out, that block zeroing capacity there was decided not only by ISA flags, but with referring on CPU model also: - // On T4 and newer Sparc BIS to the beginning of cache line always zeros it. - static bool has_block_zeroing() { return has_blk_init() && is_T4(); } JDK 8 works well for my case, because BIS instruction isn?t used Despite ISA flags that is returned by getisax reports that block initialization is supported ( AV_SPARC_ASI_BLK_INIT 0x0080 ) [0.172s][info][os,cpu ] getisax(2) returned 1 words: [0.172s][info][os,cpu ] word 0: 0xc001b1f0 So, as I can see, the CPU version ( ?cpu brand? in jdk 8 ) has main role in detecting CPU block zeroing feature. Do you have some more information, probably any doc, where noted why CPU version plays such a role in feature detecting for JVM? In CPU specifications I didn?t found any clues about this. Thank you in advance. From hohensee at amazon.com Mon Apr 19 19:31:17 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 19 Apr 2021 19:31:17 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: References: <7FF068E8-BDC9-4945-A263-72613C31A461@amazon.com> <34EE065E-8B6F-4307-82D2-448BD3C5561E@sap.com> Message-ID: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html Paul ?-----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From lutz.schmidt at sap.com Mon Apr 19 20:01:11 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 19 Apr 2021 20:01:11 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: References: <7FF068E8-BDC9-4945-A263-72613C31A461@amazon.com> <34EE065E-8B6F-4307-82D2-448BD3C5561E@sap.com> Message-ID: See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz ?On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From hohensee at amazon.com Mon Apr 19 20:44:27 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 19 Apr 2021 20:44:27 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Message-ID: <47739DCA-B360-4D57-BEE6-414F3C53A8F5@amazon.com> I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } ?-----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From snazarki at openjdk.java.net Mon Apr 19 21:14:43 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Mon, 19 Apr 2021 21:14:43 GMT Subject: [jdk13u-dev] RFR: 8256359: AArch64: runtime/ReservedStack/ReservedStackTestCompiler.java fails Message-ID: Please review backport of JDK-8256359. Patch applies cleanly except update of ProblemList.txt is not required since JDK-8256803 was not backported to jdk13. I was not able to reproduce the crash on any board accessible for tests, but the patch fixes obvious error and required for parity with jdk11 ------------- Commit messages: - Backport 4e43b28858b0c7c9fb7ad91a506b61aa1d554f86 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/186/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=186&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256359 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/186.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/186/head:pull/186 PR: https://git.openjdk.java.net/jdk13u-dev/pull/186 From lutz.schmidt at sap.com Mon Apr 19 21:39:07 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 19 Apr 2021 21:39:07 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: <47739DCA-B360-4D57-BEE6-414F3C53A8F5@amazon.com> References: <47739DCA-B360-4D57-BEE6-414F3C53A8F5@amazon.com> Message-ID: <0612795F-8831-4B7B-B350-026722699691@sap.com> Yes, that's in the #else path of #if defined(USE_BUFFEREDSTREAM). You have to look further up: +// Same as above, but with fixed buffer size. +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K); + #define STRINGSTREAM_FLUSH(termString) \ _sstbuf->print("%s", termString); \ _outbuf->print("%s", _sstbuf->as_string()); \ _sstbuf->reset(); +// Flush the buffer contents unconditionally. +// No action if the buffer is empty. +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ ?On 19.04.21, 22:44, "Hohensee, Paul" wrote: I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From david.buck at oracle.com Tue Apr 20 02:25:59 2021 From: david.buck at oracle.com (David Buck) Date: Tue, 20 Apr 2021 02:25:59 +0000 Subject: question about JDK-8172231: SPARC CPU features detection In-Reply-To: <69C42B8E-5761-4216-A572-3E3BC3D6226E@azul.com> References: <82F0DDEB-9103-4280-A7BC-1C67916DFDAA@azul.com> <69C42B8E-5761-4216-A572-3E3BC3D6226E@azul.com> Message-ID: Hi Ilarion! The OpenJDK community may want to consider a fix similar to what we did in Oracle JDK 11 [0]. Cheers, -Buck [0] https://bugs.openjdk.java.net/browse/JDK-8263407 -----Original Message----- From: jdk-updates-dev On Behalf Of Ilarion Nakonechnyy Sent: Tuesday, April 20, 2021 4:21 AM To: jdk-updates-dev at openjdk.java.net Subject: FW: question about JDK-8172231: SPARC CPU features detection Dear sirs, good day. My name is Ilarion, I?m new contributor for OpenJDK project. I have some questions about implementation of fix for bug JDK-8172231: SPARC CPU features detection, probably somebody may shed some lights on it. I?m doing my exercises on JDK 11 and noticed that on exact SPARC CPU block zeroing detection feature determines wrong. Having system with SPARC64-X CPU, java fails with segmentation violation error, on the very beginning of the java run. My investigations lead me to MacroAssembler::bis_zeroing() routine. Where begin and end of memory area is cleared by stx instruction, and the rest ? via stxa(G0, to, G0, Assembler::ASI_ST_BLKINIT_PRIMARY), that supposed to zeroing memory, but it doesn?t. Turning off block zeroing feature via flag -XX:-UseBlockZeroing helps to avoid the crash. Decision if CPU has the CPU_blk_zeroing_msk feature based on determining another cpu flag, ISA_ima_msk + // Niagara Core S3 supports fast RDPC and block zeroing. + if (has_ima()) { + synthetic |= (CPU_fast_rdpc_msk | CPU_blk_zeroing_msk); + } But there is also mentioned special flag, that corresponds to Block initialization feature: ISA_blk_init_msk. That actually isn?t checked at all. ( Other than in reporting ) I looked in JDK 8, and figured out, that block zeroing capacity there was decided not only by ISA flags, but with referring on CPU model also: - // On T4 and newer Sparc BIS to the beginning of cache line always zeros it. - static bool has_block_zeroing() { return has_blk_init() && is_T4(); } JDK 8 works well for my case, because BIS instruction isn?t used Despite ISA flags that is returned by getisax reports that block initialization is supported ( AV_SPARC_ASI_BLK_INIT 0x0080 ) [0.172s][info][os,cpu ] getisax(2) returned 1 words: [0.172s][info][os,cpu ] word 0: 0xc001b1f0 So, as I can see, the CPU version ( ?cpu brand? in jdk 8 ) has main role in detecting CPU block zeroing feature. Do you have some more information, probably any doc, where noted why CPU version plays such a role in feature detecting for JVM? In CPU specifications I didn?t found any clues about this. Thank you in advance. From goetz.lindenmaier at sap.com Tue Apr 20 06:43:11 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Apr 2021 06:43:11 +0000 Subject: question about JDK-8172231: SPARC CPU features detection In-Reply-To: References: <82F0DDEB-9103-4280-A7BC-1C67916DFDAA@azul.com> <69C42B8E-5761-4216-A572-3E3BC3D6226E@azul.com> Message-ID: Hi David, do you mind sharing the patch? As the change was made in OracleJDK, we can not reach the changeset from JBS. Thanks! Goetz > -----Original Message----- > From: jdk-updates-dev On > Behalf Of David Buck > Sent: Tuesday, April 20, 2021 4:26 AM > To: Ilarion Nakonechnyy ; jdk-updates- > dev at openjdk.java.net > Subject: RE: question about JDK-8172231: SPARC CPU features detection > > Hi Ilarion! > > The OpenJDK community may want to consider a fix similar to what we did in > Oracle JDK 11 [0]. > > Cheers, > -Buck > > [0] https://bugs.openjdk.java.net/browse/JDK-8263407 > > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ilarion Nakonechnyy > Sent: Tuesday, April 20, 2021 4:21 AM > To: jdk-updates-dev at openjdk.java.net > Subject: FW: question about JDK-8172231: SPARC CPU features detection > > Dear sirs, good day. > My name is Ilarion, I?m new contributor for OpenJDK project. > > I have some questions about implementation of fix for bug JDK-8172231: > SPARC CPU features detection, probably somebody may shed some lights on > it. > > I?m doing my exercises on JDK 11 and noticed that on exact SPARC CPU block > zeroing detection feature determines wrong. > Having system with SPARC64-X CPU, java fails with segmentation violation > error, on the very beginning of the java run. > My investigations lead me to MacroAssembler::bis_zeroing() routine. Where > begin and end of memory area is cleared by stx instruction, and the rest ? via > stxa(G0, to, G0, Assembler::ASI_ST_BLKINIT_PRIMARY), that supposed to > zeroing memory, but it doesn?t. > Turning off block zeroing feature via flag -XX:-UseBlockZeroing helps to avoid > the crash. > > > > > Decision if CPU has the CPU_blk_zeroing_msk feature based on determining > another cpu flag, ISA_ima_msk > > + // Niagara Core S3 supports fast RDPC and block zeroing. > > + if (has_ima()) { > > + synthetic |= (CPU_fast_rdpc_msk | CPU_blk_zeroing_msk); > > + } > > But there is also mentioned special flag, that corresponds to Block > initialization feature: ISA_blk_init_msk. That actually isn?t checked at all. > ( Other than in reporting ) I looked in JDK 8, and figured out, that block > zeroing capacity there was decided not only by ISA flags, but with referring > on CPU model also: > > - // On T4 and newer Sparc BIS to the beginning of cache line always zeros it. > > - static bool has_block_zeroing() { return has_blk_init() && is_T4(); } > > > JDK 8 works well for my case, because BIS instruction isn?t used Despite ISA > flags that is returned by getisax reports that block initialization is supported > ( AV_SPARC_ASI_BLK_INIT 0x0080 ) > > [0.172s][info][os,cpu ] getisax(2) returned 1 words: > > [0.172s][info][os,cpu ] word 0: 0xc001b1f0 > > So, as I can see, the CPU version ( ?cpu brand? in jdk 8 ) has main role in > detecting CPU block zeroing feature. > Do you have some more information, probably any doc, where noted why > CPU version plays such a role in feature detecting for JVM? In CPU > specifications I didn?t found any clues about this. > Thank you in advance. From shade at redhat.com Tue Apr 20 07:59:51 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 09:59:51 +0200 Subject: [11u] RFR (S) 8244205: HTTP/2 tunnel connections through proxy may be reused regardless of which proxy is selected Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8244205 https://hg.openjdk.java.net/jdk/jdk/rev/dd61d60329f6 This fixes the issue exposed by JDK-8244031 backport. The patch applies nearly exactly, but the tests need adjustments for 11u: - jdk.test.lib.net.SimpleSSLContext is jdk.testlibrary.SimpleSSLContext - @library /test/lib is @library /lib/testlibrary Testing: java/net/httpclient tests -- Thanks, -Aleksey From shade at redhat.com Tue Apr 20 07:59:48 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 09:59:48 +0200 Subject: [11u] RFR (S) 8244031: HttpClient should have more tests for HEAD requests Message-ID: Original fix: https://bugs.openjdk.java.net/browse/JDK-8244031 https://hg.openjdk.java.net/jdk/jdk/rev/a0d9d2e73ef2 The patch applies nearly exactly, but the tests need adjustments for 11u: - jdk.test.lib.net.SimpleSSLContext is jdk.testlibrary.SimpleSSLContext - @library /test/lib is @library /lib/testlibrary ForbiddenHeadTest exposes the bug that is fixed by JDK-8244205. I'll propose it for 11u backports shortly. Testing: java/net/httpclient tests -- Thanks, -Aleksey From shade at redhat.com Tue Apr 20 08:06:14 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 10:06:14 +0200 Subject: RFR[11u]: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: Message-ID: On 4/19/21 11:43 AM, Thomas St?fe wrote: > Modified for 11u (I removed the irrelevant protection modifier change from > this downport): I would prefer to keep the backport exact, i.e. with "protected" removal. Reason: subsequent backports might depend on visibility change. Or does it break something else? > diff -r 530d75a38b9b -r 22ccf5b00e12 src/hotspot/share/prims/jni.cpp > --- a/src/hotspot/share/prims/jni.cpp Mon Jul 30 16:35:54 2018 -0400 > +++ b/src/hotspot/share/prims/jni.cpp Mon Apr 19 11:35:58 2021 +0200 > @@ -953,6 +953,10 @@ > set_ap(rap); > } > > + ~JNI_ArgumentPusherVaArg() { > + va_end(_ap); > + } > + > // Optimized path if we have the bitvector form of signature > void iterate( uint64_t fingerprint ) { > if (fingerprint == (uint64_t)CONST64(-1)) { Otherwise, this looks good to me. -- Thanks, -Aleksey From shade at redhat.com Tue Apr 20 08:09:13 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 10:09:13 +0200 Subject: [11u] RFR (S) 8244031: HttpClient should have more tests for HEAD requests In-Reply-To: References: Message-ID: On 4/20/21 9:59 AM, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8244031 > https://hg.openjdk.java.net/jdk/jdk/rev/a0d9d2e73ef2 > > The patch applies nearly exactly, but the tests need adjustments for 11u: > - jdk.test.lib.net.SimpleSSLContext is jdk.testlibrary.SimpleSSLContext > - @library /test/lib is @library /lib/testlibrary > > ForbiddenHeadTest exposes the bug that is fixed by JDK-8244205. I'll propose it for 11u backports > shortly. > > Testing: java/net/httpclient tests Gaa! I forgot the link to 11u webrev: https://cr.openjdk.java.net/~shade/8244031/webrev.11u.01/ -- Thanks, -Aleksey From shade at redhat.com Tue Apr 20 08:09:49 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 10:09:49 +0200 Subject: [11u] RFR (S) 8244205: HTTP/2 tunnel connections through proxy may be reused regardless of which proxy is selected In-Reply-To: References: Message-ID: <635d8f25-9c9d-c9ac-1dd4-7ba6de1f8ef5@redhat.com> On 4/20/21 9:59 AM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8244205 > https://hg.openjdk.java.net/jdk/jdk/rev/dd61d60329f6 > > This fixes the issue exposed by JDK-8244031 backport. > > The patch applies nearly exactly, but the tests need adjustments for 11u: > - jdk.test.lib.net.SimpleSSLContext is jdk.testlibrary.SimpleSSLContext > - @library /test/lib is @library /lib/testlibrary > > Testing: java/net/httpclient tests Forgot the link to 11u webrev as well: https://cr.openjdk.java.net/~shade/8244205/webrev.11u.01/ -- Thanks, -Aleksey From yan at openjdk.java.net Tue Apr 20 09:10:20 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 20 Apr 2021 09:10:20 GMT Subject: [jdk13u-dev] RFR: 8256359: AArch64: runtime/ReservedStack/ReservedStackTestCompiler.java fails In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 21:08:58 GMT, Sergey Nazarkin wrote: > Please review backport of JDK-8256359. Patch applies cleanly except update of ProblemList.txt is not required since JDK-8256803 was not backported to jdk13. I was not able to reproduce the crash on any board accessible for tests, but the patch fixes obvious error and required for parity with jdk11 NB: in bug description it is stated "tier2 test failure". Could you run that set of tests as well? And, is a comment at line 656 still valid? ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/186 From sgehwolf at redhat.com Tue Apr 20 09:22:27 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 20 Apr 2021 11:22:27 +0200 Subject: [11u] RFR: JDK-8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 In-Reply-To: References: <539f75e37eeb240a9b51e9de54888e995fd30db5.camel@redhat.com> , Message-ID: <8f0ae3b31d50e857b3ecdc4d99a6f8d0e511ea97.camel@redhat.com> On Mon, 2021-04-19 at 13:54 +0000, Ramanand Patil wrote: > http://cr.openjdk.java.net/~rpatil/8247753/webrev.01/ This looks fine. Thanks, Severin From thomas.stuefe at gmail.com Tue Apr 20 10:53:55 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 20 Apr 2021 12:53:55 +0200 Subject: RFR[11u]: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: Message-ID: You are right, I'll re-add the protected removal. Thanks for reviewing. Cheers, Thomas On Tue, Apr 20, 2021 at 10:06 AM Aleksey Shipilev wrote: > On 4/19/21 11:43 AM, Thomas St?fe wrote: > > Modified for 11u (I removed the irrelevant protection modifier change > from > > this downport): > > I would prefer to keep the backport exact, i.e. with "protected" removal. > Reason: subsequent > backports might depend on visibility change. Or does it break something > else? > > > diff -r 530d75a38b9b -r 22ccf5b00e12 src/hotspot/share/prims/jni.cpp > > --- a/src/hotspot/share/prims/jni.cpp Mon Jul 30 16:35:54 2018 -0400 > > +++ b/src/hotspot/share/prims/jni.cpp Mon Apr 19 11:35:58 2021 +0200 > > @@ -953,6 +953,10 @@ > > set_ap(rap); > > } > > > > + ~JNI_ArgumentPusherVaArg() { > > + va_end(_ap); > > + } > > + > > // Optimized path if we have the bitvector form of signature > > void iterate( uint64_t fingerprint ) { > > if (fingerprint == (uint64_t)CONST64(-1)) { > > Otherwise, this looks good to me. > > -- > Thanks, > -Aleksey > > From shade at redhat.com Tue Apr 20 11:00:06 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 13:00:06 +0200 Subject: [11u] RFR: 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM In-Reply-To: <88424.121041910500901101@us-mta-207.us.mimecast.lan> References: <38129jy9pv-1@aserp2020.oracle.com> <1ebdcf3f-3e3c-b27c-c77e-18298b5c3e54@redhat.com> <88424.121041910500901101@us-mta-207.us.mimecast.lan> Message-ID: <3758a5e1-153a-b6cf-986c-4eeb2552fb73@redhat.com> On 4/19/21 4:48 PM, Christoph G?ttschkes wrote: > I will make the fix request and report back, since I need a sponsor for this change. I see you got the 11u approval. I sponsored the push for you: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9846af5a0949 -- Thanks, -Aleksey From snazarki at openjdk.java.net Tue Apr 20 13:30:13 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Tue, 20 Apr 2021 13:30:13 GMT Subject: [jdk13u-dev] RFR: 8256359: AArch64: runtime/ReservedStack/ReservedStackTestCompiler.java fails In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 09:07:16 GMT, Yuri Nesterenko wrote: >> Please review backport of JDK-8256359. Patch applies cleanly except update of ProblemList.txt is not required since JDK-8256803 was not backported to jdk13. I was not able to reproduce the crash on any board accessible for tests, but the patch fixes obvious error and required for parity with jdk11 > > NB: in bug description it is stated "tier2 test failure". Could you run that set of tests as well? And, is a comment at line 656 still valid? @yan-too the test is a part of tier2 group, but I tried it individually. Will run whole hotspot set. Regarding the comment. The code and comments equals to the related pieces at jdk/jdk11. Anyway the comment is right: we're still loading sender sp ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/186 From richard.reingruber at sap.com Tue Apr 20 13:54:19 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 20 Apr 2021 13:54:19 +0000 Subject: [11u] RFR 8262295: C2: Out-of-Bounds Array Load from Clone Source Message-ID: Hi, Please help review this backport of JDK-8262295 to 11u. The fix itself applies cleanly. Just the test required trivial adaptation. Original bug: https://bugs.openjdk.java.net/browse/JDK-8262295 https://git.openjdk.java.net/jdk/commit/9689863a 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8262295_11u_C2_Out_of_Bounds_Array_Load_from_Clone_Source/webrev.0/ Adaptations: I had to remove the package from the class ClassFileInstaller in the included test TestOutOfBoundsArrayLoad.java Testing: CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From jbachorik at openjdk.java.net Tue Apr 20 15:04:32 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 20 Apr 2021 15:04:32 GMT Subject: [jdk16u] RFR: 8258414: OldObjectSample events too expensive Message-ID: 8258414: OldObjectSample events too expensive ------------- Commit messages: - 8258414: OldObjectSample events too expensive Changes: https://git.openjdk.java.net/jdk16u/pull/107/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=107&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258414 Stats: 142 lines in 9 files changed: 64 ins; 31 del; 47 mod Patch: https://git.openjdk.java.net/jdk16u/pull/107.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/107/head:pull/107 PR: https://git.openjdk.java.net/jdk16u/pull/107 From martin.doerr at sap.com Tue Apr 20 15:26:38 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Apr 2021 15:26:38 +0000 Subject: [11u] RFR 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: References: Message-ID: Hi Richard, looks good. Thanks for backporting! Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Reingruber, Richard > Sent: Dienstag, 20. April 2021 15:54 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8262295: C2: Out-of-Bounds Array Load from Clone Source > > Hi, > > Please help review this backport of JDK-8262295 to 11u. > The fix itself applies cleanly. > Just the test required trivial adaptation. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8262295 > https://git.openjdk.java.net/jdk/commit/9689863a > > 11u webrev: > > http://cr.openjdk.java.net/~rrich/webrevs/8262295_11u_C2_Out_of_Bound > s_Array_Load_from_Clone_Source/webrev.0/ > > Adaptations: > > I had to remove the package from the class ClassFileInstaller in the included > test TestOutOfBoundsArrayLoad.java > > Testing: > > CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, > SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms > > Thanks, Richard. From martin.doerr at sap.com Tue Apr 20 15:30:32 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Apr 2021 15:30:32 +0000 Subject: [11u] RFR (S) 8244205: HTTP/2 tunnel connections through proxy may be reused regardless of which proxy is selected In-Reply-To: <635d8f25-9c9d-c9ac-1dd4-7ba6de1f8ef5@redhat.com> References: <635d8f25-9c9d-c9ac-1dd4-7ba6de1f8ef5@redhat.com> Message-ID: Hi Aleksey, looks good. Thanks for backporting! Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Dienstag, 20. April 2021 10:10 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR (S) 8244205: HTTP/2 tunnel connections through proxy > may be reused regardless of which proxy is selected > > On 4/20/21 9:59 AM, Aleksey Shipilev wrote: > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8244205 > > https://hg.openjdk.java.net/jdk/jdk/rev/dd61d60329f6 > > > > This fixes the issue exposed by JDK-8244031 backport. > > > > The patch applies nearly exactly, but the tests need adjustments for 11u: > > - jdk.test.lib.net.SimpleSSLContext is jdk.testlibrary.SimpleSSLContext > > - @library /test/lib is @library /lib/testlibrary > > > > Testing: java/net/httpclient tests > > Forgot the link to 11u webrev as well: > https://cr.openjdk.java.net/~shade/8244205/webrev.11u.01/ > > -- > Thanks, > -Aleksey From martin.doerr at sap.com Tue Apr 20 15:32:49 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Apr 2021 15:32:49 +0000 Subject: [11u] RFR (S) 8244031: HttpClient should have more tests for HEAD requests In-Reply-To: References: Message-ID: Hi Aleksey, looks good. Thanks for backporting! Would be great if you could push it together with JDK-8244205. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Dienstag, 20. April 2021 10:09 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR (S) 8244031: HttpClient should have more tests for > HEAD requests > > On 4/20/21 9:59 AM, Aleksey Shipilev wrote: > > Original fix: > > https://bugs.openjdk.java.net/browse/JDK-8244031 > > https://hg.openjdk.java.net/jdk/jdk/rev/a0d9d2e73ef2 > > > > The patch applies nearly exactly, but the tests need adjustments for 11u: > > - jdk.test.lib.net.SimpleSSLContext is jdk.testlibrary.SimpleSSLContext > > - @library /test/lib is @library /lib/testlibrary > > > > ForbiddenHeadTest exposes the bug that is fixed by JDK-8244205. I'll > propose it for 11u backports > > shortly. > > > > Testing: java/net/httpclient tests > > Gaa! I forgot the link to 11u webrev: > https://cr.openjdk.java.net/~shade/8244031/webrev.11u.01/ > > -- > Thanks, > -Aleksey From shade at redhat.com Tue Apr 20 15:35:29 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 17:35:29 +0200 Subject: [11u] RFR (S) 8244031: HttpClient should have more tests for HEAD requests In-Reply-To: References: Message-ID: <9d57effa-94cd-5a92-4da6-f3087ac0dcb7@redhat.com> On 4/20/21 5:32 PM, Doerr, Martin wrote: > looks good. Thanks for backporting! Would be great if you could push it together with JDK-8244205. Thanks! Yes, that is my intent, because otherwise bugs are exposed and tier1 breaks. -- Thanks, -Aleksey From jbachorik at openjdk.java.net Tue Apr 20 15:39:20 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 20 Apr 2021 15:39:20 GMT Subject: [jdk16u] Integrated: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 14:55:56 GMT, Jaroslav Bachorik wrote: > 8258414: OldObjectSample events too expensive This pull request has now been integrated. Changeset: 5d5b122e Author: Jaroslav Bachorik URL: https://git.openjdk.java.net/jdk16u/commit/5d5b122e Stats: 142 lines in 9 files changed: 64 ins; 31 del; 47 mod 8258414: OldObjectSample events too expensive Backport-of: a9b156d358b0436584a33f71abc00c9bed9d47a3 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/107 From richard.reingruber at sap.com Tue Apr 20 16:03:04 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 20 Apr 2021 16:03:04 +0000 Subject: [11u] RFR 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: References: Message-ID: Hi Martin, thanks for reviewing! Richard. -----Original Message----- From: Doerr, Martin Sent: Dienstag, 20. April 2021 17:27 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR 8262295: C2: Out-of-Bounds Array Load from Clone Source Hi Richard, looks good. Thanks for backporting! Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Reingruber, Richard > Sent: Dienstag, 20. April 2021 15:54 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8262295: C2: Out-of-Bounds Array Load from Clone Source > > Hi, > > Please help review this backport of JDK-8262295 to 11u. > The fix itself applies cleanly. > Just the test required trivial adaptation. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8262295 > https://git.openjdk.java.net/jdk/commit/9689863a > > 11u webrev: > > http://cr.openjdk.java.net/~rrich/webrevs/8262295_11u_C2_Out_of_Bound > s_Array_Load_from_Clone_Source/webrev.0/ > > Adaptations: > > I had to remove the package from the class ClassFileInstaller in the included > test TestOutOfBoundsArrayLoad.java > > Testing: > > CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, > SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms > > Thanks, Richard. From yan at openjdk.java.net Tue Apr 20 16:12:32 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 20 Apr 2021 16:12:32 GMT Subject: [jdk15u-dev] Integrated: 8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 Message-ID: This port of a change necessary for newer Gnome is clean on jdk15. ------------- Commit messages: - Backport 79a4a019bba1c99bef2377fe88f1464943530a55 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/27/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=27&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247753 Stats: 33 lines in 2 files changed: 12 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/27/head:pull/27 PR: https://git.openjdk.java.net/jdk15u-dev/pull/27 From yan at openjdk.java.net Tue Apr 20 16:12:32 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 20 Apr 2021 16:12:32 GMT Subject: [jdk15u-dev] Integrated: 8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 In-Reply-To: References: Message-ID: <0boV31GyO1miqSWN4hyzcsoCpCwkQv5HLAXyxMwV9yE=.7ec19d57-bf45-4d11-aed7-6cf6f1ca2947@github.com> On Tue, 20 Apr 2021 16:03:28 GMT, Yuri Nesterenko wrote: > This port of a change necessary for newer Gnome is clean on jdk15. This pull request has now been integrated. Changeset: a44e891d Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/a44e891d Stats: 33 lines in 2 files changed: 12 ins; 0 del; 21 mod 8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 Backport-of: 79a4a019bba1c99bef2377fe88f1464943530a55 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/27 From eastig at amazon.co.uk Tue Apr 20 17:02:21 2021 From: eastig at amazon.co.uk (Astigeevich, Evgeny) Date: Tue, 20 Apr 2021 17:02:21 +0000 Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow In-Reply-To: <14294007-A41E-4A5C-86BB-1E616ECCDA1C@amazon.com> References: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com> <14294007-A41E-4A5C-86BB-1E616ECCDA1C@amazon.com> Message-ID: Ping. From: compiler-dev on behalf of "Astigeevich, Evgeny" Date: Monday, 19 April 2021 at 12:04 To: "jdk-updates-dev at openjdk.java.net" Cc: "compiler-dev at openjdk.java.net" Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow Hi, Please review the backport of JDK-8177068 to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8177068 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a3c63a9dfb2c The original patch does not apply cleanly to 11u. In the original patch, file DeferredAttr.java, calls of ?attribSpeculative? to be changed have the argument AttributionMode.SPECULATIVE. The original patch does not change this. In 11u ?attribSpeculative? does not have the parameter AttributionMode. I changed the affected calls to 11u API. 11u webrev: http://cr.openjdk.java.net/~eastigeevich/8177068/webrev.00/ Tested: Amazon Linux 2 x86_64, tier1, tier2, langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153 Thanks, Evgeny Astigeevich Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. From shade at redhat.com Tue Apr 20 17:23:57 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 19:23:57 +0200 Subject: [11u] RFR (XS) 8265537: x86 version string truncated after JDK-8249672 11u backport Message-ID: <89e2926e-1ab7-785f-343e-d7d841de1fbb@redhat.com> 11u-specific regression: https://bugs.openjdk.java.net/browse/JDK-8265537 See the details in the bug. 11u patch: diff -r 9846af5a0949 src/hotspot/cpu/x86/vm_version_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_x86.cpp Mon Apr 19 12:47:46 2021 +0200 +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp Tue Apr 20 19:23:24 2021 +0200 @@ -743,11 +743,11 @@ if (is_knights_family()) { _features &= ~CPU_VZEROUPPER; } } - char buf[256]; + char buf[512]; jio_snprintf(buf, sizeof(buf), "(%u cores per cpu, %u threads per core) family %d model %d stepping %d microcode 0x%x" "%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s", cores_per_cpu(), threads_per_core(), cpu_family(), _model, _stepping, os::cpu_microcode_revision(), Testing: compiler/intrinsics/sha tests (now pass); tier1 -- Thanks, -Aleksey From hohensee at amazon.com Tue Apr 20 17:58:01 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 20 Apr 2021 17:58:01 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Message-ID: <2464E39E-FAFC-4E55-9DF0-1FB0229D9106@amazon.com> You're right. Emacs fumble-finger. :( New set of 3 webrevs (8214526 dropped). https://cr.openjdk.java.net/~phh/8216314/webrev.11u.02/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.03/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.04/ ?-----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 2:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Yes, that's in the #else path of #if defined(USE_BUFFEREDSTREAM). You have to look further up: +// Same as above, but with fixed buffer size. +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K); + #define STRINGSTREAM_FLUSH(termString) \ _sstbuf->print("%s", termString); \ _outbuf->print("%s", _sstbuf->as_string()); \ _sstbuf->reset(); +// Flush the buffer contents unconditionally. +// No action if the buffer is empty. +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ On 19.04.21, 22:44, "Hohensee, Paul" wrote: I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From yan at azul.com Tue Apr 20 18:02:10 2021 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 20 Apr 2021 21:02:10 +0300 Subject: OpenJDK 15.0.3 released Message-ID: Hi all, let me announce the release of OpenJDK 15.0.3. The release sources are in http://hg.openjdk.java.net/jdk-updates/jdk15u Mercurial repository which will be made read-only and archived soon while the active master repository will be moved to Git. All the current development happens already in Git team repository https://github.com/openjdk/jdk15u-dev. A rather short list of fixes please see below. * Security fixes: JDK-8244473: Contextualize registration for JNDI JDK-8244543: Enhanced handling of abstract classes JDK-8259633: compiler/graalunit/CoreTest.java fails with NPE after JDK-8244543 JDK-8250568: Less ambiguous processing JDK-8253799: Make lists of normal filenames JDK-8261183: Follow on to Make lists of normal filenames JDK-8249906: Enhance opening JARs JDK-8258247: Couple of issues in fix for JDK-8249906 JDK-8259428: AlgorithmId.getEncodedParams() should return copy JDK-8257001: Improve HTTP client support * Other changes: (P2) JDK-8256682: JDK-8202343 is incomplete (P2) JDK-8202343: Disable TLS 1.0 and 1.1 (P4) JDK-8252497: Incorrect numeric currency code for ROL (P2) JDK-8261912: Code IfNode::fold_compares_helper more defensively (P3) JDK-8245400: Upgrade to LittleCMS 2.11 (P3) JDK-8247867: Upgrade to freetype 2.10.2 (P3) JDK-8260356: (tz) Upgrade time-zone data to tzdata2021a (P4) JDK-8259048: (tz) Upgrade time-zone data to tzdata2020f (P2) JDK-8261310: PPC64 Zero build fails with 'VMError::controlled_crash(int)::FunctionDescriptor functionDescriptor' has incomplete type and cannot be defined (P3) JDK-8243559: Remove root certificates with 1024-bit keys (See CSR JDK-8262079) * Notes on some issues: _______ core-libs/java.time ____________ ==== See JDK-8259048 ======== (tz) Upgrade time-zone data to tzdata2020f 8259428 JDK 13.0.7 contains IANA time zone data version 2020f. For more information, refer to https://www.oracle.com/java/technologies/tzdata-versions.html ____________ security-libs/java.security ________ === See JDK-8243559 ========= Related CSR: JDK-8262079 Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the cacerts keystore: alias name "thawtepremiumserverca [jdk]" Distinguished Name: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA alias name "verisignclass2g2ca [jdk]" Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US alias name "verisignclass3ca [jdk]" Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US alias name "verisignclass3g2ca [jdk]" Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US alias name "verisigntsaca [jdk]" Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA From omikhaltcova at openjdk.java.net Tue Apr 20 18:36:42 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Tue, 20 Apr 2021 18:36:42 GMT Subject: [jdk13u-dev] RFR: 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X Message-ID: I'd like to backport JDK-8263846 to jdk13u for parity with jdk11u. The original patch applied cleanly. It's reasonable to add the reference check before using it. ------------- Commit messages: - Backport 118a49fc9699590fb5c935729da64dac5e61f26d Changes: https://git.openjdk.java.net/jdk13u-dev/pull/187/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=187&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263846 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/187.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/187/head:pull/187 PR: https://git.openjdk.java.net/jdk13u-dev/pull/187 From yan at azul.com Tue Apr 20 18:50:26 2021 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 20 Apr 2021 21:50:26 +0300 Subject: OpenJDK 13.0.7 released Message-ID: <69feff8e-6fe4-afcd-a21d-c63fa7bbd687@azul.com> Hi all, let me announce the release of OpenJDK 13.0.7. The release sources are in https://github.com/openjdk/jdk13u Git repository. A list of fixes please see below. Also, a nicely generated list could be found, again, at A. Shipilev's site: https://builds.shipilev.net/backports-monitor/release-notes-13.0.7.txt * Security fixes: JDK-8244473: Contextualize registration for JNDI JDK-8244543: Enhanced handling of abstract classes JDK-8259633: compiler/graalunit/CoreTest.java fails with NPE after JDK-8244543 JDK-8250568: Less ambiguous processing JDK-8253799: Make lists of normal filenames JDK-8261183: Follow on to Make lists of normal filenames JDK-8249906: Enhance opening JARs JDK-8258247: Couple of issues in fix for JDK-8249906 JDK-8259428: AlgorithmId.getEncodedParams() should return copy JDK-8257001: Improve HTTP client support * Other changes: JDK-8263996: Fix build on 13u after JDK-8234779 backport JDK-8234779: Provide idiom for declaring classes noncopyable JDK-8237977: Further update javax/net/ssl/compatibility/Compatibility.java JDK-8240295: hs_err elapsed time in seconds is not accurate enough JDK-8237950: C2 compilation fails with "Live Node limit exceeded limit" during ConvI2L::Ideal optimization JDK-8244573: java.lang.ArrayIndexOutOfBoundsException thrown for malformed class file JDK-8253409: Double-rounding possibility in float fma JDK-8261022: Fix incorrect result of Math.abs() with char type JDK-8263425: AArch64: two potential bugs in C1 LIRGenerator::generate_address() JDK-8255625: AArch64: Implement Base64.encodeBlock accelerator/intrinsic JDK-8257414: Drag n Drop target area is wrong on high DPI systems JDK-8250911: [windows] os::pd_map_memory error detection broken JDK-8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel JDK-8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack JDK-7185258: [macosx] Deadlock in SunToolKit.realSync() JDK-8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect JDK-8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:" JDK-8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" JDK-8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities JDK-8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags JDK-8260356: (tz) Upgrade time-zone data to tzdata2021a JDK-8233880: Support compilers with multi-digit major version numbers JDK-8198540: Dynalink leaks memory when generating type converters JDK-8260308: Update LogCompilation junit to 4.13.1 JDK-8232905: JFR fails with assertion: assert(t->unflushed_size() == 0) failed: invariant JDK-8257746: Regression introduced with JDK-8250984 - memory might be null in some machines JDK-8245283: JFR: Can't handle constant dynamic used by Jacoco agent JDK-8243559: Remove root certificates with 1024-bit keys (See CSR JDK-8262079) JDK-8259707: LDAP channel binding does not work with StartTLS extension JDK-8246027: Minimal fastdebug build broken after JDK-8245801 JDK-8245801: StressRecompilation triggers assert "redundunt OSR recompilation detected. memory leak in CodeCache!" JDK-8242030: Wrong package declarations in jline classes after JDK-8241598 JDK-8241598: Upgrade JLine to 3.14.0 JDK-8242283: Can't start JVM when java home path includes non-ASCII character JDK-8229815: Upgrade Jline to 3.12.1 JDK-8243320: Add SSL root certificates to Oracle Root CA program JDK-8243321: Add Entrust root CA - G4 to Oracle Root CA program JDK-8227275: Within native OOM error handling, assertions may hang the process JDK-8241319: WB_GetCodeBlob doesn't have ResourceMark JDK-8235829: graal crashes with Zombie.java test JDK-8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel JDK-8234662: Sweeper should keep current nmethod alive before yielding for ICStub refills JDK-8249176: jdk jtreg test security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java fails JDK-8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE JDK-8259048: (tz) Upgrade time-zone data to tzdata2020f JDK-8243925: Toolkit#getScreenInsets() returns wrong value on HiDPI screens (Windows) JDK-8221823: Requested JDialog width is ignored JDK-8216324: GetClassMethods is confused by the presence of default methods in super interfaces JDK-8234058: runtime/CompressedOops/CompressedClassPointers.java fails with 'Narrow klass base: 0x0000000000000000' missing from stdout/stderr JDK-8239497: SEGV in EdgeUtils::field_name_symbol(Edge const&) JDK-8241458: [JVMCI] add mark value to expose CodeOffsets::Frame_Complete JDK-8238710: LingeredApp doesn't log stdout/stderr if exits with non-zero code JDK-8241478: vmTestbase/gc/gctests/Steal/steal001/steal001.java fails with OOME JDK-8234541: C1 emits an empty message when it inlines successfully JDK-8236772: Fix build for windows 32-bit after 8212160 and 8234331. JDK-8243389: enhance os::pd_print_cpu_info on linux JDK-8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8 on Japanese Windows. JDK-8236124: Minimal VM slowdebug build failed after JDK-8212160 JDK-8235456: Minimal VM is broken after JDK-8212160 JDK-6532025: GIF reader throws misleading exception with truncated images JDK-8243290: Improve diagnostic messages for class verification and redefinition failures JDK-8256809: Annotation processing causes NPE during flow analysis JDK-8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" JDK-8234687: change javap reporting on unknown attributes JDK-7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection JDK-8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem JDK-8244819: hsdis does not compile with binutils 2.34+ JDK-8226810: Failed to launch JVM because of NullPointerException occured on System.props JDK-8251257: NMT: jcmd VM.native_memory scale=1 crashes target VM JDK-8233027: OopMapSet::all_do does oms.next() twice during iteration JDK-8222079: Don't use memset to initialize fields decode_env constructor in disassembler.cpp JDK-8232083: Minimal VM is broken after JDK-8231586 JDK-8231586: enlarge encoding space for OopMapValue offsets JDK-8235584: UseProfiledLoopPredicate fails with assert(_phase->get_loop(c) == loop) failed: have to be in the same loop JDK-8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators (see CSR JDK-8260003) JDK-8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() JDK-8257633: Missing -mmacosx-version-min=X flag when linking libjvm JDK-8248987: AOT's Linker.java seems to eagerly fail-fast on Windows. JDK-8235218: Minimal VM is broken after JDK-8173361 JDK-8204994: SA might fail to attach to process with "Windbg Error: WaitForEvent failed" JDK-8241086: Test runtime/NMT/HugeArenaTracking.java is failing on 32bit Windows JDK-8173361: various crashes in JvmtiExport::post_compiled_method_load JDK-8235846: Improve WindbgDebuggerLocal implementation * Notes on some issues: _______ core-libs/java.time ____________ ==== See JDK-8259048 ========= (tz) Upgrade time-zone data to tzdata2020f JDK 13.0.7 contains IANA time zone data version 2020f. For more information, refer to https://www.oracle.com/java/technologies/tzdata-versions.html ____________ security-libs/java.security ________ ==== See JDK-8243320 ========= Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: SSL Corporation sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ==== See JDK-8243321 ========= Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: Entrust entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US === See JDK-8243559 ========= Related CSR: JDK-8262079 Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the cacerts keystore: alias name "thawtepremiumserverca [jdk]" Distinguished Name: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA alias name "verisignclass2g2ca [jdk]" Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US alias name "verisignclass3ca [jdk]" Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US alias name "verisignclass3g2ca [jdk]" Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US alias name "verisigntsaca [jdk]" Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA From omikhaltcova at openjdk.java.net Tue Apr 20 19:00:37 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Tue, 20 Apr 2021 19:00:37 GMT Subject: [jdk15u-dev] RFR: 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X Message-ID: I'd like to backport JDK-8263846 to jdk15u for parity with jdk11u. The original patch applied cleanly. It's reasonable to add the reference check before using it. ------------- Commit messages: - Backport 118a49fc9699590fb5c935729da64dac5e61f26d Changes: https://git.openjdk.java.net/jdk15u-dev/pull/28/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=28&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263846 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/28.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/28/head:pull/28 PR: https://git.openjdk.java.net/jdk15u-dev/pull/28 From evergizova at openjdk.java.net Tue Apr 20 19:29:39 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 20 Apr 2021 19:29:39 GMT Subject: [jdk15u-dev] RFR: 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() Message-ID: I'd like to backport JDK-8258396 to 15u for parity with 11u. The patch applies cleanly. Tested with tier1 and jdk/jfr tests. ------------- Commit messages: - Backport e85892bfe243bdba6ca22f8756fdda7486baefc2 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258396 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/29/head:pull/29 PR: https://git.openjdk.java.net/jdk15u-dev/pull/29 From evergizova at openjdk.java.net Tue Apr 20 19:30:26 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 20 Apr 2021 19:30:26 GMT Subject: [jdk15u-dev] RFR: 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) Message-ID: I'd like to backport JDK-8252090 to 15u for parity with 11u. The patch applies cleanly. Tested with tier1 and jdk/jfr tests. ------------- Commit messages: - Backport 9924c45faebdba4084c9a5dd5b415dfe6c979024 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/30/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=30&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252090 Stats: 59 lines in 10 files changed: 23 ins; 4 del; 32 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/30/head:pull/30 PR: https://git.openjdk.java.net/jdk15u-dev/pull/30 From lutz.schmidt at sap.com Tue Apr 20 20:37:25 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 20 Apr 2021 20:37:25 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: <2464E39E-FAFC-4E55-9DF0-1FB0229D9106@amazon.com> References: <2464E39E-FAFC-4E55-9DF0-1FB0229D9106@amazon.com> Message-ID: You want me to retest? No problem, but results will not be available before Thursday. Please let me know. Lutz ?On 20.04.21, 19:58, "Hohensee, Paul" wrote: You're right. Emacs fumble-finger. :( New set of 3 webrevs (8214526 dropped). https://cr.openjdk.java.net/~phh/8216314/webrev.11u.02/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.03/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.04/ -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 2:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Yes, that's in the #else path of #if defined(USE_BUFFEREDSTREAM). You have to look further up: +// Same as above, but with fixed buffer size. +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K); + #define STRINGSTREAM_FLUSH(termString) \ _sstbuf->print("%s", termString); \ _outbuf->print("%s", _sstbuf->as_string()); \ _sstbuf->reset(); +// Flush the buffer contents unconditionally. +// No action if the buffer is empty. +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ On 19.04.21, 22:44, "Hohensee, Paul" wrote: I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From rob.mckenna at oracle.com Tue Apr 20 21:11:25 2021 From: rob.mckenna at oracle.com (Robert Mckenna) Date: Tue, 20 Apr 2021 21:11:25 +0000 Subject: [Updates Communication] 16.0.1 security changes pushed Message-ID: Note: there is a jdk16.0.1 branch along with the merge commit. -Rob From hohensee at amazon.com Tue Apr 20 22:49:40 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 20 Apr 2021 22:49:40 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Message-ID: <5969F266-A269-4329-98D2-E8022EEDD5A7@amazon.com> Yes, please, and also review. I've run tier1 and tier2 on linux-x64. ?-----Original Message----- From: "Schmidt, Lutz" Date: Tuesday, April 20, 2021 at 1:38 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods You want me to retest? No problem, but results will not be available before Thursday. Please let me know. Lutz On 20.04.21, 19:58, "Hohensee, Paul" wrote: You're right. Emacs fumble-finger. :( New set of 3 webrevs (8214526 dropped). https://cr.openjdk.java.net/~phh/8216314/webrev.11u.02/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.03/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.04/ -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 2:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Yes, that's in the #else path of #if defined(USE_BUFFEREDSTREAM). You have to look further up: +// Same as above, but with fixed buffer size. +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K); + #define STRINGSTREAM_FLUSH(termString) \ _sstbuf->print("%s", termString); \ _outbuf->print("%s", _sstbuf->as_string()); \ _sstbuf->reset(); +// Flush the buffer contents unconditionally. +// No action if the buffer is empty. +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ On 19.04.21, 22:44, "Hohensee, Paul" wrote: I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From thomas.stuefe at gmail.com Wed Apr 21 04:29:23 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 21 Apr 2021 06:29:23 +0200 Subject: [11u] RFR: 8265417: Backport of JDK-8249672 breaks Solaris x86 build Message-ID: Hi, may I have reviews for this 11u-only build fix please? https://bugs.openjdk.java.net/browse/JDK-8253115 had been downported without testing Solaris x86, which broke. The fix is trivial and just adds a stubbed-out variant of the missing microcode printing function. It's only used for error reporting, so stubbing it out is fine here. Solaris enthusiasts can add a follow-up patch later to flesh this function out. http://cr.openjdk.java.net/~stuefe/webrevs/backports/8265417-solaris-x86-missing-microcode-function-breaks-build Thanks to Steffen for reporting this: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2021-April/046107.html Cheers, Thomas From thomas.stuefe at gmail.com Wed Apr 21 05:07:58 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 21 Apr 2021 07:07:58 +0200 Subject: [11u] RFR: JDK-8260707: java/lang/instrument/PremainClass/InheritAgent0100.java times out Message-ID: Hi, I would like to backport this patch to 11u. It's trivial really, but the code has moved since then and the patch does not apply. This fixes a couple of negative tests (in which the VM is supposed to crash) which run with default heap and without suppressed cores, which hurts mostly on AIX. Issue: https://bugs.openjdk.java.net/browse/JDK-8260707 Orig patch: https://github.com/openjdk/jdk/commit/d7b1fc59.diff 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260707-java-lang-instrument-premainclass-inheritagent0100-java-timed-out-11u Thank you, Thomas From thomas.stuefe at gmail.com Wed Apr 21 05:08:53 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 21 Apr 2021 07:08:53 +0200 Subject: [11u] RFR: 8265417: Backport of JDK-8249672 breaks Solaris x86 build In-Reply-To: References: Message-ID: Sorry, forgot the primary issue link: https://bugs.openjdk.java.net/browse/JDK-8265417 On Wed, Apr 21, 2021 at 6:29 AM Thomas St?fe wrote: > Hi, > > may I have reviews for this 11u-only build fix please? > > https://bugs.openjdk.java.net/browse/JDK-8253115 had been downported > without testing Solaris x86, which broke. > > The fix is trivial and just adds a stubbed-out variant of the missing > microcode printing function. It's only used for error reporting, so > stubbing it out is fine here. Solaris enthusiasts can add a follow-up patch > later to flesh this function out. > > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8265417-solaris-x86-missing-microcode-function-breaks-build > > Thanks to Steffen for reporting this: > > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2021-April/046107.html > > Cheers, Thomas > From gnu.andrew at redhat.com Wed Apr 21 05:54:14 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 Apr 2021 06:54:14 +0100 Subject: OpenJDK 11.0.11 Released Message-ID: <20210421055414.GA539091@rincewind> We are pleased to announce the release of OpenJDK 11.0.11. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.11-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.11-ga.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: a00f8cf0c1edbefb767bce893a74b170478cb9bf152224b215aa59e7b431079c openjdk-11.0.11-ga.tar.xz b5f7a56a6aad10d3378784f7aa829cadf4c2796faa13d01d1f5933be4740eadd openjdk-11.0.11-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.11-ga.sha256 New in release OpenJDK 11.0.11 (2021-04-20): ============================================= Live versions of these release notes can be found at: * https://bitly.com/openjdk11011 * https://builds.shipilev.net/backports-monitor/release-notes-11.0.11.txt * Security fixes - JDK-8244473: Contextualize registration for JNDI - JDK-8244543: Enhanced handling of abstract classes - JDK-8249906, CVE-2021-2163: Enhance opening JARs - JDK-8250568, CVE-2021-2161: Less ambiguous processing - JDK-8253799: Make lists of normal filenames - JDK-8257001: Improve Http Client Support * Other changes - JDK-7107012: sun.jvm.hotspot.code.CompressedReadStream readDouble() conversion to long mishandled - JDK-7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection - JDK-8086003: Test fails on OSX with java.lang.RuntimeException 'Narrow klass base: 0x0000000000000000, Narrow klass shift: 3' missing - JDK-8168869: jdeps: localized messages don't use proper line breaks - JDK-8180837: SunPKCS11-NSS tests failing with CKR_ATTRIBUTE_READ_ONLY and CKR_MECHANISM_PARAM_INVALID - JDK-8202343: Disable TLS 1.0 and 1.1 - JDK-8205992: jhsdb cannot attach to Java processes running in Docker containers - JDK-8209193: Fix aarch64-linux compilation after -Wreorder changes - JDK-8210413: AArch64: Optimize div/rem by constant in C1 - JDK-8210578: AArch64: Invalid encoding for fmlsvs instruction - JDK-8211051: jdeps usage of --dot-output doesn't provide valid output for modular jar - JDK-8211057: Gensrc step CompileProperties generates unstable CompilerProperties output - JDK-8211150: G1 Full GC not purging code root memory and hence causing memory leak - JDK-8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module - JDK-8212043: Add floating-point Math.min/max intrinsics - JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out - JDK-8213116: javax/swing/JComboBox/WindowsComboBoxSize/WindowsComboBoxSizeTest.java fails in Windows - JDK-8213909: jdeps --print-module-deps should report missing dependences - JDK-8214180: Need better granularity for sleeping - JDK-8214223: tools/jdeps/listdeps/ListModuleDeps.java failed due to missing Lib2 file - JDK-8214230: Classes generated by SystemModulesPlugin.java are not reproducable - JDK-8214741: docs/index.html has no title or copyright - JDK-8215687: [Graal] unit test CheckGraalIntrinsics failed after 8212043 - JDK-8217848: [Graal] vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java fails - JDK-8218482: sun/security/krb5/auto/ReplayCachePrecise.java failed - no KrbException thrown - JDK-8218550: Add test omitted from JDK-8212043 - JDK-8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event - JDK-8221995: AARCH64: problems with CAS instructions encoding - JDK-8222518: Remove unnecessary caching of Parker object in java.lang.Thread - JDK-8222785: aarch64: add necessary masking for immediate shift counts - JDK-8223186: HotSpot compile warnings from GCC 9 - JDK-8225773: jdeps --check produces NPE if there are missing module dependences - JDK-8225805: Java Access Bridge does not close the logger - JDK-8226810: Failed to launch JVM because of NullPointerException occured on System.props - JDK-8229396: jdeps ignores multi-release when generate-module-info used on command line - JDK-8229474: Shenandoah: Cleanup CM::update_roots() - JDK-8232225: Rework the fix for JDK-8071483 - JDK-8232905: JFR fails with assertion: assert(t->unflushed_size() == 0) failed: invariant - JDK-8233164: C2 fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain - JDK-8233910: java/awt/ColorClass/AlphaColorTest.java is failing intermittently in nightly lnux-x64 system - JDK-8233912: aarch64: minor improvements of atomic operations - JDK-8234508: VM_HeapWalkOperation::iterate_over_object reads non-strong fields with an on-strong load barrier - JDK-8234742: Improve handshake logging - JDK-8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure - JDK-8235324: Dying objects are published from users of CollectedHeap::object_iterate - JDK-8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag - JDK-8237369: Shenandoah: failed vmTestbase/nsk/jvmti/AttachOnDemand/attach021/TestDescription.java test - JDK-8237392: Shenandoah: Remove unreliable assertion - JDK-8237483: AArch64 C1 OopMap inserted twice fatal error - JDK-8237495: Java MIDI fails with a dereferenced memory error when asked to send a raw 0xF7 - JDK-8239355: (dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS) - JDK-8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 - JDK-8240704: CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent." - JDK-8240751: Shenandoah: fold ShenandoahTracer definition - JDK-8240795: [REDO] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found" - JDK-8241598: Upgrade JLine to 3.14.0 - JDK-8241649: Optimize Character.toString - JDK-8241770: Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module - JDK-8241911: AArch64: Fix a potential register clash issue in reduce_add2I - JDK-8242030: Wrong package declarations in jline classes after JDK-8241598 - JDK-8242565: Policy initialization issues when the denyAfter constraint is enabled - JDK-8243618: compiler/rtm/cli tests can be run w/o WhiteBox - JDK-8243670: Unexpected test result caused by C2 MergeMemNode::Ideal - JDK-8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI - JDK-8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files - JDK-8244340: Handshake processing thread lacks yielding - JDK-8244573: java.lang.ArrayIndexOutOfBoundsException thrown for malformed class file - JDK-8244683: A TSA server used by tests - JDK-8245005: javax/net/ssl/compatibility/BasicConnectTest.java failed with No enum constant - JDK-8245026: PsAdaptiveSizePolicy::_old_gen_policy_is_ready is unused - JDK-8245283: JFR: Can't handle constant dynamic used by Jacoco agent - JDK-8245512: CRC32 optimization using AVX512 instructions - JDK-8245527: LDAP Channel Binding support for Java GSS/Kerberos - JDK-8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel - JDK-8246709: sun/security/tools/jarsigner/TsacertOptionTest.java compilation failed after JDK-8244683 - JDK-8247200: assert((unsigned)fpargs < 32) - JDK-8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field too big for insn. - JDK-8248336: AArch64: C2: offset overflow in BoxLockNode::emit - JDK-8248865: Document JNDI/LDAP timeout properties - JDK-8248901: Signed immediate support in .../share/assembler.hpp is broken. - JDK-8249543: Force DirectBufferAllocTest to run with -ExplicitGCInvokesConcurrent - JDK-8249588: libwindowsaccessbridge issues on 64bit Windows - JDK-8249749: modify a primitive array through a stream and a for cycle causes jre crash - JDK-8249787: Make TestGCLocker more resilient with concurrent GCs - JDK-8249867: xml declaration is not followed by a newline - JDK-8250911: [windows] os::pd_map_memory() error detection broken - JDK-8251255: [linux] Add process-memory information to hs-err and VM.info - JDK-8251359: Shenandoah: filter null oops before calling enqueue/SATB barrier - JDK-8251925: C2: RenaissanceStressTest fails with assert(!had_error): bad dominance - JDK-8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java - JDK-8251992: VM crashed running TestComplexAddrExpr.java test with -XX:UseAVX=X - JDK-8253220: Epsilon: clean up unused code/declarations - JDK-8253274: The CycleDMImagetest brokes the system - JDK-8253353: Crash in C2: guarantee(n != NULL) failed: No Node - JDK-8253368: TLS connection always receives close_notify exception - JDK-8253404: C2: assert(C->live_nodes() <= C->max_node_limit()) failed: Live Node limit exceeded limit - JDK-8253409: Double-rounding possibility in float fma - JDK-8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities - JDK-8253524: C2: Refactor code that clones predicates during loop unswitching - JDK-8253644: C2: assert(skeleton_predicate_has_opaque(iff)) failed: unexpected - JDK-8253681: closed java/awt/dnd/MouseEventAfterStartDragTest/MouseEventAfterStartDragTest.html test failed - JDK-8253702: BigSur version number reported as 10.16, should be 11.nn - JDK-8253756: C2 CompilerThread0 crash in Node::add_req(Node*) - JDK-8254104: MethodCounters must exist before nmethod is installed - JDK-8254734: "dead loop detected" assert failure with patch from 8223051 - JDK-8254748: Bad Copyright header format after JDK-8212218 - JDK-8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs - JDK-8255058: C1: assert(is_virtual()) failed: type check - JDK-8255351: Add detection for Graviton 2 CPUs - JDK-8255368: Math.exp() gives wrong result for large values on x86 32-bit platforms - JDK-8255387: Japanese characters were printed upside down on AIX - JDK-8255401: Shenandoah: Allow oldval and newval registers to overlap in cmpxchg_oop() - JDK-8255479: [aarch64] assert(src->section_index_of(target) == CodeBuffer::SECT_NONE) failed: sanity - JDK-8255544: Create a checked cast - JDK-8255559: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() - JDK-8255681: print callstack in error case in runAWTLoopWithApp - JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too - JDK-8255742: PrintInlining as compiler directive doesn't print virtual calls - JDK-8255845: Memory leak in imageFile.cpp - JDK-8255880: UI of Swing components is not redrawn after their internal state changed - JDK-8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem - JDK-8256025: AArch64: MachCallRuntimeNode::ret_addr_offset() is incorrect for stub calls - JDK-8256056: Deoptimization stub doesn't save vector registers on x86 - JDK-8256061: RegisterSaver::save_live_registers() omits upper halves of ZMM0-15 registers - JDK-8256187: [TEST_BUG] Automate bug4275046.java test - JDK-8256220: C1: x86_32 fails with -XX:UseSSE=1 after JDK-8210764 due to mishandled lir_neg - JDK-8256258: some missing NULL checks or asserts after CodeCache::find_blob_unsafe - JDK-8256264: Printed GlyphVector outline with low DPI has bad quality on Windows - JDK-8256290: javac/lambda/T8031967.java fails with StackOverflowError on x86_32 - JDK-8256359: AArch64: runtime/ReservedStack/ReservedStackTestCompiler.java fails - JDK-8256387: Unexpected result if patching an entire instruction on AArch64 - JDK-8256421: Add 2 HARICA roots to cacerts truststore - JDK-8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory - JDK-8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners - JDK-8256501: libTestMainKeyWindow fails to build with Xcode 12.2 - JDK-8256633: Fix product build on Windows+Arm64 - JDK-8256682: JDK-8202343 is incomplete - JDK-8256751: Incremental rebuild with precompiled header fails when touching a header file - JDK-8256757: Incorrect MachCallRuntimeNode::ret_addr_offset() for CallLeafNoFP on x86_32 - JDK-8256806: Shenandoah: optimize shenandoah/jni/TestPinnedGarbage.java test - JDK-8256807: C2: Not marking stores correctly as mismatched in string opts - JDK-8256810: Incremental rebuild broken on Macosx - JDK-8256818: SSLSocket that is never bound or connected leaks socket resources - JDK-8256888: Client manual test problem list update - JDK-8257083: Security infra test failures caused by JDK-8202343 - JDK-8257408: Bump update version for OpenJDK: jdk-11.0.11 - JDK-8257423: [PPC64] Support -XX:-UseInlineCaches - JDK-8257436: [aarch64] Regressions in ArrayCopyUnalignedDst.testByte/testChar for 65-78 bytes when UseSIMDForMemoryOps is on - JDK-8257513: C2: assert((constant_addr - _masm.code()->consts()->start()) == con.offset()) - JDK-8257547: Handle multiple prereqs on the same line in deps files - JDK-8257561: Some code is not vectorized after 8251925 and 8250607 - JDK-8257565: epsilonBarrierSet.hpp should not include barrierSetAssembler - JDK-8257575: C2: "failed: only phis" assert failure in loop strip mining verification - JDK-8257594: C2 compiled checkcast of non-null object triggers endless deoptimization/recompilation cycle - JDK-8257633: Missing -mmacosx-version-min=X flag when linking libjvm - JDK-8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks - JDK-8257707: Fix incorrect format string in Http1HeaderParser - JDK-8257746: Regression introduced with JDK-8250984 - memory might be null in some machines - JDK-8257798: [PPC64] undefined reference to Klass::vtable_start_offset() - JDK-8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test - JDK-8257910: [JVMCI] Set exception_seen accordingly in the runtime. - JDK-8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884 - JDK-8257999: Parallel GC crash in gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region - JDK-8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 - JDK-8258247: Couple of issues in fix for JDK-8249906 - JDK-8258373: Update the text handling in the JPasswordField - JDK-8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() - JDK-8258419: RSA cipher buffer cleanup - JDK-8258471: "search codecache" clhsdb command does not work - JDK-8258534: Epsilon: clean up unused includes - JDK-8258805: Japanese characters not entered by mouse click on Windows 10 - JDK-8258833: Cancel multi-part cipher operations in SunPKCS11 after failures - JDK-8258836: JNI local refs exceed capacity getDiagnosticCommandInfo - JDK-8258884: [TEST_BUG] Convert applet-based test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a regular java test - JDK-8259007: This test printed a blank page - JDK-8259048: (tz) Upgrade time-zone data to tzdata2020f - JDK-8259049: Uninitialized variable after JDK-8257513 - JDK-8259231: Epsilon: improve performance under contention during virtual space expansion - JDK-8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region" - JDK-8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days - JDK-8259319: Illegal package access when SunPKCS11 requires SunJCE's classes - JDK-8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input - JDK-8259428: AlgorithmId.getEncodedParams() should return copy - JDK-8259446: runtime/jni/checked/TestCheckedReleaseArrayElements.java fails with stderr not empty - JDK-8259451: Zero: skip serviceability/sa tests, set vm.hasSA to false - JDK-8259580: Shenandoah: uninitialized label in VerifyThreadGCState - JDK-8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect - JDK-8259633: compiler/graalunit/CoreTest.java fails with NPE after JDK-8244543 - JDK-8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value - JDK-8259707: LDAP channel binding does not work with StartTLS extension - JDK-8259773: Incorrect encoding of AVX-512 kmovq instruction - JDK-8259849: Shenandoah: Rename store-val to IU-barrier - JDK-8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags - JDK-8259954: gc/shenandoah/mxbeans tests fail with -Xcomp - JDK-8260029: aarch64: fix typo in verify_oop_array - JDK-8260308: Update LogCompilation junit to 4.13.1 - JDK-8260338: Some fields in HaltNode is not cloned - JDK-8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS - JDK-8260356: (tz) Upgrade time-zone data to tzdata2021a - JDK-8260378: [TESTBUG] DcmdMBeanTestCheckJni.java reports false positive - JDK-8260497: Shenandoah: Improve SATB flushing - JDK-8260502: [s390] NativeMovRegMem::verify() fails because it's too strict - JDK-8260632: Build failures after JDK-8253353 - JDK-8260704: ParallelGC: oldgen expansion needs release-store for _end - JDK-8261022: Fix incorrect result of Math.abs() with char type - JDK-8261089: [TESTBUG] native library of test TestCheckedReleaseCriticalArray.java fails to compile with gcc 4.x - JDK-8261183: Follow on to Make lists of normal filenames - JDK-8261209: isStandalone property: remove dependency on pretty-print - JDK-8261231: Windows IME was disabled after DnD operation - JDK-8261251: Shenandoah: Use object size for full GC humongous compaction - JDK-8261310: PPC64 Zero build fails with 'VMError::controlled_crash(int)::FunctionDescriptor functionDescriptor' has incomplete type and cannot be defined - JDK-8261334: NMT: tuning statistic shows incorrect hash distribution - JDK-8261413: Shenandoah: Disable class-unloading in I-U mode - JDK-8261522: [PPC64] AES intrinsics write beyond the destination array - JDK-8261534: Test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java fails on platforms where no nsslib artifacts are defined - JDK-8261585: Restore HandleArea used in Deoptimization::uncommon_trap - JDK-8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 - JDK-8261829: Exclude tools/jlink/JLinkReproducibleTest.java in 11u - JDK-8261912: Code IfNode::fold_compares_helper more defensively - JDK-8261920: [AIX] jshell command throws java.io.IOError on non English locales - JDK-8262018: Wrong format in SAP copyright header of OsVersionTest - JDK-8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator Notes on individual issues: =========================== core-libs/javax.naming: JDK-8258824: LDAP Channel Binding Support for Java GSS/Kerberos =============================================================== A new JNDI environment property "com.sun.jndi.ldap.tls.cbtype" has been added to enable TLS Channel Binding data in LDAP authentication over SSL/TLS protocol to the Windows AD server. The only valid value at present is "tls-server-end-point", where channel binding data is created on the base of the TLS server certificate. See RFC-5929 [0] and the module description of the `java.naming` module for further details. [0] RFC-5929 "Channel Bindings for TLS": https://www.ietf.org/rfc/rfc5929.txt security-libs/java.security: JDK-8260597: Added 2 HARICA Root CA Certificates ================================================ The following root certificates have been added to the cacerts truststore: Alias Name: haricarootca2015 Distinguished Name: CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR Alias Name: haricaeccrootca2015 Distinguished Name: CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR security-libs/javax.net.ssl: JDK-8256490: Disable TLS 1.0 and 1.1 ==================================== TLS 1.0 and 1.1 are versions of the TLS protocol that are no longer considered secure and have been superseded by more secure and modern versions (TLS 1.2 and 1.3). These versions have now been disabled by default. If you encounter issues, you can, at your own risk, re-enable the versions by removing "TLSv1" and/or "TLSv1.1" from the `jdk.tls.disabledAlgorithms` security property in the `java.security` configuration file. tools: JDK-8214213: jdeps --print-module-deps Reports Transitive Dependencies ====================================================================== `jdeps --print-module-deps`, `--list-deps`, and `--list-reduce-deps` options have been enhanced as follows. 1. By default, they perform transitive module dependence analysis on libraries on the class path and module path, both directly and indirectly, as required by the given input JAR files or classes. Previously, they only reported the modules required by the given input JAR files or classes. The `--no-recursive` option can be used to request non-transitive dependence analysis. 2. By default, they flag any missing dependency, i.e. not found from class path and module path, as an error. The `--ignore-missing-deps` option can be used to suppress missing dependence errors. Note that a custom image is created with the list of modules output by jdeps when using the `--ignore-missing-deps` option for a non-modular application. Such an application, running on the custom image, might fail at runtime when missing dependence errors are suppressed. xml/jaxp: JDK-8249867 XML declaration is not followed by a newline ======================================================== The DOM Load and Save `LSSerializer` does not have an explicit control for whether or not the XML Declaration ends with a newline. In this release, a JDK implementation specific property `http://www.oracle.com/xml/jaxp/properties/isStandalone` and corresponding System property `jdk.xml.isStandalone` are added to control the addition of a newline and act independently without having to set the pretty-print property. This property can be used to reverse the incompatible change introduced in Java SE 7 Update 4 with an update of Xalan 2.7.1 where a newline is omitted when pretty-print is required. For details, please refer to the bug report and the java.xml module-summary. Usage: // to set the property, get an instance of LSSerializer and set it along with pretty-print LSSerializer ser = impl.createLSSerializer(); ser.getDomConfig().setParameter("format-pretty-print", true); ser.getDomConfig().setParameter("http://www.oracle.com/xml/jaxp/properties/isStandalone", true); // to use the System property, set it before initializing a LSSerializer System.setProperty("jdk.xml.isStandalone", ?true?); // to clear the property, place the line anywhere after the LSSerializer is initialized System.clearProperty("jdk.xml.isStandalone"); 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 christoph.goettschkes at microdoc.com Wed Apr 21 07:04:44 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Wed, 21 Apr 2021 09:04:44 +0200 Subject: [11u] RFR: 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM In-Reply-To: <3758a5e1-153a-b6cf-986c-4eeb2552fb73@redhat.com> References: <38129jy9pv-1@aserp2020.oracle.com> <1ebdcf3f-3e3c-b27c-c77e-18298b5c3e54@redhat.com> <88424.121041910500901101@us-mta-207.us.mimecast.lan> <3758a5e1-153a-b6cf-986c-4eeb2552fb73@redhat.com> Message-ID: <3828vp6s3r-1@userp2040.oracle.com> On 4/20/21 1:00 PM, Aleksey Shipilev wrote: > On 4/19/21 4:48 PM, Christoph G?ttschkes wrote: >> I will make the fix request and report back, since I need a sponsor for this change. > > I see you got the 11u approval. I sponsored the push for you: > ?https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9846af5a0949 > Thanks for monitoring this and sponsoring the change. -- Christoph From shade at redhat.com Wed Apr 21 08:54:58 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Apr 2021 10:54:58 +0200 Subject: [11u] RFR: 8265417: Backport of JDK-8249672 breaks Solaris x86 build In-Reply-To: References: Message-ID: <5dd0dcfb-bfc7-d128-f1cb-984726afe0d3@redhat.com> On 4/21/21 6:29 AM, Thomas St?fe wrote: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8265417-solaris-x86-missing-microcode-function-breaks-build This looks fine to me. Indeed, only solaris-x86 is missing. $ cd jdk-updates-jdk11u-dev/src/hotspot/os_cpu $ ls -1 | grep x86 bsd_x86 linux_x86 solaris_x86 windows_x86 $ ack cpu_microcode_revision linux_x86/os_linux_x86.cpp 664:juint os::cpu_microcode_revision() { linux_x86/os_linux_x86.hpp 30: static juint cpu_microcode_revision(); windows_x86/os_windows_x86.hpp 62: static juint cpu_microcode_revision(); windows_x86/os_windows_x86.cpp 653:juint os::cpu_microcode_revision() { bsd_x86/os_bsd_x86.cpp 841:juint os::cpu_microcode_revision() { bsd_x86/os_bsd_x86.hpp 30: static juint cpu_microcode_revision() -- Thanks, -Aleksey From thomas.stuefe at gmail.com Wed Apr 21 08:59:46 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 21 Apr 2021 10:59:46 +0200 Subject: [11u] RFR: 8265417: Backport of JDK-8249672 breaks Solaris x86 build In-Reply-To: <5dd0dcfb-bfc7-d128-f1cb-984726afe0d3@redhat.com> References: <5dd0dcfb-bfc7-d128-f1cb-984726afe0d3@redhat.com> Message-ID: Thank you Aleksey. On Wed, Apr 21, 2021 at 10:55 AM Aleksey Shipilev wrote: > On 4/21/21 6:29 AM, Thomas St?fe wrote: > > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8265417-solaris-x86-missing-microcode-function-breaks-build > > This looks fine to me. Indeed, only solaris-x86 is missing. > > $ cd jdk-updates-jdk11u-dev/src/hotspot/os_cpu > > $ ls -1 | grep x86 > bsd_x86 > linux_x86 > solaris_x86 > windows_x86 > > $ ack cpu_microcode_revision > > linux_x86/os_linux_x86.cpp > 664:juint os::cpu_microcode_revision() { > > linux_x86/os_linux_x86.hpp > 30: static juint cpu_microcode_revision(); > > windows_x86/os_windows_x86.hpp > 62: static juint cpu_microcode_revision(); > > windows_x86/os_windows_x86.cpp > 653:juint os::cpu_microcode_revision() { > > bsd_x86/os_bsd_x86.cpp > 841:juint os::cpu_microcode_revision() { > > bsd_x86/os_bsd_x86.hpp > 30: static juint cpu_microcode_revision() > > -- > Thanks, > -Aleksey > > From lutz.schmidt at sap.com Wed Apr 21 09:04:39 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 21 Apr 2021 09:04:39 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: <5969F266-A269-4329-98D2-E8022EEDD5A7@amazon.com> References: <5969F266-A269-4329-98D2-E8022EEDD5A7@amazon.com> Message-ID: <708D4864-3499-42A3-9EBA-18D6CB219DA3@sap.com> Changes look good to me now. Version 2 of the patches applies clean, not even any fuzz. Diffs against OpenJDK head are only those which can't be avoided. The patches are queued to be tested overnight. Results expected Thursday morning. Local tests on my Mac revealed no issues. I'll report on the test status once available. Thanks, Lutz ?On 21.04.21, 00:49, "Hohensee, Paul" wrote: Yes, please, and also review. I've run tier1 and tier2 on linux-x64. -----Original Message----- From: "Schmidt, Lutz" Date: Tuesday, April 20, 2021 at 1:38 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods You want me to retest? No problem, but results will not be available before Thursday. Please let me know. Lutz On 20.04.21, 19:58, "Hohensee, Paul" wrote: You're right. Emacs fumble-finger. :( New set of 3 webrevs (8214526 dropped). https://cr.openjdk.java.net/~phh/8216314/webrev.11u.02/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.03/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.04/ -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 2:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Yes, that's in the #else path of #if defined(USE_BUFFEREDSTREAM). You have to look further up: +// Same as above, but with fixed buffer size. +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K); + #define STRINGSTREAM_FLUSH(termString) \ _sstbuf->print("%s", termString); \ _outbuf->print("%s", _sstbuf->as_string()); \ _sstbuf->reset(); +// Flush the buffer contents unconditionally. +// No action if the buffer is empty. +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ On 19.04.21, 22:44, "Hohensee, Paul" wrote: I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From goetz.lindenmaier at sap.com Wed Apr 21 09:17:17 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Apr 2021 09:17:17 +0000 Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance In-Reply-To: References: Message-ID: Hi Martin, I had a look at the change. Looks good. Especially the code in macro.cpp is correctly adapted. Best regards Goetz From: Doerr, Martin Sent: Monday, April 19, 2021 4:32 PM To: jdk-updates-dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' Cc: Lindenmaier, Goetz ; Langer, Christoph Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance Hi, JDK-8261812 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8261812 Original change: https://git.openjdk.java.net/jdk/commit/2c0507ec Resolution steps: compile.hpp: - push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry, - BasicType bt); + static bool push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry, + BasicType bt); This cleanup is not applicable. Skipped. macro.cpp: + if (is_subword_type(ft)) { + n = Compile::narrow_value(ft, n, phi_type, &_igvn, true); + } The surrounding code is different in 11u because of GC related changes. I had to adapt it. 11u backport: http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/ Please review. Best regards, Martin From aph at redhat.com Wed Apr 21 09:28:08 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Apr 2021 10:28:08 +0100 Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance In-Reply-To: References: Message-ID: <8ab99bf4-8543-190e-360d-3432d8070f2f@redhat.com> On 4/19/21 3:32 PM, Doerr, Martin wrote: > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/ Looks OK to me, but we definitely need Roland's opinion here. -- 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 Wed Apr 21 09:40:25 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 21 Apr 2021 09:40:25 +0000 Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Mittwoch, 21. April 2021 11:17 To: Doerr, Martin ; jdk-updates-dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' Cc: Langer, Christoph Subject: RE: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance Hi Martin, I had a look at the change. Looks good. Especially the code in macro.cpp is correctly adapted. Best regards Goetz From: Doerr, Martin > Sent: Monday, April 19, 2021 4:32 PM To: jdk-updates-dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' > Cc: Lindenmaier, Goetz >; Langer, Christoph > Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance Hi, JDK-8261812 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8261812 Original change: https://git.openjdk.java.net/jdk/commit/2c0507ec Resolution steps: compile.hpp: - push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry, - BasicType bt); + static bool push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry, + BasicType bt); This cleanup is not applicable. Skipped. macro.cpp: + if (is_subword_type(ft)) { + n = Compile::narrow_value(ft, n, phi_type, &_igvn, true); + } The surrounding code is different in 11u because of GC related changes. I had to adapt it. 11u backport: http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/ Please review. Best regards, Martin From omikhaltcova at openjdk.java.net Wed Apr 21 09:53:41 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Wed, 21 Apr 2021 09:53:41 GMT Subject: [jdk13u-dev] Integrated: 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 18:28:16 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8263846 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > It's reasonable to add the reference check before using it. This pull request has now been integrated. Changeset: 6313a7ca Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/6313a7ca Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X Backport-of: 118a49fc9699590fb5c935729da64dac5e61f26d ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/187 From omikhaltcova at openjdk.java.net Wed Apr 21 09:55:44 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Wed, 21 Apr 2021 09:55:44 GMT Subject: [jdk15u-dev] Integrated: 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 18:53:57 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8263846 to jdk15u for parity with jdk11u. > The original patch applied cleanly. > It's reasonable to add the reference check before using it. This pull request has now been integrated. Changeset: dc56503b Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/dc56503b Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X Backport-of: 118a49fc9699590fb5c935729da64dac5e61f26d ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/28 From yan at openjdk.java.net Wed Apr 21 10:41:36 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 21 Apr 2021 10:41:36 GMT Subject: [jdk13u-dev] RFR: 8256359: AArch64: runtime/ReservedStack/ReservedStackTestCompiler.java fails In-Reply-To: References: Message-ID: <-g6vmAu9yQOOQI9F-eZ9QkMCdx8uPvY2qd57LxMUBJ4=.5187725d-3a0b-4642-99d6-0309b71f347b@github.com> On Mon, 19 Apr 2021 21:08:58 GMT, Sergey Nazarkin wrote: > Please review backport of JDK-8256359. Patch applies cleanly except update of ProblemList.txt is not required since JDK-8256803 was not backported to jdk13. I was not able to reproduce the crash on any board accessible for tests, but the patch fixes obvious error and required for parity with jdk11 Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/186 From evergizova at openjdk.java.net Wed Apr 21 10:41:39 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 21 Apr 2021 10:41:39 GMT Subject: [jdk15u-dev] Integrated: 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 19:23:13 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8258396 to 15u for parity with 11u. > The patch applies cleanly. > Tested with tier1 and jdk/jfr tests. This pull request has now been integrated. Changeset: 1fc67292 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/1fc67292 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() Backport-of: e85892bfe243bdba6ca22f8756fdda7486baefc2 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/29 From evergizova at openjdk.java.net Wed Apr 21 10:42:41 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 21 Apr 2021 10:42:41 GMT Subject: [jdk15u-dev] Integrated: 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 19:24:38 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8252090 to 15u for parity with 11u. > The patch applies cleanly. > Tested with tier1 and jdk/jfr tests. This pull request has now been integrated. Changeset: 6d6a0fef Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/6d6a0fef Stats: 59 lines in 10 files changed: 23 ins; 4 del; 32 mod 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) Backport-of: 9924c45faebdba4084c9a5dd5b415dfe6c979024 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/30 From snazarki at openjdk.java.net Wed Apr 21 11:10:42 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 21 Apr 2021 11:10:42 GMT Subject: [jdk13u-dev] Integrated: 8256359: AArch64: runtime/ReservedStack/ReservedStackTestCompiler.java fails In-Reply-To: References: Message-ID: <_JjBiua5gLxhpih4TehVdqQau9LG4HPCNk_e4_ZV4bI=.d59f4a0b-b9ec-4424-9925-f829c9b8a494@github.com> On Mon, 19 Apr 2021 21:08:58 GMT, Sergey Nazarkin wrote: > Please review backport of JDK-8256359. Patch applies cleanly except update of ProblemList.txt is not required since JDK-8256803 was not backported to jdk13. I was not able to reproduce the crash on any board accessible for tests, but the patch fixes obvious error and required for parity with jdk11 This pull request has now been integrated. Changeset: ee8051fa Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/ee8051fa Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod 8256359: AArch64: runtime/ReservedStack/ReservedStackTestCompiler.java fails Reviewed-by: yan Backport-of: 4e43b28858b0c7c9fb7ad91a506b61aa1d554f86 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/186 From eastig at amazon.co.uk Wed Apr 21 12:31:36 2021 From: eastig at amazon.co.uk (Astigeevich, Evgeny) Date: Wed, 21 Apr 2021 12:31:36 +0000 Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow In-Reply-To: <22320329-53EB-4B4B-8764-42C8D0A0C80C@amazon.com> References: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com> <14294007-A41E-4A5C-86BB-1E616ECCDA1C@amazon.com> <22320329-53EB-4B4B-8764-42C8D0A0C80C@amazon.com> Message-ID: <86AF48AA-D21B-4192-B774-131FD05EBE8A@amazon.com> Hi Paul, Thanks for reviewing. -Evgeny From: "Hohensee, Paul" Date: Tuesday, 20 April 2021 at 19:13 To: "Astigeevich, Evgeny" , "jdk-updates-dev at openjdk.java.net" Cc: "compiler-dev at openjdk.java.net" Subject: RE: [11u] RFR 8177068: incomplete classpath causes NPE in Flow Lgtm. Thanks, Paul From: compiler-dev on behalf of "Astigeevich, Evgeny" Date: Tuesday, April 20, 2021 at 10:03 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "compiler-dev at openjdk.java.net" Subject: Re: [11u] RFR 8177068: incomplete classpath causes NPE in Flow Ping. From: compiler-dev on behalf of "Astigeevich, Evgeny" Date: Monday, 19 April 2021 at 12:04 To: "jdk-updates-dev at openjdk.java.net" Cc: "compiler-dev at openjdk.java.net" Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow Hi, Please review the backport of JDK-8177068 to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8177068 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a3c63a9dfb2c The original patch does not apply cleanly to 11u. In the original patch, file DeferredAttr.java, calls of ?attribSpeculative? to be changed have the argument AttributionMode.SPECULATIVE. The original patch does not change this. In 11u ?attribSpeculative? does not have the parameter AttributionMode. I changed the affected calls to 11u API. 11u webrev: http://cr.openjdk.java.net/~eastigeevich/8177068/webrev.00/ Tested: Amazon Linux 2 x86_64, tier1, tier2, langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153 Thanks, Evgeny Astigeevich Amazon Development Centre (London) Ltd.Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. From yan at openjdk.java.net Wed Apr 21 14:20:02 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 21 Apr 2021 14:20:02 GMT Subject: [jdk13u-dev] RFR: 8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 Message-ID: This patch does change some code inside a condition clause in a test. Now, in jdk17 that condition (so, context for this fix) checks for linux only but in jdk13 it checks also for solaris. Other than that, patch goes clean. ------------- Commit messages: - Backport 79a4a019bba1c99bef2377fe88f1464943530a55 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/188/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=188&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247753 Stats: 33 lines in 2 files changed: 10 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/188.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/188/head:pull/188 PR: https://git.openjdk.java.net/jdk13u-dev/pull/188 From richard.reingruber at sap.com Wed Apr 21 14:25:20 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 21 Apr 2021 14:25:20 +0000 Subject: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier Message-ID: Hi, please review this XXS fix for 11u which adds a storestore barrier to `CardTableBarrierSet::write_ref_array_work(MemRegion mr)`. The barrier is only executed if CMS is selected. Please refer to the bug report for more details. Bug: https://bugs.openjdk.java.net/browse/JDK-8265677 https://git.openjdk.java.net/jdk/commit/9689863a 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8265677_11u_CMS__CardTableBarrierSet__write_ref_array_work___lacks_storestore_barrier/webrev.0/ Testing: make run-test-tier1 JTREG="VM_OPTIONS=-XX:+UseConcMarkSweepGC" CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From richard.reingruber at sap.com Wed Apr 21 14:31:42 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 21 Apr 2021 14:31:42 +0000 Subject: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier In-Reply-To: References: Message-ID: // Resend after removing incorrect link Hi, please review this XXS fix for 11u which adds a storestore barrier to `CardTableBarrierSet::write_ref_array_work(MemRegion mr)`. The barrier is only executed if CMS is selected. Please refer to the bug report for more details. Bug: https://bugs.openjdk.java.net/browse/JDK-8265677 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8265677_11u_CMS__CardTableBarrierSet__write_ref_array_work___lacks_storestore_barrier/webrev.0/ Testing: make run-test-tier1 JTREG="VM_OPTIONS=-XX:+UseConcMarkSweepGC" CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From jhuttana at redhat.com Wed Apr 21 15:05:52 2021 From: jhuttana at redhat.com (Jayashree Huttanagoudar) Date: Wed, 21 Apr 2021 20:35:52 +0530 Subject: OpenJDK 11.0.11 Released In-Reply-To: <20210421055414.GA539091@rincewind> References: <20210421055414.GA539091@rincewind> Message-ID: On Wed, Apr 21, 2021 at 11:27 AM Andrew Hughes wrote: > We are pleased to announce the release of OpenJDK 11.0.11. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.11-ga.tar.xz > > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.11-ga.tar.xz.sig > > This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): > > PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) > Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F > > SHA256 checksums: > > a00f8cf0c1edbefb767bce893a74b170478cb9bf152224b215aa59e7b431079c > openjdk-11.0.11-ga.tar.xz > b5f7a56a6aad10d3378784f7aa829cadf4c2796faa13d01d1f5933be4740eadd > openjdk-11.0.11-ga.tar.xz.sig > > The checksums can be downloaded from: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.11-ga.sha256 The binaries to go with this are here: https://adoptopenjdk.net/upstream.html?variant=openjdk11&jvmVariant=hotspot Thanks & Regards, Jaya > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From hohensee at amazon.com Wed Apr 21 17:25:23 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 21 Apr 2021 17:25:23 +0000 Subject: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier Message-ID: Putting an unconditional storestore barrier in dirty_MemRegion might be a better fix since it will catch everything, not just arrays. But, that's not in tip, so lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Reingruber, Richard" Date: Wednesday, April 21, 2021 at 7:32 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier // Resend after removing incorrect link Hi, please review this XXS fix for 11u which adds a storestore barrier to `CardTableBarrierSet::write_ref_array_work(MemRegion mr)`. The barrier is only executed if CMS is selected. Please refer to the bug report for more details. Bug: https://bugs.openjdk.java.net/browse/JDK-8265677 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8265677_11u_CMS__CardTableBarrierSet__write_ref_array_work___lacks_storestore_barrier/webrev.0/ Testing: make run-test-tier1 JTREG="VM_OPTIONS=-XX:+UseConcMarkSweepGC" CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From hohensee at amazon.com Wed Apr 21 17:42:19 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 21 Apr 2021 17:42:19 +0000 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive Message-ID: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> Hi, Jaroslav. This push (https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/b103107d7ceb) broke the debug builds, vis /home/hohensee/workspaces/jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:298:14: error: ?JfrJavaSupport? has not been declared DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) The fix is diff -r b103107d7ceb src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp --- a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Wed Apr 21 12:24:28 2021 +0200 +++ b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Wed Apr 21 17:40:23 2021 +0000 @@ -24,6 +24,7 @@ #include "precompiled.hpp" #include "jfr/jfrEvents.hpp" +#include "jfr/jni/jfrJavaSupport.hpp" #include "jfr/leakprofiler/chains/edgeStore.hpp" #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Jaroslav Bachor?k Date: Monday, April 12, 2021 at 1:40 AM To: Florian David Cc: jdk-updates-dev , Marcus Hirt Subject: RE: [11u] RFR: 8258414: OldObjectSample events too expensive Great, thanks! Reviewed! -JB- On Fri, Apr 9, 2021 at 11:49 PM Florian David wrote: > > After receiving feedback from Markus stating that: > > There is no need to attempt a lock replacement, because in 11, there is no concurrent class unloading. There, unloading only happens at a safepoint. > > With concurrent class unloading, there is a need to protect this list, but in 11 it is mutually exclusive and cannot be modified concurrently with the JFR Recorder thread calling "install_stack_traces(sampler"). > > I removed the module lock and added an is_at_safepoint() assert. > > Update webrev link: > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.02/ > Original PR: https://github.com/openjdk/jdk/pull/2780 > > Florian > > On Sun, Apr 4, 2021 at 8:33 PM Florian David wrote: >> >> Hi Jaroslav, >> >> Thanks for the review. >> >>> >>> - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >>> L287 - IMO, the TODO is not necessary >> >> It's removed. >> >>> >>> L293 - I think the comment `// caller needs ResourceMark` should >>> not be removed >> >> I added it back. >> >>> L303 - Not sure if using Module_lock instead of >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >>> bringing in changes unrelated to the patch. >>> From what is happening in other places it would seem >>> that a safepoint should be asserted instead (or nothing should be >>> done). >>> I will let Markus weigh in on this. >> >> No change for the moment. >> >>> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >>> L38 - can this be completely removed? >> >> It's removed. >> >>> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >>> L30 - I think `class JfrThreadLocal;` can also be removed >>> >> It's removed. >> >> Update webrev link: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >> webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.01/ >> Original PR: https://github.com/openjdk/jdk/pull/2780 >> >> Florian >> >> On Mon, Mar 29, 2021 at 12:22 PM Jaroslav Bachor?k wrote: >>> >>> Hi Florian, >>> >>> a few nits: >>> - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >>> L287 - IMO, the TODO is not necessary >>> L293 - I think the comment `// caller needs ResourceMark` should >>> not be removed >>> L303 - Not sure if using Module_lock instead of >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >>> bringing in changes unrelated to the patch. >>> From what is happening in other places it would seem >>> that a safepoint should be asserted instead (or nothing should be >>> done). >>> I will let Markus weigh in on this. >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >>> L38 - can this be completely removed? >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >>> L30 - I think `class JfrThreadLocal;` can also be removed >>> >>> Cheers, >>> >>> -JB- >>> >>> >>> On Wed, Mar 24, 2021 at 8:42 PM Florian David >>> wrote: >>> > >>> > Hi, >>> > >>> > Please review this 11u backport. It's very similar to the original patch, >>> > except for the class loader data graph lock and JfrKlassUnloading::sort() >>> > method which are not available in 11u. >>> > >>> > The missing lock has been replaced by locking the module_lock instead, >>> > as it is done in jfrcheckpointManager.cpp:363. >>> > JfrKlassUnloading class does not exist and thus sort() method is not replaced, >>> > I added a TODO instead. >>> > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >>> > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ >>> > Original PR: https://github.com/openjdk/jdk/pull/2780 >>> > >>> > Testing: >>> > - Linux x86_64 tier1 tests >>> > - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is 75.12 MB before the patch and 3.08 MB after the patch. >>> > >>> > Let me know what you think. >>> > >>> > Thanks, >>> > Florian From vladimir.kozlov at oracle.com Wed Apr 21 18:29:04 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Apr 2021 11:29:04 -0700 Subject: [11u] RFR 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: References: Message-ID: <74b89e0d-6dda-6ee5-4c79-dfa45be8b116@oracle.com> Good. Matches our backport. Thanks, Vladimir K On 4/20/21 6:54 AM, Reingruber, Richard wrote: > Hi, > > Please help review this backport of JDK-8262295 to 11u. > The fix itself applies cleanly. > Just the test required trivial adaptation. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8262295 > https://git.openjdk.java.net/jdk/commit/9689863a > > 11u webrev: > http://cr.openjdk.java.net/~rrich/webrevs/8262295_11u_C2_Out_of_Bounds_Array_Load_from_Clone_Source/webrev.0/ > > Adaptations: > > I had to remove the package from the class ClassFileInstaller in the included > test TestOutOfBoundsArrayLoad.java > > Testing: > > CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms > > Thanks, Richard. > From thomas.stuefe at gmail.com Thu Apr 22 05:19:15 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Apr 2021 07:19:15 +0200 Subject: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample events too expensive) Message-ID: Hi guys, Errors happen, that is normal. But I wonder if we need some clearer standards for testing downported patches? Currently the only requirement is to run tier1 tests, but nothing is mentioned about the configuration and the platforms to be tested. 11u is a stable maintenance release and in theory it should have a higher, not a lower bar for testing than the head release. Surely testing just release is not enough, the debug builds need to be tested too. Then, arguably one should test on more than one platform. It's fine for individual contributors which don't have the resources, but larger companies should be able to test 11u patches on multiple platforms. Otherwise the burden of running the full gamut of tests and analysing accumulated errors lies overly by the 11u maintainers. What do you think? (Ccing Aleksey as the maintainer of https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix). Cheers, Thomas On Wed, Apr 21, 2021 at 7:42 PM Hohensee, Paul wrote: > Hi, Jaroslav. > > This push ( > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/b103107d7ceb) > broke the debug builds, vis > > /home/hohensee/workspaces/jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:298:14: > error: ?JfrJavaSupport? has not been declared > DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) > > The fix is > > diff -r b103107d7ceb > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > --- > a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > Wed Apr 21 12:24:28 2021 +0200 > +++ > b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > Wed Apr 21 17:40:23 2021 +0000 > @@ -24,6 +24,7 @@ > > #include "precompiled.hpp" > #include "jfr/jfrEvents.hpp" > +#include "jfr/jni/jfrJavaSupport.hpp" > #include "jfr/leakprofiler/chains/edgeStore.hpp" > #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" > #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf > of Jaroslav Bachor?k > Date: Monday, April 12, 2021 at 1:40 AM > To: Florian David > Cc: jdk-updates-dev , Marcus Hirt < > marcus.hirt at datadoghq.com> > Subject: RE: [11u] RFR: 8258414: OldObjectSample events too expensive > > Great, thanks! > > Reviewed! > > -JB- > > On Fri, Apr 9, 2021 at 11:49 PM Florian David > wrote: > > > > After receiving feedback from Markus stating that: > > > There is no need to attempt a lock replacement, because in 11, there > is no concurrent class unloading. There, unloading only happens at a > safepoint. > > > With concurrent class unloading, there is a need to protect this list, > but in 11 it is mutually exclusive and cannot be modified concurrently with > the JFR Recorder thread calling "install_stack_traces(sampler"). > > > > I removed the module lock and added an is_at_safepoint() assert. > > > > Update webrev link: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.02/ > > Original PR: https://github.com/openjdk/jdk/pull/2780 > > > > Florian > > > > On Sun, Apr 4, 2021 at 8:33 PM Florian David < > florian.david at datadoghq.com> wrote: > >> > >> Hi Jaroslav, > >> > >> Thanks for the review. > >> > >>> > >>> - > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > >>> L287 - IMO, the TODO is not necessary > >> > >> It's removed. > >> > >>> > >>> L293 - I think the comment `// caller needs ResourceMark` should > >>> not be removed > >> > >> I added it back. > >> > >>> L303 - Not sure if using Module_lock instead of > >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be > >>> bringing in changes unrelated to the patch. > >>> From what is happening in other places it would seem > >>> that a safepoint should be asserted instead (or nothing should be > >>> done). > >>> I will let Markus weigh in on this. > >> > >> No change for the moment. > >> > >>> > >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp > >>> L38 - can this be completely removed? > >> > >> It's removed. > >> > >>> > >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp > >>> L30 - I think `class JfrThreadLocal;` can also be removed > >>> > >> It's removed. > >> > >> Update webrev link: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > >> webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.01/ > >> Original PR: https://github.com/openjdk/jdk/pull/2780 > >> > >> Florian > >> > >> On Mon, Mar 29, 2021 at 12:22 PM Jaroslav Bachor?k < > jaroslav.bachorik at datadoghq.com> wrote: > >>> > >>> Hi Florian, > >>> > >>> a few nits: > >>> - > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > >>> L287 - IMO, the TODO is not necessary > >>> L293 - I think the comment `// caller needs ResourceMark` should > >>> not be removed > >>> L303 - Not sure if using Module_lock instead of > >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be > >>> bringing in changes unrelated to the patch. > >>> From what is happening in other places it would seem > >>> that a safepoint should be asserted instead (or nothing should be > >>> done). > >>> I will let Markus weigh in on this. > >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp > >>> L38 - can this be completely removed? > >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp > >>> L30 - I think `class JfrThreadLocal;` can also be removed > >>> > >>> Cheers, > >>> > >>> -JB- > >>> > >>> > >>> On Wed, Mar 24, 2021 at 8:42 PM Florian David > >>> wrote: > >>> > > >>> > Hi, > >>> > > >>> > Please review this 11u backport. It's very similar to the original > patch, > >>> > except for the class loader data graph lock and > JfrKlassUnloading::sort() > >>> > method which are not available in 11u. > >>> > > >>> > The missing lock has been replaced by locking the module_lock > instead, > >>> > as it is done in jfrcheckpointManager.cpp:363. > >>> > JfrKlassUnloading class does not exist and thus sort() method is not > replaced, > >>> > I added a TODO instead. > >>> > > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > >>> > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ > >>> > Original PR: https://github.com/openjdk/jdk/pull/2780 > >>> > > >>> > Testing: > >>> > - Linux x86_64 tier1 tests > >>> > - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is > 75.12 MB before the patch and 3.08 MB after the patch. > >>> > > >>> > Let me know what you think. > >>> > > >>> > Thanks, > >>> > Florian > > From thomas.stuefe at gmail.com Thu Apr 22 05:25:06 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Apr 2021 07:25:06 +0200 Subject: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample events too expensive) In-Reply-To: References: Message-ID: Should have had my first coffee before posting; Aleksey was not the creator of the wiki page, so I add Christoph... On Thu, Apr 22, 2021 at 7:19 AM Thomas St?fe wrote: > Hi guys, > > Errors happen, that is normal. But I wonder if we need some clearer > standards for testing downported patches? Currently the only requirement is > to run tier1 tests, but nothing is mentioned about the configuration and > the platforms to be tested. 11u is a stable maintenance release and in > theory it should have a higher, not a lower bar for testing than the head > release. > > Surely testing just release is not enough, the debug builds need to be > tested too. Then, arguably one should test on more than one platform. It's > fine for individual contributors which don't have the resources, but larger > companies should be able to test 11u patches on multiple platforms. > Otherwise the burden of running the full gamut of tests and analysing > accumulated errors lies overly by the 11u maintainers. > > What do you think? > > (Ccing Aleksey as the maintainer of > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix). > > Cheers, Thomas > > > On Wed, Apr 21, 2021 at 7:42 PM Hohensee, Paul > wrote: > >> Hi, Jaroslav. >> >> This push ( >> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/b103107d7ceb) >> broke the debug builds, vis >> >> /home/hohensee/workspaces/jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:298:14: >> error: ?JfrJavaSupport? has not been declared >> DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) >> >> The fix is >> >> diff -r b103107d7ceb >> src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> --- >> a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> Wed Apr 21 12:24:28 2021 +0200 >> +++ >> b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> Wed Apr 21 17:40:23 2021 +0000 >> @@ -24,6 +24,7 @@ >> >> #include "precompiled.hpp" >> #include "jfr/jfrEvents.hpp" >> +#include "jfr/jni/jfrJavaSupport.hpp" >> #include "jfr/leakprofiler/chains/edgeStore.hpp" >> #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" >> #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" >> >> Thanks, >> Paul >> >> ?-----Original Message----- >> From: jdk-updates-dev on behalf >> of Jaroslav Bachor?k >> Date: Monday, April 12, 2021 at 1:40 AM >> To: Florian David >> Cc: jdk-updates-dev , Marcus Hirt < >> marcus.hirt at datadoghq.com> >> Subject: RE: [11u] RFR: 8258414: OldObjectSample events too expensive >> >> Great, thanks! >> >> Reviewed! >> >> -JB- >> >> On Fri, Apr 9, 2021 at 11:49 PM Florian David >> wrote: >> > >> > After receiving feedback from Markus stating that: >> > > There is no need to attempt a lock replacement, because in 11, there >> is no concurrent class unloading. There, unloading only happens at a >> safepoint. >> > > With concurrent class unloading, there is a need to protect this >> list, but in 11 it is mutually exclusive and cannot be modified >> concurrently with the JFR Recorder thread calling >> "install_stack_traces(sampler"). >> > >> > I removed the module lock and added an is_at_safepoint() assert. >> > >> > Update webrev link: >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >> > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.02/ >> > Original PR: https://github.com/openjdk/jdk/pull/2780 >> > >> > Florian >> > >> > On Sun, Apr 4, 2021 at 8:33 PM Florian David < >> florian.david at datadoghq.com> wrote: >> >> >> >> Hi Jaroslav, >> >> >> >> Thanks for the review. >> >> >> >>> >> >>> - >> src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> >>> L287 - IMO, the TODO is not necessary >> >> >> >> It's removed. >> >> >> >>> >> >>> L293 - I think the comment `// caller needs ResourceMark` should >> >>> not be removed >> >> >> >> I added it back. >> >> >> >>> L303 - Not sure if using Module_lock instead of >> >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >> >>> bringing in changes unrelated to the patch. >> >>> From what is happening in other places it would seem >> >>> that a safepoint should be asserted instead (or nothing should be >> >>> done). >> >>> I will let Markus weigh in on this. >> >> >> >> No change for the moment. >> >> >> >>> >> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >> >>> L38 - can this be completely removed? >> >> >> >> It's removed. >> >> >> >>> >> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >> >>> L30 - I think `class JfrThreadLocal;` can also be removed >> >>> >> >> It's removed. >> >> >> >> Update webrev link: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >> >> webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.01/ >> >> Original PR: https://github.com/openjdk/jdk/pull/2780 >> >> >> >> Florian >> >> >> >> On Mon, Mar 29, 2021 at 12:22 PM Jaroslav Bachor?k < >> jaroslav.bachorik at datadoghq.com> wrote: >> >>> >> >>> Hi Florian, >> >>> >> >>> a few nits: >> >>> - >> src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> >>> L287 - IMO, the TODO is not necessary >> >>> L293 - I think the comment `// caller needs ResourceMark` should >> >>> not be removed >> >>> L303 - Not sure if using Module_lock instead of >> >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >> >>> bringing in changes unrelated to the patch. >> >>> From what is happening in other places it would seem >> >>> that a safepoint should be asserted instead (or nothing should be >> >>> done). >> >>> I will let Markus weigh in on this. >> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >> >>> L38 - can this be completely removed? >> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >> >>> L30 - I think `class JfrThreadLocal;` can also be removed >> >>> >> >>> Cheers, >> >>> >> >>> -JB- >> >>> >> >>> >> >>> On Wed, Mar 24, 2021 at 8:42 PM Florian David >> >>> wrote: >> >>> > >> >>> > Hi, >> >>> > >> >>> > Please review this 11u backport. It's very similar to the original >> patch, >> >>> > except for the class loader data graph lock and >> JfrKlassUnloading::sort() >> >>> > method which are not available in 11u. >> >>> > >> >>> > The missing lock has been replaced by locking the module_lock >> instead, >> >>> > as it is done in jfrcheckpointManager.cpp:363. >> >>> > JfrKlassUnloading class does not exist and thus sort() method is >> not replaced, >> >>> > I added a TODO instead. >> >>> > >> >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >> >>> > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ >> >>> > Original PR: https://github.com/openjdk/jdk/pull/2780 >> >>> > >> >>> > Testing: >> >>> > - Linux x86_64 tier1 tests >> >>> > - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is >> 75.12 MB before the patch and 3.08 MB after the patch. >> >>> > >> >>> > Let me know what you think. >> >>> > >> >>> > Thanks, >> >>> > Florian >> >> From shade at redhat.com Thu Apr 22 06:11:21 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 08:11:21 +0200 Subject: [11u] RFR (XS) 8265537: x86 version string truncated after JDK-8249672 11u backport In-Reply-To: <89e2926e-1ab7-785f-343e-d7d841de1fbb@redhat.com> References: <89e2926e-1ab7-785f-343e-d7d841de1fbb@redhat.com> Message-ID: On 4/20/21 7:23 PM, Aleksey Shipilev wrote: > 11u-specific regression: > https://bugs.openjdk.java.net/browse/JDK-8265537 > > See the details in the bug. > > 11u patch: > > diff -r 9846af5a0949 src/hotspot/cpu/x86/vm_version_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_x86.cpp Mon Apr 19 12:47:46 2021 +0200 > +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp Tue Apr 20 19:23:24 2021 +0200 > @@ -743,11 +743,11 @@ > if (is_knights_family()) { > _features &= ~CPU_VZEROUPPER; > } > } > > - char buf[256]; > + char buf[512]; > jio_snprintf(buf, sizeof(buf), > "(%u cores per cpu, %u threads per core) family %d model %d stepping %d microcode 0x%x" > "%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s", > cores_per_cpu(), threads_per_core(), > cpu_family(), _model, _stepping, os::cpu_microcode_revision(), > > Testing: compiler/intrinsics/sha tests (now pass); tier1 Anyone? -- Thanks, -Aleksey From shade at redhat.com Thu Apr 22 06:17:16 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 08:17:16 +0200 Subject: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u backport Message-ID: <92630a56-141e-1245-1973-ee098d6a90b6@redhat.com> Current jdk11u fastdebug build fails with: /home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp: In static member function 'static void ObjectSampleCheckpoint::on_rotation(const ObjectSampler*)': /home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:298:14: error: 'JfrJavaSupport' has not been declared 298 | DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) | ^~~~~~~~~~~~~~ /home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/utilities/macros.hpp:393:26: note: in definition of macro 'DEBUG_ONLY' 393 | #define DEBUG_ONLY(code) code | ^~~~ Fix: diff -r 31224d74aa23 src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp --- a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Sep 05 12:39:48 2019 +0200 +++ b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Apr 22 08:09:40 2021 +0200 @@ -22,10 +22,11 @@ * */ #include "precompiled.hpp" #include "jfr/jfrEvents.hpp" +#include "jfr/jni/jfrJavaSupport.hpp" #include "jfr/leakprofiler/chains/edgeStore.hpp" #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" Testing: Linux x86_64 fastdebug build -- Thanks, -Aleksey From shade at redhat.com Thu Apr 22 06:10:43 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 08:10:43 +0200 Subject: [11u] (urgent) RFR (XS) 8265718: Build failure after JDK-8258414 11u backport Message-ID: <334c925c-1b71-fc9e-493e-af354a397e7c@redhat.com> Current jdk11u fastdebug build fails with: /home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp: In static member function 'static void ObjectSampleCheckpoint::on_rotation(const ObjectSampler*)': /home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:298:14: error: 'JfrJavaSupport' has not been declared 298 | DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) | ^~~~~~~~~~~~~~ /home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/utilities/macros.hpp:393:26: note: in definition of macro 'DEBUG_ONLY' 393 | #define DEBUG_ONLY(code) code | ^~~~ Fix: diff -r 31224d74aa23 src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp --- a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Sep 05 12:39:48 2019 +0200 +++ b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Apr 22 08:09:40 2021 +0200 @@ -22,10 +22,11 @@ * */ #include "precompiled.hpp" #include "jfr/jfrEvents.hpp" +#include "jfr/jni/jfrJavaSupport.hpp" #include "jfr/leakprofiler/chains/edgeStore.hpp" #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" #include "jfr/leakprofiler/checkpoint/objectSampleWriter.hpp" #include "jfr/leakprofiler/leakProfiler.hpp" Testing: Linux x86_64 fastdebug build -- Thanks, -Aleksey From shade at redhat.com Thu Apr 22 06:19:14 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 08:19:14 +0200 Subject: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample events too expensive) In-Reply-To: References: Message-ID: <2a8e696b-98e1-87de-e882-9f4a0ba84121@redhat.com> On 4/22/21 7:19 AM, Thomas St?fe wrote: > What do you think? I think the move to Skara would give us GHA, which would run the tests we want. In the meantime, the minimal bar for testing should be x86_64 {release,fastdebug} tier1. BTW, I filed this for 11u build failure: https://bugs.openjdk.java.net/browse/JDK-8265718 -- Thanks, -Aleksey From thomas.stuefe at gmail.com Thu Apr 22 06:54:17 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Apr 2021 08:54:17 +0200 Subject: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample events too expensive) In-Reply-To: <2a8e696b-98e1-87de-e882-9f4a0ba84121@redhat.com> References: <2a8e696b-98e1-87de-e882-9f4a0ba84121@redhat.com> Message-ID: Sounds reasonable. Thanks, Thomas On Thu, Apr 22, 2021, 08:19 Aleksey Shipilev wrote: > On 4/22/21 7:19 AM, Thomas St?fe wrote: > > What do you think? > > I think the move to Skara would give us GHA, which would run the tests we > want. > In the meantime, the minimal bar for testing should be x86_64 > {release,fastdebug} tier1. > > BTW, I filed this for 11u build failure: > https://bugs.openjdk.java.net/browse/JDK-8265718 > > -- > Thanks, > -Aleksey > > From goetz.lindenmaier at sap.com Thu Apr 22 07:19:49 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 22 Apr 2021 07:19:49 +0000 Subject: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u backport In-Reply-To: <92630a56-141e-1245-1973-ee098d6a90b6@redhat.com> References: <92630a56-141e-1245-1973-ee098d6a90b6@redhat.com> Message-ID: Hi Aleksey, The patch looks good to me. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Thursday, April 22, 2021 8:17 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u backport > > Current jdk11u fastdebug build fails with: > > /home/shade/trunks/jdk-updates-jdk11u- > dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint > .cpp: > > In static member function 'static void > ObjectSampleCheckpoint::on_rotation(const ObjectSampler*)': > /home/shade/trunks/jdk-updates-jdk11u- > dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint > .cpp:298:14: > > error: 'JfrJavaSupport' has not been declared > 298 | > DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) > | ^~~~~~~~~~~~~~ > /home/shade/trunks/jdk-updates-jdk11u- > dev/src/hotspot/share/utilities/macros.hpp:393:26: note: in > definition of macro 'DEBUG_ONLY' > 393 | #define DEBUG_ONLY(code) code > | ^~~~ > > Fix: > > diff -r 31224d74aa23 > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > --- > a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cp > p Thu Sep 05 12:39:48 > 2019 +0200 > +++ > b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.c > pp Thu Apr 22 08:09:40 > 2021 +0200 > @@ -22,10 +22,11 @@ > * > */ > > #include "precompiled.hpp" > #include "jfr/jfrEvents.hpp" > +#include "jfr/jni/jfrJavaSupport.hpp" > #include "jfr/leakprofiler/chains/edgeStore.hpp" > #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" > > Testing: Linux x86_64 fastdebug build > > -- > Thanks, > -Aleksey From thomas.stuefe at gmail.com Thu Apr 22 07:13:21 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Apr 2021 09:13:21 +0200 Subject: [11u] (urgent) RFR (XS) 8265718: Build failure after JDK-8258414 11u backport In-Reply-To: <334c925c-1b71-fc9e-493e-af354a397e7c@redhat.com> References: <334c925c-1b71-fc9e-493e-af354a397e7c@redhat.com> Message-ID: That's not enough to fix it, it also misses #include "runtime/interfaceSupport.inline.hpp" ..Thomas On Thu, Apr 22, 2021 at 8:18 AM Aleksey Shipilev wrote: > Current jdk11u fastdebug build fails with: > > /home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp: > > In static member function 'static void > ObjectSampleCheckpoint::on_rotation(const ObjectSampler*)': > /home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:298:14: > > error: 'JfrJavaSupport' has not been declared > 298 | DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) > | ^~~~~~~~~~~~~~ > /home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/utilities/macros.hpp:393:26: > note: in > definition of macro 'DEBUG_ONLY' > 393 | #define DEBUG_ONLY(code) code > | ^~~~ > > Fix: > > diff -r 31224d74aa23 > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > --- > a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > Thu Sep 05 12:39:48 > 2019 +0200 > +++ > b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > Thu Apr 22 08:09:40 > 2021 +0200 > @@ -22,10 +22,11 @@ > * > */ > > #include "precompiled.hpp" > #include "jfr/jfrEvents.hpp" > +#include "jfr/jni/jfrJavaSupport.hpp" > #include "jfr/leakprofiler/chains/edgeStore.hpp" > #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" > #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" > #include "jfr/leakprofiler/checkpoint/objectSampleWriter.hpp" > #include "jfr/leakprofiler/leakProfiler.hpp" > > Testing: Linux x86_64 fastdebug build > > -- > Thanks, > -Aleksey > > From shade at redhat.com Thu Apr 22 07:44:53 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 09:44:53 +0200 Subject: [11u] (urgent) RFR (XS) 8265718: Build failure after JDK-8258414 11u backport In-Reply-To: References: <334c925c-1b71-fc9e-493e-af354a397e7c@redhat.com> Message-ID: <591b7393-72db-5b70-621b-9ba4c0e72677@redhat.com> On 4/22/21 9:13 AM, Thomas St?fe wrote: > That's not enough to fix it, it also misses > > #include "runtime/interfaceSupport.inline.hpp" I don't see why, can you explain? I added it to current patch: diff -r 31224d74aa23 src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp --- a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Sep 05 12:39:48 2019 +0200 +++ b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Apr 22 09:44:39 2021 +0200 @@ -25,4 +25,5 @@ #include "precompiled.hpp" #include "jfr/jfrEvents.hpp" +#include "jfr/jni/jfrJavaSupport.hpp" #include "jfr/leakprofiler/chains/edgeStore.hpp" #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" @@ -38,4 +39,5 @@ #include "jfr/utilities/jfrHashtable.hpp" #include "jfr/utilities/jfrTypes.hpp" +#include "runtime/interfaceSupport.inline.hpp" #include "runtime/safepoint.hpp" #include "runtime/thread.hpp" -- Thanks, -Aleksey From goetz.lindenmaier at sap.com Thu Apr 22 07:45:25 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 22 Apr 2021 07:45:25 +0000 Subject: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u backport In-Reply-To: References: <92630a56-141e-1245-1973-ee098d6a90b6@redhat.com> Message-ID: Hi, Thomas is right, the patch looks good but is not. I compiled on linuxx86_64 dbg/fastdbg/product with diff --git a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp --- a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp +++ b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp @@ -24,6 +24,7 @@ #include "precompiled.hpp" #include "jfr/jfrEvents.hpp" +#include "jfr/jni/jfrJavaSupport.hpp" #include "jfr/leakprofiler/chains/edgeStore.hpp" #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" @@ -37,6 +38,7 @@ #include "jfr/recorder/stacktrace/jfrStackTraceRepository.hpp" #include "jfr/utilities/jfrHashtable.hpp" #include "jfr/utilities/jfrTypes.hpp" +#include "runtime/interfaceSupport.inline.hpp" #include "runtime/safepoint.hpp" #include "runtime/thread.hpp" #include "utilities/growableArray.hpp" successfully. The code uses ThreadInVMfromNative. Please add the interfaceSupport include and consider it reviewed. Best regards, Goetz > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Thursday, April 22, 2021 9:20 AM > To: 'Aleksey Shipilev' ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u > backport > > Hi Aleksey, > > The patch looks good to me. > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Aleksey Shipilev > > Sent: Thursday, April 22, 2021 8:17 AM > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u > backport > > > > Current jdk11u fastdebug build fails with: > > > > /home/shade/trunks/jdk-updates-jdk11u- > > > dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint > > .cpp: > > > > In static member function 'static void > > ObjectSampleCheckpoint::on_rotation(const ObjectSampler*)': > > /home/shade/trunks/jdk-updates-jdk11u- > > > dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint > > .cpp:298:14: > > > > error: 'JfrJavaSupport' has not been declared > > 298 | > > DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) > > | ^~~~~~~~~~~~~~ > > /home/shade/trunks/jdk-updates-jdk11u- > > dev/src/hotspot/share/utilities/macros.hpp:393:26: note: in > > definition of macro 'DEBUG_ONLY' > > 393 | #define DEBUG_ONLY(code) code > > | ^~~~ > > > > Fix: > > > > diff -r 31224d74aa23 > > > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > > --- > > > a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cp > > p Thu Sep 05 12:39:48 > > 2019 +0200 > > +++ > > > b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.c > > pp Thu Apr 22 08:09:40 > > 2021 +0200 > > @@ -22,10 +22,11 @@ > > * > > */ > > > > #include "precompiled.hpp" > > #include "jfr/jfrEvents.hpp" > > +#include "jfr/jni/jfrJavaSupport.hpp" > > #include "jfr/leakprofiler/chains/edgeStore.hpp" > > #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" > > > > Testing: Linux x86_64 fastdebug build > > > > -- > > Thanks, > > -Aleksey From shade at redhat.com Thu Apr 22 07:48:22 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 09:48:22 +0200 Subject: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u backport In-Reply-To: References: <92630a56-141e-1245-1973-ee098d6a90b6@redhat.com> Message-ID: <904cb832-3469-e6af-c93b-47d2ddcc54f6@redhat.com> On 4/22/21 9:45 AM, Lindenmaier, Goetz wrote: > Hi, > > Thomas is right, the patch looks good but is not. > I compiled on linuxx86_64 dbg/fastdbg/product with > > diff --git a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > --- a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > +++ b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > @@ -24,6 +24,7 @@ > > #include "precompiled.hpp" > #include "jfr/jfrEvents.hpp" > +#include "jfr/jni/jfrJavaSupport.hpp" > #include "jfr/leakprofiler/chains/edgeStore.hpp" > #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" > #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" > @@ -37,6 +38,7 @@ > #include "jfr/recorder/stacktrace/jfrStackTraceRepository.hpp" > #include "jfr/utilities/jfrHashtable.hpp" > #include "jfr/utilities/jfrTypes.hpp" > +#include "runtime/interfaceSupport.inline.hpp" > #include "runtime/safepoint.hpp" > #include "runtime/thread.hpp" > #include "utilities/growableArray.hpp" > > successfully. > The code uses ThreadInVMfromNative. > > Please add the interfaceSupport include and consider it reviewed. Added! diff -r 31224d74aa23 src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp --- a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Sep 05 12:39:48 2019 +0200 +++ b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Apr 22 09:44:39 2021 +0200 @@ -25,4 +25,5 @@ #include "precompiled.hpp" #include "jfr/jfrEvents.hpp" +#include "jfr/jni/jfrJavaSupport.hpp" #include "jfr/leakprofiler/chains/edgeStore.hpp" #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" @@ -38,4 +39,5 @@ #include "jfr/utilities/jfrHashtable.hpp" #include "jfr/utilities/jfrTypes.hpp" +#include "runtime/interfaceSupport.inline.hpp" #include "runtime/safepoint.hpp" #include "runtime/thread.hpp" I wonder why it is not failing for me without a second include... Anyways. -- Thanks, -Aleksey From shade at redhat.com Thu Apr 22 07:57:30 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 09:57:30 +0200 Subject: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u backport In-Reply-To: <904cb832-3469-e6af-c93b-47d2ddcc54f6@redhat.com> References: <92630a56-141e-1245-1973-ee098d6a90b6@redhat.com> <904cb832-3469-e6af-c93b-47d2ddcc54f6@redhat.com> Message-ID: On 4/22/21 9:48 AM, Aleksey Shipilev wrote: > diff -r 31224d74aa23 src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > --- a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Sep 05 12:39:48 > 2019 +0200 > +++ b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Thu Apr 22 09:44:39 > 2021 +0200 > @@ -25,4 +25,5 @@ > #include "precompiled.hpp" > #include "jfr/jfrEvents.hpp" > +#include "jfr/jni/jfrJavaSupport.hpp" > #include "jfr/leakprofiler/chains/edgeStore.hpp" > #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" > @@ -38,4 +39,5 @@ > #include "jfr/utilities/jfrHashtable.hpp" > #include "jfr/utilities/jfrTypes.hpp" > +#include "runtime/interfaceSupport.inline.hpp" > #include "runtime/safepoint.hpp" > #include "runtime/thread.hpp" This passes Linux x86_64 {fastdebug,release} builds for me. I tagged the bug for 11u approval. -- Thanks, -Aleksey From thomas.stuefe at gmail.com Thu Apr 22 07:58:06 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Apr 2021 09:58:06 +0200 Subject: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u backport In-Reply-To: <904cb832-3469-e6af-c93b-47d2ddcc54f6@redhat.com> References: <92630a56-141e-1245-1973-ee098d6a90b6@redhat.com> <904cb832-3469-e6af-c93b-47d2ddcc54f6@redhat.com> Message-ID: All good and trivial. Ship it. Sorry for stating the obvious, do you build with pch? On Thu, Apr 22, 2021 at 9:48 AM Aleksey Shipilev wrote: > On 4/22/21 9:45 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > Thomas is right, the patch looks good but is not. > > I compiled on linuxx86_64 dbg/fastdbg/product with > > > > diff --git > a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > > --- > a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > > +++ > b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > > @@ -24,6 +24,7 @@ > > > > #include "precompiled.hpp" > > #include "jfr/jfrEvents.hpp" > > +#include "jfr/jni/jfrJavaSupport.hpp" > > #include "jfr/leakprofiler/chains/edgeStore.hpp" > > #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" > > #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" > > @@ -37,6 +38,7 @@ > > #include "jfr/recorder/stacktrace/jfrStackTraceRepository.hpp" > > #include "jfr/utilities/jfrHashtable.hpp" > > #include "jfr/utilities/jfrTypes.hpp" > > +#include "runtime/interfaceSupport.inline.hpp" > > #include "runtime/safepoint.hpp" > > #include "runtime/thread.hpp" > > #include "utilities/growableArray.hpp" > > > > successfully. > > The code uses ThreadInVMfromNative. > > > > Please add the interfaceSupport include and consider it reviewed. > Added! > > diff -r 31224d74aa23 > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > --- > a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > Thu Sep 05 12:39:48 > 2019 +0200 > +++ > b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > Thu Apr 22 09:44:39 > 2021 +0200 > @@ -25,4 +25,5 @@ > #include "precompiled.hpp" > #include "jfr/jfrEvents.hpp" > +#include "jfr/jni/jfrJavaSupport.hpp" > #include "jfr/leakprofiler/chains/edgeStore.hpp" > #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" > @@ -38,4 +39,5 @@ > #include "jfr/utilities/jfrHashtable.hpp" > #include "jfr/utilities/jfrTypes.hpp" > +#include "runtime/interfaceSupport.inline.hpp" > #include "runtime/safepoint.hpp" > #include "runtime/thread.hpp" > > I wonder why it is not failing for me without a second include... Anyways. > > -- > Thanks, > -Aleksey > > From shade at redhat.com Thu Apr 22 08:05:18 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 10:05:18 +0200 Subject: [11u] RFR (XS) 8265718: Build failure after JDK-8258414 11u backport In-Reply-To: References: <92630a56-141e-1245-1973-ee098d6a90b6@redhat.com> <904cb832-3469-e6af-c93b-47d2ddcc54f6@redhat.com> Message-ID: <7fdd4940-3365-d151-bb1c-0be536dbb306@redhat.com> On 4/22/21 9:58 AM, Thomas St?fe wrote: > All good and trivial. Ship it. > > Sorry for stating the obvious, do you build with pch? I always build without PCH, because my hardware allows to spend more time on it. I figured it out: all my build configurations also include --with-jvm-features=shenandoahgc, which must have included interfaceSupport.inline.hpp transitively somehow. I'll add the vanilla build config to my test scripts... -- Thanks, -Aleksey From dcherepanov at openjdk.java.net Thu Apr 22 08:52:35 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 22 Apr 2021 08:52:35 GMT Subject: [jdk15u-dev] RFR: 8264823: Update building.html document for Git in jdk15u In-Reply-To: <6PJbNlKkkoawa1O9Cm6Ktu7brctbUnMBIKSYjUZI3Vg=.6da5ba26-5fe0-464a-8b0a-a680b2867234@github.com> References: <6PJbNlKkkoawa1O9Cm6Ktu7brctbUnMBIKSYjUZI3Vg=.6da5ba26-5fe0-464a-8b0a-a680b2867234@github.com> Message-ID: On Wed, 7 Apr 2021 11:03:54 GMT, Yuri Nesterenko wrote: > To generate this HTML version of .md original, we had to > install locally Pandoc v. 2.3.1 using make/devkit/createPandocBundle.sh, > configure with PANDOC=path-to-pandoc-executable flag > remove building.html > and make update-build-docs > > New version has only necessary changes for Git transition, I think. See also a backport of JDK-8251549. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/19 From dcherepanov at openjdk.java.net Thu Apr 22 08:55:29 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 22 Apr 2021 08:55:29 GMT Subject: [jdk13u-dev] RFR: 8251549: Update docs on building for Git In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 15:21:47 GMT, Yuri Nesterenko wrote: > It is long overdue update for jdk13u. Patch of original JDK-8251549 applies clean. In addition, I'm putting in the same jdk13u commit also building.html generated from the updated version of building.md. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/174 From dcherepanov at openjdk.java.net Thu Apr 22 08:57:30 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 22 Apr 2021 08:57:30 GMT Subject: [jdk13u-dev] RFR: 8262110: DST starts from incorrect time in 2038 In-Reply-To: <5nJMXFZBqLLBo95hf1_M9enzpGDVAG-JlHS4BvsacAc=.4adc9f99-302b-4408-af1d-275e6847db32@github.com> References: <5nJMXFZBqLLBo95hf1_M9enzpGDVAG-JlHS4BvsacAc=.4adc9f99-302b-4408-af1d-275e6847db32@github.com> Message-ID: On Thu, 15 Apr 2021 14:48:22 GMT, Yuri Nesterenko wrote: > Old copyright year differs in 13u code! Other than that, no surprises. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/183 From yan at openjdk.java.net Thu Apr 22 08:58:25 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 22 Apr 2021 08:58:25 GMT Subject: [jdk15u-dev] Integrated: 8264823: Update building.html document for Git in jdk15u In-Reply-To: <6PJbNlKkkoawa1O9Cm6Ktu7brctbUnMBIKSYjUZI3Vg=.6da5ba26-5fe0-464a-8b0a-a680b2867234@github.com> References: <6PJbNlKkkoawa1O9Cm6Ktu7brctbUnMBIKSYjUZI3Vg=.6da5ba26-5fe0-464a-8b0a-a680b2867234@github.com> Message-ID: On Wed, 7 Apr 2021 11:03:54 GMT, Yuri Nesterenko wrote: > To generate this HTML version of .md original, we had to > install locally Pandoc v. 2.3.1 using make/devkit/createPandocBundle.sh, > configure with PANDOC=path-to-pandoc-executable flag > remove building.html > and make update-build-docs > > New version has only necessary changes for Git transition, I think. See also a backport of JDK-8251549. This pull request has now been integrated. Changeset: f35be844 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/f35be844 Stats: 39 lines in 1 file changed: 4 ins; 23 del; 12 mod 8264823: Update building.html document for Git in jdk15u Reviewed-by: dcherepanov ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/19 From dcherepanov at openjdk.java.net Thu Apr 22 09:03:31 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 22 Apr 2021 09:03:31 GMT Subject: [jdk13u-dev] RFR: 8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:14:41 GMT, Yuri Nesterenko wrote: > This patch does change some code inside a condition clause in a test. Now, in jdk17 that condition (so, context for this fix) checks for linux only but in jdk13 it checks also for solaris. Other than that, patch goes clean. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/188 From yan at openjdk.java.net Thu Apr 22 09:02:33 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 22 Apr 2021 09:02:33 GMT Subject: [jdk13u-dev] Integrated: 8251549: Update docs on building for Git In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 15:21:47 GMT, Yuri Nesterenko wrote: > It is long overdue update for jdk13u. Patch of original JDK-8251549 applies clean. In addition, I'm putting in the same jdk13u commit also building.html generated from the updated version of building.md. This pull request has now been integrated. Changeset: bc1d8d54 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/bc1d8d54 Stats: 108 lines in 2 files changed: 16 ins; 61 del; 31 mod 8251549: Update docs on building for Git Reviewed-by: dcherepanov Backport-of: 042734cc5b17302a8f2ecdf577511bd6d5ec5e22 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/174 From martin.doerr at sap.com Thu Apr 22 09:19:13 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 22 Apr 2021 09:19:13 +0000 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> Message-ID: Hi, it did not only break the debug build. We have seen a crash on Windows: # Internal Error (./src/hotspot/share/runtime/safepoint.cpp:894), pid=11412, tid=12932 # fatal error: Deadlock in safepoint code. Should have called back to the VM before blocking. V [jvm.dll+0x247c64] report_fatal+0x64 (debug.cpp:268) V [jvm.dll+0x65e30b] SafepointSynchronize::block+0x14b (safepoint.cpp:893) V [jvm.dll+0x101d44] SafepointMechanism::block_if_requested+0x34 (safepointmechanism.inline.hpp:73) V [jvm.dll+0x6f0d9a] JavaThread::check_safepoint_and_suspend_for_native_trans+0xca (thread.cpp:2508) V [jvm.dll+0x5e3175] ObjectSampleCheckpoint::on_rotation+0xa5 (objectsamplecheckpoint.cpp:301) V [jvm.dll+0x397694] JfrRecorderService::pre_safepoint_write+0x64 (jfrrecorderservice.cpp:428) V [jvm.dll+0x3978a4] JfrRecorderService::rotate+0x194 (jfrrecorderservice.cpp:325) V [jvm.dll+0x398324] recorderthread_entry+0xd4 (jfrrecorderthreadloop.cpp:76) V [jvm.dll+0x6f7649] JavaThread::run+0x139 (thread.cpp:1840) V [jvm.dll+0x6f06b4] Thread::call_run+0x84 (thread.cpp:391) V [jvm.dll+0x5f8e36] thread_native_entry+0xd6 (os_windows.cpp:460) Test: jdk/jfr/startupargs/TestOldObjectQueueSize.java Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Mittwoch, 21. April 2021 19:42 > To: Jaroslav Bachor?k ; Florian David > > Cc: jdk-updates-dev ; Marcus Hirt > > Subject: RE: [11u] RFR: 8258414: OldObjectSample events too expensive > > Hi, Jaroslav. > > This push (https://hg.openjdk.java.net/jdk-updates/jdk11u- > dev/rev/b103107d7ceb) broke the debug builds, vis > > /home/hohensee/workspaces/jdk11u- > dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint > .cpp:298:14: error: ?JfrJavaSupport? has not been declared > DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) > > The fix is > > diff -r b103107d7ceb > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > --- > a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cp > p Wed Apr 21 12:24:28 2021 +0200 > +++ > b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.c > pp Wed Apr 21 17:40:23 2021 +0000 > @@ -24,6 +24,7 @@ > > #include "precompiled.hpp" > #include "jfr/jfrEvents.hpp" > +#include "jfr/jni/jfrJavaSupport.hpp" > #include "jfr/leakprofiler/chains/edgeStore.hpp" > #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" > #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of Jaroslav Bachor?k > Date: Monday, April 12, 2021 at 1:40 AM > To: Florian David > Cc: jdk-updates-dev , Marcus Hirt > > Subject: RE: [11u] RFR: 8258414: OldObjectSample events too expensive > > Great, thanks! > > Reviewed! > > -JB- > > On Fri, Apr 9, 2021 at 11:49 PM Florian David > wrote: > > > > After receiving feedback from Markus stating that: > > > There is no need to attempt a lock replacement, because in 11, there is > no concurrent class unloading. There, unloading only happens at a safepoint. > > > With concurrent class unloading, there is a need to protect this list, but in > 11 it is mutually exclusive and cannot be modified concurrently with the JFR > Recorder thread calling "install_stack_traces(sampler"). > > > > I removed the module lock and added an is_at_safepoint() assert. > > > > Update webrev link: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.02/ > > Original PR: https://github.com/openjdk/jdk/pull/2780 > > > > Florian > > > > On Sun, Apr 4, 2021 at 8:33 PM Florian David > wrote: > >> > >> Hi Jaroslav, > >> > >> Thanks for the review. > >> > >>> > >>> - > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > >>> L287 - IMO, the TODO is not necessary > >> > >> It's removed. > >> > >>> > >>> L293 - I think the comment `// caller needs ResourceMark` should > >>> not be removed > >> > >> I added it back. > >> > >>> L303 - Not sure if using Module_lock instead of > >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be > >>> bringing in changes unrelated to the patch. > >>> From what is happening in other places it would seem > >>> that a safepoint should be asserted instead (or nothing should be > >>> done). > >>> I will let Markus weigh in on this. > >> > >> No change for the moment. > >> > >>> > >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp > >>> L38 - can this be completely removed? > >> > >> It's removed. > >> > >>> > >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp > >>> L30 - I think `class JfrThreadLocal;` can also be removed > >>> > >> It's removed. > >> > >> Update webrev link: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > >> webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.01/ > >> Original PR: https://github.com/openjdk/jdk/pull/2780 > >> > >> Florian > >> > >> On Mon, Mar 29, 2021 at 12:22 PM Jaroslav Bachor?k > wrote: > >>> > >>> Hi Florian, > >>> > >>> a few nits: > >>> - > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > >>> L287 - IMO, the TODO is not necessary > >>> L293 - I think the comment `// caller needs ResourceMark` should > >>> not be removed > >>> L303 - Not sure if using Module_lock instead of > >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be > >>> bringing in changes unrelated to the patch. > >>> From what is happening in other places it would seem > >>> that a safepoint should be asserted instead (or nothing should be > >>> done). > >>> I will let Markus weigh in on this. > >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp > >>> L38 - can this be completely removed? > >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp > >>> L30 - I think `class JfrThreadLocal;` can also be removed > >>> > >>> Cheers, > >>> > >>> -JB- > >>> > >>> > >>> On Wed, Mar 24, 2021 at 8:42 PM Florian David > >>> wrote: > >>> > > >>> > Hi, > >>> > > >>> > Please review this 11u backport. It's very similar to the original patch, > >>> > except for the class loader data graph lock and > JfrKlassUnloading::sort() > >>> > method which are not available in 11u. > >>> > > >>> > The missing lock has been replaced by locking the module_lock > instead, > >>> > as it is done in jfrcheckpointManager.cpp:363. > >>> > JfrKlassUnloading class does not exist and thus sort() method is not > replaced, > >>> > I added a TODO instead. > >>> > > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > >>> > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ > >>> > Original PR: https://github.com/openjdk/jdk/pull/2780 > >>> > > >>> > Testing: > >>> > - Linux x86_64 tier1 tests > >>> > - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is 75.12 > MB before the patch and 3.08 MB after the patch. > >>> > > >>> > Let me know what you think. > >>> > > >>> > Thanks, > >>> > Florian From neugens at redhat.com Thu Apr 22 09:21:03 2021 From: neugens at redhat.com (Mario Torre) Date: Thu, 22 Apr 2021 11:21:03 +0200 Subject: [11u] RFR (XS) 8265537: x86 version string truncated after JDK-8249672 11u backport In-Reply-To: References: <89e2926e-1ab7-785f-343e-d7d841de1fbb@redhat.com> Message-ID: Hi Aleksey, The change looks good to me. Cheers, Mario On Thu, Apr 22, 2021 at 8:16 AM Aleksey Shipilev wrote: > > On 4/20/21 7:23 PM, Aleksey Shipilev wrote: > > 11u-specific regression: > > https://bugs.openjdk.java.net/browse/JDK-8265537 > > > > See the details in the bug. > > > > 11u patch: > > > > diff -r 9846af5a0949 src/hotspot/cpu/x86/vm_version_x86.cpp > > --- a/src/hotspot/cpu/x86/vm_version_x86.cpp Mon Apr 19 12:47:46 2021 +0200 > > +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp Tue Apr 20 19:23:24 2021 +0200 > > @@ -743,11 +743,11 @@ > > if (is_knights_family()) { > > _features &= ~CPU_VZEROUPPER; > > } > > } > > > > - char buf[256]; > > + char buf[512]; > > jio_snprintf(buf, sizeof(buf), > > "(%u cores per cpu, %u threads per core) family %d model %d stepping %d microcode 0x%x" > > "%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s", > > cores_per_cpu(), threads_per_core(), > > cpu_family(), _model, _stepping, os::cpu_microcode_revision(), > > > > Testing: compiler/intrinsics/sha tests (now pass); tier1 > > Anyone? > > -- > Thanks, > -Aleksey > -- Mario Torre Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From yan at openjdk.java.net Thu Apr 22 09:22:33 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 22 Apr 2021 09:22:33 GMT Subject: [jdk13u-dev] Integrated: 8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:14:41 GMT, Yuri Nesterenko wrote: > This patch does change some code inside a condition clause in a test. Now, in jdk17 that condition (so, context for this fix) checks for linux only but in jdk13 it checks also for solaris. Other than that, patch goes clean. This pull request has now been integrated. Changeset: 6389acfa Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/6389acfa Stats: 33 lines in 2 files changed: 10 ins; 0 del; 23 mod 8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32 Reviewed-by: dcherepanov Backport-of: 79a4a019bba1c99bef2377fe88f1464943530a55 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/188 From shade at redhat.com Thu Apr 22 09:23:52 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 11:23:52 +0200 Subject: [11u] RFR (XS) 8265537: x86 version string truncated after JDK-8249672 11u backport In-Reply-To: References: <89e2926e-1ab7-785f-343e-d7d841de1fbb@redhat.com> Message-ID: <79e8b9e9-133f-e6d7-4944-632c75abacac@redhat.com> On 4/22/21 11:21 AM, Mario Torre wrote: > The change looks good to me. Thanks, I tagged it for approvals. -- -Aleksey From shade at redhat.com Thu Apr 22 09:32:58 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 11:32:58 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> Message-ID: On 4/22/21 11:19 AM, Doerr, Martin wrote: > Hi, > > it did not only break the debug build. > > We have seen a crash on Windows: > # Internal Error (./src/hotspot/share/runtime/safepoint.cpp:894), pid=11412, tid=12932 > # fatal error: Deadlock in safepoint code. Should have called back to the VM before blocking. > > V [jvm.dll+0x247c64] report_fatal+0x64 (debug.cpp:268) > V [jvm.dll+0x65e30b] SafepointSynchronize::block+0x14b (safepoint.cpp:893) > V [jvm.dll+0x101d44] SafepointMechanism::block_if_requested+0x34 (safepointmechanism.inline.hpp:73) > V [jvm.dll+0x6f0d9a] JavaThread::check_safepoint_and_suspend_for_native_trans+0xca (thread.cpp:2508) > V [jvm.dll+0x5e3175] ObjectSampleCheckpoint::on_rotation+0xa5 (objectsamplecheckpoint.cpp:301) > V [jvm.dll+0x397694] JfrRecorderService::pre_safepoint_write+0x64 (jfrrecorderservice.cpp:428) > V [jvm.dll+0x3978a4] JfrRecorderService::rotate+0x194 (jfrrecorderservice.cpp:325) > V [jvm.dll+0x398324] recorderthread_entry+0xd4 (jfrrecorderthreadloop.cpp:76) > V [jvm.dll+0x6f7649] JavaThread::run+0x139 (thread.cpp:1840) > V [jvm.dll+0x6f06b4] Thread::call_run+0x84 (thread.cpp:391) > V [jvm.dll+0x5f8e36] thread_native_entry+0xd6 (os_windows.cpp:460) > > Test: > jdk/jfr/startupargs/TestOldObjectQueueSize.java Even on Linux, there are lots of jdk_jfr test failures: TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/jdk/jfr 441 387 54 0 << Mostly failing like this: # Internal Error (/home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:298), pid=2199952, tid=2200076 # assert(SafepointSynchronize::is_at_safepoint()) failed: must be at safepoint! Stack: [0x00007f7cbd920000,0x00007f7cbda21000], sp=0x00007f7cbda1f700, free space=1021k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1b836c7] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x397 V [libjvm.so+0x1b845e5] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x35 V [libjvm.so+0xc3d7aa] report_vm_error(char const*, int, char const*, char const*, ...)+0x10a V [libjvm.so+0x1645973] ObjectSampleCheckpoint::on_rotation(ObjectSampler const*)+0x893 V [libjvm.so+0x1093c45] JfrRecorderService::pre_safepoint_write()+0x255 V [libjvm.so+0x1093e9c] JfrRecorderService::write()+0xcc V [libjvm.so+0x1094242] JfrRecorderService::finalize_current_chunk()+0x22 V [libjvm.so+0x10948b0] JfrRecorderService::rotate(int)+0x370 V [libjvm.so+0x1096492] recorderthread_entry(JavaThread*, Thread*)+0x162 V [libjvm.so+0x1ab7d92] JavaThread::thread_main_inner()+0x252 V [libjvm.so+0x1ab0e8b] Thread::call_run()+0x7b V [libjvm.so+0x1694806] thread_native_entry(Thread*)+0x116 David, Jaroslav, you have to run the targeted subsystem tests when doing a backport like this! -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Thu Apr 22 09:37:17 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Thu, 22 Apr 2021 11:37:17 +0200 Subject: [11u] RFR: 8213483: ARM32: runtime/ErrorHandling/ShowRegistersOnAssertTest.java jtreg test fail Message-ID: <3833xmuen6-1@aserp2020.oracle.com> Hi, please review this backport of JDK-8213483 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8213483 Original commit: https://git.openjdk.java.net/jdk/commit/bca9e55b Webrev: https://cr.openjdk.java.net/~cgo/8213483/webrev.11u.00/ The patch doesn't apply cleanly because of a different copyright year. This removes the hardware breakpoints defined for windows and 32-bit arm. The test case runtime/ErrorHandling/ShowRegistersOnAssertTest.java fails because it intentionally hits the BREAKPOINT macro, and since it is a hardware breakpoint on these platforms, the test case fails. Because it is a tier1 test, I think it is more important to have the test pass, than to have the hardware breakpoint available, which might make it easier to debug certain problems, but can always be added by the developer if needed. The commit is also marked to solve 8253167 (https://bugs.openjdk.java.net/browse/JDK-8253167) as well, but this is not a problem in 11u. Should I, if the review is OK and I can tag for approval, tag both bugs and wait for the approval of both? Thanks, Christoph From shade at redhat.com Thu Apr 22 09:50:13 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 11:50:13 +0200 Subject: [11u] RFR: 8213483: ARM32: runtime/ErrorHandling/ShowRegistersOnAssertTest.java jtreg test fail In-Reply-To: <3833xmuen6-1@aserp2020.oracle.com> References: <3833xmuen6-1@aserp2020.oracle.com> Message-ID: Hi, On 4/22/21 11:37 AM, Christoph G?ttschkes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8213483 > Original commit: https://git.openjdk.java.net/jdk/commit/bca9e55b > > Webrev: https://cr.openjdk.java.net/~cgo/8213483/webrev.11u.00/ It was on my plate to backport, so I am glad to see you handling this :) This looks good, with one minor nit: src/hotspot/share/utilities/breakpoint.hpp changes the copyright year to 2020, your webrev should follow suit. In other words, do not change the copyright header beyond what the patch does. > Because it is a tier1 test, I think it is more important to have the test > pass, than to have the hardware breakpoint available, which might make it easier > to debug certain problems, but can always be added by the developer if needed. > > The commit is also marked to solve 8253167 (https://bugs.openjdk.java.net/browse/JDK-8253167) as well, > but this is not a problem in 11u. Should I, if the review is OK and I can tag for approval, > tag both bugs and wait for the approval of both? Yes, that is the way, I think. Mention that in fix request, something along the lines of "This bug does not technically affect 11u yet, but the changeset for JDK-8213483 backport mentions it. Marking for 11u approval too." -- Thanks, -Aleksey From pkumaraswamy at openjdk.java.net Thu Apr 22 09:52:48 2021 From: pkumaraswamy at openjdk.java.net (Prajwal Kumaraswamy) Date: Thu, 22 Apr 2021 09:52:48 GMT Subject: [jdk16u] RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 Message-ID: <_Ap_VBdGcovzGbN_yjsZq1FIva4C_EpRRueinAiEcKI=.ae47f878-da45-483a-9056-1d0dc8020a28@github.com> This is a clean back port of JDK-8023980 ------------- Commit messages: - Backport 68cf65d284a73f5c5229d30ca642bba9585095f3 Changes: https://git.openjdk.java.net/jdk16u/pull/108/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=108&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8023980 Stats: 462 lines in 6 files changed: 303 ins; 55 del; 104 mod Patch: https://git.openjdk.java.net/jdk16u/pull/108.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/108/head:pull/108 PR: https://git.openjdk.java.net/jdk16u/pull/108 From shade at redhat.com Thu Apr 22 10:06:58 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 12:06:58 +0200 Subject: [11u] RFR (XS) 8265537: x86 version string truncated after JDK-8249672 11u backport In-Reply-To: <89e2926e-1ab7-785f-343e-d7d841de1fbb@redhat.com> References: <89e2926e-1ab7-785f-343e-d7d841de1fbb@redhat.com> Message-ID: <076c6acd-c7cb-2d56-a978-887409ade166@redhat.com> On 4/20/21 7:23 PM, Aleksey Shipilev wrote: > 11u-specific regression: > https://bugs.openjdk.java.net/browse/JDK-8265537 > > See the details in the bug. > > 11u patch: > > diff -r 9846af5a0949 src/hotspot/cpu/x86/vm_version_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_x86.cpp Mon Apr 19 12:47:46 2021 +0200 > +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp Tue Apr 20 19:23:24 2021 +0200 > @@ -743,11 +743,11 @@ > if (is_knights_family()) { > _features &= ~CPU_VZEROUPPER; > } > } > > - char buf[256]; > + char buf[512]; > jio_snprintf(buf, sizeof(buf), > "(%u cores per cpu, %u threads per core) family %d model %d stepping %d microcode 0x%x" > "%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s", > cores_per_cpu(), threads_per_core(), > cpu_family(), _model, _stepping, os::cpu_microcode_revision(), > > Testing: compiler/intrinsics/sha tests (now pass); tier1 Goetz, (since you were the author of that 11u backport,) you are fine with this patch, right? -- Thanks, -Aleksey From shade at redhat.com Thu Apr 22 10:08:52 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 12:08:52 +0200 Subject: [11u] RFR: 8213483: ARM32: runtime/ErrorHandling/ShowRegistersOnAssertTest.java jtreg test fail In-Reply-To: <30773.121042206070200201@us-mta-1.us.mimecast.lan> References: <3833xmuen6-1@aserp2020.oracle.com> <30773.121042206070200201@us-mta-1.us.mimecast.lan> Message-ID: <21c1d9b8-e360-bd77-eacc-842f7f3acc52@redhat.com> On 4/22/21 12:05 PM, Christoph G?ttschkes wrote: > Thanks for the information. Fixed: > https://cr.openjdk.java.net/~cgo/8213483/webrev.11u.01/ Looks fine. -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Thu Apr 22 10:05:27 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Thu, 22 Apr 2021 12:05:27 +0200 Subject: [11u] RFR: 8213483: ARM32: runtime/ErrorHandling/ShowRegistersOnAssertTest.java jtreg test fail In-Reply-To: References: <3833xmuen6-1@aserp2020.oracle.com> Message-ID: <3833xmv54t-1@aserp2020.oracle.com> Thanks for the review. On 4/22/21 11:50 AM, Aleksey Shipilev wrote: > Hi, > > On 4/22/21 11:37 AM, Christoph G?ttschkes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213483 >> Original commit: https://git.openjdk.java.net/jdk/commit/bca9e55b >> >> Webrev: https://cr.openjdk.java.net/~cgo/8213483/webrev.11u.00/ > > It was on my plate to backport, so I am glad to see you handling this :) > > This looks good, with one minor nit: src/hotspot/share/utilities/breakpoint.hpp changes the copyright year to 2020, your webrev should follow suit. In other words, do not change the copyright header beyond what the patch does. Thanks for the information. Fixed: https://cr.openjdk.java.net/~cgo/8213483/webrev.11u.01/ > >> Because it is a tier1 test, I think it is more important to have the test >> pass, than to have the hardware breakpoint available, which might make iteasier >> to debug certain problems, but can always be added by the developer if needed. >> >> The commit is also marked to solve 8253167 (https://bugs.openjdk.java.net/browse/JDK-8253167) as well, >> but this is not a problem in 11u. Should I, if the review is OK and I cantag for approval, >> tag both bugs and wait for the approval of both? > > Yes, that is the way, I think. Mention that in fix request, something alongthe lines of "This bug does not technically affect 11u yet, but the changeset for JDK-8213483 backport mentions it. Marking for 11u approval too." > I will then tag for approval for both issues. Thanks, Christoph From yan at openjdk.java.net Thu Apr 22 09:16:34 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 22 Apr 2021 09:16:34 GMT Subject: [jdk13u-dev] Integrated: 8262110: DST starts from incorrect time in 2038 In-Reply-To: <5nJMXFZBqLLBo95hf1_M9enzpGDVAG-JlHS4BvsacAc=.4adc9f99-302b-4408-af1d-275e6847db32@github.com> References: <5nJMXFZBqLLBo95hf1_M9enzpGDVAG-JlHS4BvsacAc=.4adc9f99-302b-4408-af1d-275e6847db32@github.com> Message-ID: On Thu, 15 Apr 2021 14:48:22 GMT, Yuri Nesterenko wrote: > Old copyright year differs in 13u code! Other than that, no surprises. This pull request has now been integrated. Changeset: 3075cb06 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/3075cb06 Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod 8262110: DST starts from incorrect time in 2038 8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137 Reviewed-by: dcherepanov Backport-of: 7284f013ea3064b2aa643658938ccaafdfa1c885 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/183 From lutz.schmidt at sap.com Thu Apr 22 10:37:57 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 22 Apr 2021 10:37:57 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: <708D4864-3499-42A3-9EBA-18D6CB219DA3@sap.com> References: <5969F266-A269-4329-98D2-E8022EEDD5A7@amazon.com> <708D4864-3499-42A3-9EBA-18D6CB219DA3@sap.com> Message-ID: <2C964E5D-E880-446C-ADD0-8AACF31AEB70@sap.com> No builds last night for jdk11u-dev, as you have noticed yourself. We will have to wait till Friday. Best, Lutz ?On 21.04.21, 11:04, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Changes look good to me now. Version 2 of the patches applies clean, not even any fuzz. Diffs against OpenJDK head are only those which can't be avoided. The patches are queued to be tested overnight. Results expected Thursday morning. Local tests on my Mac revealed no issues. I'll report on the test status once available. Thanks, Lutz On 21.04.21, 00:49, "Hohensee, Paul" wrote: Yes, please, and also review. I've run tier1 and tier2 on linux-x64. -----Original Message----- From: "Schmidt, Lutz" Date: Tuesday, April 20, 2021 at 1:38 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods You want me to retest? No problem, but results will not be available before Thursday. Please let me know. Lutz On 20.04.21, 19:58, "Hohensee, Paul" wrote: You're right. Emacs fumble-finger. :( New set of 3 webrevs (8214526 dropped). https://cr.openjdk.java.net/~phh/8216314/webrev.11u.02/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.03/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.04/ -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 2:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Yes, that's in the #else path of #if defined(USE_BUFFEREDSTREAM). You have to look further up: +// Same as above, but with fixed buffer size. +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K); + #define STRINGSTREAM_FLUSH(termString) \ _sstbuf->print("%s", termString); \ _outbuf->print("%s", _sstbuf->as_string()); \ _sstbuf->reset(); +// Flush the buffer contents unconditionally. +// No action if the buffer is empty. +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ On 19.04.21, 22:44, "Hohensee, Paul" wrote: I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From thomas.stuefe at gmail.com Thu Apr 22 11:02:16 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Apr 2021 13:02:16 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> Message-ID: Opened Issue https://bugs.openjdk.java.net/browse/JDK-8265750 ...Thomas On Thu, Apr 22, 2021 at 11:35 AM Aleksey Shipilev wrote: > On 4/22/21 11:19 AM, Doerr, Martin wrote: > > Hi, > > > > it did not only break the debug build. > > > > We have seen a crash on Windows: > > # Internal Error (./src/hotspot/share/runtime/safepoint.cpp:894), > pid=11412, tid=12932 > > # fatal error: Deadlock in safepoint code. Should have called back to > the VM before blocking. > > > > V [jvm.dll+0x247c64] report_fatal+0x64 (debug.cpp:268) > > V [jvm.dll+0x65e30b] SafepointSynchronize::block+0x14b > (safepoint.cpp:893) > > V [jvm.dll+0x101d44] SafepointMechanism::block_if_requested+0x34 > (safepointmechanism.inline.hpp:73) > > V [jvm.dll+0x6f0d9a] > JavaThread::check_safepoint_and_suspend_for_native_trans+0xca > (thread.cpp:2508) > > V [jvm.dll+0x5e3175] ObjectSampleCheckpoint::on_rotation+0xa5 > (objectsamplecheckpoint.cpp:301) > > V [jvm.dll+0x397694] JfrRecorderService::pre_safepoint_write+0x64 > (jfrrecorderservice.cpp:428) > > V [jvm.dll+0x3978a4] JfrRecorderService::rotate+0x194 > (jfrrecorderservice.cpp:325) > > V [jvm.dll+0x398324] recorderthread_entry+0xd4 > (jfrrecorderthreadloop.cpp:76) > > V [jvm.dll+0x6f7649] JavaThread::run+0x139 (thread.cpp:1840) > > V [jvm.dll+0x6f06b4] Thread::call_run+0x84 (thread.cpp:391) > > V [jvm.dll+0x5f8e36] thread_native_entry+0xd6 (os_windows.cpp:460) > > > > Test: > > jdk/jfr/startupargs/TestOldObjectQueueSize.java > > Even on Linux, there are lots of jdk_jfr test failures: > > TEST TOTAL PASS FAIL > ERROR > >> jtreg:test/jdk/jdk/jfr 441 387 54 > 0 << > > > Mostly failing like this: > > # Internal Error > (/home/shade/trunks/jdk-updates-jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:298), > > pid=2199952, tid=2200076 > # assert(SafepointSynchronize::is_at_safepoint()) failed: must be at > safepoint! > > Stack: [0x00007f7cbd920000,0x00007f7cbda21000], sp=0x00007f7cbda1f700, > free space=1021k > Native frames: (J=compiled Java code, A=aot compiled Java code, > j=interpreted, Vv=VM code, C=native > code) > V [libjvm.so+0x1b836c7] VMError::report_and_die(int, char const*, char > const*, __va_list_tag*, > Thread*, unsigned char*, void*, void*, char const*, int, unsigned > long)+0x397 > V [libjvm.so+0x1b845e5] VMError::report_and_die(Thread*, void*, char > const*, int, char const*, > char const*, __va_list_tag*)+0x35 > V [libjvm.so+0xc3d7aa] report_vm_error(char const*, int, char const*, > char const*, ...)+0x10a > V [libjvm.so+0x1645973] > ObjectSampleCheckpoint::on_rotation(ObjectSampler const*)+0x893 > V [libjvm.so+0x1093c45] JfrRecorderService::pre_safepoint_write()+0x255 > V [libjvm.so+0x1093e9c] JfrRecorderService::write()+0xcc > V [libjvm.so+0x1094242] JfrRecorderService::finalize_current_chunk()+0x22 > V [libjvm.so+0x10948b0] JfrRecorderService::rotate(int)+0x370 > V [libjvm.so+0x1096492] recorderthread_entry(JavaThread*, Thread*)+0x162 > V [libjvm.so+0x1ab7d92] JavaThread::thread_main_inner()+0x252 > V [libjvm.so+0x1ab0e8b] Thread::call_run()+0x7b > V [libjvm.so+0x1694806] thread_native_entry(Thread*)+0x116 > > > David, Jaroslav, you have to run the targeted subsystem tests when doing a > backport like this! > > -- > Thanks, > -Aleksey > > From christoph.langer at sap.com Thu Apr 22 11:12:11 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 22 Apr 2021 11:12:11 +0000 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> Message-ID: Hi, it appears as if this backport wasn't tested properly. We should take care that something like that doesn't happen too often... Maybe for now it would be most appropriate to back it out and redo it later when the problems are understood/fixed? Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Thomas St?fe > Sent: Donnerstag, 22. April 2021 13:02 > To: Aleksey Shipilev > Cc: Doerr, Martin ; Hohensee, Paul > ; Jaroslav Bachor?k > ; Florian David > ; jdk-updates-dev dev at openjdk.java.net>; Marcus Hirt > Subject: Re: [11u] RFR: 8258414: OldObjectSample events too expensive > > Opened Issue https://bugs.openjdk.java.net/browse/JDK-8265750 > > ...Thomas > > On Thu, Apr 22, 2021 at 11:35 AM Aleksey Shipilev > wrote: > > > On 4/22/21 11:19 AM, Doerr, Martin wrote: > > > Hi, > > > > > > it did not only break the debug build. > > > > > > We have seen a crash on Windows: > > > # Internal Error (./src/hotspot/share/runtime/safepoint.cpp:894), > > pid=11412, tid=12932 > > > # fatal error: Deadlock in safepoint code. Should have called back to > > the VM before blocking. > > > > > > V [jvm.dll+0x247c64] report_fatal+0x64 (debug.cpp:268) > > > V [jvm.dll+0x65e30b] SafepointSynchronize::block+0x14b > > (safepoint.cpp:893) > > > V [jvm.dll+0x101d44] SafepointMechanism::block_if_requested+0x34 > > (safepointmechanism.inline.hpp:73) > > > V [jvm.dll+0x6f0d9a] > > JavaThread::check_safepoint_and_suspend_for_native_trans+0xca > > (thread.cpp:2508) > > > V [jvm.dll+0x5e3175] ObjectSampleCheckpoint::on_rotation+0xa5 > > (objectsamplecheckpoint.cpp:301) > > > V [jvm.dll+0x397694] JfrRecorderService::pre_safepoint_write+0x64 > > (jfrrecorderservice.cpp:428) > > > V [jvm.dll+0x3978a4] JfrRecorderService::rotate+0x194 > > (jfrrecorderservice.cpp:325) > > > V [jvm.dll+0x398324] recorderthread_entry+0xd4 > > (jfrrecorderthreadloop.cpp:76) > > > V [jvm.dll+0x6f7649] JavaThread::run+0x139 (thread.cpp:1840) > > > V [jvm.dll+0x6f06b4] Thread::call_run+0x84 (thread.cpp:391) > > > V [jvm.dll+0x5f8e36] thread_native_entry+0xd6 (os_windows.cpp:460) > > > > > > Test: > > > jdk/jfr/startupargs/TestOldObjectQueueSize.java > > > > Even on Linux, there are lots of jdk_jfr test failures: > > > > TEST TOTAL PASS FAIL > > ERROR > > >> jtreg:test/jdk/jdk/jfr 441 387 54 > > 0 << > > > > > > Mostly failing like this: > > > > # Internal Error > > (/home/shade/trunks/jdk-updates-jdk11u- > dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint > .cpp:298), > > > > pid=2199952, tid=2200076 > > # assert(SafepointSynchronize::is_at_safepoint()) failed: must be at > > safepoint! > > > > Stack: [0x00007f7cbd920000,0x00007f7cbda21000], > sp=0x00007f7cbda1f700, > > free space=1021k > > Native frames: (J=compiled Java code, A=aot compiled Java code, > > j=interpreted, Vv=VM code, C=native > > code) > > V [libjvm.so+0x1b836c7] VMError::report_and_die(int, char const*, char > > const*, __va_list_tag*, > > Thread*, unsigned char*, void*, void*, char const*, int, unsigned > > long)+0x397 > > V [libjvm.so+0x1b845e5] VMError::report_and_die(Thread*, void*, char > > const*, int, char const*, > > char const*, __va_list_tag*)+0x35 > > V [libjvm.so+0xc3d7aa] report_vm_error(char const*, int, char const*, > > char const*, ...)+0x10a > > V [libjvm.so+0x1645973] > > ObjectSampleCheckpoint::on_rotation(ObjectSampler const*)+0x893 > > V [libjvm.so+0x1093c45] JfrRecorderService::pre_safepoint_write()+0x255 > > V [libjvm.so+0x1093e9c] JfrRecorderService::write()+0xcc > > V [libjvm.so+0x1094242] > JfrRecorderService::finalize_current_chunk()+0x22 > > V [libjvm.so+0x10948b0] JfrRecorderService::rotate(int)+0x370 > > V [libjvm.so+0x1096492] recorderthread_entry(JavaThread*, > Thread*)+0x162 > > V [libjvm.so+0x1ab7d92] JavaThread::thread_main_inner()+0x252 > > V [libjvm.so+0x1ab0e8b] Thread::call_run()+0x7b > > V [libjvm.so+0x1694806] thread_native_entry(Thread*)+0x116 > > > > > > David, Jaroslav, you have to run the targeted subsystem tests when doing a > > backport like this! > > > > -- > > Thanks, > > -Aleksey > > > > From christoph.langer at sap.com Thu Apr 22 11:13:52 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 22 Apr 2021 11:13:52 +0000 Subject: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample events too expensive) In-Reply-To: References: <2a8e696b-98e1-87de-e882-9f4a0ba84121@redhat.com> Message-ID: Yes, we should set up GHA shortly after moving 11u over to Github to give contributors with a less extensive testsuite a better possibility to verify their changes. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Thomas St?fe > Sent: Donnerstag, 22. April 2021 08:54 > To: Aleksey Shipilev > Cc: Hohensee, Paul ; Jaroslav Bachor?k > ; Florian David > ; jdk-updates-dev dev at openjdk.java.net>; Marcus Hirt > Subject: Re: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample > events too expensive) > > Sounds reasonable. > > Thanks, Thomas > > On Thu, Apr 22, 2021, 08:19 Aleksey Shipilev wrote: > > > On 4/22/21 7:19 AM, Thomas St?fe wrote: > > > What do you think? > > > > I think the move to Skara would give us GHA, which would run the tests we > > want. > > In the meantime, the minimal bar for testing should be x86_64 > > {release,fastdebug} tier1. > > > > BTW, I filed this for 11u build failure: > > https://bugs.openjdk.java.net/browse/JDK-8265718 > > > > -- > > Thanks, > > -Aleksey > > > > From shade at redhat.com Thu Apr 22 12:19:11 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Apr 2021 14:19:11 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> Message-ID: <8fe619f6-5e1b-104d-9865-9ad2c8951ac1@redhat.com> On 4/22/21 1:12 PM, Langer, Christoph wrote: > Maybe for now it would be most appropriate to back it out and redo it later when the problems are understood/fixed? Yes, I'd vote for reversal to get 11u back to sane state. -- Thanks, -Aleksey From pkumaraswamy at openjdk.java.net Thu Apr 22 13:19:24 2021 From: pkumaraswamy at openjdk.java.net (Prajwal Kumaraswamy) Date: Thu, 22 Apr 2021 13:19:24 GMT Subject: [jdk16u] Integrated: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 In-Reply-To: <_Ap_VBdGcovzGbN_yjsZq1FIva4C_EpRRueinAiEcKI=.ae47f878-da45-483a-9056-1d0dc8020a28@github.com> References: <_Ap_VBdGcovzGbN_yjsZq1FIva4C_EpRRueinAiEcKI=.ae47f878-da45-483a-9056-1d0dc8020a28@github.com> Message-ID: <8N17jsnumVCpajr4VgvIn0gQ24cKMQPnM9_ouKZy91k=.d5050236-5b0c-4005-925e-c0f890a45a11@github.com> On Thu, 22 Apr 2021 09:42:07 GMT, Prajwal Kumaraswamy wrote: > This is a clean back port of JDK-8023980 This pull request has now been integrated. Changeset: cce99e57 Author: Prajwal Kumaraswamy Committer: Rob McKenna URL: https://git.openjdk.java.net/jdk16u/commit/cce99e57 Stats: 462 lines in 6 files changed: 303 ins; 55 del; 104 mod 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 Backport-of: 68cf65d284a73f5c5229d30ca642bba9585095f3 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/108 From dmitry.chuyko at bell-sw.com Thu Apr 22 14:19:46 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 22 Apr 2021 17:19:46 +0300 Subject: [11u] RFR (S) 8255625: AArch64: Implement Base64.encodeBlock accelerator/intrinsic Message-ID: <28ff66de-e321-9a5d-c380-05441e5efdf7@bell-sw.com> Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8255625 The patch does not apply cleanly: corrected fuzz, adjusted small part to missing context in stubGenerator_aarch64.cpp (JDK-8224974 is not in 11u). Resulting patch was formatted for 11u. CheckGraalIntrinsics test already has this intrinsic. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8255625/webrev.11u.00/ Testing: test/jdk/java/util/Base64, tier1, tier2. -- Thanks, -Dmitry From richard.reingruber at sap.com Thu Apr 22 14:28:19 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 22 Apr 2021 14:28:19 +0000 Subject: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier In-Reply-To: References: Message-ID: Thanks for reviewing! > Putting an unconditional storestore barrier in dirty_MemRegion might be a > better fix since it will catch everything, not just arrays. But, that's not in > tip, so lgtm. I thought about this too. My conclusion was that the only additional execution path that might require a barrier was the following: CardTable::dirty_MemRegion(MemRegion) : void CardTable::invalidate(MemRegion) : void CardGeneration::invalidate_remembered_set() : void CardTableBarrierSet::invalidate(MemRegion) : void CardTableBarrierSet::on_slowpath_allocation_exit(JavaThread *, oop) : void CardTableBarrierSet::write_region(MemRegion) : void CardTableBarrierSet::flush_deferred_card_mark_barrier(JavaThread *) : void And then I assumed that the transition _thread_in_Java to _thread_in_vm would do the necessary ordering. But looking again I think it does not. So maybe a should just do as you suggested? dirty_MemRegion doesn't seem to be on any hot execution path. Thanks, Richard. -----Original Message----- From: Hohensee, Paul Sent: Mittwoch, 21. April 2021 19:25 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier Putting an unconditional storestore barrier in dirty_MemRegion might be a better fix since it will catch everything, not just arrays. But, that's not in tip, so lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Reingruber, Richard" Date: Wednesday, April 21, 2021 at 7:32 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier // Resend after removing incorrect link Hi, please review this XXS fix for 11u which adds a storestore barrier to `CardTableBarrierSet::write_ref_array_work(MemRegion mr)`. The barrier is only executed if CMS is selected. Please refer to the bug report for more details. Bug: https://bugs.openjdk.java.net/browse/JDK-8265677 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8265677_11u_CMS__CardTableBarrierSet__write_ref_array_work___lacks_storestore_barrier/webrev.0/ Testing: make run-test-tier1 JTREG="VM_OPTIONS=-XX:+UseConcMarkSweepGC" CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From hohensee at amazon.com Thu Apr 22 15:18:49 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 22 Apr 2021 15:18:49 +0000 Subject: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier Message-ID: <98941A1C-E9CC-4FAD-A6ED-B15D23AD5376@amazon.com> Let's leave it alone since it's not in tip. Maybe someone will look into it there. Also, I see you have 11u approval already. :) I looked at 8u too, but it doesn't have scanned_concurrently() so it could only be done in dirty_MemRegion. Thanks, Paul ?-----Original Message----- From: "Reingruber, Richard" Date: Thursday, April 22, 2021 at 7:29 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier Thanks for reviewing! > Putting an unconditional storestore barrier in dirty_MemRegion might be a > better fix since it will catch everything, not just arrays. But, that's not in > tip, so lgtm. I thought about this too. My conclusion was that the only additional execution path that might require a barrier was the following: CardTable::dirty_MemRegion(MemRegion) : void CardTable::invalidate(MemRegion) : void CardGeneration::invalidate_remembered_set() : void CardTableBarrierSet::invalidate(MemRegion) : void CardTableBarrierSet::on_slowpath_allocation_exit(JavaThread *, oop) : void CardTableBarrierSet::write_region(MemRegion) : void CardTableBarrierSet::flush_deferred_card_mark_barrier(JavaThread *) : void And then I assumed that the transition _thread_in_Java to _thread_in_vm would do the necessary ordering. But looking again I think it does not. So maybe a should just do as you suggested? dirty_MemRegion doesn't seem to be on any hot execution path. Thanks, Richard. -----Original Message----- From: Hohensee, Paul Sent: Mittwoch, 21. April 2021 19:25 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier Putting an unconditional storestore barrier in dirty_MemRegion might be a better fix since it will catch everything, not just arrays. But, that's not in tip, so lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Reingruber, Richard" Date: Wednesday, April 21, 2021 at 7:32 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier // Resend after removing incorrect link Hi, please review this XXS fix for 11u which adds a storestore barrier to `CardTableBarrierSet::write_ref_array_work(MemRegion mr)`. The barrier is only executed if CMS is selected. Please refer to the bug report for more details. Bug: https://bugs.openjdk.java.net/browse/JDK-8265677 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8265677_11u_CMS__CardTableBarrierSet__write_ref_array_work___lacks_storestore_barrier/webrev.0/ Testing: make run-test-tier1 JTREG="VM_OPTIONS=-XX:+UseConcMarkSweepGC" CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From richard.reingruber at sap.com Thu Apr 22 20:17:44 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 22 Apr 2021 20:17:44 +0000 Subject: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier In-Reply-To: <98941A1C-E9CC-4FAD-A6ED-B15D23AD5376@amazon.com> References: <98941A1C-E9CC-4FAD-A6ED-B15D23AD5376@amazon.com> Message-ID: > Let's leave it alone since it's not in tip. Maybe someone will look into it > there. Also, I see you have 11u approval already. :) Ok, sure. > I looked at 8u too, but it doesn't have scanned_concurrently() so it could > only be done in dirty_MemRegion. Right. I guess it is pretty unlikely but it can crash the vm. More likely if no arraycopy stubs are generated. We've found it (depressingly ;)) long ago doing ports for which we used the default copy routines in the runtime. Thanks, Richard. -----Original Message----- From: Hohensee, Paul Sent: Donnerstag, 22. April 2021 17:19 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: Re: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier Let's leave it alone since it's not in tip. Maybe someone will look into it there. Also, I see you have 11u approval already. :) I looked at 8u too, but it doesn't have scanned_concurrently() so it could only be done in dirty_MemRegion. Thanks, Paul ?-----Original Message----- From: "Reingruber, Richard" Date: Thursday, April 22, 2021 at 7:29 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier Thanks for reviewing! > Putting an unconditional storestore barrier in dirty_MemRegion might be a > better fix since it will catch everything, not just arrays. But, that's not in > tip, so lgtm. I thought about this too. My conclusion was that the only additional execution path that might require a barrier was the following: CardTable::dirty_MemRegion(MemRegion) : void CardTable::invalidate(MemRegion) : void CardGeneration::invalidate_remembered_set() : void CardTableBarrierSet::invalidate(MemRegion) : void CardTableBarrierSet::on_slowpath_allocation_exit(JavaThread *, oop) : void CardTableBarrierSet::write_region(MemRegion) : void CardTableBarrierSet::flush_deferred_card_mark_barrier(JavaThread *) : void And then I assumed that the transition _thread_in_Java to _thread_in_vm would do the necessary ordering. But looking again I think it does not. So maybe a should just do as you suggested? dirty_MemRegion doesn't seem to be on any hot execution path. Thanks, Richard. -----Original Message----- From: Hohensee, Paul Sent: Mittwoch, 21. April 2021 19:25 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier Putting an unconditional storestore barrier in dirty_MemRegion might be a better fix since it will catch everything, not just arrays. But, that's not in tip, so lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Reingruber, Richard" Date: Wednesday, April 21, 2021 at 7:32 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8265677: CMS: CardTableBarrierSet::write_ref_array_work() lacks storestore barrier // Resend after removing incorrect link Hi, please review this XXS fix for 11u which adds a storestore barrier to `CardTableBarrierSet::write_ref_array_work(MemRegion mr)`. The barrier is only executed if CMS is selected. Please refer to the bug report for more details. Bug: https://bugs.openjdk.java.net/browse/JDK-8265677 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8265677_11u_CMS__CardTableBarrierSet__write_ref_array_work___lacks_storestore_barrier/webrev.0/ Testing: make run-test-tier1 JTREG="VM_OPTIONS=-XX:+UseConcMarkSweepGC" CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From richard.reingruber at sap.com Thu Apr 22 20:54:21 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 22 Apr 2021 20:54:21 +0000 Subject: [11u] RFR 8262295: C2: Out-of-Bounds Array Load from Clone Source In-Reply-To: <74b89e0d-6dda-6ee5-4c79-dfa45be8b116@oracle.com> References: <74b89e0d-6dda-6ee5-4c79-dfa45be8b116@oracle.com> Message-ID: Thanks for the confirmation, Vladimir. And sorry for having been a bit hasty with the push. Richard. -----Original Message----- From: jdk-updates-dev On Behalf Of Vladimir Kozlov Sent: Mittwoch, 21. April 2021 20:29 To: jdk-updates-dev at openjdk.java.net Subject: Re: [11u] RFR 8262295: C2: Out-of-Bounds Array Load from Clone Source Good. Matches our backport. Thanks, Vladimir K On 4/20/21 6:54 AM, Reingruber, Richard wrote: > Hi, > > Please help review this backport of JDK-8262295 to 11u. > The fix itself applies cleanly. > Just the test required trivial adaptation. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8262295 > https://git.openjdk.java.net/jdk/commit/9689863a > > 11u webrev: > http://cr.openjdk.java.net/~rrich/webrevs/8262295_11u_C2_Out_of_Bounds_Array_Load_from_Clone_Source/webrev.0/ > > Adaptations: > > I had to remove the package from the class ClassFileInstaller in the included > test TestOutOfBoundsArrayLoad.java > > Testing: > > CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms > > Thanks, Richard. > From kemperw at amazon.com Thu Apr 22 23:27:54 2021 From: kemperw at amazon.com (Kemper, William) Date: Thu, 22 Apr 2021 23:27:54 +0000 Subject: [11u] RFR 8246274 and 8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC Message-ID: <1619134073992.60757@amazon.com> This fix went in originally as two changes, so there are two backports. Original bug: https://bugs.openjdk.java.net/browse/JDK-8245511 https://hg.openjdk.java.net/jdk/jdk/rev/d2eafcf20079 Depends on: https://bugs.openjdk.java.net/browse/JDK-8246274 https://hg.openjdk.java.net/jdk/jdk/rev/69c5e17adacd Patches applied cleanly. 11u webrev: https://cr.openjdk.java.net/~phh/8245511/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8246274/webrev.11u.01/? Testing: x86_64 build, tier1, tier1_gc, tier2 Thank you, William From vkempik at azul.com Fri Apr 23 07:34:47 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 23 Apr 2021 07:34:47 +0000 Subject: [11u] RFR: jnf_removal, series of patches In-Reply-To: <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com> References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com> Message-ID: Hello can I get a review for this please? or if current format of webrev is not good - a suggestion for improving it. Thanks in advance, Valdimir. > 16 ???. 2021 ?., ? 15:43, Vladimir Kempik ???????(?): > > Tier2 testing is good as well. > >> 16 ???. 2021 ?., ? 15:12, Vladimir Kempik ???????(?): >> >> The collated webrev: >> http://cr.openjdk.java.net/~vkempik/jnf_removal/webrev.01/ >> >> Testing - tier1, will soon update on tier2. >> >>> 16 ???. 2021 ?., ? 14:39, Vladimir Kempik ???????(?): >>> >>> Hello >>> Please review this backport of 11 patches from jdk17 to jdk11, they remove dependendy on JavaNativeFoundation.framework on macos >>> It?s 7 original patches fo jnf removal and 4 postmortem items to fix bugs. >>> I have created one collated webrev for 11 changesets, please let me know if it?s not the best way to do it. >>> Brief summary for backports: >>> 1_8257858 & 8257860 - Applies almost clean, few gmk files had different filename and few copyright year issues, context difference in gmk files. >>> 2_8257853 - Not clean, most of issues were in CPrinterJob and JavaAccessibility due to changes in jdk12+. Rest was mostly context code difference. >>> 3_8259343 - Clean, only gmk files renames were needed >>> 4_8259651 - Not clean, have to remove some changes to parts which are missing in jdk11: CMenuBar: ActivateDefaultMenuBar, Accessebility: titleChanged, getMultiClickTime >>> 5_8259869 - Almost Clean, slight Context code difference in CGLLayer.h >>> 6_8260616 & 8259729 - not clean, Missing CommonTextAccessibility.m in jdk11. Some Context code difference. Two changes in one patch to not break the build >>> 7_8257988 - Clean >>> 8_8259232 - clean >>> 9_8259585 - clean >>> 10_8261198 - Clean >>> 11_8263846 - clean >>> >>> So I need review for patches #1 #2 #4 #5 #6 and maybe (not sure) #3 >>> >>> #1 the bug - https://bugs.openjdk.java.net/browse/JDK-8257858 >>> Original changeset - https://github.com/openjdk/jdk/commit/4a8b5c16 >>> >>> #2 the bug - https://bugs.openjdk.java.net/browse/JDK-8257853 >>> Original changeset - https://github.com/openjdk/jdk/commit/fa50877c >>> >>> #3 the bug - https://bugs.openjdk.java.net/browse/JDK-8259343 >>> Original changeset - https://git.openjdk.java.net/jdk/commit/d6a2105b >>> >>> #4 the bug - https://bugs.openjdk.java.net/browse/JDK-8259651 >>> Original changeset - https://github.com/openjdk/jdk/commit/5855d52a >>> >>> #5 the bug - https://bugs.openjdk.java.net/browse/JDK-8259869 >>> Original changeset - https://github.com/openjdk/jdk/commit/92c2f084 >>> >>> #6 the bug - https://bugs.openjdk.java.net/browse/JDK-8260616 >>> Original changeset - https://github.com/openjdk/jdk/commit/8760688d >>> >>> Regards, Vladimir >>> >> > From thomas.stuefe at gmail.com Fri Apr 23 08:07:11 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Apr 2021 10:07:11 +0200 Subject: [11u] RFR: 8260926: Trace resource exhausted events unconditionally Message-ID: Hi all, may I please have eyes on this trivial backport. The trace line is useful to us especially in CloudFoundry scenarios when the jvmkill agent reacts on the jvmti resource exhausted event and then often just kills the VM without a trace. The patch had to be changed for 11u (nullptr -> NULL). Issue: https://bugs.openjdk.java.net/browse/JDK-8260926 Original Patch: https://github.com/openjdk/jdk/commit/ee2f2055 11u Patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260926-trace-resource-exhausted-events-unconditionally-11u Thanks! ..Thomas From shade at redhat.com Fri Apr 23 08:09:48 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 23 Apr 2021 10:09:48 +0200 Subject: [11u] RFR: 8260926: Trace resource exhausted events unconditionally In-Reply-To: References: Message-ID: On 4/23/21 10:07 AM, Thomas St?fe wrote: > Issue: https://bugs.openjdk.java.net/browse/JDK-8260926 > Original Patch: https://github.com/openjdk/jdk/commit/ee2f2055 > 11u Patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260926-trace-resource-exhausted-events-unconditionally-11u Looks fine. -- Thanks, -Aleksey From goetz.lindenmaier at sap.com Fri Apr 23 08:10:17 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 23 Apr 2021 08:10:17 +0000 Subject: [11u] RFR: 8260926: Trace resource exhausted events unconditionally In-Reply-To: References: Message-ID: Hi Thomas, The change looks good to me. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Thomas St?fe > Sent: Friday, April 23, 2021 10:07 AM > To: jdk-updates-dev > Subject: [11u] RFR: 8260926: Trace resource exhausted events > unconditionally > > Hi all, > > may I please have eyes on this trivial backport. The trace line is useful > to us especially in CloudFoundry scenarios when the jvmkill agent reacts on > the jvmti resource exhausted event and then often just kills the VM without > a trace. > > The patch had to be changed for 11u (nullptr -> NULL). > > Issue: https://bugs.openjdk.java.net/browse/JDK-8260926 > Original Patch: https://github.com/openjdk/jdk/commit/ee2f2055 > 11u Patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260926-trace- > resource-exhausted-events-unconditionally-11u > > Thanks! > > ..Thomas From thomas.stuefe at gmail.com Fri Apr 23 08:12:11 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Apr 2021 10:12:11 +0200 Subject: [11u] RFR: 8262163: Extend settings printout in jcmd VM.metaspace Message-ID: Hi, may I please have reviews for this trivial backport. This just adds some useful small output lines to the VM.metaspace jcmd. Original issue: https://bugs.openjdk.java.net/browse/JDK-8262163 Original Patch: https://github.com/openjdk/jdk/commit/ea48a0bb.diff The original patch does not apply, the code moved. Also, "MetaspaceReclaimPolicy" does not exist in JDK 11 (came with JEP 387). 11u Patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8262163-extend-settings-printout-in-jcmd-VM.metaspace-11u.diff Thank you, Thomas From thomas.stuefe at gmail.com Fri Apr 23 08:12:26 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Apr 2021 10:12:26 +0200 Subject: [11u] RFR: 8260926: Trace resource exhausted events unconditionally In-Reply-To: References: Message-ID: Thanks Aleksey & Goetz. On Fri, Apr 23, 2021 at 10:10 AM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Thomas, > > The change looks good to me. > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Thomas St?fe > > Sent: Friday, April 23, 2021 10:07 AM > > To: jdk-updates-dev > > Subject: [11u] RFR: 8260926: Trace resource exhausted events > > unconditionally > > > > Hi all, > > > > may I please have eyes on this trivial backport. The trace line is useful > > to us especially in CloudFoundry scenarios when the jvmkill agent reacts > on > > the jvmti resource exhausted event and then often just kills the VM > without > > a trace. > > > > The patch had to be changed for 11u (nullptr -> NULL). > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8260926 > > Original Patch: https://github.com/openjdk/jdk/commit/ee2f2055 > > 11u Patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260926-trace- > > resource-exhausted-events-unconditionally-11u > > > > Thanks! > > > > ..Thomas > From shade at redhat.com Fri Apr 23 08:17:29 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 23 Apr 2021 10:17:29 +0200 Subject: [11u] RFR: 8262163: Extend settings printout in jcmd VM.metaspace In-Reply-To: References: Message-ID: <0e8d0307-ea78-b552-5bf7-86742c0e081f@redhat.com> On 4/23/21 10:12 AM, Thomas St?fe wrote: > Original issue: https://bugs.openjdk.java.net/browse/JDK-8262163 > Original Patch: https://github.com/openjdk/jdk/commit/ea48a0bb.diff > > The original patch does not apply, the code moved. Also, > "MetaspaceReclaimPolicy" does not exist in JDK 11 (came with JEP 387). > > 11u Patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8262163-extend-settings-printout-in-jcmd-VM.metaspace-11u.diff Looks fine. -- Thanks, -Aleksey From thomas.stuefe at gmail.com Fri Apr 23 08:20:18 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Apr 2021 10:20:18 +0200 Subject: [11u] RFR: 8262163: Extend settings printout in jcmd VM.metaspace In-Reply-To: <0e8d0307-ea78-b552-5bf7-86742c0e081f@redhat.com> References: <0e8d0307-ea78-b552-5bf7-86742c0e081f@redhat.com> Message-ID: Thank you! On Fri, Apr 23, 2021 at 10:17 AM Aleksey Shipilev wrote: > On 4/23/21 10:12 AM, Thomas St?fe wrote: > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8262163 > > Original Patch: https://github.com/openjdk/jdk/commit/ea48a0bb.diff > > > > The original patch does not apply, the code moved. Also, > > "MetaspaceReclaimPolicy" does not exist in JDK 11 (came with JEP 387). > > > > 11u Patch: > > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8262163-extend-settings-printout-in-jcmd-VM.metaspace-11u.diff > > Looks fine. > > -- > Thanks, > -Aleksey > > From thomas.stuefe at gmail.com Fri Apr 23 08:53:03 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Apr 2021 10:53:03 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: <8fe619f6-5e1b-104d-9865-9ad2c8951ac1@redhat.com> References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> <8fe619f6-5e1b-104d-9865-9ad2c8951ac1@redhat.com> Message-ID: Hi Florian and others, we decided on a clean rollback instead of letting fixes pile on. Atm there is a lack of trust in this patch, sorry. Please roll back it - and Alekseys subsequent build fix from yesterday - back and retry with a fully tested, complete patch. Thank you. Cheers, Thomas On Thu, Apr 22, 2021 at 2:19 PM Aleksey Shipilev wrote: > On 4/22/21 1:12 PM, Langer, Christoph wrote: > > Maybe for now it would be most appropriate to back it out and redo it > later when the problems are understood/fixed? > > Yes, I'd vote for reversal to get 11u back to sane state. > > -- > Thanks, > -Aleksey > > From lutz.schmidt at sap.com Fri Apr 23 09:20:55 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 23 Apr 2021 09:20:55 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: <2C964E5D-E880-446C-ADD0-8AACF31AEB70@sap.com> References: <5969F266-A269-4329-98D2-E8022EEDD5A7@amazon.com> <708D4864-3499-42A3-9EBA-18D6CB219DA3@sap.com> <2C964E5D-E880-446C-ADD0-8AACF31AEB70@sap.com> Message-ID: <6E017FE1-76DE-4ECF-8B0F-4DA507F41C0C@sap.com> Despite the issues with JDK-8258414, builds and tests were successful last night to such an extent that I dare to say the latest revisions of the downport patches are ready to be pushed. I have added the jdk11u-fix-request label to the "intermediate" bugs (8216314 and 8217465). Thanks, Lutz ?On 22.04.21, 12:37, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: No builds last night for jdk11u-dev, as you have noticed yourself. We will have to wait till Friday. Best, Lutz On 21.04.21, 11:04, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Changes look good to me now. Version 2 of the patches applies clean, not even any fuzz. Diffs against OpenJDK head are only those which can't be avoided. The patches are queued to be tested overnight. Results expected Thursday morning. Local tests on my Mac revealed no issues. I'll report on the test status once available. Thanks, Lutz On 21.04.21, 00:49, "Hohensee, Paul" wrote: Yes, please, and also review. I've run tier1 and tier2 on linux-x64. -----Original Message----- From: "Schmidt, Lutz" Date: Tuesday, April 20, 2021 at 1:38 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods You want me to retest? No problem, but results will not be available before Thursday. Please let me know. Lutz On 20.04.21, 19:58, "Hohensee, Paul" wrote: You're right. Emacs fumble-finger. :( New set of 3 webrevs (8214526 dropped). https://cr.openjdk.java.net/~phh/8216314/webrev.11u.02/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.03/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.04/ -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 2:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Yes, that's in the #else path of #if defined(USE_BUFFEREDSTREAM). You have to look further up: +// Same as above, but with fixed buffer size. +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K); + #define STRINGSTREAM_FLUSH(termString) \ _sstbuf->print("%s", termString); \ _outbuf->print("%s", _sstbuf->as_string()); \ _sstbuf->reset(); +// Flush the buffer contents unconditionally. +// No action if the buffer is empty. +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ On 19.04.21, 22:44, "Hohensee, Paul" wrote: I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From christoph.goettschkes at microdoc.com Fri Apr 23 10:02:18 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Fri, 23 Apr 2021 12:02:18 +0200 Subject: [11u] RFR: 8213483: ARM32: runtime/ErrorHandling/ShowRegistersOnAssertTest.java jtreg test fail In-Reply-To: <21c1d9b8-e360-bd77-eacc-842f7f3acc52@redhat.com> References: <3833xmuen6-1@aserp2020.oracle.com> <30773.121042206070200201@us-mta-1.us.mimecast.lan> <21c1d9b8-e360-bd77-eacc-842f7f3acc52@redhat.com> Message-ID: <383u4fh456-1@userp2020.oracle.com> Hi Aleksey, both issues got approved, would you mind sponsoring? https://bugs.openjdk.java.net/browse/JDK-8213483 https://bugs.openjdk.java.net/browse/JDK-8253167 https://cr.openjdk.java.net/~cgo/8213483/webrev.11u.01/ -- Christoph On 4/22/21 12:08 PM, Aleksey Shipilev wrote: > On 4/22/21 12:05 PM, Christoph G?ttschkes wrote: >> Thanks for the information. Fixed: >> https://cr.openjdk.java.net/~cgo/8213483/webrev.11u.01/ > > Looks fine. > From shade at redhat.com Fri Apr 23 10:06:52 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 23 Apr 2021 12:06:52 +0200 Subject: [11u] RFR: 8213483: ARM32: runtime/ErrorHandling/ShowRegistersOnAssertTest.java jtreg test fail In-Reply-To: <35068.121042306033900701@us-mta-492.us.mimecast.lan> References: <3833xmuen6-1@aserp2020.oracle.com> <30773.121042206070200201@us-mta-1.us.mimecast.lan> <21c1d9b8-e360-bd77-eacc-842f7f3acc52@redhat.com> <35068.121042306033900701@us-mta-492.us.mimecast.lan> Message-ID: On 4/23/21 12:02 PM, Christoph G?ttschkes wrote: > both issues got approved, would you mind sponsoring? > > https://bugs.openjdk.java.net/browse/JDK-8213483 > https://bugs.openjdk.java.net/browse/JDK-8253167 Sure: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/7e17825e47e7 I actually retested that patch on my ARM32 yesterday, and it indeed fixed the test. -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Fri Apr 23 10:09:54 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Fri, 23 Apr 2021 12:09:54 +0200 Subject: [11u] RFR: 8213483: ARM32: runtime/ErrorHandling/ShowRegistersOnAssertTest.java jtreg test fail In-Reply-To: References: <3833xmuen6-1@aserp2020.oracle.com> <30773.121042206070200201@us-mta-1.us.mimecast.lan> <21c1d9b8-e360-bd77-eacc-842f7f3acc52@redhat.com> <35068.121042306033900701@us-mta-492.us.mimecast.lan> Message-ID: <383rmfngwj-1@aserp2030.oracle.com> On 4/23/21 12:06 PM, Aleksey Shipilev wrote: > On 4/23/21 12:02 PM, Christoph G?ttschkes wrote: >> both issues got approved, would you mind sponsoring? >> >> https://bugs.openjdk.java.net/browse/JDK-8213483 >> https://bugs.openjdk.java.net/browse/JDK-8253167 > > Sure: > ?https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/7e17825e47e7 > > I actually retested that patch on my ARM32 yesterday, and it indeed fixed the test. > Thank you. From yan at azul.com Fri Apr 23 10:50:46 2021 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 23 Apr 2021 13:50:46 +0300 Subject: [13u] RFR: 8265837: Update version .jcheck/conf in jdk13u to be 13.0.8 Message-ID: Hi, this change will go to jdk13u master repo directly, so without Pull Request. It is necessary to avoid triggering of backports creation with old version number for all the commits in 13.0.8+1. The procedure is, make this change first, pull it to the team repo, push 13.0.8+1. Diff is diff --git a/.jcheck/conf b/.jcheck/conf index 96fb0d27d6..d0a0e98363 100644 --- a/.jcheck/conf +++ b/.jcheck/conf @@ -1,7 +1,7 @@ [general] project=jdk-updates jbs=JDK -version=13.0.7 +version=13.0.8 [checks] error=author,committer,reviewers,issues,executable,symlink,message,hg-tag,whitespace I'm not sure I should file such a request at all -- but it may be someway useful. Thanks, --yan From abrygin at azul.com Fri Apr 23 11:50:58 2021 From: abrygin at azul.com (Andrew Brygin) Date: Fri, 23 Apr 2021 14:50:58 +0300 Subject: [13u] RFR: 8265837: Update version .jcheck/conf in jdk13u to be 13.0.8 In-Reply-To: <1f9ec357-3833-f45c-f175-cc6c00ca2f97@azul.com> References: <1f9ec357-3833-f45c-f175-cc6c00ca2f97@azul.com> Message-ID: <3a59917d-5b9c-d6b3-6163-afa7b16e1544@azul.com> Hi Yuri, the change looks fine to me. Thanks, Andrew On 23/04/2021 14:48, Yuri Nesterenko wrote: > Hi, > > this change will go to jdk13u master repo directly, so without Pull Request. > It is necessary to avoid triggering of backports creation with old > version number > for all the commits in 13.0.8+1. The procedure is, make this change > first, pull it to > the team repo, push 13.0.8+1. > Diff is > > diff --git a/.jcheck/conf b/.jcheck/conf > index 96fb0d27d6..d0a0e98363 100644 > --- a/.jcheck/conf > +++ b/.jcheck/conf > @@ -1,7 +1,7 @@ > [general] > project=jdk-updates > jbs=JDK > -version=13.0.7 > +version=13.0.8 > > [checks] > error=author,committer,reviewers,issues,executable,symlink,message,hg-tag,whitespace > > I'm not sure I should file such a request at all -- but it may be > someway useful. > > Thanks, > --yan > From lutz.schmidt at sap.com Fri Apr 23 12:07:48 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 23 Apr 2021 12:07:48 +0000 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> <8fe619f6-5e1b-104d-9865-9ad2c8951ac1@redhat.com> Message-ID: <41FD9309-CD0C-4A28-955C-07A37E640D70@sap.com> Hi, I'm in full support of the decision. Bad patches with multiple causes of failure should be rolled back and retried - after thorough rework, testing and reviews. The bare minimum requirement for committers pushing a change is to be at least responsive on a mediocre level. Push, go away and let the others clean up is generally not well accepted by the community. Best regards, Lutz ?On 23.04.21, 10:53, "jdk-updates-dev on behalf of Thomas St?fe" wrote: Hi Florian and others, we decided on a clean rollback instead of letting fixes pile on. Atm there is a lack of trust in this patch, sorry. Please roll back it - and Alekseys subsequent build fix from yesterday - back and retry with a fully tested, complete patch. Thank you. Cheers, Thomas On Thu, Apr 22, 2021 at 2:19 PM Aleksey Shipilev wrote: > On 4/22/21 1:12 PM, Langer, Christoph wrote: > > Maybe for now it would be most appropriate to back it out and redo it > later when the problems are understood/fixed? > > Yes, I'd vote for reversal to get 11u back to sane state. > > -- > Thanks, > -Aleksey > > From thomas.stuefe at gmail.com Fri Apr 23 12:11:51 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Apr 2021 14:11:51 +0200 Subject: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads Message-ID: Hi, may I please have reviews for this backport, which fixes crashes which can happen if SafeFetch is used from within non-java-threads. Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb Unfortunately the original patch does not apply at all, since we unified all the coding in JDK16 to os_posix.cpp. Which is a change I do not want to backport. So the 11u specific patch looks big but is actually simple: - for all Posix platforms, in all the various signal handlers, we heave the handling of SafeFetch faults out of the "if current thread is java thread" condition up some lines, and do it unconditionally. Exception are the SAP platforms (AIX, linux ppc and s390) where we had fixed this bug already, so nothing to do here - for Windows, no such change was necessary, but there was a bug where Handle_Exception() did cast Thread to JavaThread without checking. The change here looks bigger than necessary to keep the code similar to upstream. - the new gtest is mostly unchanged from the upstream version apart from a fixed include (safefetch.hpp -> stubroutines.hpp) and the definition of invalid_address, since VMError::segfault_address is missing from JDK 11. 11u Patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads Testing: full gamut of SAP tests ran tonight seemingly ok, but I will rerun due to the current instability of 11u. However this patch touches two platforms we don't test (solaris x86, arm 32bit), so I would be happy if someone with access to those platforms could test at least the build, and if possible run the gtests too. Thanks, Thomas From yan at azul.com Fri Apr 23 13:12:32 2021 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 23 Apr 2021 16:12:32 +0300 Subject: [15u] RFR 8265860: Update version .jcheck/conf in jdk15u to be 15.0.4 Message-ID: Hi, this is again, a change of a per repository config stored in the Git repository itself, a minor inconvenience in two-repo setup. This .jcheck/conf file contains a value for the current version which should correspond to the version of the fixes coming from the team repository. To minimize merging, it is prudent to change the value as the last act of a release. No PR since the change goes directly to the master repo. The repository is just created, so .jcheck/conf will be a copy of that in the team jdk15u-dev, see below. Thanks, --yan diff --git a/.jcheck/conf b/.jcheck/conf index 0446bc3bbcd..3d2ec15b6f2 100644 --- a/.jcheck/conf +++ b/.jcheck/conf @@ -1,2 +1,28 @@ -project=jdk -bugids=dup +[general] +project=jdk-updates +jbs=JDK +version=15.0.4 + +[checks] +error=author,committer,reviewers,issues,executable,symlink,message,hg-tag,whitespace + +[repository] +tags=(?:jdk-(?:[1-9]([0-9]*)(?:\.(?:0|[1-9][0-9]*)){0,4})(?:\+(?:(?:[0-9]+))|(?:-ga)))|(?:jdk[4-9](?:u\d{1,3})?-(?:(?:b\d{2,3})|(?:ga)))|(?:hs\d\d(?:\.\d{1,2})?-b\d\d) +branches= + +[census] +version=0 +domain=openjdk.org + +[checks "whitespace"] +files=.*\.cpp|.*\.hpp|.*\.c|.*\.h|.*\.java + +[checks "reviewers"] +reviewers=1 +ignore=duke + +[checks "committer"] +role=committer + +[checks "issues"] +pattern=^([124-8][0-9]{6}): (\S.*)$ From abrygin at azul.com Fri Apr 23 13:27:29 2021 From: abrygin at azul.com (Andrew Brygin) Date: Fri, 23 Apr 2021 16:27:29 +0300 Subject: [15u] RFR 8265860: Update version .jcheck/conf in jdk15u to be 15.0.4 In-Reply-To: <9fd4d8b8-fb03-64e7-450f-e52c74077ae1@azul.com> References: <9fd4d8b8-fb03-64e7-450f-e52c74077ae1@azul.com> Message-ID: Hi Yuri, the proposed change looks fine to me. Thanks, Andrew On 23/04/2021 16:24, Yuri Nesterenko wrote: > Hi, > > this is again, a change of a per repository config stored in the Git > repository itself, > a minor inconvenience in two-repo setup. This .jcheck/conf file contains > a value for the current > version which should correspond to the version of the fixes coming from > the team repository. > To minimize merging, it is prudent to change the value as the last act > of a release. > No PR since the change goes directly to the master repo. > > The repository is just created, so .jcheck/conf will be a copy of that > in the team jdk15u-dev, > see below. > > Thanks, > --yan > > diff --git a/.jcheck/conf b/.jcheck/conf > index 0446bc3bbcd..3d2ec15b6f2 100644 > --- a/.jcheck/conf > +++ b/.jcheck/conf > @@ -1,2 +1,28 @@ > -project=jdk > -bugids=dup > +[general] > +project=jdk-updates > +jbs=JDK > +version=15.0.4 > + > +[checks] > +error=author,committer,reviewers,issues,executable,symlink,message,hg-tag,whitespace > + > +[repository] > +tags=(?:jdk-(?:[1-9]([0-9]*)(?:\.(?:0|[1-9][0-9]*)){0,4})(?:\+(?:(?:[0-9]+))|(?:-ga)))|(?:jdk[4-9](?:u\d{1,3})?-(?:(?:b\d{2,3})|(?:ga)))|(?:hs\d\d(?:\.\d{1,2})?-b\d\d) > +branches= > + > +[census] > +version=0 > +domain=openjdk.org > + > +[checks "whitespace"] > +files=.*\.cpp|.*\.hpp|.*\.c|.*\.h|.*\.java > + > +[checks "reviewers"] > +reviewers=1 > +ignore=duke > + > +[checks "committer"] > +role=committer > + > +[checks "issues"] > +pattern=^([124-8][0-9]{6}): (\S.*)$ > From hohensee at amazon.com Fri Apr 23 14:23:56 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 23 Apr 2021 14:23:56 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Message-ID: The 3 issues have been approved, so I've pushed them on your behalf. ?-----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 23, 2021 at 2:21 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Despite the issues with JDK-8258414, builds and tests were successful last night to such an extent that I dare to say the latest revisions of the downport patches are ready to be pushed. I have added the jdk11u-fix-request label to the "intermediate" bugs (8216314 and 8217465). Thanks, Lutz On 22.04.21, 12:37, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: No builds last night for jdk11u-dev, as you have noticed yourself. We will have to wait till Friday. Best, Lutz On 21.04.21, 11:04, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Changes look good to me now. Version 2 of the patches applies clean, not even any fuzz. Diffs against OpenJDK head are only those which can't be avoided. The patches are queued to be tested overnight. Results expected Thursday morning. Local tests on my Mac revealed no issues. I'll report on the test status once available. Thanks, Lutz On 21.04.21, 00:49, "Hohensee, Paul" wrote: Yes, please, and also review. I've run tier1 and tier2 on linux-x64. -----Original Message----- From: "Schmidt, Lutz" Date: Tuesday, April 20, 2021 at 1:38 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods You want me to retest? No problem, but results will not be available before Thursday. Please let me know. Lutz On 20.04.21, 19:58, "Hohensee, Paul" wrote: You're right. Emacs fumble-finger. :( New set of 3 webrevs (8214526 dropped). https://cr.openjdk.java.net/~phh/8216314/webrev.11u.02/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.03/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.04/ -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 2:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Yes, that's in the #else path of #if defined(USE_BUFFEREDSTREAM). You have to look further up: +// Same as above, but with fixed buffer size. +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K); + #define STRINGSTREAM_FLUSH(termString) \ _sstbuf->print("%s", termString); \ _outbuf->print("%s", _sstbuf->as_string()); \ _sstbuf->reset(); +// Flush the buffer contents unconditionally. +// No action if the buffer is empty. +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ On 19.04.21, 22:44, "Hohensee, Paul" wrote: I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From jaroslav.bachorik at datadoghq.com Fri Apr 23 14:32:37 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 23 Apr 2021 16:32:37 +0200 Subject: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample events too expensive) In-Reply-To: References: Message-ID: Hi, On Thu, Apr 22, 2021 at 7:19 AM Thomas St?fe wrote: > > Hi guys, > > Errors happen, that is normal. But I wonder if we need some clearer standards for testing downported patches? Currently the only requirement is to run tier1 tests, but nothing is mentioned about the configuration and the platforms to be tested. 11u is a stable maintenance release and in theory it should have a higher, not a lower bar for testing than the head release. I totally agree. This was my fault as I was lulled to a false sense of safety by the GH actions which I completely forgot were not happening for 11u. > > Surely testing just release is not enough, the debug builds need to be tested too. Then, arguably one should test on more than one platform. It's fine for individual contributors which don't have the resources, but larger companies should be able to test 11u patches on multiple platforms. Otherwise the burden of running the full gamut of tests and analysing accumulated errors lies overly by the 11u maintainers. IMO, a requirement to have a full spectrum of OS-HW combinations covered before pushing a backport will basically mean that the contributors without access to such resources will not be able/allowed to push backports at all. I am not saying it is wrong - just flagging the possible result. Cheers, -JB- > > What do you think? > > (Ccing Aleksey as the maintainer of https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix). > > Cheers, Thomas > > > On Wed, Apr 21, 2021 at 7:42 PM Hohensee, Paul wrote: >> >> Hi, Jaroslav. >> >> This push (https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/b103107d7ceb) broke the debug builds, vis >> >> /home/hohensee/workspaces/jdk11u-dev/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:298:14: error: ?JfrJavaSupport? has not been declared >> DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(thread);) >> >> The fix is >> >> diff -r b103107d7ceb src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> --- a/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Wed Apr 21 12:24:28 2021 +0200 >> +++ b/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp Wed Apr 21 17:40:23 2021 +0000 >> @@ -24,6 +24,7 @@ >> >> #include "precompiled.hpp" >> #include "jfr/jfrEvents.hpp" >> +#include "jfr/jni/jfrJavaSupport.hpp" >> #include "jfr/leakprofiler/chains/edgeStore.hpp" >> #include "jfr/leakprofiler/chains/objectSampleMarker.hpp" >> #include "jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp" >> >> Thanks, >> Paul >> >> ?-----Original Message----- >> From: jdk-updates-dev on behalf of Jaroslav Bachor?k >> Date: Monday, April 12, 2021 at 1:40 AM >> To: Florian David >> Cc: jdk-updates-dev , Marcus Hirt >> Subject: RE: [11u] RFR: 8258414: OldObjectSample events too expensive >> >> Great, thanks! >> >> Reviewed! >> >> -JB- >> >> On Fri, Apr 9, 2021 at 11:49 PM Florian David >> wrote: >> > >> > After receiving feedback from Markus stating that: >> > > There is no need to attempt a lock replacement, because in 11, there is no concurrent class unloading. There, unloading only happens at a safepoint. >> > > With concurrent class unloading, there is a need to protect this list, but in 11 it is mutually exclusive and cannot be modified concurrently with the JFR Recorder thread calling "install_stack_traces(sampler"). >> > >> > I removed the module lock and added an is_at_safepoint() assert. >> > >> > Update webrev link: >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >> > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.02/ >> > Original PR: https://github.com/openjdk/jdk/pull/2780 >> > >> > Florian >> > >> > On Sun, Apr 4, 2021 at 8:33 PM Florian David wrote: >> >> >> >> Hi Jaroslav, >> >> >> >> Thanks for the review. >> >> >> >>> >> >>> - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> >>> L287 - IMO, the TODO is not necessary >> >> >> >> It's removed. >> >> >> >>> >> >>> L293 - I think the comment `// caller needs ResourceMark` should >> >>> not be removed >> >> >> >> I added it back. >> >> >> >>> L303 - Not sure if using Module_lock instead of >> >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >> >>> bringing in changes unrelated to the patch. >> >>> From what is happening in other places it would seem >> >>> that a safepoint should be asserted instead (or nothing should be >> >>> done). >> >>> I will let Markus weigh in on this. >> >> >> >> No change for the moment. >> >> >> >>> >> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >> >>> L38 - can this be completely removed? >> >> >> >> It's removed. >> >> >> >>> >> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >> >>> L30 - I think `class JfrThreadLocal;` can also be removed >> >>> >> >> It's removed. >> >> >> >> Update webrev link: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >> >> webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.01/ >> >> Original PR: https://github.com/openjdk/jdk/pull/2780 >> >> >> >> Florian >> >> >> >> On Mon, Mar 29, 2021 at 12:22 PM Jaroslav Bachor?k wrote: >> >>> >> >>> Hi Florian, >> >>> >> >>> a few nits: >> >>> - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp >> >>> L287 - IMO, the TODO is not necessary >> >>> L293 - I think the comment `// caller needs ResourceMark` should >> >>> not be removed >> >>> L303 - Not sure if using Module_lock instead of >> >>> ClassLoaderDataGraph_lock is correct. Also, this change seems to be >> >>> bringing in changes unrelated to the patch. >> >>> From what is happening in other places it would seem >> >>> that a safepoint should be asserted instead (or nothing should be >> >>> done). >> >>> I will let Markus weigh in on this. >> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp >> >>> L38 - can this be completely removed? >> >>> - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp >> >>> L30 - I think `class JfrThreadLocal;` can also be removed >> >>> >> >>> Cheers, >> >>> >> >>> -JB- >> >>> >> >>> >> >>> On Wed, Mar 24, 2021 at 8:42 PM Florian David >> >>> wrote: >> >>> > >> >>> > Hi, >> >>> > >> >>> > Please review this 11u backport. It's very similar to the original patch, >> >>> > except for the class loader data graph lock and JfrKlassUnloading::sort() >> >>> > method which are not available in 11u. >> >>> > >> >>> > The missing lock has been replaced by locking the module_lock instead, >> >>> > as it is done in jfrcheckpointManager.cpp:363. >> >>> > JfrKlassUnloading class does not exist and thus sort() method is not replaced, >> >>> > I added a TODO instead. >> >>> > >> >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 >> >>> > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ >> >>> > Original PR: https://github.com/openjdk/jdk/pull/2780 >> >>> > >> >>> > Testing: >> >>> > - Linux x86_64 tier1 tests >> >>> > - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is 75.12 MB before the patch and 3.08 MB after the patch. >> >>> > >> >>> > Let me know what you think. >> >>> > >> >>> > Thanks, >> >>> > Florian >> From lutz.schmidt at sap.com Fri Apr 23 14:34:27 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 23 Apr 2021 14:34:27 +0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: References: Message-ID: <51E13B92-F1C4-4689-9382-39FBBEF384D0@sap.com> Thank you very much, Paul! I appreciate your assistance and patience. Have a great weekend, Lutz ?On 23.04.21, 16:23, "Hohensee, Paul" wrote: The 3 issues have been approved, so I've pushed them on your behalf. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 23, 2021 at 2:21 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Despite the issues with JDK-8258414, builds and tests were successful last night to such an extent that I dare to say the latest revisions of the downport patches are ready to be pushed. I have added the jdk11u-fix-request label to the "intermediate" bugs (8216314 and 8217465). Thanks, Lutz On 22.04.21, 12:37, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: No builds last night for jdk11u-dev, as you have noticed yourself. We will have to wait till Friday. Best, Lutz On 21.04.21, 11:04, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Changes look good to me now. Version 2 of the patches applies clean, not even any fuzz. Diffs against OpenJDK head are only those which can't be avoided. The patches are queued to be tested overnight. Results expected Thursday morning. Local tests on my Mac revealed no issues. I'll report on the test status once available. Thanks, Lutz On 21.04.21, 00:49, "Hohensee, Paul" wrote: Yes, please, and also review. I've run tier1 and tier2 on linux-x64. -----Original Message----- From: "Schmidt, Lutz" Date: Tuesday, April 20, 2021 at 1:38 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods You want me to retest? No problem, but results will not be available before Thursday. Please let me know. Lutz On 20.04.21, 19:58, "Hohensee, Paul" wrote: You're right. Emacs fumble-finger. :( New set of 3 webrevs (8214526 dropped). https://cr.openjdk.java.net/~phh/8216314/webrev.11u.02/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.03/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.04/ -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 2:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Yes, that's in the #else path of #if defined(USE_BUFFEREDSTREAM). You have to look further up: +// Same as above, but with fixed buffer size. +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K); + #define STRINGSTREAM_FLUSH(termString) \ _sstbuf->print("%s", termString); \ _outbuf->print("%s", _sstbuf->as_string()); \ _sstbuf->reset(); +// Flush the buffer contents unconditionally. +// No action if the buffer is empty. +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ On 19.04.21, 22:44, "Hohensee, Paul" wrote: I see in the webrev -#define STRINGSTREAM_DECL(_anyst, _outst) \ +#define BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, _capa) \ + size_t _capacity = _capa; \ outputStream* _outbuf = _outst; \ outputStream* _anyst = _outst; /* any stream. Use this to just print - no buffer flush. */ -#define STRINGSTREAM_FLUSH(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_DECL(_anyst, _outst) \ + BUFFEREDSTREAM_DECL_SIZE(_anyst, _outst, 4*K) -#define STRINGSTREAM_FLUSH_LOCKED(termString) \ - _outbuf->print("%s", termString); +#define BUFFEREDSTREAM_FLUSH(_termString) \ + if (((_termString) != NULL) && (strlen(_termString) > 0)){\ + _outbuf->print("%s", _termString); \ + } -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 1:02 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods See inline comments. There is no reason for you to say thank you! I have to be grateful that you separated the patches. Best Regards, Lutz On 19.04.21, 21:31, "Hohensee, Paul" wrote: Thanks very much for running the tests, Lutz. The reference to PrintCodeHeapAnalytics is in your original webrev at https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html I see. You fixed this comment already. Thanks. I see STRINGSTREAM_DECL and STRINGSTREAM_FLUSH_LOCKED as deleted code in https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/src/hotspot/share/code/codeHeapState.cpp.udiff.html STRINGSTREAM_DECL is correctly deleted. I was referring to STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. I see these two #defines as unchanged in the udiff (in the #if defined() path). In the #else path, everything is fine. Paul -----Original Message----- From: "Schmidt, Lutz" Date: Monday, April 19, 2021 at 8:54 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods 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. Mail does not show up in PiperMail. Maybe due to .jpg attachment. Resending without attachment... Best, Lutz On 19.04.21, 14:20, "Schmidt, Lutz" wrote: Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From neugens at redhat.com Fri Apr 23 14:55:57 2021 From: neugens at redhat.com (Mario Torre) Date: Fri, 23 Apr 2021 16:55:57 +0200 Subject: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample events too expensive) In-Reply-To: References: Message-ID: On Fri, Apr 23, 2021 at 4:33 PM Jaroslav Bachor?k wrote: > > Hi, > > On Thu, Apr 22, 2021 at 7:19 AM Thomas St?fe wrote: > > > > Hi guys, > > > > Errors happen, that is normal. But I wonder if we need some clearer standards for testing downported patches? Currently the only requirement is to run tier1 tests, but nothing is mentioned about the configuration and the platforms to be tested. 11u is a stable maintenance release and in theory it should have a higher, not a lower bar for testing than the head release. > > I totally agree. This was my fault as I was lulled to a false sense of > safety by the GH actions which I completely forgot were not happening > for 11u. > > > > > Surely testing just release is not enough, the debug builds need to be tested too. Then, arguably one should test on more than one platform. It's fine for individual contributors which don't have the resources, but larger companies should be able to test 11u patches on multiple platforms. Otherwise the burden of running the full gamut of tests and analysing accumulated errors lies overly by the 11u maintainers. > > IMO, a requirement to have a full spectrum of OS-HW combinations > covered before pushing a backport will basically mean that the > contributors without access to such resources will not be able/allowed > to push backports at all. > I am not saying it is wrong - just flagging the possible result. I agree it shouldn't be a requirement to have a full spectrum, but I think it should be a requirement to have a wide spectrum, which is what Thomas is suggesting as I understand. Since we may start using the GH actions, adding x86 Linux, Windows and OSX in both standard and debug configurations doesn't sound implausible, less mainstream platforms may let pass without a specific test unless the maintainers/reviewers have concerns, in which case they should help with the testing too. The author may just say "sorry, I don't have a Windows box, can someone test there?", and that should not be a blocker if no one follows up. Overall, it's always very dynamic and very case-by-case, but the automation on some specific widely available platforms helps a lot and we should implement it. Cheers, Mario -- Mario Torre Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From thomas.stuefe at gmail.com Fri Apr 23 15:36:36 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Apr 2021 17:36:36 +0200 Subject: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample events too expensive) In-Reply-To: References: Message-ID: On Fri, Apr 23, 2021 at 4:32 PM Jaroslav Bachor?k < jaroslav.bachorik at datadoghq.com> wrote: > Hi, > > On Thu, Apr 22, 2021 at 7:19 AM Thomas St?fe > wrote: > > > > Hi guys, > > > > Errors happen, that is normal. But I wonder if we need some clearer > standards for testing downported patches? Currently the only requirement is > to run tier1 tests, but nothing is mentioned about the configuration and > the platforms to be tested. 11u is a stable maintenance release and in > theory it should have a higher, not a lower bar for testing than the head > release. > > I totally agree. This was my fault as I was lulled to a false sense of > safety by the GH actions which I completely forgot were not happening > for 11u. > > > > > Surely testing just release is not enough, the debug builds need to be > tested too. Then, arguably one should test on more than one platform. It's > fine for individual contributors which don't have the resources, but larger > companies should be able to test 11u patches on multiple platforms. > Otherwise the burden of running the full gamut of tests and analysing > accumulated errors lies overly by the 11u maintainers. > > IMO, a requirement to have a full spectrum of OS-HW combinations > covered before pushing a backport will basically mean that the > contributors without access to such resources will not be able/allowed > to push backports at all. > I am not saying it is wrong - just flagging the possible result. > > Honestly, I would give preference to the need of the users regarding the stability of the code base over the need of individual contributors to backport a specific feature. For the mainline JDK, we have the full power of the Oracle team, plus Oracle's large testing infrastructure, plus a generous cooking time until a release is rolled out, plus - lets be honest - a much longer time until serious mass adoption. For backport releases, we have a rather small team of maintainers and reviewers, and testing mainly done by Red Hat and SAP? I may forget someone but I am not aware of large scale testing done by others. But the way to mass adoption on older releases is way shorter. A comparatively quick baking time, then an update gets rolled out to millions of customers which expect everything to continue smoothly. This is fine for a slow trickle of important patches, but gets overwhelmed when facing many changes, especially if they are of low quality. Therefore I think backport authors should be aware of this and test their patches thoroughly before turning them in. What constitutes "thorough" testing is up to the individual author, and depends on the patch oc. Cheers, Thomas From jaroslav.bachorik at datadoghq.com Fri Apr 23 15:43:07 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 23 Apr 2021 17:43:07 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 Message-ID: Please, review this backout patch for a backport causing fatal error. JIRA: https://bugs.openjdk.java.net/browse/JDK-8265750 Webrev: http://cr.openjdk.java.net/~jbachorik/8265750/webrev/ The backout changes also revert the change introduced by https://bugs.openjdk.java.net/browse/JDK-8265718 as the affected code is not present any more. Tier 1 tests are passing on linux x64 but I have no windows machine ready for JDK build and tests (as was obvious from the breakage ...). So, if someone could do a test run on windows x64 (at least) I would greatly appreciate it. Thanks, -JB- From thomas.stuefe at gmail.com Fri Apr 23 15:49:26 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Apr 2021 17:49:26 +0200 Subject: 11u testing (was: Re: [11u] RFR: 8258414: OldObjectSample events too expensive) In-Reply-To: References: Message-ID: On Fri, Apr 23, 2021 at 4:56 PM Mario Torre wrote: > On Fri, Apr 23, 2021 at 4:33 PM Jaroslav Bachor?k > wrote: > > > > Hi, > > > > On Thu, Apr 22, 2021 at 7:19 AM Thomas St?fe > wrote: > > > > > > Hi guys, > > > > > > Errors happen, that is normal. But I wonder if we need some clearer > standards for testing downported patches? Currently the only requirement is > to run tier1 tests, but nothing is mentioned about the configuration and > the platforms to be tested. 11u is a stable maintenance release and in > theory it should have a higher, not a lower bar for testing than the head > release. > > > > I totally agree. This was my fault as I was lulled to a false sense of > > safety by the GH actions which I completely forgot were not happening > > for 11u. > > > > > > > > Surely testing just release is not enough, the debug builds need to be > tested too. Then, arguably one should test on more than one platform. It's > fine for individual contributors which don't have the resources, but larger > companies should be able to test 11u patches on multiple platforms. > Otherwise the burden of running the full gamut of tests and analysing > accumulated errors lies overly by the 11u maintainers. > > > > IMO, a requirement to have a full spectrum of OS-HW combinations > > covered before pushing a backport will basically mean that the > > contributors without access to such resources will not be able/allowed > > to push backports at all. > > I am not saying it is wrong - just flagging the possible result. > > I agree it shouldn't be a requirement to have a full spectrum, but I > think it should be a requirement to have a wide spectrum, which is > what Thomas is suggesting as I understand. Since we may start using > the GH actions, adding x86 Linux, Windows and OSX in both standard and > debug configurations doesn't sound implausible, less mainstream > platforms may let pass without a specific test unless the > maintainers/reviewers have concerns, in which case they should help > with the testing too. > > The author may just say "sorry, I don't have a Windows box, can > someone test there?", and that should not be a blocker if no one > follows up. Why not? In your hypothetical case probably reviewers are overwhelmed and no-one has found time to build and test for the contributor. IMHO that should not be an automatic okay-to-push. If it's not time critical, it's better if the contributor waits then to push an untested fix. Where more exotic hardware is concerned (e.g. ppc) I agree, but even then - if the patch explicitly touches architecture specific stuff, it should be tested on that architecture before pushing. > Overall, it's always very dynamic and very case-by-case, > but the automation on some specific widely available platforms helps a > lot and we should implement it. > I agree. > > Cheers, Mario > > -- > Mario Torre > Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > From sgehwolf at redhat.com Fri Apr 23 16:31:05 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 23 Apr 2021 18:31:05 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: References: Message-ID: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> On Fri, 2021-04-23 at 17:43 +0200, Jaroslav Bachor?k wrote: > Please, review this backout patch for a backport causing fatal error. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8265750 > Webrev: http://cr.openjdk.java.net/~jbachorik/8265750/webrev/ > > The backout changes also revert the change introduced by > https://bugs.openjdk.java.net/browse/JDK-8265718?as the affected code > is not present any more. > > Tier 1 tests are passing on linux x64 but I have no windows machine > ready for JDK build and tests (as was obvious from the breakage ...). > So, if someone could do a test run on windows x64 (at least) I would > greatly appreciate it. I'm not sure this is the right bug to use. If JDK-8265750 is going to be a backout of JDK-8258414 in jdk head, then this would be OK. If this is an OpenJDK 11.0.12 only problem it would be OK too, but the bug doesn't say (it should say so if so). What was the course of action in jdk 17 and jdk 16? Thanks, Severin From jaroslav.bachorik at datadoghq.com Fri Apr 23 16:57:38 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 23 Apr 2021 18:57:38 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> References: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> Message-ID: Hi Severin, This 11u only problem. In 16 and 17 this crash is not happening. The bug has 'Affects Version/s' set to 11 - is there anything else that should be set there? Cheers, -JB- On Fri, Apr 23, 2021 at 6:31 PM Severin Gehwolf wrote: > > On Fri, 2021-04-23 at 17:43 +0200, Jaroslav Bachor?k wrote: > > Please, review this backout patch for a backport causing fatal error. > > > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8265750 > > Webrev: http://cr.openjdk.java.net/~jbachorik/8265750/webrev/ > > > > The backout changes also revert the change introduced by > > https://bugs.openjdk.java.net/browse/JDK-8265718 as the affected code > > is not present any more. > > > > Tier 1 tests are passing on linux x64 but I have no windows machine > > ready for JDK build and tests (as was obvious from the breakage ...). > > So, if someone could do a test run on windows x64 (at least) I would > > greatly appreciate it. > > I'm not sure this is the right bug to use. If JDK-8265750 is going to > be a backout of JDK-8258414 in jdk head, then this would be OK. If this > is an OpenJDK 11.0.12 only problem it would be OK too, but the bug > doesn't say (it should say so if so). What was the course of action in > jdk 17 and jdk 16? > > Thanks, > Severin > From igor.ignatyev at oracle.com Fri Apr 23 17:03:33 2021 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Fri, 23 Apr 2021 17:03:33 +0000 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: References: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> Message-ID: <4E5BC48A-C78F-4573-BB71-7872A0D10A22@oracle.com> Hi Jaroslav, if the issues doesn't exist (which is somewhat different from 'crash not happening') in 16 and 17, you might want to add '16-na' and '17-na' labels to show that these releases aren't affected. -- Igor > On Apr 23, 2021, at 9:57 AM, Jaroslav Bachor?k wrote: > > Hi Severin, > > This 11u only problem. In 16 and 17 this crash is not happening. The > bug has 'Affects Version/s' set to 11 - is there anything else that > should be set there? > > Cheers, > > -JB- > > On Fri, Apr 23, 2021 at 6:31 PM Severin Gehwolf wrote: >> >> On Fri, 2021-04-23 at 17:43 +0200, Jaroslav Bachor?k wrote: >>> Please, review this backout patch for a backport causing fatal error. >>> >>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8265750 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8265750/webrev/ >>> >>> The backout changes also revert the change introduced by >>> https://bugs.openjdk.java.net/browse/JDK-8265718 as the affected code >>> is not present any more. >>> >>> Tier 1 tests are passing on linux x64 but I have no windows machine >>> ready for JDK build and tests (as was obvious from the breakage ...). >>> So, if someone could do a test run on windows x64 (at least) I would >>> greatly appreciate it. >> >> I'm not sure this is the right bug to use. If JDK-8265750 is going to >> be a backout of JDK-8258414 in jdk head, then this would be OK. If this >> is an OpenJDK 11.0.12 only problem it would be OK too, but the bug >> doesn't say (it should say so if so). What was the course of action in >> jdk 17 and jdk 16? >> >> Thanks, >> Severin >> From jaroslav.bachorik at datadoghq.com Fri Apr 23 17:12:58 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 23 Apr 2021 19:12:58 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: <4E5BC48A-C78F-4573-BB71-7872A0D10A22@oracle.com> References: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> <4E5BC48A-C78F-4573-BB71-7872A0D10A22@oracle.com> Message-ID: Hi Igor, Thanks, I set the labels. I am fairly sure the issue is not affecting neither 16 nor 17. For 17 the fix was supervised, tested and pushed by the Oracle JFR team. For 16, the backport was a clean application of the same patch - also the GH pre commit checks didn't report any failures. -JB- On Fri, Apr 23, 2021 at 7:03 PM Igor Ignatev wrote: > > Hi Jaroslav, > > if the issues doesn't exist (which is somewhat different from 'crash not happening') in 16 and 17, you might want to add '16-na' and '17-na' labels to show that these releases aren't affected. > > -- Igor > > > On Apr 23, 2021, at 9:57 AM, Jaroslav Bachor?k wrote: > > > > Hi Severin, > > > > This 11u only problem. In 16 and 17 this crash is not happening. The > > bug has 'Affects Version/s' set to 11 - is there anything else that > > should be set there? > > > > Cheers, > > > > -JB- > > > > On Fri, Apr 23, 2021 at 6:31 PM Severin Gehwolf wrote: > >> > >> On Fri, 2021-04-23 at 17:43 +0200, Jaroslav Bachor?k wrote: > >>> Please, review this backout patch for a backport causing fatal error. > >>> > >>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8265750 > >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8265750/webrev/ > >>> > >>> The backout changes also revert the change introduced by > >>> https://bugs.openjdk.java.net/browse/JDK-8265718 as the affected code > >>> is not present any more. > >>> > >>> Tier 1 tests are passing on linux x64 but I have no windows machine > >>> ready for JDK build and tests (as was obvious from the breakage ...). > >>> So, if someone could do a test run on windows x64 (at least) I would > >>> greatly appreciate it. > >> > >> I'm not sure this is the right bug to use. If JDK-8265750 is going to > >> be a backout of JDK-8258414 in jdk head, then this would be OK. If this > >> is an OpenJDK 11.0.12 only problem it would be OK too, but the bug > >> doesn't say (it should say so if so). What was the course of action in > >> jdk 17 and jdk 16? > >> > >> Thanks, > >> Severin > >> > From sgehwolf at redhat.com Fri Apr 23 17:22:00 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 23 Apr 2021 19:22:00 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: References: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> Message-ID: <8c9fa29cb5818954c700b0d3d2b95c7d81df3114.camel@redhat.com> On Fri, 2021-04-23 at 18:57 +0200, Jaroslav Bachor?k wrote: > In 16 and 17 this crash is not happening. Why? Thanks, Severin From jaroslav.bachorik at datadoghq.com Fri Apr 23 17:34:01 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 23 Apr 2021 19:34:01 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: <8c9fa29cb5818954c700b0d3d2b95c7d81df3114.camel@redhat.com> References: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> <8c9fa29cb5818954c700b0d3d2b95c7d81df3114.camel@redhat.com> Message-ID: On Fri, Apr 23, 2021 at 7:22 PM Severin Gehwolf wrote: > > On Fri, 2021-04-23 at 18:57 +0200, Jaroslav Bachor?k wrote: > > In 16 and 17 this crash is not happening. > > Why? I assume because the safepoint assumptions are slightly different? The fix for jdk head was pushed more than a month ago. The push was done by Markus Gronlund and I assume he wouldn't have pushed that without going through the whole shebang of Oracle internal test rigs. The backport for 16u is identical to 17. All the affected code in JFR is identical. Although there still might be a chance for error the same test that failed in 11u did pass for 16 as a part of the pre-commit GH actions. AFAICT, the issue we are talking about was filed as a reaction to failure observed in 11u. The adjustments for the differences between JDK head and 11u are the most likely the cause of this failure. There is no indication this should apply to any other version than 11u unless I am missing something. Cheers, -JB- > > Thanks, > Severin > > From hohensee at amazon.com Fri Apr 23 17:56:30 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 23 Apr 2021 17:56:30 +0000 Subject: [11u] RFR (S) 8255625: AArch64: Implement Base64.encodeBlock accelerator/intrinsic Message-ID: <1C827A5E-FF5F-4729-826B-E18B5C3065E5@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Thursday, April 22, 2021 at 7:20 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (S) 8255625: AArch64: Implement Base64.encodeBlock accelerator/intrinsic Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8255625 The patch does not apply cleanly: corrected fuzz, adjusted small part to missing context in stubGenerator_aarch64.cpp (JDK-8224974 is not in 11u). Resulting patch was formatted for 11u. CheckGraalIntrinsics test already has this intrinsic. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8255625/webrev.11u.00/ Testing: test/jdk/java/util/Base64, tier1, tier2. -- Thanks, -Dmitry From omikhaltcova at openjdk.java.net Fri Apr 23 21:36:38 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 23 Apr 2021 21:36:38 GMT Subject: [jdk13u-dev] RFR: 8247502: PhaseStringOpts crashes while optimising effectively dead code Message-ID: <3HKMwRMfm5eh-wOO9ZBdZFqpQ6kD-yaMYAbTHbxMe3Q=.981b94c1-6c63-40b1-9c38-0ead2f1a264d@github.com> I'd like to backport JDK-8247502 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with tier1, tier2. No regression in tests. ------------- Commit messages: - Backport a14490dd161b9ac9b4f900489fd84e756ff6e740 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247502 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/189/head:pull/189 PR: https://git.openjdk.java.net/jdk13u-dev/pull/189 From sean.coffey at oracle.com Sun Apr 25 13:34:36 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Sun, 25 Apr 2021 14:34:36 +0100 Subject: Result: New JDK-Updates Committer: Kiran Ravikumar Message-ID: Voting for Kiran Ravikumar [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. regards, Sean. [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005678.html From omikhaltcova at openjdk.java.net Sun Apr 25 21:01:32 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Sun, 25 Apr 2021 21:01:32 GMT Subject: [jdk15u-dev] RFR: 8248532: Every time I change keyboard language at my MacBook, Java crashes Message-ID: I'd like to backport JDK-8248532 to jdk15u for parity with jdk11u. The original patch applied cleanly. ------------- Commit messages: - Backport 6329de45045da3ce937cd22d82e74c3f142ea3f2 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/31/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=31&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248532 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/31/head:pull/31 PR: https://git.openjdk.java.net/jdk15u-dev/pull/31 From omikhaltcova at openjdk.java.net Sun Apr 25 22:03:14 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Sun, 25 Apr 2021 22:03:14 GMT Subject: [jdk15u-dev] RFR: 8257242: [macOS] Java app crashes while switching input methods Message-ID: I'd like to backport JDK-8257242 to jdk15u for parity with jdk11u. The original patch applied cleanly. ------------- Commit messages: - Backport 822ee47459d3a33ab3acd7f8798525967a20d237 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/32/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=32&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257242 Stats: 8 lines in 2 files changed: 3 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/32/head:pull/32 PR: https://git.openjdk.java.net/jdk15u-dev/pull/32 From omikhaltcova at openjdk.java.net Mon Apr 26 07:30:41 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 26 Apr 2021 07:30:41 GMT Subject: [jdk13u-dev] Integrated: 8247502: PhaseStringOpts crashes while optimising effectively dead code In-Reply-To: <3HKMwRMfm5eh-wOO9ZBdZFqpQ6kD-yaMYAbTHbxMe3Q=.981b94c1-6c63-40b1-9c38-0ead2f1a264d@github.com> References: <3HKMwRMfm5eh-wOO9ZBdZFqpQ6kD-yaMYAbTHbxMe3Q=.981b94c1-6c63-40b1-9c38-0ead2f1a264d@github.com> Message-ID: On Fri, 23 Apr 2021 14:14:32 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8247502 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with tier1, tier2. No regression in tests. This pull request has now been integrated. Changeset: d61430b6 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/d61430b6 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod 8247502: PhaseStringOpts crashes while optimising effectively dead code Backport-of: a14490dd161b9ac9b4f900489fd84e756ff6e740 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/189 From rwestrel at redhat.com Mon Apr 26 07:44:47 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 26 Apr 2021 09:44:47 +0200 Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance In-Reply-To: References: Message-ID: <875z09o5g0.fsf@redhat.com> > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/ Looks good to me too. Roland. From shade at redhat.com Mon Apr 26 08:11:03 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Apr 2021 10:11:03 +0200 Subject: [11u] RFR: JDK-8260707: java/lang/instrument/PremainClass/InheritAgent0100.java times out In-Reply-To: References: Message-ID: <60817b40-9038-6a44-a3e4-e3688ef87e48@redhat.com> On 4/21/21 7:07 AM, Thomas St?fe wrote: > Issue: https://bugs.openjdk.java.net/browse/JDK-8260707 > Orig patch: https://github.com/openjdk/jdk/commit/d7b1fc59.diff > 11u patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260707-java-lang-instrument-premainclass-inheritagent0100-java-timed-out-11u This looks fine to me. -- Thanks, -Aleksey From omikhaltcova at openjdk.java.net Mon Apr 26 08:22:40 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 26 Apr 2021 08:22:40 GMT Subject: [jdk15u-dev] Integrated: 8257242: [macOS] Java app crashes while switching input methods In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 21:55:04 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8257242 to jdk15u for parity with jdk11u. > The original patch applied cleanly. This pull request has now been integrated. Changeset: 59f8941c Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/59f8941c Stats: 8 lines in 2 files changed: 3 ins; 3 del; 2 mod 8257242: [macOS] Java app crashes while switching input methods Backport-of: 822ee47459d3a33ab3acd7f8798525967a20d237 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/32 From omikhaltcova at openjdk.java.net Mon Apr 26 08:26:29 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 26 Apr 2021 08:26:29 GMT Subject: [jdk15u-dev] Integrated: 8248532: Every time I change keyboard language at my MacBook, Java crashes In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 20:51:54 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8248532 to jdk15u for parity with jdk11u. > The original patch applied cleanly. This pull request has now been integrated. Changeset: 6fb2ac22 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/6fb2ac22 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8248532: Every time I change keyboard language at my MacBook, Java crashes Backport-of: 6329de45045da3ce937cd22d82e74c3f142ea3f2 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/31 From martin.doerr at sap.com Mon Apr 26 09:09:59 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 26 Apr 2021 09:09:59 +0000 Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance In-Reply-To: <875z09o5g0.fsf@redhat.com> References: <875z09o5g0.fsf@redhat.com> Message-ID: Hi Roland, thanks for the review! Pushed. Best regards, Martin > -----Original Message----- > From: Roland Westrelin > Sent: Montag, 26. April 2021 09:45 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' compiler-dev at openjdk.java.net> > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) > failed: bad dominance > > > > 11u backport: > > http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/ > > Looks good to me too. > > Roland. From github.com+20224954+gdams at openjdk.java.net Mon Apr 26 09:21:06 2021 From: github.com+20224954+gdams at openjdk.java.net (George Adams) Date: Mon, 26 Apr 2021 09:21:06 GMT Subject: [jdk16u] RFR: 8265531: doc/building.md should mention homebrew install freetype Message-ID: Backport of 8265531: doc/building.md should mention homebrew install freetype ------------- Commit messages: - 8265531: doc/building.md should mention homebrew install freetype Changes: https://git.openjdk.java.net/jdk16u/pull/109/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=109&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265531 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/109.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/109/head:pull/109 PR: https://git.openjdk.java.net/jdk16u/pull/109 From shade at redhat.com Mon Apr 26 09:58:41 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Apr 2021 11:58:41 +0200 Subject: [11u] RFR (XS) 8265537: x86 version string truncated after JDK-8249672 11u backport In-Reply-To: <076c6acd-c7cb-2d56-a978-887409ade166@redhat.com> References: <89e2926e-1ab7-785f-343e-d7d841de1fbb@redhat.com> <076c6acd-c7cb-2d56-a978-887409ade166@redhat.com> Message-ID: On 4/22/21 12:06 PM, Aleksey Shipilev wrote: > On 4/20/21 7:23 PM, Aleksey Shipilev wrote: >> 11u-specific regression: >> https://bugs.openjdk.java.net/browse/JDK-8265537 >> >> See the details in the bug. >> >> 11u patch: >> >> diff -r 9846af5a0949 src/hotspot/cpu/x86/vm_version_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp Mon Apr 19 12:47:46 2021 +0200 >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp Tue Apr 20 19:23:24 2021 +0200 >> @@ -743,11 +743,11 @@ >> if (is_knights_family()) { >> _features &= ~CPU_VZEROUPPER; >> } >> } >> >> - char buf[256]; >> + char buf[512]; >> jio_snprintf(buf, sizeof(buf), >> "(%u cores per cpu, %u threads per core) family %d model %d stepping %d microcode 0x%x" >> "%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s", >> cores_per_cpu(), threads_per_core(), >> cpu_family(), _model, _stepping, os::cpu_microcode_revision(), >> >> Testing: compiler/intrinsics/sha tests (now pass); tier1 > > Goetz, (since you were the author of that 11u backport,) you are fine with this patch, right? Ping? :) -- Thanks, -Aleksey From github.com+20224954+gdams at openjdk.java.net Mon Apr 26 10:09:46 2021 From: github.com+20224954+gdams at openjdk.java.net (George Adams) Date: Mon, 26 Apr 2021 10:09:46 GMT Subject: [jdk16u] RFR: 8265531: doc/building.md should mention homebrew install freetype [v2] In-Reply-To: References: Message-ID: > Backport of 8265531: doc/building.md should mention homebrew install freetype George Adams 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. The pull request contains one new commit since the last revision: Backport 5aab1609b97284ccff8b7ae20a3ddcf1e29c47d7 ------------- Changes: - all: https://git.openjdk.java.net/jdk16u/pull/109/files - new: https://git.openjdk.java.net/jdk16u/pull/109/files/6e878894..745586a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=109&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=109&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/109.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/109/head:pull/109 PR: https://git.openjdk.java.net/jdk16u/pull/109 From linzang at tencent.com Mon Apr 26 11:10:16 2021 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Mon, 26 Apr 2021 11:10:16 +0000 Subject: [Discuss] backport - parallel heap inspection for different GC Heap(Internet mail) In-Reply-To: References: Message-ID: <59241b4ced8e54a8b60a473eda3dd0913657328f.camel@tencent.com> Dear All, Sorry that we delayed this too much! Recently we have implemented the parallel heap inspection support for CMS in JDK11. Bin(Buddy) and I will start with backport to JDK11u, and we are planning support parallelScavenge, CMS, G1. BRs, Lin On Thu, 2020-11-12 at 16:05 +0000, 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(??)" < > jdk-updates-dev-retn at openjdk.java.net on behalf of > linzang at tencent.com> 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 yan at openjdk.java.net Mon Apr 26 11:37:52 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 26 Apr 2021 11:37:52 GMT Subject: [jdk15u-dev] RFR: 8256810: Incremental rebuild broken on Macosx Message-ID: <1aCK1MTjzpYOV_olxUzGkqjVIEVyTGDHjjIWnoMWtIk=.0e472790-d301-4038-86fc-73c145664db3@github.com> This should be fixed in 15u, too, and after that, fix JDK-8257547 ------------- Commit messages: - Backport 4c86e46d75f6703aeab165df9c4068a76786d538 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/33/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=33&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256810 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/33/head:pull/33 PR: https://git.openjdk.java.net/jdk15u-dev/pull/33 From yan at openjdk.java.net Mon Apr 26 11:52:54 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 26 Apr 2021 11:52:54 GMT Subject: [jdk15u-dev] Integrated: 8256751: Incremental rebuild with precompiled header fails when touching a header file Message-ID: Let's try to file this PR _after_ (not yet integrated) PR for its right successor 8256810: hope it works. All patches apply clean, in the right order. ------------- Commit messages: - Backport 19b2898691f945f0d6257e88ec74e291d5d7f277 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/34/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=34&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256751 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/34.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/34/head:pull/34 PR: https://git.openjdk.java.net/jdk15u-dev/pull/34 From yan at openjdk.java.net Mon Apr 26 11:52:55 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 26 Apr 2021 11:52:55 GMT Subject: [jdk15u-dev] Integrated: 8256751: Incremental rebuild with precompiled header fails when touching a header file In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 11:44:14 GMT, Yuri Nesterenko wrote: > Let's try to file this PR _after_ (not yet integrated) PR for its right successor 8256810: hope it works. All patches apply clean, in the right order. This pull request has now been integrated. Changeset: 70230e22 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/70230e22 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8256751: Incremental rebuild with precompiled header fails when touching a header file Backport-of: 19b2898691f945f0d6257e88ec74e291d5d7f277 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/34 From martin.doerr at sap.com Mon Apr 26 12:11:47 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 26 Apr 2021 12:11:47 +0000 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: References: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> <8c9fa29cb5818954c700b0d3d2b95c7d81df3114.camel@redhat.com>, Message-ID: <2D96F483-B750-4D21-BDFF-A856E8ED18DB@sap.com> Backout change looks good. jdk-fix-request label should get added. Best regards, Martin > Am 23.04.2021 um 19:34 schrieb Jaroslav Bachor?k : > > ?On Fri, Apr 23, 2021 at 7:22 PM Severin Gehwolf wrote: >> >>> On Fri, 2021-04-23 at 18:57 +0200, Jaroslav Bachor?k wrote: >>> In 16 and 17 this crash is not happening. >> >> Why? > > I assume because the safepoint assumptions are slightly different? > The fix for jdk head was pushed more than a month ago. The push was > done by Markus Gronlund and I assume he wouldn't have pushed that > without going through the whole shebang of Oracle internal test rigs. > The backport for 16u is identical to 17. All the affected code in JFR > is identical. Although there still might be a chance for error the > same test that failed in 11u did pass for 16 as a part of the > pre-commit GH actions. > > AFAICT, the issue we are talking about was filed as a reaction to > failure observed in 11u. The adjustments for the differences between > JDK head and 11u are the most likely the cause of this failure. There > is no indication this should apply to any other version than 11u > unless I am missing something. > > Cheers, > > -JB- > >> >> Thanks, >> Severin >> >> From yan at openjdk.java.net Mon Apr 26 12:11:59 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 26 Apr 2021 12:11:59 GMT Subject: [jdk15u-dev] Integrated: 8256810: Incremental rebuild broken on Macosx In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 12:02:54 GMT, Yuri Nesterenko wrote: > This should be fixed in 15u, too, before JDK-8257547. This pull request has now been integrated. Changeset: 12951437 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/12951437 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod 8256810: Incremental rebuild broken on Macosx Backport-of: 4c86e46d75f6703aeab165df9c4068a76786d538 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/35 From yan at openjdk.java.net Mon Apr 26 12:11:59 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 26 Apr 2021 12:11:59 GMT Subject: [jdk15u-dev] Integrated: 8256810: Incremental rebuild broken on Macosx Message-ID: This should be fixed in 15u, too, before JDK-8257547. ------------- Commit messages: - Backport 4c86e46d75f6703aeab165df9c4068a76786d538 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/35/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=35&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256810 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/35.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/35/head:pull/35 PR: https://git.openjdk.java.net/jdk15u-dev/pull/35 From yan at openjdk.java.net Mon Apr 26 12:17:33 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 26 Apr 2021 12:17:33 GMT Subject: [jdk15u-dev] Withdrawn: 8256810: Incremental rebuild broken on Macosx In-Reply-To: <1aCK1MTjzpYOV_olxUzGkqjVIEVyTGDHjjIWnoMWtIk=.0e472790-d301-4038-86fc-73c145664db3@github.com> References: <1aCK1MTjzpYOV_olxUzGkqjVIEVyTGDHjjIWnoMWtIk=.0e472790-d301-4038-86fc-73c145664db3@github.com> Message-ID: On Mon, 26 Apr 2021 11:31:53 GMT, Yuri Nesterenko wrote: > This should be fixed in 15u, too, and after that, fix JDK-8257547 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/33 From sgehwolf at redhat.com Mon Apr 26 13:51:08 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Apr 2021 15:51:08 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: References: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> Message-ID: <40fa4ea83aef5bfd35f623cab16a58b183037201.camel@redhat.com> Hi Jaroslav, On Fri, 2021-04-23 at 18:57 +0200, Jaroslav Bachor?k wrote: > This 11u only problem. In 16 and 17 this crash is not happening. The > bug has 'Affects Version/s' set to 11 - is there anything else that > should be set there? No, not any more. Thanks! The -na labels are a good way to indicate a version specific bug. Also setting the Fix Version to the specific JDK version this is intended to be fixed first. Finally, explaining in the bug description that it's a 11-only bug is helpful too. 'Affects Version/s' isn't usually a complete list and I take it with a grain of salt. In this case, I understood it as: "Reproducible on JDK 11. JDK 17 hasn't been looked at in terms of applicability" HTH. Thanks, Severin From sgehwolf at redhat.com Mon Apr 26 13:52:50 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Apr 2021 15:52:50 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: References: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> <8c9fa29cb5818954c700b0d3d2b95c7d81df3114.camel@redhat.com> Message-ID: <47f362b00feca01901e7765dc0ba67ce4ee37dec.camel@redhat.com> On Fri, 2021-04-23 at 19:34 +0200, Jaroslav Bachor?k wrote: > On Fri, Apr 23, 2021 at 7:22 PM Severin Gehwolf wrote: > > > > On Fri, 2021-04-23 at 18:57 +0200, Jaroslav Bachor?k wrote: > > > In 16 and 17 this crash is not happening. > > > > Why? > > I assume because the safepoint assumptions are slightly different? > The fix for jdk head was pushed more than a month ago. The push was > done by Markus Gronlund and I assume he wouldn't have pushed that > without going through the whole shebang of Oracle internal test rigs. > The backport for 16u is identical to 17. All the affected code in JFR > is identical. Although there still might be a chance for error the > same test that failed in 11u did pass for 16 as a part of the > pre-commit GH actions. > > AFAICT, the issue we are talking about was filed as a reaction to > failure observed in 11u. The adjustments for the differences between > JDK head and 11u are the most likely the cause of this failure. There > is no indication this should apply to any other version than 11u > unless I am missing something. OK. Thanks, Severin From sgehwolf at redhat.com Mon Apr 26 13:56:54 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Apr 2021 15:56:54 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: References: Message-ID: On Fri, 2021-04-23 at 17:43 +0200, Jaroslav Bachor?k wrote: > Webrev: http://cr.openjdk.java.net/~jbachorik/8265750/webrev/ So this backs out JDK-8258414 and JDK-8265718 from OpenJDK 11.0.12 (jdk11u-dev only problem). Doing a backout of the two changesets amounts to the same patch as above. Looks good. Thanks, Severin From yan at openjdk.java.net Mon Apr 26 17:38:29 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 26 Apr 2021 17:38:29 GMT Subject: [jdk15u-dev] RFR: 8257547: Handle multiple prereqs on the same line in deps files Message-ID: The patch goes without adjustments. This fix is third in the series. ------------- Commit messages: - Backport 36209b70daf4df54435b6acd7092b77d2b5053df Changes: https://git.openjdk.java.net/jdk15u-dev/pull/36/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=36&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257547 Stats: 85 lines in 3 files changed: 80 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/36/head:pull/36 PR: https://git.openjdk.java.net/jdk15u-dev/pull/36 From vkempik at openjdk.java.net Mon Apr 26 17:38:34 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 26 Apr 2021 17:38:34 GMT Subject: [jdk15u-dev] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm Message-ID: <-7C9mn-OlA2CT1_UUqzeqfCseOhfdoNPe8nssynQnq4=.a8ff9440-a086-48b8-a635-2c1a9c157333@github.com> After the patch applied, minos version for libjvm.dylib is on par with other libraries Applies almost clean, only context code difference in patch. ------------- Commit messages: - Backport 51d325e613bfcf7f8016ba6d8b146afec6f0f85c Changes: https://git.openjdk.java.net/jdk15u-dev/pull/37/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=37&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257633 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk15u-dev/pull/37 From yan at openjdk.java.net Mon Apr 26 17:53:38 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 26 Apr 2021 17:53:38 GMT Subject: [jdk15u-dev] Integrated: 8257547: Handle multiple prereqs on the same line in deps files In-Reply-To: References: Message-ID: <8YsLrxq0NFpvHdSgrDZHrVsLa1baEYYjzAIKd9iHvfo=.e19b2c93-1fc0-46f5-a5e7-9de249e5cd71@github.com> On Mon, 26 Apr 2021 14:33:39 GMT, Yuri Nesterenko wrote: > The patch goes without adjustments. This fix is third in the series. This pull request has now been integrated. Changeset: a92bbe82 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/a92bbe82 Stats: 85 lines in 3 files changed: 80 ins; 0 del; 5 mod 8257547: Handle multiple prereqs on the same line in deps files Backport-of: 36209b70daf4df54435b6acd7092b77d2b5053df ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/36 From vkempik at openjdk.java.net Mon Apr 26 18:04:37 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 26 Apr 2021 18:04:37 GMT Subject: [jdk15u-dev] Integrated: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm In-Reply-To: <-7C9mn-OlA2CT1_UUqzeqfCseOhfdoNPe8nssynQnq4=.a8ff9440-a086-48b8-a635-2c1a9c157333@github.com> References: <-7C9mn-OlA2CT1_UUqzeqfCseOhfdoNPe8nssynQnq4=.a8ff9440-a086-48b8-a635-2c1a9c157333@github.com> Message-ID: On Mon, 26 Apr 2021 14:47:51 GMT, Vladimir Kempik wrote: > Please review this backport to jdk15u > After the patch applied, minOS version for libjvm.dylib is on par with other libraries > Applies almost clean, only context code difference in patch. This pull request has now been integrated. Changeset: 981267e7 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/981267e7 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8257633: Missing -mmacosx-version-min=X flag when linking libjvm Backport-of: 51d325e613bfcf7f8016ba6d8b146afec6f0f85c ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/37 From zgu at openjdk.java.net Mon Apr 26 18:58:48 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 26 Apr 2021 18:58:48 GMT Subject: [jdk16u] RFR: 8265239: Shenandoah: Shenandoah heap region count could be off by 1 Message-ID: <4gX1MDzg8uD2mx_Ee317259s2FQrCJTWEWFnrUuaJtY=.cf0d82b1-14a0-4bd1-97d9-79a85873af4a@github.com> 8265239: Shenandoah: Shenandoah heap region count could be off by 1 ------------- Commit messages: - Backport 5a526c1c5716f6d9a7fc94741bcdb2f424d342df Changes: https://git.openjdk.java.net/jdk16u/pull/110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=110&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265239 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/110.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/110/head:pull/110 PR: https://git.openjdk.java.net/jdk16u/pull/110 From vkempik at openjdk.java.net Mon Apr 26 20:48:48 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 26 Apr 2021 20:48:48 GMT Subject: [jdk15u-dev] RFR: 8256633: Fix product build on Windows+Arm64 Message-ID: Clean backport of 8256633 to jdk15. ------------- Commit messages: - Backport f57662874afe03250050b88ced07eb480484802b Changes: https://git.openjdk.java.net/jdk15u-dev/pull/38/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=38&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256633 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/38.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/38/head:pull/38 PR: https://git.openjdk.java.net/jdk15u-dev/pull/38 From vkempik at openjdk.java.net Tue Apr 27 08:26:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 27 Apr 2021 08:26:47 GMT Subject: [jdk15u-dev] Integrated: 8256633: Fix product build on Windows+Arm64 In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 20:43:26 GMT, Vladimir Kempik wrote: > Clean backport of 8256633 to jdk15. This pull request has now been integrated. Changeset: 9b0ba2a2 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/9b0ba2a2 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8256633: Fix product build on Windows+Arm64 Backport-of: f57662874afe03250050b88ced07eb480484802b ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/38 From vkempik at openjdk.java.net Tue Apr 27 08:46:54 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 27 Apr 2021 08:46:54 GMT Subject: [jdk13u-dev] RFR: 8256633: Fix product build on Windows+Arm64 Message-ID: <_-N7ecRBQErdLvmMk7sWOIoe5l-D1bSX_-qNfv12D_U=.1be85cfd-60c2-42f6-af91-8d527879e1ab@github.com> Clean backport to jdk13u-dev ------------- Commit messages: - Backport f57662874afe03250050b88ced07eb480484802b Changes: https://git.openjdk.java.net/jdk13u-dev/pull/190/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=190&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256633 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/190/head:pull/190 PR: https://git.openjdk.java.net/jdk13u-dev/pull/190 From vkempik at openjdk.java.net Tue Apr 27 09:03:35 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 27 Apr 2021 09:03:35 GMT Subject: [jdk13u-dev] Integrated: 8256633: Fix product build on Windows+Arm64 In-Reply-To: <_-N7ecRBQErdLvmMk7sWOIoe5l-D1bSX_-qNfv12D_U=.1be85cfd-60c2-42f6-af91-8d527879e1ab@github.com> References: <_-N7ecRBQErdLvmMk7sWOIoe5l-D1bSX_-qNfv12D_U=.1be85cfd-60c2-42f6-af91-8d527879e1ab@github.com> Message-ID: On Tue, 27 Apr 2021 08:37:44 GMT, Vladimir Kempik wrote: > Clean backport to jdk13u-dev This pull request has now been integrated. Changeset: ea0df93b Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/ea0df93b Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8256633: Fix product build on Windows+Arm64 Backport-of: f57662874afe03250050b88ced07eb480484802b ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/190 From dcherepanov at openjdk.java.net Tue Apr 27 12:17:33 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 27 Apr 2021 12:17:33 GMT Subject: [jdk15u-dev] RFR: 8261170: Upgrade to FreeType 2.10.4 Message-ID: Request to backport for parity with 11u. Applies cleanly. ------------- Commit messages: - Backport 228c2857154cd6208cfbbe024a65ef31016e2ec4 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/39/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=39&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261170 Stats: 4253 lines in 265 files changed: 1642 ins; 1368 del; 1243 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/39/head:pull/39 PR: https://git.openjdk.java.net/jdk15u-dev/pull/39 From dcherepanov at openjdk.java.net Tue Apr 27 12:42:38 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 27 Apr 2021 12:42:38 GMT Subject: [jdk13u-dev] RFR: 8261170: Upgrade to FreeType 2.10.4 Message-ID: <7i3h1l-RvSkkIlmKvXmy4azuZ8kubVLCm_Ebeu9ByDQ=.7c007710-55bf-4632-a2d0-f8e513bc4011@github.com> 8261170: Upgrade to FreeType 2.10.4 ------------- Commit messages: - Backport 228c2857154cd6208cfbbe024a65ef31016e2ec4 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=191&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261170 Stats: 4253 lines in 265 files changed: 1642 ins; 1368 del; 1243 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/191.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/191/head:pull/191 PR: https://git.openjdk.java.net/jdk13u-dev/pull/191 From vkempik at azul.com Tue Apr 27 12:44:27 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 27 Apr 2021 12:44:27 +0000 Subject: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes In-Reply-To: References: <3BBDEB11-6FE8-4F93-BCDE-155132DF935A@azul.com> <8E3BF025-A532-499B-9E09-9F92C5911F42@azul.com> Message-ID: Hello Any credible "gc experts" left on this mailing list ? Or can we go forward with a single review from JohnC ? Thanks in advance, Vladimir. > 23 ???. 2020 ?., ? 21:12, Langer, Christoph ???????(?): > > Hi Aleksey, > > I'm wondering whether you could give an assessment about these changes, similar to what you've done regarding the proposed backport of JEP 346? I would hope this one would be less effort... > > Thanks > Christoph > >> -----Original Message----- >> From: Vladimir Kempik >> Sent: Dienstag, 13. Oktober 2020 22:01 >> To: Langer, Christoph >> Cc: John Cuthbertson ; Andrew Haley >> ; Severin Gehwolf ; Aleksey >> Shipilev ; jdk-updates-dev at openjdk.java.net >> Subject: Re: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes >> >> Hello >> >> Any objections about these patches ? >> >> Regards, Vladimir. >> >>> 17 ????. 2020 ?., ? 11:24, Vladimir Kempik >> ???????(?): >>> >>> Hello Langer >>> >>>> Another thing: Looking at JBS I can see that JDK-8208498 was marked as a >> blocker for JDK-8209061 and the former hasn't been backported to 11. Is that >> an issue >>>> Generally, would it be possible to fix the issue of JDK-8207200 in a way >> that's less invasive? >>> >>> well, I have tried to make 8207200 less invasive by not including 8208498. >>> >>> There is a race condition in g1 monitoring which still can be see by some >> openjdk11 users ( commited < used) and this is the attempt to fix it. >>> I have verified it helps at least one user. Sadly I don?t have a reproducer. >>> >>> Regards, Vladimir >>> >>> >>>> 17 ????. 2020 ?., ? 10:43, Langer, Christoph >> ???????(?): >>>> >>>> Hi, >>>> >>>> I've just looked at approving this series of backports (JDK-8209061, JDK- >> 8209062 and JDK-8207200). >>>> >>>> While I'm sure that JDK-8207200 fixes an important issue and I also trust >> your reviews of the backports, I can see that these 3 patches together mean >> some significant changes in the area of G1 GC. This makes me kind of >> hesitant to approve the backports right away. I'd like to get some >> assessment/reassurance of the other JDK11 maintainers (aph, sgehwolf) on >> whether we should admit them or not? >>>> >>>> Also, Aleksey, maybe you can give some technical advice as a gc expert if >> you think these backports are feasible? >>>> >>>> Another thing: Looking at JBS I can see that JDK-8208498 was marked as a >> blocker for JDK-8209061 and the former hasn't been backported to 11. Is that >> an issue? >>>> >>>> Generally, would it be possible to fix the issue of JDK-8207200 in a way >> that's less invasive? >>>> >>>> Please understand that I'd like to err on the side of caution here... >>>> >>>> Thanks & Best regards >>>> Christoph >>>> >>>>> -----Original Message----- >>>>> From: jdk-updates-dev On >>>>> Behalf Of John Cuthbertson >>>>> Sent: Dienstag, 15. September 2020 19:07 >>>>> To: Vladimir Kempik >>>>> Cc: jdk-updates-dev at openjdk.java.net >>>>> Subject: Re: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport >> changes >>>>> >>>>> Hi Vladimir, >>>>> >>>>> On Sep 3, 2020, at 5:28 AM, Vladimir Kempik >>>>> > wrote: >>>>> >>>>> Hello >>>>> >>>>> Please review these backports of JDK-8209061:Move G1 serviceability >>>>> functionality to G1MonitoringSupport and JDK-8209062:Clean up >>>>> G1MonitoringSupport to jdk11u >>>>> >>>>> These backports are prerequestes for JDK-8207200 which we can see in >> the >>>>> wild with jdk8 and jdk11. >>>>> >>>>> JDK-8209061 and JDK-8209062 applies mostly clean, very few places >> where it >>>>> wasn?t clean due to surrounding code or code layout. >>>>> >>>>> after these two, JDK-8207200 applies cleanly. >>>>> >>>>> Testing: tier1. >>>>> >>>>> The webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~vkempik/8209061/webrev.00/ >>>>> >>>>> This looks good to me and matches >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec. >>>>> >>>>> http://cr.openjdk.java.net/~vkempik/8209062/webrev.00/ >>>>> >>>>> This looks good to me also and matches >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046. >>>>> >>>>> >>>>> All mentioned bugs: >>>>> https://bugs.openjdk.java.net/browse/JDK-8209062 >>>>> https://bugs.openjdk.java.net/browse/JDK-8209061 >>>>> https://bugs.openjdk.java.net/browse/JDK-8207200 >>>>> >>>>> Original changesets: >>>>> 8209061: http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec >>>>> 8209062: http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046 >>>>> >>>>> Thanks, Vladimir >>>>> >>>>> Regards, >>>>> >>>>> JohnC >>> > From dcherepanov at openjdk.java.net Tue Apr 27 14:34:49 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 27 Apr 2021 14:34:49 GMT Subject: [jdk15u-dev] Integrated: 8261170: Upgrade to FreeType 2.10.4 In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 12:10:23 GMT, Dmitry Cherepanov wrote: > Request to backport for parity with 11u. Applies cleanly. This pull request has now been integrated. Changeset: d79cd94d Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk15u-dev/commit/d79cd94d Stats: 4253 lines in 265 files changed: 1642 ins; 1368 del; 1243 mod 8261170: Upgrade to FreeType 2.10.4 Backport-of: 228c2857154cd6208cfbbe024a65ef31016e2ec4 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/39 From dcherepanov at openjdk.java.net Tue Apr 27 14:36:46 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 27 Apr 2021 14:36:46 GMT Subject: [jdk13u-dev] Integrated: 8261170: Upgrade to FreeType 2.10.4 In-Reply-To: <7i3h1l-RvSkkIlmKvXmy4azuZ8kubVLCm_Ebeu9ByDQ=.7c007710-55bf-4632-a2d0-f8e513bc4011@github.com> References: <7i3h1l-RvSkkIlmKvXmy4azuZ8kubVLCm_Ebeu9ByDQ=.7c007710-55bf-4632-a2d0-f8e513bc4011@github.com> Message-ID: On Tue, 27 Apr 2021 12:33:00 GMT, Dmitry Cherepanov wrote: > 8261170: Upgrade to FreeType 2.10.4 This pull request has now been integrated. Changeset: ec9f4bd0 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/ec9f4bd0 Stats: 4253 lines in 265 files changed: 1642 ins; 1368 del; 1243 mod 8261170: Upgrade to FreeType 2.10.4 Backport-of: 228c2857154cd6208cfbbe024a65ef31016e2ec4 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/191 From jaroslav.bachorik at datadoghq.com Tue Apr 27 16:03:34 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 27 Apr 2021 18:03:34 +0200 Subject: RFR: 8265750: Fatal error in safepoint.cpp after backport of 8258414 In-Reply-To: <40fa4ea83aef5bfd35f623cab16a58b183037201.camel@redhat.com> References: <59a4f197e7d6e15c21ca158e82abafa3d277f9f8.camel@redhat.com> <40fa4ea83aef5bfd35f623cab16a58b183037201.camel@redhat.com> Message-ID: Hi Severin, On Mon, Apr 26, 2021 at 3:51 PM Severin Gehwolf wrote: > > Hi Jaroslav, > > On Fri, 2021-04-23 at 18:57 +0200, Jaroslav Bachor?k wrote: > > This 11u only problem. In 16 and 17 this crash is not happening. The > > bug has 'Affects Version/s' set to 11 - is there anything else that > > should be set there? > > No, not any more. Thanks! > > The -na labels are a good way to indicate a version > specific bug. Also setting the Fix Version to the specific JDK version > this is intended to be fixed first. Finally, explaining in the bug > description that it's a 11-only bug is helpful too. 'Affects Version/s' > isn't usually a complete list and I take it with a grain of salt. In > this case, I understood it as: "Reproducible on JDK 11. JDK 17 hasn't > been looked at in terms of applicability" Thanks for the explanation! I have added the jdk11u-fix-request label as requested. Cheers, -JB- > > HTH. > > Thanks, > Severin > From david.buck at oracle.com Wed Apr 28 05:07:09 2021 From: david.buck at oracle.com (David Buck) Date: Wed, 28 Apr 2021 05:07:09 +0000 Subject: question about JDK-8172231: SPARC CPU features detection In-Reply-To: References: <82F0DDEB-9103-4280-A7BC-1C67916DFDAA@azul.com> <69C42B8E-5761-4216-A572-3E3BC3D6226E@azul.com> Message-ID: Hi Goetz! Our fix looked something like below. Note the following diff also includes JDK-8263407 [1]. === diff --git a/src/hotspot/cpu/sparc/vm_version_sparc.cpp b/src/hotspot/cpu/sparc/vm_version_sparc.cpp --- a/src/hotspot/cpu/sparc/vm_version_sparc.cpp +++ b/src/hotspot/cpu/sparc/vm_version_sparc.cpp @@ -160,7 +160,8 @@ void VM_Version::initialize() { // Use compare and branch instructions if available. if (has_cbcond()) { - if (FLAG_IS_DEFAULT(UseCBCond)) { + // cbcond suspected to cause issues on Athena CPUs + if (FLAG_IS_DEFAULT(UseCBCond) && !is_athena()) { FLAG_SET_DEFAULT(UseCBCond, true); } } else if (UseCBCond) { @@ -218,7 +219,7 @@ void VM_Version::initialize() { char buf[512]; jio_snprintf(buf, sizeof(buf), - "%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s" + "%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s" "%s%s%s%s%s%s%s%s%s" "%s%s%s%s%s%s%s%s%s" "%s%s%s%s%s%s%s", (has_v9() ? "v9" : ""), @@ -228,6 +229,7 @@ void VM_Version::initialize() { (has_blk_init() ? ", blk_init" : ""), (has_fmaf() ? ", fmaf" : ""), (has_hpc() ? ", hpc" : ""), + (has_athena() ? ", athena" : ""), (has_ima() ? ", ima" : ""), (has_aes() ? ", aes" : ""), (has_des() ? ", des" : ""), diff --git a/src/hotspot/cpu/sparc/vm_version_sparc.hpp b/src/hotspot/cpu/sparc/vm_version_sparc.hpp --- a/src/hotspot/cpu/sparc/vm_version_sparc.hpp +++ b/src/hotspot/cpu/sparc/vm_version_sparc.hpp @@ -42,6 +42,7 @@ protected: ISA_FMAF, ISA_VIS3, ISA_HPC, + ISA_FJATHHPC, ISA_IMA, ISA_AES, ISA_DES, @@ -104,6 +105,7 @@ private: ISA_fmaf_msk = UINT64_C(1) << ISA_FMAF, ISA_vis3_msk = UINT64_C(1) << ISA_VIS3, ISA_hpc_msk = UINT64_C(1) << ISA_HPC, + ISA_fjathhpc_msk = UINT64_C(1) << ISA_FJATHHPC, ISA_ima_msk = UINT64_C(1) << ISA_IMA, ISA_aes_msk = UINT64_C(1) << ISA_AES, ISA_des_msk = UINT64_C(1) << ISA_DES, @@ -253,6 +255,7 @@ public: static bool has_fmaf() { return (_features & ISA_fmaf_msk) != 0; } static bool has_vis3() { return (_features & ISA_vis3_msk) != 0; } static bool has_hpc() { return (_features & ISA_hpc_msk) != 0; } + static bool has_athena() { return (_features & ISA_fjathhpc_msk) != 0; } static bool has_ima() { return (_features & ISA_ima_msk) != 0; } static bool has_aes() { return (_features & ISA_aes_msk) != 0; } static bool has_des() { return (_features & ISA_des_msk) != 0; } @@ -306,6 +309,10 @@ public: return (_features & niagara2_msk) == niagara2_msk; } + static bool is_athena() { + return has_athena() || has_athena_plus() || has_athena_plus2(); + } + // Default prefetch block size on SPARC. static uint prefetch_data_size() { return L2_data_cache_line_size(); } diff --git a/src/hotspot/os_cpu/solaris_sparc/vm_version_solaris_sparc.cpp b/src/hotspot/os_cpu/solaris_sparc/vm_version_solaris_sparc.cpp --- a/src/hotspot/os_cpu/solaris_sparc/vm_version_solaris_sparc.cpp +++ b/src/hotspot/os_cpu/solaris_sparc/vm_version_solaris_sparc.cpp @@ -355,12 +355,17 @@ void VM_Version::platform_features() { #ifndef AV_SPARC_FMAF #define AV_SPARC_FMAF 0x00000100 // Fused Multiply-Add +#endif + +#ifndef AV_SPARC_FJATHHPC +#define AV_SPARC_FJATHHPC 0x00001000 // Fujitsu HPC (Athena) instrs #endif if (av & AV_SPARC_ASI_BLK_INIT) features |= ISA_blk_init_msk; if (av & AV_SPARC_FMAF) features |= ISA_fmaf_msk; if (av & AV_SPARC_VIS3) features |= ISA_vis3_msk; if (av & AV_SPARC_HPC) features |= ISA_hpc_msk; + if (av & AV_SPARC_FJATHHPC) features |= ISA_fjathhpc_msk; if (av & AV_SPARC_IMA) features |= ISA_ima_msk; if (av & AV_SPARC_AES) features |= ISA_aes_msk; if (av & AV_SPARC_DES) features |= ISA_des_msk; @@ -460,14 +465,13 @@ void VM_Version::platform_features() { Sysinfo machine(SI_MACHINE); - bool is_sun4v = machine.match("sun4v"); // All Oracle SPARC + Fujitsu Athena+/++ + bool is_sun4v = machine.match("sun4v"); // All Oracle SPARC + Fujitsu Athena(+/++) bool is_sun4u = machine.match("sun4u"); // All other Fujitsu - // Handle Athena+/++ conservatively (simply because we are lacking info.). + // Handle Athena(+/++) conservatively (simply because we are lacking info.). - bool an_athena = has_athena_plus() || has_athena_plus2(); - bool do_sun4v = is_sun4v && !an_athena; - bool do_sun4u = is_sun4u || an_athena; + bool do_sun4v = is_sun4v && !is_athena(); + bool do_sun4u = is_sun4u || is_athena(); uint64_t synthetic = 0; === Cheers, -Buck [1] https://bugs.openjdk.java.net/browse/JDK-8263407 -----Original Message----- From: Lindenmaier, Goetz Sent: Tuesday, April 20, 2021 3:43 PM To: David Buck ; Ilarion Nakonechnyy ; jdk-updates-dev at openjdk.java.net Subject: [External] : RE: question about JDK-8172231: SPARC CPU features detection Hi David, do you mind sharing the patch? As the change was made in OracleJDK, we can not reach the changeset from JBS. Thanks! Goetz > -----Original Message----- > From: jdk-updates-dev On > Behalf Of David Buck > Sent: Tuesday, April 20, 2021 4:26 AM > To: Ilarion Nakonechnyy ; jdk-updates- > dev at openjdk.java.net > Subject: RE: question about JDK-8172231: SPARC CPU features detection > > Hi Ilarion! > > The OpenJDK community may want to consider a fix similar to what we > did in Oracle JDK 11 [0]. > > Cheers, > -Buck > > [0] https://bugs.openjdk.java.net/browse/JDK-8263407 > > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ilarion Nakonechnyy > Sent: Tuesday, April 20, 2021 4:21 AM > To: jdk-updates-dev at openjdk.java.net > Subject: FW: question about JDK-8172231: SPARC CPU features detection > > Dear sirs, good day. > My name is Ilarion, I?m new contributor for OpenJDK project. > > I have some questions about implementation of fix for bug JDK-8172231: > SPARC CPU features detection, probably somebody may shed some lights > on it. > > I?m doing my exercises on JDK 11 and noticed that on exact SPARC CPU > block zeroing detection feature determines wrong. > Having system with SPARC64-X CPU, java fails with segmentation > violation error, on the very beginning of the java run. > My investigations lead me to MacroAssembler::bis_zeroing() routine. > Where begin and end of memory area is cleared by stx instruction, and > the rest ? via stxa(G0, to, G0, Assembler::ASI_ST_BLKINIT_PRIMARY), > that supposed to zeroing memory, but it doesn?t. > Turning off block zeroing feature via flag -XX:-UseBlockZeroing helps > to avoid the crash. > > > > > Decision if CPU has the CPU_blk_zeroing_msk feature based on > determining another cpu flag, ISA_ima_msk > > + // Niagara Core S3 supports fast RDPC and block zeroing. > > + if (has_ima()) { > > + synthetic |= (CPU_fast_rdpc_msk | CPU_blk_zeroing_msk); > > + } > > But there is also mentioned special flag, that corresponds to Block > initialization feature: ISA_blk_init_msk. That actually isn?t checked at all. > ( Other than in reporting ) I looked in JDK 8, and figured out, that > block zeroing capacity there was decided not only by ISA flags, but > with referring on CPU model also: > > - // On T4 and newer Sparc BIS to the beginning of cache line always zeros it. > > - static bool has_block_zeroing() { return has_blk_init() && is_T4(); } > > > JDK 8 works well for my case, because BIS instruction isn?t used > Despite ISA flags that is returned by getisax reports that block > initialization is supported ( AV_SPARC_ASI_BLK_INIT 0x0080 ) > > [0.172s][info][os,cpu ] getisax(2) returned 1 words: > > [0.172s][info][os,cpu ] word 0: 0xc001b1f0 > > So, as I can see, the CPU version ( ?cpu brand? in jdk 8 ) has main > role in detecting CPU block zeroing feature. > Do you have some more information, probably any doc, where noted why > CPU version plays such a role in feature detecting for JVM? In CPU > specifications I didn?t found any clues about this. > Thank you in advance. From dcherepanov at openjdk.java.net Wed Apr 28 09:44:20 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 28 Apr 2021 09:44:20 GMT Subject: [jdk15u-dev] RFR: 8260380: Upgrade to LittleCMS 2.12 Message-ID: Request to backport for parity with 11u. Applies cleanly. ------------- Commit messages: - Backport 4caeb39f01b13b5472d8dacb268262fd418fd0c4 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/40/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=40&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260380 Stats: 717 lines in 20 files changed: 249 ins; 286 del; 182 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/40.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/40/head:pull/40 PR: https://git.openjdk.java.net/jdk15u-dev/pull/40 From dcherepanov at openjdk.java.net Wed Apr 28 09:53:06 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 28 Apr 2021 09:53:06 GMT Subject: [jdk13u-dev] RFR: 8260380: Upgrade to LittleCMS 2.12 Message-ID: <_6pCQRAipbPVevatYZswj8rIRM9hQjUV_zcMreaK78k=.d4488109-afdd-49ec-8000-ec3a18c83d8f@github.com> Request to backport for parity with 11u. Applies cleanly. ------------- Commit messages: - Backport 4caeb39f01b13b5472d8dacb268262fd418fd0c4 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/192/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=192&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260380 Stats: 717 lines in 20 files changed: 249 ins; 286 del; 182 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/192.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/192/head:pull/192 PR: https://git.openjdk.java.net/jdk13u-dev/pull/192 From snazarki at openjdk.java.net Wed Apr 28 10:18:24 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 28 Apr 2021 10:18:24 GMT Subject: [jdk13u-dev] RFR: 8264821: DirectIOTest fails on a system with large block size Message-ID: Please review the backport of the fix for 8264821. The test failed on FS with rw block larger than 4k. The fix doesn't apply cleanly due to missed "8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports". Changes were made manually - copyright year - isDirectIOSupportedByFS remains in the code Related JDK-8265231 is not necessary since public method is not removed. ------------- Commit messages: - Backport 7e4cd480206891550828d1fdfebae57ecc19ed37 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=193&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264821 Stats: 25 lines in 1 file changed: 8 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk13u-dev/pull/193 From yan at openjdk.java.net Wed Apr 28 11:21:16 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 28 Apr 2021 11:21:16 GMT Subject: [jdk15u-dev] Integrated: 8255845: Memory leak in imageFile.cpp Message-ID: The patch applies clean. Tested with tier1 and jlink tests, no regressions found. ------------- Commit messages: - Backport 66a2e70985fcdb8e0b91b05fbeae825db6ae9c78 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=41&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255845 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/41/head:pull/41 PR: https://git.openjdk.java.net/jdk15u-dev/pull/41 From yan at openjdk.java.net Wed Apr 28 11:21:17 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 28 Apr 2021 11:21:17 GMT Subject: [jdk15u-dev] Integrated: 8255845: Memory leak in imageFile.cpp In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 11:13:11 GMT, Yuri Nesterenko wrote: > The patch applies clean. Tested with tier1 and jlink tests, no regressions found. This pull request has now been integrated. Changeset: 9caa2902 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/9caa2902bb5f96b2144983d1865bb1d01adb912c Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8255845: Memory leak in imageFile.cpp Backport-of: 66a2e70985fcdb8e0b91b05fbeae825db6ae9c78 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/41 From snazarkin at azul.com Wed Apr 28 11:28:34 2021 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 28 Apr 2021 11:28:34 +0000 Subject: [11u] 8262465: DirectIOTest fails on a system with large block size Message-ID: <3FFEECB4-689F-4AA8-B96C-EC8CC5BE9166@azul.com> Hi! I?d like to back port this fix for DirectIOTest. The test is failed on FS with r/w blocks larger than 4k. The fix doesn?t apply cleanly due to missed "8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports?. Manual modification is required for - copyright year - isDirectIOSupportedByFS remains in the code Related backport of JDK-8265231is not required since no public functions are affected. Bug: https://bugs.openjdk.java.net/browse/JDK-8264821 Original fix: https://git.openjdk.java.net/jdk/commit/7e4cd480 Webrev: http://cr.openjdk.java.net/~snazarki/jdk11u/8264821/ From hohensee at amazon.com Wed Apr 28 16:50:11 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 28 Apr 2021 16:50:11 +0000 Subject: [11u] RFR (S): 8250876: Fix issues with cross-compile on macos Message-ID: <70672D79-66A4-4D66-B24F-3968EB1B48F4@amazon.com> Please review this backport to allow cross-compiles for macOS aarch64 builds. Patch has already been backported to 15u. Original issue: https://bugs.openjdk.java.net/browse/JDK-8250876 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/64490f533d62 11u webrev: http://cr.openjdk.java.net/~phh/8250876/webrev.11u.00/ The patch to toolchain.m4 required changing macros with a UTIL prefix to use a BASIC prefix. Otherwise clean. Tested by building on x64 macOS with Xcode 12. Thanks, Paul From kemperw at amazon.com Wed Apr 28 18:10:35 2021 From: kemperw at amazon.com (Kemper, William) Date: Wed, 28 Apr 2021 18:10:35 +0000 Subject: [11u] RFR 8246274 and 8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC In-Reply-To: <1619134073992.60757@amazon.com> References: <1619134073992.60757@amazon.com> Message-ID: <1619633435767.89897@amazon.com> Just to clarify, these patches applied cleanly from an internal JDK11 repository where they have been running in production since September, 2020. The original patches exported from 15 and 16 required minor modifications (renaming of g1_policy accessor, for example). Thanks, William ________________________________________ From: jdk-updates-dev on behalf of Kemper, William Sent: Thursday, April 22, 2021 4:27 PM To: jdk-updates-dev at openjdk.java.net Subject: [UNVERIFIED SENDER] [11u] RFR 8246274 and 8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC This fix went in originally as two changes, so there are two backports. Original bug: https://bugs.openjdk.java.net/browse/JDK-8245511 https://hg.openjdk.java.net/jdk/jdk/rev/d2eafcf20079 Depends on: https://bugs.openjdk.java.net/browse/JDK-8246274 https://hg.openjdk.java.net/jdk/jdk/rev/69c5e17adacd Patches applied cleanly. 11u webrev: https://cr.openjdk.java.net/~phh/8245511/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8246274/webrev.11u.01/? Testing: x86_64 build, tier1, tier1_gc, tier2 Thank you, William From dmitry.chuyko at bell-sw.com Wed Apr 28 19:00:06 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 28 Apr 2021 22:00:06 +0300 Subject: [11u] RFR (XXS) 8239386: handle ContendedPaddingWidth in vm_version_aarch64 Message-ID: Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8239386 Original patch applied with fuzz, so the hunk was manually put in the right place (after prefetch distance masking). 11u webrev: http://cr.openjdk.java.net/~dchuyko/8239386/webrev.11u.00/ Testing: tier1, tier2 (aarch64). Default ContendedPaddingWidth is still 128 on HW with smaller cache line. -- Thanks, -Dmitry From hohensee at amazon.com Wed Apr 28 20:17:08 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 28 Apr 2021 20:17:08 +0000 Subject: [11u] RFR (XXS) 8239386: handle ContendedPaddingWidth in vm_version_aarch64 Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Wednesday, April 28, 2021 at 12:00 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (XXS) 8239386: handle ContendedPaddingWidth in vm_version_aarch64 Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8239386 Original patch applied with fuzz, so the hunk was manually put in the right place (after prefetch distance masking). 11u webrev: http://cr.openjdk.java.net/~dchuyko/8239386/webrev.11u.00/ Testing: tier1, tier2 (aarch64). Default ContendedPaddingWidth is still 128 on HW with smaller cache line. -- Thanks, -Dmitry From eastig at amazon.co.uk Wed Apr 28 21:58:21 2021 From: eastig at amazon.co.uk (Astigeevich, Evgeny) Date: Wed, 28 Apr 2021 21:58:21 +0000 Subject: [11u] RFR 8226721: Missing intrinsics for Math.ceil, floor, rint Message-ID: Hi, Please review the backport of JDK-8226721to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8226721 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/6fc57e391539 The original patch does not apply cleanly to 11u. The update to the patch is to reposition the changes to five files: src/hotspot/cpu/x86/x86.ad src/hotspot/share/opto/library_call.cpp src/hotspot/share/opto/superword.cpp src/hotspot/share/opto/vectornode.cpp src/hotspot/share/opto/vectornode.hpp The content of the patch is not changed. 11u webrev: http://cr.openjdk.java.net/~eastigeevich/8226721/webrev.00/ Tested: Amazon Linux 2 x86_64, tier1, tier2, test/hotspot/jtreg/compiler/c2/cr6340864/TestDoubleVect.java Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153 Thanks, Evgeny Astigeevich Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. From norman.maurer at googlemail.com Thu Apr 29 07:19:17 2021 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 29 Apr 2021 09:19:17 +0200 Subject: Deadlock when loading JNI code after updating to openjdk 11.0.11 Message-ID: Hi there, I hope this is the right mailinglist if not please let me know which one it is?. In netty we have a bunch of JNI code that is loaded during initialisation. Yesterday a user reported that after upgrading from openjdk 11.0.10 to 11.0.11 he often see a deadlock while loading the JNI code. After looking at the stack trace it seems like all of this is really happening in ?java land? and so looks more like a openjdk bug / regression than a netty bug. Any idea what could have caused this ? All the details can be found in our issue tracker: https://github.com/netty/netty/issues/11209 I think the most important is the thread-dump which I include here to make things simple: [INFO] "main": [INFO] at java.util.zip.ZipFile.getEntry(java.base at 11.0.11/ZipFile.java:346) [INFO] - waiting to lock <0x00000000e119d0a8> (a java.util.jar.JarFile) [INFO] at java.util.zip.ZipFile$1.getEntry(java.base at 11.0.11/ZipFile.java:1126) [INFO] at java.util.jar.JarFile.getEntry0(java.base at 11.0.11/JarFile.java:578) [INFO] at java.util.jar.JarFile.getEntry(java.base at 11.0.11/JarFile.java:508) [INFO] at java.util.jar.JarFile.getJarEntry(java.base at 11.0.11/JarFile.java:470) [INFO] at jdk.internal.loader.URLClassPath$JarLoader.getResource(java.base at 11.0.11/URLClassPath.java:929) [INFO] at jdk.internal.loader.URLClassPath.getResource(java.base at 11.0.11/URLClassPath.java:314) [INFO] at jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(java.base at 11.0.11/BuiltinClassLoader.java:695) [INFO] at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.base at 11.0.11/BuiltinClassLoader.java:621) [INFO] - locked <0x00000000e2006a18> (a java.lang.Object) [INFO] at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 11.0.11/BuiltinClassLoader.java:579) [INFO] at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 11.0.11/ClassLoaders.java:178) [INFO] at java.lang.ClassLoader.loadClass(java.base at 11.0.11/ClassLoader.java:522) [INFO] at java.lang.ClassLoader$NativeLibrary.load0(java.base at 11.0.11/Native Method) [INFO] at java.lang.ClassLoader$NativeLibrary.load(java.base at 11.0.11/ClassLoader.java:2442) [INFO] at java.lang.ClassLoader$NativeLibrary.loadLibrary(java.base at 11.0.11/ClassLoader.java:2498) [INFO] - locked <0x00000000e11d6ad0> (a java.util.HashSet) [INFO] at java.lang.ClassLoader.loadLibrary0(java.base at 11.0.11/ClassLoader.java:2694) [INFO] at java.lang.ClassLoader.loadLibrary(java.base at 11.0.11/ClassLoader.java:2627) [INFO] at java.lang.Runtime.load0(java.base at 11.0.11/Runtime.java:768) [INFO] at java.lang.System.load(java.base at 11.0.11/System.java:1837) [INFO] at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:36) [INFO] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 11.0.11/Native Method) [INFO] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 11.0.11/NativeMethodAccessorImpl.java:62) [INFO] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 11.0.11/DelegatingMethodAccessorImpl.java:43) [INFO] at java.lang.reflect.Method.invoke(java.base at 11.0.11/Method.java:566) [INFO] at io.netty.util.internal.NativeLibraryLoader$1.run(NativeLibraryLoader.java:378) [INFO] at java.security.AccessController.doPrivileged(java.base at 11.0.11/Native Method) [INFO] at io.netty.util.internal.NativeLibraryLoader.loadLibraryByHelper(NativeLibraryLoader.java:370) [INFO] at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:336) [INFO] at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:200) [INFO] at io.netty.channel.epoll.Native.loadNativeLibrary(Native.java:290) [INFO] at io.netty.channel.epoll.Native.(Native.java:70) [INFO] at io.netty.channel.epoll.Epoll.(Epoll.java:39) [INFO] at java.lang.Class.forName0(java.base at 11.0.11/Native Method) [INFO] at java.lang.Class.forName(java.base at 11.0.11/Class.java:315) [INFO] at io.grpc.netty.Utils.isEpollAvailable(Utils.java:291) [INFO] at io.grpc.netty.Utils.(Utils.java:109) [INFO] at io.grpc.netty.NettyServerBuilder.(NettyServerBuilder.java:83) [INFO] at c.i.w.m.e.ApplicationCode.applicationMethod(ApplicationCode.java:112) [INFO] at c.i.w.m.e.ApplicationCode.(ApplicationCode.java:108) [INFO] at c.i.w.m.e.ApplicationCode.(ApplicationCode.java:101) [INFO] at c.i.w.m.AppUnitTest.initialize(AppUnitTest.java:90) [INFO] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 11.0.11/Native Method) [INFO] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 11.0.11/NativeMethodAccessorImpl.java:62) [INFO] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 11.0.11/DelegatingMethodAccessorImpl.java:43) [INFO] at java.lang.reflect.Method.invoke(java.base at 11.0.11/Method.java:566) [INFO] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) [INFO] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [INFO] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) [INFO] at org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33) [INFO] at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) [INFO] at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) [INFO] at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) [INFO] at org.junit.runners.ParentRunner.run(ParentRunner.java:413) [INFO] at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364) [INFO] at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272) [INFO] at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237) [INFO] at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158) [INFO] at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428) [INFO] at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162) [INFO] at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562) [INFO] at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548) [INFO] "other-thread": [INFO] at java.lang.ClassLoader$NativeLibrary.loadLibrary(java.base at 11.0.11/ClassLoader.java:2462) [INFO] - waiting to lock <0x00000000e11d6ad0> (a java.util.HashSet) [INFO] at java.lang.ClassLoader.loadLibrary0(java.base at 11.0.11/ClassLoader.java:2694) [INFO] at java.lang.ClassLoader.loadLibrary(java.base at 11.0.11/ClassLoader.java:2648) [INFO] at java.lang.Runtime.loadLibrary0(java.base at 11.0.11/Runtime.java:830) [INFO] at java.lang.System.loadLibrary(java.base at 11.0.11/System.java:1873) [INFO] at sun.security.ec.SunEC$1.run(jdk.crypto.ec at 11.0.11/SunEC.java:63) [INFO] at sun.security.ec.SunEC$1.run(jdk.crypto.ec at 11.0.11/SunEC.java:61) [INFO] at java.security.AccessController.doPrivileged(java.base at 11.0.11/Native Method) [INFO] at sun.security.ec.SunEC.(jdk.crypto.ec at 11.0.11/SunEC.java:61) [INFO] at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 11.0.11/Native Method) [INFO] at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 11.0.11/NativeConstructorAccessorImpl.java:62) [INFO] at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 11.0.11/DelegatingConstructorAccessorImpl.java:45) [INFO] at java.lang.reflect.Constructor.newInstance(java.base at 11.0.11/Constructor.java:490) [INFO] at java.util.ServiceLoader$ProviderImpl.newInstance(java.base at 11.0.11/ServiceLoader.java:780) [INFO] at java.util.ServiceLoader$ProviderImpl.get(java.base at 11.0.11/ServiceLoader.java:722) [INFO] at java.util.ServiceLoader$3.next(java.base at 11.0.11/ServiceLoader.java:1395) [INFO] at sun.security.jca.ProviderConfig$ProviderLoader.load(java.base at 11.0.11/ProviderConfig.java:340) [INFO] at sun.security.jca.ProviderConfig$3.run(java.base at 11.0.11/ProviderConfig.java:248) [INFO] at sun.security.jca.ProviderConfig$3.run(java.base at 11.0.11/ProviderConfig.java:242) [INFO] at java.security.AccessController.doPrivileged(java.base at 11.0.11/Native Method) [INFO] at sun.security.jca.ProviderConfig.doLoadProvider(java.base at 11.0.11/ProviderConfig.java:242) [INFO] at sun.security.jca.ProviderConfig.getProvider(java.base at 11.0.11/ProviderConfig.java:222) [INFO] - locked <0x00000000e20c9f58> (a sun.security.jca.ProviderConfig) [INFO] at sun.security.jca.ProviderList.loadAll(java.base at 11.0.11/ProviderList.java:315) [INFO] at sun.security.jca.ProviderList.removeInvalid(java.base at 11.0.11/ProviderList.java:332) [INFO] at sun.security.jca.Providers.getFullProviderList(java.base at 11.0.11/Providers.java:165) [INFO] - locked <0x00000000e20bc668> (a java.lang.Class for sun.security.jca.Providers) [INFO] at java.security.Security.getProviders(java.base at 11.0.11/Security.java:483) [INFO] at sun.security.x509.AlgorithmId.computeOidTable(java.base at 11.0.11/AlgorithmId.java:637) [INFO] at sun.security.x509.AlgorithmId.oidTable(java.base at 11.0.11/AlgorithmId.java:627) [INFO] - locked <0x00000000e2bdd3d0> (a java.lang.Class for sun.security.x509.AlgorithmId) [INFO] at sun.security.x509.AlgorithmId.algOID(java.base at 11.0.11/AlgorithmId.java:609) [INFO] at sun.security.x509.AlgorithmId.get(java.base at 11.0.11/AlgorithmId.java:441) [INFO] at sun.security.pkcs.SignerInfo.verify(java.base at 11.0.11/SignerInfo.java:380) [INFO] at sun.security.pkcs.PKCS7.verify(java.base at 11.0.11/PKCS7.java:578) [INFO] at sun.security.pkcs.PKCS7.verify(java.base at 11.0.11/PKCS7.java:595) [INFO] at sun.security.pkcs.SignerInfo.getTimestamp(java.base at 11.0.11/SignerInfo.java:545) [INFO] at sun.security.pkcs.SignerInfo.verify(java.base at 11.0.11/SignerInfo.java:318) [INFO] at sun.security.pkcs.PKCS7.verify(java.base at 11.0.11/PKCS7.java:578) [INFO] at sun.security.pkcs.PKCS7.verify(java.base at 11.0.11/PKCS7.java:595) [INFO] at sun.security.util.SignatureFileVerifier.processImpl(java.base at 11.0.11/SignatureFileVerifier.java:283) [INFO] at sun.security.util.SignatureFileVerifier.process(java.base at 11.0.11/SignatureFileVerifier.java:259) [INFO] at java.util.jar.JarVerifier.processEntry(java.base at 11.0.11/JarVerifier.java:316) [INFO] at java.util.jar.JarVerifier.update(java.base at 11.0.11/JarVerifier.java:230) [INFO] at java.util.jar.JarFile.initializeVerifier(java.base at 11.0.11/JarFile.java:759) [INFO] at java.util.jar.JarFile.ensureInitialization(java.base at 11.0.11/JarFile.java:1038) [INFO] - locked <0x00000000e119d0a8> (a java.util.jar.JarFile) [INFO] at java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(java.base at 11.0.11/JavaUtilJarAccessImpl.java:69) [INFO] at jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(java.base at 11.0.11/URLClassPath.java:870) [INFO] at jdk.internal.loader.BuiltinClassLoader.defineClass(java.base at 11.0.11/BuiltinClassLoader.java:786) [INFO] at jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(java.base at 11.0.11/BuiltinClassLoader.java:698) [INFO] at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.base at 11.0.11/BuiltinClassLoader.java:621) [INFO] - locked <0x00000000e204d228> (a java.lang.Object) [INFO] at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 11.0.11/BuiltinClassLoader.java:579) [INFO] at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 11.0.11/ClassLoaders.java:178) [INFO] at java.lang.ClassLoader.loadClass(java.base at 11.0.11/ClassLoader.java:522) [INFO] at c.i.w.m.OtherAppCode.(OtherAppCode.java:371) [INFO] at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 11.0.11/Native Method) [INFO] at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 11.0.11/NativeConstructorAccessorImpl.java:62) [INFO] at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 11.0.11/DelegatingConstructorAccessorImpl.java:45) [INFO] at java.lang.reflect.Constructor.newInstance(java.base at 11.0.11/Constructor.java:490) [INFO] at java.lang.Class.newInstance(java.base at 11.0.11/Class.java:584) [INFO] at c.i.w.l.server.DefaultServer.lambda$doStart$0(DefaultServer.java:347) [INFO] at c.i.w.l.server.DefaultServer/0x00000008401c4840.run(Unknown Source) [INFO] at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11.0.11/ThreadPoolExecutor.java:1128) [INFO] at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11.0.11/ThreadPoolExecutor.java:628) [INFO] at java.lang.Thread.run(java.base at 11.0.11/Thread.java:829) [INFO] at c.i.w.l.ThreadPoolHelper$3$1.run(ThreadPoolHelper.java:94) From aph at redhat.com Thu Apr 29 08:33:49 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Apr 2021 09:33:49 +0100 Subject: Deadlock when loading JNI code after updating to openjdk 11.0.11 In-Reply-To: References: Message-ID: <37d98dd9-7137-0555-f6d4-2cb98bd84db8@redhat.com> On 4/29/21 8:19 AM, Norman Maurer wrote: > In netty we have a bunch of JNI code that is loaded during initialisation. Yesterday a user reported that after upgrading from openjdk 11.0.10 to 11.0.11 he often see a deadlock while loading the JNI code. > After looking at the stack trace it seems like all of this is really happening in ?java land? and so looks more like a openjdk bug / regression than a netty bug. > Any idea what could have caused this ? It's the sort of thing that could have been caused by something quite innocuous. http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c82c3d65c256 looks like it might be relevant. But if the OP can reproduce the bug, let's have it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From yan at openjdk.java.net Thu Apr 29 08:51:27 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 29 Apr 2021 08:51:27 GMT Subject: [jdk13u-dev] Integrated: 8255845: Memory leak in imageFile.cpp Message-ID: fix here, too, for consistency. Clean; no regressions found. ------------- Commit messages: - Backport 66a2e70985fcdb8e0b91b05fbeae825db6ae9c78 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/194/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=194&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255845 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/194/head:pull/194 PR: https://git.openjdk.java.net/jdk13u-dev/pull/194 From yan at openjdk.java.net Thu Apr 29 08:51:29 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 29 Apr 2021 08:51:29 GMT Subject: [jdk13u-dev] Integrated: 8255845: Memory leak in imageFile.cpp In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 08:41:43 GMT, Yuri Nesterenko wrote: > fix here, too, for consistency. Clean; no regressions found. This pull request has now been integrated. Changeset: a46fd368 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/a46fd36814da3b8adcb04b53cf7166a6051aac77 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8255845: Memory leak in imageFile.cpp Backport-of: 66a2e70985fcdb8e0b91b05fbeae825db6ae9c78 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/194 From pkumaraswamy at openjdk.java.net Thu Apr 29 11:04:19 2021 From: pkumaraswamy at openjdk.java.net (Prajwal Kumaraswamy) Date: Thu, 29 Apr 2021 11:04:19 GMT Subject: [jdk16u] RFR: 8196415: Disable SHA-1 Signed JARs Message-ID: This is a clean backport. I've ran this against test suite and works fine. ------------- Commit messages: - Backport 278057756a1a79a4b030750c48b821ba9735a0f9 Changes: https://git.openjdk.java.net/jdk16u/pull/111/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=111&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8196415 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/111.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/111/head:pull/111 PR: https://git.openjdk.java.net/jdk16u/pull/111 From pkumaraswamy at openjdk.java.net Thu Apr 29 11:17:55 2021 From: pkumaraswamy at openjdk.java.net (Prajwal Kumaraswamy) Date: Thu, 29 Apr 2021 11:17:55 GMT Subject: [jdk16u] Integrated: 8196415: Disable SHA-1 Signed JARs In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 10:56:37 GMT, Prajwal Kumaraswamy wrote: > This is a clean backport. > I've ran this against test suite and works fine. This pull request has now been integrated. Changeset: 4ea26b89 Author: Prajwal Kumaraswamy Committer: Sean Coffey URL: https://git.openjdk.java.net/jdk16u/commit/4ea26b8918b1092a7f57be825f62c8146ca75d1a Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8196415: Disable SHA-1 Signed JARs Backport-of: 278057756a1a79a4b030750c48b821ba9735a0f9 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/111 From hohensee at amazon.com Thu Apr 29 14:51:26 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 29 Apr 2021 14:51:26 +0000 Subject: [11u] RFR 8246274 and 8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC In-Reply-To: <1619633435767.89897@amazon.com> References: <1619134073992.60757@amazon.com> <1619633435767.89897@amazon.com> Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Kemper, William" Date: Wednesday, April 28, 2021 at 11:11 AM To: "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] RFR 8246274 and 8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC Just to clarify, these patches applied cleanly from an internal JDK11 repository where they have been running in production since September, 2020. The original patches exported from 15 and 16 required minor modifications (renaming of g1_policy accessor, for example). Thanks, William ________________________________________ From: jdk-updates-dev on behalf of Kemper, William Sent: Thursday, April 22, 2021 4:27 PM To: jdk-updates-dev at openjdk.java.net Subject: [UNVERIFIED SENDER] [11u] RFR 8246274 and 8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC This fix went in originally as two changes, so there are two backports. Original bug: https://bugs.openjdk.java.net/browse/JDK-8245511 https://hg.openjdk.java.net/jdk/jdk/rev/d2eafcf20079 Depends on: https://bugs.openjdk.java.net/browse/JDK-8246274 https://hg.openjdk.java.net/jdk/jdk/rev/69c5e17adacd Patches applied cleanly. 11u webrev: https://cr.openjdk.java.net/~phh/8245511/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8246274/webrev.11u.01/? Testing: x86_64 build, tier1, tier1_gc, tier2 Thank you, William From martin.doerr at sap.com Thu Apr 29 16:02:25 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 29 Apr 2021 16:02:25 +0000 Subject: AW: [11u] 8262465: DirectIOTest fails on a system with large block size In-Reply-To: <3FFEECB4-689F-4AA8-B96C-EC8CC5BE9166@azul.com> References: <3FFEECB4-689F-4AA8-B96C-EC8CC5BE9166@azul.com> Message-ID: Hi Sergey, looks good. Thanks for backporting! Best regards, Martin ________________________________ Von: jdk-updates-dev im Auftrag von Sergey Nazarkin Gesendet: Mittwoch, 28. April 2021 11:28 An: jdk-updates-dev at openjdk.java.net Betreff: [11u] 8262465: DirectIOTest fails on a system with large block size Hi! I?d like to back port this fix for DirectIOTest. The test is failed on FS with r/w blocks larger than 4k. The fix doesn?t apply cleanly due to missed "8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports?. Manual modification is required for - copyright year - isDirectIOSupportedByFS remains in the code Related backport of JDK-8265231is not required since no public functions are affected. Bug: https://bugs.openjdk.java.net/browse/JDK-8264821 Original fix: https://git.openjdk.java.net/jdk/commit/7e4cd480 Webrev: http://cr.openjdk.java.net/~snazarki/jdk11u/8264821/ From aleksei.voitylov at bell-sw.com Thu Apr 29 16:59:30 2021 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 29 Apr 2021 19:59:30 +0300 Subject: Deadlock when loading JNI code after updating to openjdk 11.0.11 In-Reply-To: <37d98dd9-7137-0555-f6d4-2cb98bd84db8@redhat.com> References: <37d98dd9-7137-0555-f6d4-2cb98bd84db8@redhat.com> Message-ID: I'm on it, creating a standalone test/reproducer now: https://bugs.openjdk.java.net/browse/JDK-8266310 On 29/04/2021 11:33, Andrew Haley wrote: > On 4/29/21 8:19 AM, Norman Maurer wrote: >> In netty we have a bunch of JNI code that is loaded during initialisation. Yesterday a user reported that after upgrading from openjdk 11.0.10 to 11.0.11 he often see a deadlock while loading the JNI code. >> After looking at the stack trace it seems like all of this is really happening in ?java land? and so looks more like a openjdk bug / regression than a netty bug. >> Any idea what could have caused this ? > It's the sort of thing that could have been caused by something quite > innocuous. > > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c82c3d65c256 > looks like it might be relevant. But if the OP can reproduce the bug, > let's have it. > From hohensee at amazon.com Thu Apr 29 17:53:28 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 29 Apr 2021 17:53:28 +0000 Subject: [11u] RFR: Missing intrinsics for Math.ceil, floor, rint Message-ID: <698957E0-3737-47DE-84F3-2EBB9F439EC1@amazon.com> Lgtm, but note that the JBS issue says it needs 8231713 (which is trivial) as a follow-up. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Astigeevich, Evgeny" Date: Wednesday, April 28, 2021 at 2:59 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8226721: Missing intrinsics for Math.ceil, floor, rint Hi, Please review the backport of JDK-8226721to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8226721 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/6fc57e391539 The original patch does not apply cleanly to 11u. The update to the patch is to reposition the changes to five files: src/hotspot/cpu/x86/x86.ad src/hotspot/share/opto/library_call.cpp src/hotspot/share/opto/superword.cpp src/hotspot/share/opto/vectornode.cpp src/hotspot/share/opto/vectornode.hpp The content of the patch is not changed. 11u webrev: http://cr.openjdk.java.net/~eastigeevich/8226721/webrev.00/ Tested: Amazon Linux 2 x86_64, tier1, tier2, test/hotspot/jtreg/compiler/c2/cr6340864/TestDoubleVect.java Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153 Thanks, Evgeny Astigeevich Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. From github.com+20224954+gdams at openjdk.java.net Thu Apr 29 20:33:57 2021 From: github.com+20224954+gdams at openjdk.java.net (George Adams) Date: Thu, 29 Apr 2021 20:33:57 GMT Subject: [jdk16u] Integrated: 8265531: doc/building.md should mention homebrew install freetype In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 09:15:52 GMT, George Adams wrote: > Backport of 8265531: doc/building.md should mention homebrew install freetype This pull request has now been integrated. Changeset: e4651f3a Author: George Adams Committer: Christoph Langer URL: https://git.openjdk.java.net/jdk16u/commit/e4651f3adc4543f61c114172985b59dc4b0b05d6 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod 8265531: doc/building.md should mention homebrew install freetype Backport-of: 5aab1609b97284ccff8b7ae20a3ddcf1e29c47d7 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/109 From omikhaltcova at openjdk.java.net Fri Apr 30 13:44:23 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 30 Apr 2021 13:44:23 GMT Subject: [jdk13u-dev] RFR: 8230010: Remove jdk8037819/BasicTest1.java Message-ID: I'd like to backport JDK-8230002, JDK-8230010 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with test/jaxp/javax/xml/jaxp/unittest/transform/SecureProcessingTest.java. ------------- Commit messages: - Backport f85fe3a3d64fd6e6cfbea577362f37446311bcfd Changes: https://git.openjdk.java.net/jdk13u-dev/pull/195/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=195&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230010 Stats: 71 lines in 2 files changed: 2 ins; 68 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/195.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/195/head:pull/195 PR: https://git.openjdk.java.net/jdk13u-dev/pull/195 From omikhaltcova at openjdk.java.net Fri Apr 30 14:08:05 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 30 Apr 2021 14:08:05 GMT Subject: [jdk13u-dev] Integrated: 8230010: Remove jdk8037819/BasicTest1.java In-Reply-To: References: Message-ID: <5rwyreVoOCAmWqDuT4yrkIPFUNLlI-yrMwEhoESXwK8=.a1bfb827-93a8-419d-8aaf-84ad539b636b@github.com> On Fri, 30 Apr 2021 13:36:42 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8230002, JDK-8230010 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with test/jaxp/javax/xml/jaxp/unittest/transform/SecureProcessingTest.java. This pull request has now been integrated. Changeset: 6623cfe1 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/6623cfe16cbb4671dc495775dfa4824c7baef570 Stats: 71 lines in 2 files changed: 2 ins; 68 del; 1 mod 8230010: Remove jdk8037819/BasicTest1.java 8230002: javax/xml/jaxp/unittest/transform/SecureProcessingTest.java runs zero test Backport-of: f85fe3a3d64fd6e6cfbea577362f37446311bcfd ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/195 From martin.doerr at sap.com Fri Apr 30 16:34:08 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 30 Apr 2021 16:34:08 +0000 Subject: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms Message-ID: Hi, JDK-8153005 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8153005 CSR covering 11u: https://bugs.openjdk.java.net/browse/JDK-8228481 Original change: https://github.com/openjdk/jdk/commit/f77a6585 11u rejected hunks: http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/8153005_PKCS12_rej.txt Resolution: - Regular code is trivial to resolve, but the tests are tricky and the hunks were mostly integrated manually. - Introduce test/lib/jdk/test/lib/KnownOIDs.java as copy from jdk head src/java.base/share/classes/sun/security/util/KnownOIDs.java with last change from Oct 2020. Put into package jdk.test.lib and using System.out as debug output stream. This should make future backports easier, too. - DerUtils.java: ObjectIdentifier interface is diffent in 11u (different constructors). - Hunks in GenerateAll.java were skipped because the affected code is not in 11u (JDK-8242068). 11u backport: http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/webrev.00/ Please review. Best regards, Martin From snazarkin at azul.com Fri Apr 30 18:26:33 2021 From: snazarkin at azul.com (Sergey Nazarkin) Date: Fri, 30 Apr 2021 18:26:33 +0000 Subject: [11u] 8262465: DirectIOTest fails on a system with large block size In-Reply-To: References: <3FFEECB4-689F-4AA8-B96C-EC8CC5BE9166@azul.com> Message-ID: <0AA50718-6C72-41E2-972E-AA20E3FD9839@azul.com> Hi Martin, thanks for the review. The Issue is tagged Sergey > On Apr 29, 2021, at 19:02, Doerr, Martin wrote: > > Hi Sergey, > > looks good. Thanks for backporting! > > Best regards, > Martin > Von: jdk-updates-dev im Auftrag von Sergey Nazarkin > Gesendet: Mittwoch, 28. April 2021 11:28 > An: jdk-updates-dev at openjdk.java.net > Betreff: [11u] 8262465: DirectIOTest fails on a system with large block size > > Hi! > > I?d like to back port this fix for DirectIOTest. The test is failed on FS with r/w blocks larger than 4k. > > The fix doesn?t apply cleanly due to missed "8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports?. Manual modification is required for > - copyright year > - isDirectIOSupportedByFS remains in the code > > Related backport of JDK-8265231is not required since no public functions are affected. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8264821 > Original fix: https://git.openjdk.java.net/jdk/commit/7e4cd480 > Webrev: http://cr.openjdk.java.net/~snazarki/jdk11u/8264821/ From beurba at microsoft.com Fri Apr 30 21:09:59 2021 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Fri, 30 Apr 2021 21:09:59 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: References: <3dce3427-973d-7dbf-9534-2d4c829e5097@redhat.com> <536cfc7be4ad88d34068ee649f5c96e24f5d3959.camel@redhat.com>, <339748a7-b8ce-ed94-ad93-9bf60e38d0af@redhat.com>, Message-ID: Hello everyone, bumping this thread. Could I get some eyes on https://github.com/openjdk/jdk11u/pull/2 ? The current plan is to get the review done on GitHub and once everyone is happy, I'll convert it into a webrev. Thanks, -Bernhard ________________________________________ From: Bernhard Urban-Forster Sent: Thursday, March 25, 2021 22:48 To: Andrew Haley; Severin Gehwolf; Vladimir Kempik Cc: Anton Kozlov; aarch64-port-dev at openjdk.java.net; Monica Beckwith; jdk-updates-dev at openjdk.java.net; Magnus Ihse Bursie; openjdk-aarch64 Subject: Re: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u > Just to clarify. jdk11u hasn't transitioned to skara yet. jdk11u-dev > will transition to it in June[1]. At that point the bots will no longer > > auto-close PRs. > > Sure. I don't care if it's been auto-closed, I can still review it. Hah, that's actually a good idea! Let's do the review feedback loop on that PR, and once finalized I can turn that into a webrev. That doesn't sound too painful to me :-) Thanks, -Bernhard ________________________________________ From: Andrew Haley Sent: Thursday, March 25, 2021 17:42 To: Severin Gehwolf; Bernhard Urban-Forster; Vladimir Kempik Cc: Anton Kozlov; aarch64-port-dev at openjdk.java.net; Monica Beckwith; jdk-updates-dev at openjdk.java.net; Magnus Ihse Bursie; openjdk-aarch64 Subject: Re: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u On 3/25/21 4:30 PM, Severin Gehwolf wrote: > Just to clarify. jdk11u hasn't transitioned to skara yet. jdk11u-dev > will transition to it in June[1]. At that point the bots will no longer > auto-close PRs. Sure. I don't care if it's been auto-closed, I can still review it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=04%7C01%7Cbeurba%40microsoft.com%7C75b981562be84529033908d8efad0888%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637522873741905341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I0HxiyMAwKx1sYxvy8%2Fs8arCVLjO0g2LFDOJKGkMPak%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From eastig at amazon.co.uk Fri Apr 16 15:09:30 2021 From: eastig at amazon.co.uk (Astigeevich, Evgeny) Date: Fri, 16 Apr 2021 15:09:30 -0000 Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow Message-ID: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com> Hi, Please review the backport of JDK-8177068 to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8177068 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a3c63a9dfb2c The original patch does not apply cleanly to 11u. In the original patch, file DeferredAttr.java, calls of ?attribSpeculative? to be changed have the argument AttributionMode.SPECULATIVE. The original patch does not change this. In 11u ?attribSpeculative? does not have the parameter AttributionMode. I changed the affected calls to 11u API. 11u webrev: http://cr.openjdk.java.net/~eastigeevich/8177068/webrev.00/ Tested: Amazon Linux 2 x86_64, tier1, tier2, langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java Note: There is a failing test: sun/security/pkcs11/Secmod/AddTrustedCert.java. It fails without the patch as well. Details: https://bugs.openjdk.java.net/browse/JDK-8232153 Thanks, Evgeny Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. From lutz.schmidt at sap.com Mon Apr 19 12:21:17 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 19 Apr 2021 12:21:17 -0000 Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods In-Reply-To: References: <7FF068E8-BDC9-4945-A263-72613C31A461@amazon.com> Message-ID: <34EE065E-8B6F-4307-82D2-448BD3C5561E@sap.com> Hi Paul, thank you for waiting. The test results are in. In summary: no issues which could be related to the pending downport changes in any way. For some more details, you may refer to the attached PDF. It gives you an idea of what tests we run every night. Green squares indicate all subtests of the suite completed OK. Purple squares indicate "test still running" and the yellow squares show suites with at least one subtest failing. I checked all yellow squares. Each represents just one failing subtest, and all failures are completely unrelated to the backport. There were no builds and tests last night for rs6000_64 (AIX), sun_64 (Solaris/SPARC), and darwinintel64 (MacOS/Intel). Their trigger time was before I had the patches ready and in the queue. As this is all platform-independent code, I do not expect we missed any findings. The comments in codeHeapState.cpp are correct. I couldn't find a reference to PrintCodeHeapAnalytics or similar. I believe the patch for 8217465 is incomplete because it does not delete the macro definitions for STRINGSTREAM_FLUSH and STRINGSTREAM_FLUSH_LOCKED. Thank you again for the effort you put into this downport. Lutz ?On 16.04.21, 19:28, "Hohensee, Paul" wrote: Forgot to write I agree with you on not including 8214526. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, April 16, 2021 at 10:03 AM To: "Schmidt, Lutz" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods If we meet up again in Belgium, I'll take you up on the beer offer. :) I see why I thought 8214526 was included: it's in a comment in your webrev for codeHeapState.cpp. I guess the comment should be changed to use -Xlog, but I don't know exactly how it should be worded. -----Original Message----- From: "Schmidt, Lutz" Date: Friday, April 16, 2021 at 9:48 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Hi Paul, sorry for the mess! I owe you a beer! 8214526: This change is not in my downport change. It should not be downported to 11u because it changes how you control CodeHeapAnalytics. The sole purpose was to switch from -Xlog:codecache= to -XX:+PrintCodeHeapAnalytics. There was a long and fierce discussion about how to control the feature. Print* is deprecated and -Xlog does not fit the requirements. I don't want to revive that. 8219586: The differences in lock handling are caused by major changes in mutex.cpp/hpp. I found no way to write the locks which works for both, jdk11u and tip. The issues that were found surfaced during option stress testing. These are Oracle-internal tests where they exercise the command-line options. At least that's my understanding. Other than that, I do not know of specific tests. I conducted manual tests only. It's anyway hard to write an automated test which performs meaningful checks without being very shaky. I will take your webrevs (except 8214526) and feed them into our build and test farm over the weekend. If everything runs fine, I should have results by Monday morning. I will let you know immediately. Enjoy your weekend! Lutz On 16.04.21, 18:06, "Hohensee, Paul" wrote: The maintainers prefer to see individual backports rather than bulk ones. You're bulk backporting codeHeapState.cpp. Instead of that, you could backport these commits individually. 8219586: CodeHeap State Analytics processes dead nmethods 8217465: [REDO] - Optimize CodeHeap Analytics 8216314: SIGILL in CodeHeapState::print_names() 8214526: Change CodeHeap State Analytics control from UL to Print* 8214526: applies cleanly. 8216314: needs a copyright change in codeHeapState.cpp. 8217465: Needs an implicit bufferedStream copy constructor removed in codeHeapState.cpp. This change was in 8224487, which was previously backported to 11u, but the change was omitted in that backport. 8219586: Context adjustment in codeHeapState.cpp because 8183574 has not been backported. Context adjustment in compiledMethod.cpp. Also, your webrev has global_lock_1 and function_lock_1 used with _no_safepoint_check_flag, but the tip version uses _safepoint_check_flag. Context adjustment in mutexLocker.cpp. I made incremental webrevs of the above. They apply in sequence. https://cr.openjdk.java.net/~phh/8214526/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8216314/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8217465/webrev.11u.01/ https://cr.openjdk.java.net/~phh/8219586/webrev.11u.02/ I'm running tier1 on linux-x64, but don't have access to other platforms. Would you be able to apply these patches and test them thoroughly? Are there any specific tests I can run beyond tier1? Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Wednesday, April 14, 2021 at 9:09 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR(M): 8219586 backport: CodeHeap State Analytics processes dead nmethods Dear Community, I would happily accept reviews for this downport change. The change puts an end to discussions on the "accessing dead storage" topic, at least to the best of Erik ?sterlund's and my knowledge. Most merge conflicts (and the complicated ones) were encountered codeHeapState.{c|h}pp. To resolve them, I copied the files from OpenJDK/jdk. That was the desired state for these files anyway. To resolve compileBroker.cpp, I copied the OpenJDK/jdk version of CompileBroker::print_heapinfo() and retrofitted the Monitor and Mutex objects and calls to the jdk11 interfaces. The remaining conflicts were trivial to resolve. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219586 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8219586.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8219586-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. Results pending (expected by April 15th, start of business). Thanks, Lutz From samuelseballos329 at gmail.com Wed Apr 21 12:32:54 2021 From: samuelseballos329 at gmail.com (Samuel Seballos) Date: Wed, 21 Apr 2021 12:32:54 -0000 Subject: [Ping] [11u] 8207247: AARCH64: Enable Minimal and Client VM builds Message-ID: From samuelseballos329 at gmail.com Wed Apr 21 13:20:16 2021 From: samuelseballos329 at gmail.com (Samuel Seballos) Date: Wed, 21 Apr 2021 13:20:16 -0000 Subject: [Ping] [11u] 8207247: AARCH64: Enable Minimal and Client VM builds Message-ID: From j.bachorik at gmail.com Fri Apr 23 14:09:13 2021 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Fri, 23 Apr 2021 14:09:13 -0000 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: <41FD9309-CD0C-4A28-955C-07A37E640D70@sap.com> References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> <8fe619f6-5e1b-104d-9865-9ad2c8951ac1@redhat.com> <41FD9309-CD0C-4A28-955C-07A37E640D70@sap.com> Message-ID: Hi all, I am really sorry, gmail moved this thread to a spam folder and that's why I didn't respond. I am preparing the rollback. -JB- On Fri, Apr 23, 2021 at 2:42 PM Schmidt, Lutz wrote: > Hi, > > I'm in full support of the decision. Bad patches with multiple causes of > failure should be rolled back and retried - after thorough rework, testing > and reviews. > > The bare minimum requirement for committers pushing a change is to be at > least responsive on a mediocre level. Push, go away and let the others > clean up is generally not well accepted by the community. > > Best regards, > Lutz > > ?On 23.04.21, 10:53, "jdk-updates-dev on behalf of Thomas St?fe" < > jdk-updates-dev-retn at openjdk.java.net on behalf of thomas.stuefe at gmail.com> > wrote: > > Hi Florian and others, > > we decided on a clean rollback instead of letting fixes pile on. Atm > there > is a lack of trust in this patch, sorry. > > Please roll back it - and Alekseys subsequent build fix from yesterday > - > back and retry with a fully tested, complete patch. Thank you. > > Cheers, Thomas > > > > > On Thu, Apr 22, 2021 at 2:19 PM Aleksey Shipilev > wrote: > > > On 4/22/21 1:12 PM, Langer, Christoph wrote: > > > Maybe for now it would be most appropriate to back it out and redo > it > > later when the problems are understood/fixed? > > > > Yes, I'd vote for reversal to get 11u back to sane state. > > > > -- > > Thanks, > > -Aleksey > > > > > > From florian.david at datadoghq.com Fri Apr 23 14:51:37 2021 From: florian.david at datadoghq.com (Florian David) Date: Fri, 23 Apr 2021 14:51:37 -0000 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> <8fe619f6-5e1b-104d-9865-9ad2c8951ac1@redhat.com> <41FD9309-CD0C-4A28-955C-07A37E640D70@sap.com> Message-ID: Hi all, I'm terribly sorry for the bad testing quality and all the frustration and time lost this patch caused to the community. As mentioned in the patch submission, I tested on Linux x86 but not Windows and debug/fastdebug builds. I will make sure this does not happen again and will add these platforms to my testing suite. As it's my first contribution to the OpenJDK project, I promise that this lesson has been learned and I'll do my best for it not to happen again next time, along with being more responsive to the mailing list. My apologizes, Florian David On Fri, Apr 23, 2021 at 4:08 PM Jaroslav Bachorik wrote: > Hi all, > > I am really sorry, gmail moved this thread to a spam folder and that's why > I didn't respond. > > I am preparing the rollback. > > -JB- > > On Fri, Apr 23, 2021 at 2:42 PM Schmidt, Lutz > wrote: > >> Hi, >> >> I'm in full support of the decision. Bad patches with multiple causes of >> failure should be rolled back and retried - after thorough rework, testing >> and reviews. >> >> The bare minimum requirement for committers pushing a change is to be at >> least responsive on a mediocre level. Push, go away and let the others >> clean up is generally not well accepted by the community. >> >> Best regards, >> Lutz >> >> ?On 23.04.21, 10:53, "jdk-updates-dev on behalf of Thomas St?fe" < >> jdk-updates-dev-retn at openjdk.java.net on behalf of >> thomas.stuefe at gmail.com> wrote: >> >> Hi Florian and others, >> >> we decided on a clean rollback instead of letting fixes pile on. Atm >> there >> is a lack of trust in this patch, sorry. >> >> Please roll back it - and Alekseys subsequent build fix from >> yesterday - >> back and retry with a fully tested, complete patch. Thank you. >> >> Cheers, Thomas >> >> >> >> >> On Thu, Apr 22, 2021 at 2:19 PM Aleksey Shipilev >> wrote: >> >> > On 4/22/21 1:12 PM, Langer, Christoph wrote: >> > > Maybe for now it would be most appropriate to back it out and >> redo it >> > later when the problems are understood/fixed? >> > >> > Yes, I'd vote for reversal to get 11u back to sane state. >> > >> > -- >> > Thanks, >> > -Aleksey >> > >> > >> >> From martin.doerr at sap.com Fri Apr 23 15:52:36 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 23 Apr 2021 15:52:36 -0000 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: <6626B232-F0F0-48DC-BAAE-B35B6E2BE7A4@amazon.com> <8fe619f6-5e1b-104d-9865-9ad2c8951ac1@redhat.com> <41FD9309-CD0C-4A28-955C-07A37E640D70@sap.com> Message-ID: Hi Florian and Jaroslav, we actually do appreciate new contributors. We only need to keep the quality high and the tests passing. Thanks for your understanding and taking care of the problem. You can also ask for additional testing if you can?t cover all platforms when requesting 11u approval. Best regards, Martin From: Florian David Sent: Freitag, 23. April 2021 16:50 To: Jaroslav Bachorik Cc: Schmidt, Lutz ; Marcus Hirt ; Jaroslav Bachor?k ; Langer, Christoph ; Doerr, Martin ; Hohensee, Paul ; jdk-updates-dev ; Aleksey Shipilev ; Thomas St?fe Subject: Re: [11u] RFR: 8258414: OldObjectSample events too expensive Hi all, I'm terribly sorry for the bad testing quality and all the frustration and time lost this patch caused to the community. As mentioned in the patch submission, I tested on Linux x86 but not Windows and debug/fastdebug builds. I will make sure this does not happen again and will add these platforms to my testing suite. As it's my first contribution to the OpenJDK project, I promise that this lesson has been learned and I'll do my best for it not to happen again next time, along with being more responsive to the mailing list. My apologizes, Florian David On Fri, Apr 23, 2021 at 4:08 PM Jaroslav Bachorik > wrote: Hi all, I am really sorry, gmail moved this thread to a spam folder and that's why I didn't respond. I am preparing the rollback. -JB- On Fri, Apr 23, 2021 at 2:42 PM Schmidt, Lutz > wrote: Hi, I'm in full support of the decision. Bad patches with multiple causes of failure should be rolled back and retried - after thorough rework, testing and reviews. The bare minimum requirement for committers pushing a change is to be at least responsive on a mediocre level. Push, go away and let the others clean up is generally not well accepted by the community. Best regards, Lutz ?On 23.04.21, 10:53, "jdk-updates-dev on behalf of Thomas St?fe" on behalf of thomas.stuefe at gmail.com> wrote: Hi Florian and others, we decided on a clean rollback instead of letting fixes pile on. Atm there is a lack of trust in this patch, sorry. Please roll back it - and Alekseys subsequent build fix from yesterday - back and retry with a fully tested, complete patch. Thank you. Cheers, Thomas On Thu, Apr 22, 2021 at 2:19 PM Aleksey Shipilev > wrote: > On 4/22/21 1:12 PM, Langer, Christoph wrote: > > Maybe for now it would be most appropriate to back it out and redo it > later when the problems are understood/fixed? > > Yes, I'd vote for reversal to get 11u back to sane state. > > -- > Thanks, > -Aleksey > >