From aph at redhat.com Sat May 1 09:04:51 2021 From: aph at redhat.com (Andrew Haley) Date: Sat, 1 May 2021 10:04:51 +0100 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: On 4/30/21 10:09 PM, Bernhard Urban-Forster wrote: > 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. It all looks fine to me. We'll be moving 11u to GitHub soon, so you can just copy your pull request over. As soon as the 11u transition is done, we can push it. I'd like to figure out some way to kick the tyres myself without a ton of effort. Maybe a Windows VM on a Mac M1 works? -- 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 vkempik at azul.com Sat May 1 09:06:41 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Sat, 1 May 2021 09:06:41 +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: <4001C8A0-BF69-4229-8AF0-AAB9A26DB22F@azul.com> Hello Well, it works, parallels 16.5 or qemu with m1 patches and win10 arm64 insider image from MS. Regards, Vladimir > 1 ??? 2021 ?., ? 12:04, Andrew Haley ???????(?): > > On 4/30/21 10:09 PM, Bernhard Urban-Forster wrote: >> 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. > > It all looks fine to me. We'll be moving 11u to GitHub soon, so you can just > copy your pull request over. > > As soon as the 11u transition is done, we can push it. I'd like to figure > out some way to kick the tyres myself without a ton of effort. Maybe a > Windows VM on a Mac M1 works? > > -- > 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 denghui.ddh at alibaba-inc.com Sat May 1 09:39:15 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Sat, 01 May 2021 17:39:15 +0800 Subject: =?UTF-8?B?UElORyBbMTF1XSBSRlIgKFhTKTogODI2MTAyMDogV3JvbmcgZm9ybWF0IHBhcmFtZXRlciBp?= =?UTF-8?B?biBjcmVhdGVfZW1lcmdlbmN5X2NodW5rX3BhdGg=?= Message-ID: <4c5f9947-6977-437f-8f6f-ebc2c09b013c.denghui.ddh@alibaba-inc.com> Gentle ping? ------------------------------------------------------------------ From:???(??) Send Time:2021?4?6?(???) 14:43 To:jdk-updates-dev at openjdk.java.net Subject:PING [11u] RFR (XS): 8261020: Wrong format parameter in create_emergency_chunk_path 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 goetz.lindenmaier at sap.com Mon May 3 05:50:53 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 3 May 2021 05:50:53 +0000 Subject: [DMARC FAILURE] PING [11u] RFR (XS): 8261020: Wrong format parameter in create_emergency_chunk_path In-Reply-To: <4c5f9947-6977-437f-8f6f-ebc2c09b013c.denghui.ddh@alibaba-inc.com> References: <4c5f9947-6977-437f-8f6f-ebc2c09b013c.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, This looks good to me! Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Denghui Dong > Sent: Saturday, May 1, 2021 11:39 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] PING [11u] RFR (XS): 8261020: Wrong format > parameter in create_emergency_chunk_path > > Gentle ping? > ------------------------------------------------------------------ > From:???(??) > Send Time:2021?4?6?(???) 14:43 > To:jdk-updates-dev at openjdk.java.net > Subject:PING [11u] RFR (XS): 8261020: Wrong format parameter in > create_emergency_chunk_path > > 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 denghui.ddh at alibaba-inc.com Mon May 3 07:28:33 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 03 May 2021 15:28:33 +0800 Subject: =?UTF-8?B?UmU6IFtETUFSQyBGQUlMVVJFXSBQSU5HIFsxMXVdIFJGUiAoWFMpOiA4MjYxMDIwOiBXcm9u?= =?UTF-8?B?ZyBmb3JtYXQgcGFyYW1ldGVyIGluIGNyZWF0ZV9lbWVyZ2VuY3lfY2h1bmtfcGF0aA==?= In-Reply-To: References: <4c5f9947-6977-437f-8f6f-ebc2c09b013c.denghui.ddh@alibaba-inc.com>, Message-ID: <90ed4bbb-168e-47c0-b782-1568101edfb5.denghui.ddh@alibaba-inc.com> Hi Goetz, Thank you for the review. Could you sponsor the change? Thanks, Denghui ------------------------------------------------------------------ From:Lindenmaier, Goetz Send Time:2021?5?3?(???) 13:52 To:???(??) ; jdk-updates-dev at openjdk.java.net Subject:RE: [DMARC FAILURE] PING [11u] RFR (XS): 8261020: Wrong format parameter in create_emergency_chunk_path Hi Denghui, This looks good to me! Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Denghui Dong > Sent: Saturday, May 1, 2021 11:39 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] PING [11u] RFR (XS): 8261020: Wrong format > parameter in create_emergency_chunk_path > > Gentle ping? > ------------------------------------------------------------------ > From:???(??) > Send Time:2021?4?6?(???) 14:43 > To:jdk-updates-dev at openjdk.java.net > Subject:PING [11u] RFR (XS): 8261020: Wrong format parameter in > create_emergency_chunk_path > > 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 goetz.lindenmaier at sap.com Mon May 3 07:35:38 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 3 May 2021 07:35:38 +0000 Subject: [DMARC FAILURE] PING [11u] RFR (XS): 8261020: Wrong format parameter in create_emergency_chunk_path In-Reply-To: <90ed4bbb-168e-47c0-b782-1568101edfb5.denghui.ddh@alibaba-inc.com> References: <4c5f9947-6977-437f-8f6f-ebc2c09b013c.denghui.ddh@alibaba-inc.com>, <90ed4bbb-168e-47c0-b782-1568101edfb5.denghui.ddh@alibaba-inc.com> Message-ID: Yes, sire. Please mark it for downport so that it can get labeled jdk11u-fix-yes and ping me once it is ready to be pushed. Thanks, Goetz. From: Denghui Dong Sent: Monday, May 3, 2021 9:29 AM To: jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz Subject: Re: [DMARC FAILURE] PING [11u] RFR (XS): 8261020: Wrong format parameter in create_emergency_chunk_path Hi Goetz, Thank you for the review. Could you sponsor the change? Thanks, Denghui ------------------------------------------------------------------ From:Lindenmaier, Goetz > Send Time:2021?5?3?(???) 13:52 To:???(??) >; jdk-updates-dev at openjdk.java.net > Subject:RE: [DMARC FAILURE] PING [11u] RFR (XS): 8261020: Wrong format parameter in create_emergency_chunk_path Hi Denghui, This looks good to me! Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Denghui Dong > Sent: Saturday, May 1, 2021 11:39 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] PING [11u] RFR (XS): 8261020: Wrong format > parameter in create_emergency_chunk_path > > Gentle ping? > ------------------------------------------------------------------ > From:???(??) > > Send Time:2021?4?6?(???) 14:43 > To:jdk-updates-dev at openjdk.java.net > > Subject:PING [11u] RFR (XS): 8261020: Wrong format parameter in > create_emergency_chunk_path > > 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 beurba at microsoft.com Mon May 3 10:15:51 2021 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 3 May 2021 10:15:51 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u Message-ID: Thanks, I'll wait for the GitHub transition of jdk11u-dev then which seems to happen on June 2nd [1]. Yes, Windows 10 Arm64 works very well via virtualization on the M1. Even faster than on a Surface Pro X. However, keep in mind that you'll still need a Windows x86_64 machine for cross compiling OpenJDK. -Bernhard [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-March/005470.html ________________________________________ From: Vladimir Kempik Sent: Saturday, May 01, 2021 11:06 To: Andrew Haley Cc: Bernhard Urban-Forster; Anton Kozlov; aarch64-port-dev at openjdk.java.net; Monica Beckwith; jdk-updates-dev at openjdk.java.net; Magnus Ihse Bursie; openjdk-aarch64 Subject: Re: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u Hello Well, it works, parallels 16.5 or qemu with m1 patches and win10 arm64 insider image from MS. Regards, Vladimir > 1 ??? 2021 ?., ? 12:04, Andrew Haley ???????(?): > > On 4/30/21 10:09 PM, Bernhard Urban-Forster wrote: >> 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. > > It all looks fine to me. We'll be moving 11u to GitHub soon, so you can just > copy your pull request over. > > As soon as the 11u transition is done, we can push it. I'd like to figure > out some way to kick the tyres myself without a ton of effort. Maybe a > Windows VM on a Mac M1 works? > > -- > 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 zgu at redhat.com Mon May 3 21:03:42 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 3 May 2021 17:03:42 -0400 Subject: [11u] RFR 8218458: [TESTBUG] runtime/NMT/CheckForProperDetailStackTrace.java fails with Expected stack trace missing from output Message-ID: <4ba67941-55ca-9989-8655-4f914b2962c1@redhat.com> I would like to backport this patch to 11u for parity with Oracle 11.0.13. The original bug: https://bugs.openjdk.java.net/browse/JDK-8218458 The original patch: http://hg.openjdk.java.net/jdk/jdk/rev/b02d1d829b09 The original patch does not apply cleanly to 11u. 1) CheckForProperDetailStackTrace.java is not in 11u's ProblemList.txt 2) 11u does not have JDK-8217660. Therefore, context is bit off in CheckForProperDetailStackTrace.java, resolved manually. 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.00/ Test: The test passed on Linux x86_64. Thanks, -Zhengyu From vkempik at openjdk.java.net Mon May 3 21:18:24 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 3 May 2021 21:18:24 GMT Subject: [jdk15u-dev] RFR: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched Message-ID: Almost clean backport to jdk15u-dev, inly issue was copyright year in NSApplicationAWT.m file ------------- Commit messages: - Backport 020236cb9825bf4fa91a495a179623e3fcdc0149 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/42/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=42&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264786 Stats: 24 lines in 4 files changed: 9 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/42/head:pull/42 PR: https://git.openjdk.java.net/jdk15u-dev/pull/42 From vkempik at azul.com Mon May 3 22:07:43 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Mon, 3 May 2021 22:07:43 +0000 Subject: [11u] RFR (S): 8250876: Fix issues with cross-compile on macos In-Reply-To: <70672D79-66A4-4D66-B24F-3968EB1B48F4@amazon.com> References: <70672D79-66A4-4D66-B24F-3968EB1B48F4@amazon.com> Message-ID: <338DB003-DF17-4036-AB51-AB074B9C023A@azul.com> Hello Looks good not a reviewer tho, just an author of original fix. Regards, Vladimir. > 28 ???. 2021 ?., ? 19:50, Hohensee, Paul ???????(?): > > 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 hohensee at amazon.com Mon May 3 22:52:15 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 3 May 2021 22:52:15 +0000 Subject: [11u] RFR (S): 8250876: Fix issues with cross-compile on macos Message-ID: I think that will suffice. :) Thanks, Paul ?-----Original Message----- From: Vladimir Kempik Date: Monday, May 3, 2021 at 3:08 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR (S): 8250876: Fix issues with cross-compile on macos Hello Looks good not a reviewer tho, just an author of original fix. Regards, Vladimir. > 28 ???. 2021 ?., ? 19:50, Hohensee, Paul ???????(?): > > 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 yan at openjdk.java.net Tue May 4 07:09:04 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 4 May 2021 07:09:04 GMT Subject: [jdk15u-dev] RFR: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched In-Reply-To: References: Message-ID: On Mon, 3 May 2021 21:11:04 GMT, Vladimir Kempik wrote: > Almost clean backport to jdk15u-dev, inly issue was copyright year in NSApplicationAWT.m file Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/42 From yan at openjdk.java.net Tue May 4 08:15:07 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 4 May 2021 08:15:07 GMT Subject: [jdk13u-dev] RFR: 8264821: DirectIOTest fails on a system with large block size In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:09:46 GMT, Sergey Nazarkin wrote: > 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. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/193 From aph at redhat.com Tue May 4 08:15:09 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 May 2021 09:15:09 +0100 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: References: Message-ID: <079d2c10-b1bc-5ffb-0b8d-2b25d52ddb9d@redhat.com> On 5/3/21 11:15 AM, Bernhard Urban-Forster wrote: > Yes, Windows 10 Arm64 works very well via virtualization on the M1. Even faster than on a Surface Pro X. However, keep in mind that you'll still need a Windows x86_64 machine for cross compiling OpenJDK. Is there a documentation page with "How to build this stuff" somewhere? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From beurba at microsoft.com Tue May 4 08:59:55 2021 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Tue, 4 May 2021 08:59:55 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: <079d2c10-b1bc-5ffb-0b8d-2b25d52ddb9d@redhat.com> References: , <079d2c10-b1bc-5ffb-0b8d-2b25d52ddb9d@redhat.com> Message-ID: Build deps are listed in the following link. Also you'll require to build a devkit and use that, and a build system hack for "fixpath.exe" is needed: https://github.com/microsoft/openjdk-aarch64/blob/2f8fc04a24086f2b9bd46405061e8a7b3e307c62/README.md#building-from-githubcomopenjdkjdkgit Configure line looks something like this: BOOTJDK="/cygdrive/c/work/bootjdk-x64/jdk-11.0.10+9/" DEVKIT="/cygdrive/c/work/VS2019-16.6.1-devkit" $ bash configure \ --openjdk-target=aarch64-unknown-cygwin \ --with-devkit="$DEVKIT" \ --with-build-devkit="$DEVKIT" \ --with-build-jdk=$BOOTJDK \ --with-boot-jdk=$BOOTJDK FWIW, tip is much easier because the situation was improved significantly with the WINENV patch by Magnus: https://github.com/microsoft/openjdk-aarch64/#building-from-githubcomopenjdkjdkgit ________________________________________ From: Andrew Haley Sent: Tuesday, May 4, 2021 10:15 To: Bernhard Urban-Forster; Vladimir Kempik Cc: Anton Kozlov; aarch64-port-dev at openjdk.java.net; Monica Beckwith; jdk-updates-dev at openjdk.java.net; Magnus Ihse Bursie; openjdk-aarch64 Subject: Re: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u On 5/3/21 11:15 AM, Bernhard Urban-Forster wrote: > Yes, Windows 10 Arm64 works very well via virtualization on the M1. Even faster than on a Surface Pro X. However, keep in mind that you'll still need a Windows x86_64 machine for cross compiling OpenJDK. Is there a documentation page with "How to build this stuff" somewhere? -- 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%7C7f8df6fc49724b7aefcf08d90ed4bfd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637557129182484016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hO%2F7Y8t%2FsJzdDykMjiYSIOCt5GUpqVAhTGuMM3Vpl1c%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vkempik at openjdk.java.net Tue May 4 09:52:03 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 4 May 2021 09:52:03 GMT Subject: [jdk15u-dev] Integrated: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched In-Reply-To: References: Message-ID: On Mon, 3 May 2021 21:11:04 GMT, Vladimir Kempik wrote: > Almost clean backport to jdk15u-dev, inly issue was copyright year in NSApplicationAWT.m file This pull request has now been integrated. Changeset: acf2eea2 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/acf2eea2262ce78d5103afa826aa79c91298013d Stats: 24 lines in 4 files changed: 9 ins; 9 del; 6 mod 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched Reviewed-by: yan Backport-of: 020236cb9825bf4fa91a495a179623e3fcdc0149 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/42 From vkempik at openjdk.java.net Tue May 4 09:55:28 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 4 May 2021 09:55:28 GMT Subject: [jdk13u-dev] RFR: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched Message-ID: Clean backport from jdk15 to jdk13. JDK17->JDK13 only one copyright year update issue ------------- Commit messages: - Backport acf2eea2262ce78d5103afa826aa79c91298013d Changes: https://git.openjdk.java.net/jdk13u-dev/pull/196/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=196&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264786 Stats: 24 lines in 4 files changed: 9 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/196.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/196/head:pull/196 PR: https://git.openjdk.java.net/jdk13u-dev/pull/196 From dcherepanov at openjdk.java.net Tue May 4 10:00:09 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 4 May 2021 10:00:09 GMT Subject: [jdk15u-dev] Integrated: 8260380: Upgrade to LittleCMS 2.12 In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 09:29:56 GMT, Dmitry Cherepanov wrote: > Request to backport for parity with 11u. Applies cleanly. This pull request has now been integrated. Changeset: 547c7984 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk15u-dev/commit/547c7984e6fb83e15fec8f59c4bd087a8a5bab10 Stats: 717 lines in 20 files changed: 249 ins; 286 del; 182 mod 8260380: Upgrade to LittleCMS 2.12 Backport-of: 4caeb39f01b13b5472d8dacb268262fd418fd0c4 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/40 From yan at openjdk.java.net Tue May 4 10:02:06 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 4 May 2021 10:02:06 GMT Subject: [jdk13u-dev] RFR: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched In-Reply-To: References: Message-ID: On Tue, 4 May 2021 09:50:14 GMT, Vladimir Kempik wrote: > Clean backport from jdk15 to jdk13. > JDK17->JDK13 only one copyright year update issue Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/196 From snazarki at openjdk.java.net Tue May 4 10:05:08 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Tue, 4 May 2021 10:05:08 GMT Subject: [jdk13u-dev] Integrated: 8264821: DirectIOTest fails on a system with large block size In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:09:46 GMT, Sergey Nazarkin wrote: > 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. This pull request has now been integrated. Changeset: 1c24c099 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/1c24c09924408d0b3e8b257c95c1e93205deaf2a Stats: 25 lines in 1 file changed: 8 ins; 0 del; 17 mod 8264821: DirectIOTest fails on a system with large block size Reviewed-by: yan Backport-of: 7e4cd480206891550828d1fdfebae57ecc19ed37 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/193 From dcherepanov at openjdk.java.net Tue May 4 10:11:05 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 4 May 2021 10:11:05 GMT Subject: [jdk13u-dev] Integrated: 8260380: Upgrade to LittleCMS 2.12 In-Reply-To: <_6pCQRAipbPVevatYZswj8rIRM9hQjUV_zcMreaK78k=.d4488109-afdd-49ec-8000-ec3a18c83d8f@github.com> References: <_6pCQRAipbPVevatYZswj8rIRM9hQjUV_zcMreaK78k=.d4488109-afdd-49ec-8000-ec3a18c83d8f@github.com> Message-ID: On Wed, 28 Apr 2021 09:46:14 GMT, Dmitry Cherepanov wrote: > Request to backport for parity with 11u. Applies cleanly. This pull request has now been integrated. Changeset: 7a23750e Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/7a23750e10e4bea71c8adffbfeb214fb52d186eb Stats: 717 lines in 20 files changed: 249 ins; 286 del; 182 mod 8260380: Upgrade to LittleCMS 2.12 Backport-of: 4caeb39f01b13b5472d8dacb268262fd418fd0c4 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/192 From vkempik at openjdk.java.net Tue May 4 10:22:01 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 4 May 2021 10:22:01 GMT Subject: [jdk13u-dev] Integrated: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched In-Reply-To: References: Message-ID: On Tue, 4 May 2021 09:50:14 GMT, Vladimir Kempik wrote: > Clean backport from jdk15 to jdk13. > JDK17->JDK13 only one copyright year update issue This pull request has now been integrated. Changeset: 61803a99 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/61803a998b94f871ea4cbcbdf5c6b9c9264fa4dc Stats: 24 lines in 4 files changed: 9 ins; 9 del; 6 mod 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched Reviewed-by: yan Backport-of: 020236cb9825bf4fa91a495a179623e3fcdc0149 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/196 From vkempik at azul.com Tue May 4 11:21:29 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 4 May 2021 11:21:29 +0000 Subject: [11u] RFR (S): 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched Message-ID: <082BF0FC-55A4-469D-B580-5E7D15832794@azul.com> Please review this backport to fix the issue with notification center pop-ups on jdk10+ the fix didn?t apply cleanly because one more line of code had to be moved to NSApplicationAWT.m to CTrayIcon.m: [[NSNotificationCenter defaultCenter] postNotificationName:JNFRunLoopDidStartNotification object:self]; The bug - https://bugs.openjdk.java.net/browse/JDK-8264786 The webrev - http://cr.openjdk.java.net/~vkempik/8264786/webrev.01/ The original commit - https://git.openjdk.java.net/jdk/commit/020236cb9825bf4fa91a495a179623e3fcdc0149 Will wait for positive tests run before doing jdk11u-fix-request in the bug. Regards, Vladimir From vkempik at azul.com Tue May 4 11:31:53 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 4 May 2021 11:31:53 +0000 Subject: [11u] RFR (S): 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched In-Reply-To: <082BF0FC-55A4-469D-B580-5E7D15832794@azul.com> References: <082BF0FC-55A4-469D-B580-5E7D15832794@azul.com> Message-ID: <03958C01-95C7-4E5E-B04D-8BDE77CA6E4C@azul.com> Hello Updating webrev, I don?t think that additional line has to be moved to CTrayIcon.m http://cr.openjdk.java.net/~vkempik/8264786/webrev.02/ Vladimir. > 4 ??? 2021 ?., ? 14:21, Vladimir Kempik ???????(?): > > Please review this backport to fix the issue with notification center pop-ups on jdk10+ > > the fix didn?t apply cleanly because one more line of code had to be moved to NSApplicationAWT.m to CTrayIcon.m: > [[NSNotificationCenter defaultCenter] postNotificationName:JNFRunLoopDidStartNotification object:self]; > > > The bug - https://bugs.openjdk.java.net/browse/JDK-8264786 > The webrev - http://cr.openjdk.java.net/~vkempik/8264786/webrev.01/ > The original commit - https://git.openjdk.java.net/jdk/commit/020236cb9825bf4fa91a495a179623e3fcdc0149 > > Will wait for positive tests run before doing jdk11u-fix-request in the bug. > > Regards, Vladimir From harold.seigel at oracle.com Tue May 4 12:55:03 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 4 May 2021 08:55:03 -0400 Subject: [11u] RFR 8218458: [TESTBUG] runtime/NMT/CheckForProperDetailStackTrace.java fails with Expected stack trace missing from output In-Reply-To: <4ba67941-55ca-9989-8655-4f914b2962c1@redhat.com> References: <4ba67941-55ca-9989-8655-4f914b2962c1@redhat.com> Message-ID: Hi Zhengyu, Should "locked_create_entry" be changed to "locked_create_entry_or_null" in the below change? + private static String stackTraceAlternate = + ".*Hashtable.*allocate_new_entry.*\n" + + ".*ModuleEntryTable.*locked_create_entry.*\n" + Thanks, Harold On 5/3/2021 5:03 PM, Zhengyu Gu wrote: > I would like to backport this patch to 11u for parity with Oracle > 11.0.13. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8218458 > The original patch: http://hg.openjdk.java.net/jdk/jdk/rev/b02d1d829b09 > > The original patch does not apply cleanly to 11u. > > 1) CheckForProperDetailStackTrace.java is not in 11u's ProblemList.txt > 2) 11u does not have JDK-8217660. Therefore, context is bit off in > ? CheckForProperDetailStackTrace.java, resolved manually. > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.00/ > > > Test: > ?The test passed on Linux x86_64. > > Thanks, > > -Zhengyu > From yan at openjdk.java.net Tue May 4 13:53:12 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 4 May 2021 13:53:12 GMT Subject: [jdk13u-dev] RFR: 8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI Message-ID: The issue exists and the fix works in GTK-3-based systems (e.g. Xfce). ------------- Commit messages: - Backport a7f46919ff43ede12ed977512a3b0d93bc4cbc76 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/197/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=197&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244088 Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/197.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/197/head:pull/197 PR: https://git.openjdk.java.net/jdk13u-dev/pull/197 From hohensee at amazon.com Tue May 4 14:48:57 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 4 May 2021 14:48:57 +0000 Subject: [11u] RFR (S): 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Vladimir Kempik Date: Tuesday, May 4, 2021 at 4:33 AM To: jdk-updates-dev Cc: "Sergey.Bylokhov at oracle.com" Subject: RE: [11u] RFR (S): 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched Hello Updating webrev, I don?t think that additional line has to be moved to CTrayIcon.m http://cr.openjdk.java.net/~vkempik/8264786/webrev.02/ Vladimir. > 4 ??? 2021 ?., ? 14:21, Vladimir Kempik ???????(?): > > Please review this backport to fix the issue with notification center pop-ups on jdk10+ > > the fix didn?t apply cleanly because one more line of code had to be moved to NSApplicationAWT.m to CTrayIcon.m: > [[NSNotificationCenter defaultCenter] postNotificationName:JNFRunLoopDidStartNotification object:self]; > > > The bug - https://bugs.openjdk.java.net/browse/JDK-8264786 > The webrev - http://cr.openjdk.java.net/~vkempik/8264786/webrev.01/ > The original commit - https://git.openjdk.java.net/jdk/commit/020236cb9825bf4fa91a495a179623e3fcdc0149 > > Will wait for positive tests run before doing jdk11u-fix-request in the bug. > > Regards, Vladimir From mdoerr at openjdk.java.net Tue May 4 21:31:26 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 4 May 2021 21:31:26 GMT Subject: [jdk16u] RFR: 8266288: assert root method not found in witnessed_reabstraction_in_supers is too strong Message-ID: 8266288: assert root method not found in witnessed_reabstraction_in_supers is too strong ------------- Commit messages: - Backport 49d04586ed27fc905083d60aa68793d84824c7f3 Changes: https://git.openjdk.java.net/jdk16u/pull/112/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=112&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266288 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/112/head:pull/112 PR: https://git.openjdk.java.net/jdk16u/pull/112 From clanger at openjdk.java.net Tue May 4 21:51:14 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 4 May 2021 21:51:14 GMT Subject: [jdk16u] RFR: 8265666: Enable AIX build platform to make external debug symbols Message-ID: 8265666: Enable AIX build platform to make external debug symbols ------------- Commit messages: - Backport 84b52db931943db5aa2df7edca7103776f2f2092 Changes: https://git.openjdk.java.net/jdk16u/pull/113/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=113&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265666 Stats: 18 lines in 2 files changed: 7 ins; 9 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/113.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/113/head:pull/113 PR: https://git.openjdk.java.net/jdk16u/pull/113 From clanger at openjdk.java.net Wed May 5 04:53:59 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 5 May 2021 04:53:59 GMT Subject: [jdk16u] Integrated: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 22:05:52 GMT, Christoph Langer wrote: > Backport of 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding This pull request has now been integrated. Changeset: ce14719d Author: Christoph Langer URL: https://git.openjdk.java.net/jdk16u/commit/ce14719df196f914a6695097601c2ad7f3ffb1fd Stats: 245 lines in 2 files changed: 163 ins; 29 del; 53 mod 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding Backport-of: 1ee80e03adfae5f428519f7c134e78a0f277a0a5 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/105 From yan at openjdk.java.net Wed May 5 07:35:02 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 5 May 2021 07:35:02 GMT Subject: [jdk13u-dev] Integrated: 8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI In-Reply-To: References: Message-ID: On Tue, 4 May 2021 13:45:18 GMT, Yuri Nesterenko wrote: > The issue exists and the fix works in GTK-3-based systems (e.g. Xfce). This pull request has now been integrated. Changeset: 9ed07b90 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/9ed07b9029c3174462ed778dba552d119febd1d9 Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod 8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI Backport-of: a7f46919ff43ede12ed977512a3b0d93bc4cbc76 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/197 From aph at redhat.com Wed May 5 09:00:48 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 5 May 2021 10:00:48 +0100 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: References: Message-ID: On 5/3/21 11:15 AM, Bernhard Urban-Forster wrote: > Thanks, I'll wait for the GitHub transition of jdk11u-dev then which seems to happen on June 2nd [1]. Well, maybe. We'll be close to rampdown for the July CPU by then. We might ask you to hold off until after we're branched for release. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From yan at openjdk.java.net Wed May 5 09:26:10 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 5 May 2021 09:26:10 GMT Subject: [jdk15u-dev] RFR: 8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI Message-ID: applicable seamlessly, all relevant tests do pass. ------------- Commit messages: - Backport a7f46919ff43ede12ed977512a3b0d93bc4cbc76 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/43/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=43&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244088 Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/43/head:pull/43 PR: https://git.openjdk.java.net/jdk15u-dev/pull/43 From yan at openjdk.java.net Wed May 5 09:39:55 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 5 May 2021 09:39:55 GMT Subject: [jdk15u-dev] Integrated: 8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI In-Reply-To: References: Message-ID: On Wed, 5 May 2021 09:19:34 GMT, Yuri Nesterenko wrote: > applicable seamlessly, all relevant tests do pass. This pull request has now been integrated. Changeset: 5626db38 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/5626db38fe39dd43b46d9f28d792a73a075188d3 Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod 8244088: [Regression] Switch of Gnome theme ends up in deadlocked UI Backport-of: a7f46919ff43ede12ed977512a3b0d93bc4cbc76 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/43 From matthias.baesken at sap.com Wed May 5 13:53:31 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 May 2021 13:53:31 +0000 Subject: RFR [jdk11]: 8215009: GCC 8 compilation error in libjli Message-ID: Hello , please review the jdk11 backport of 8215009: GCC 8 compilation error in libjli . The patch mostly applies cleanly. However on macOS the file name java_md_macosx.c is different from the file name in jdk/jdk . JBS issue and webrev : https://bugs.openjdk.java.net/browse/JDK-8215009 http://cr.openjdk.java.net/~mbaesken/webrevs/8215009_0_jdk11/ (jdk/jdk change was : http://hg.openjdk.java.net/jdk/jdk/rev/f9302cf718c9 ) Thanks, Matthias From martin.doerr at sap.com Wed May 5 14:22:22 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 5 May 2021 14:22:22 +0000 Subject: AW: RFR [jdk11]: 8215009: GCC 8 compilation error in libjli In-Reply-To: References: Message-ID: Hi Matthias, looks good. Thanks for backporting! Best regards, Martin Von: Baesken, Matthias Datum: Mittwoch, 5. Mai 2021 um 15:53 An: jdk-updates-dev at openjdk.java.net Cc: Doerr, Martin Betreff: RFR [jdk11]: 8215009: GCC 8 compilation error in libjli Hello , please review the jdk11 backport of 8215009: GCC 8 compilation error in libjli . The patch mostly applies cleanly. However on macOS the file name java_md_macosx.c is different from the file name in jdk/jdk . JBS issue and webrev : https://bugs.openjdk.java.net/browse/JDK-8215009 http://cr.openjdk.java.net/~mbaesken/webrevs/8215009_0_jdk11/ (jdk/jdk change was : http://hg.openjdk.java.net/jdk/jdk/rev/f9302cf718c9 ) Thanks, Matthias From thomas.stuefe at gmail.com Wed May 5 14:23:00 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 May 2021 16:23:00 +0200 Subject: RFR [jdk11]: 8215009: GCC 8 compilation error in libjli In-Reply-To: References: Message-ID: I eyeballed this and this looks fine. I was confused at first about the massive diff, but realized that the original patch consists mostly of whitespace changes for some reason. Cheers, Thomas On Wed, May 5, 2021 at 3:53 PM Baesken, Matthias wrote: > Hello , please review the jdk11 backport of 8215009: GCC 8 compilation > error in libjli . > > The patch mostly applies cleanly. However on macOS the file name > java_md_macosx.c is different from the file name in jdk/jdk . > > > JBS issue and webrev : > > https://bugs.openjdk.java.net/browse/JDK-8215009 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215009_0_jdk11/ > > (jdk/jdk change was : > http://hg.openjdk.java.net/jdk/jdk/rev/f9302cf718c9 ) > > > Thanks, Matthias > From matthias.baesken at sap.com Wed May 5 15:02:06 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 May 2021 15:02:06 +0000 Subject: RFR [jdk11]: 8215009: GCC 8 compilation error in libjli In-Reply-To: References: Message-ID: >I eyeballed this and this looks fine. I was confused at first about the massive diff, but realized that the original patch consists mostly of whitespace changes for some reason. Hi Thomas and Martin, thanks for the reviews . Best regards, Matthias From dcherepanov at openjdk.java.net Wed May 5 15:44:32 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 5 May 2021 15:44:32 GMT Subject: [jdk13u-dev] RFR: 8245981: Upgrade to jQuery 3.5.1 Message-ID: 8245981: Upgrade to jQuery 3.5.1 The original patch doesn't apply cleanly. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java > test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java > test/langtools/jdk/javadoc/tool/api/basic/APITest.java the files have different context in 15 after [1] so I changed "jquery-3.4.1.js" to "jquery-3.5.1.js" in these files manually. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/external/jquery/jquery.js the file was removed in 15 after [2] so I replaced the file with new version for consistency Testing: regression tests test/langtools/jdk/javadoc/ passed [1] https://bugs.openjdk.java.net/browse/JDK-8236823 [2] https://bugs.openjdk.java.net/browse/JDK-8238167 ------------- Commit messages: - Backport 0b02c5b5e038db4b86d15a2a99a3a3fd051f406d Changes: https://git.openjdk.java.net/jdk13u-dev/pull/198/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=198&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245981 Stats: 1760 lines in 7 files changed: 786 ins; 238 del; 736 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/198.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/198/head:pull/198 PR: https://git.openjdk.java.net/jdk13u-dev/pull/198 From snazarkin at azul.com Wed May 5 15:59:50 2021 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 5 May 2021 15:59:50 +0000 Subject: RFR [jdk11]: 8215009: GCC 8 compilation error in libjli In-Reply-To: References: Message-ID: Hi Matthias, do you plan to backport other fixes for gcc8.x? Like 8254270 or 8220072 Thanks, /Sergey > On May 5, 2021, at 16:53, Baesken, Matthias wrote: > > Hello , please review the jdk11 backport of 8215009: GCC 8 compilation error in libjli . > > The patch mostly applies cleanly. However on macOS the file name java_md_macosx.c is different from the file name in jdk/jdk . > > > JBS issue and webrev : > > https://bugs.openjdk.java.net/browse/JDK-8215009 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215009_0_jdk11/ > > (jdk/jdk change was : http://hg.openjdk.java.net/jdk/jdk/rev/f9302cf718c9 ) > > > Thanks, Matthias From christoph.langer at sap.com Wed May 5 21:15:33 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 5 May 2021 21:15:33 +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: Hi, just had a quick look at the PR. Since it contains several changes which are backports of a JBS bug item each, we should talk to the Skara folks on whether it's possible to merge such PRs somehow without squashing and with creating backports items in JBS for each change. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Bernhard Urban-Forster > Sent: Freitag, 30. April 2021 23:10 > To: aph ; 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 aarch64 at microsoft.com> > Subject: Re: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u > > 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. > ww.redhat.com%2F&data=04%7C01%7Cbeurba%40microsoft.com%7C7 > 5b981562be84529033908d8efad0888%7C72f988bf86f141af91ab2d7cd011db47 > %7C1%7C0%7C637522873741905341%7CUnknown%7CTWFpbGZsb3d8eyJWIj > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1 > 000&sdata=gq599kym0%2BA8M%2BYjHUKR84Mw5od3vS2dLZ5PfjI1%2F > Ig%3D&reserved=0> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkey > base.io%2Fandrewhaley&data=04%7C01%7Cbeurba%40microsoft.com > %7C75b981562be84529033908d8efad0888%7C72f988bf86f141af91ab2d7cd01 > 1db47%7C1%7C0%7C637522873741905341%7CUnknown%7CTWFpbGZsb3d8 > eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > D%7C1000&sdata=I0HxiyMAwKx1sYxvy8%2Fs8arCVLjO0g2LFDOJKGkMP > ak%3D&reserved=0 > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From matthias.baesken at sap.com Thu May 6 06:48:25 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 6 May 2021 06:48:25 +0000 Subject: RFR [jdk11]: 8215009: GCC 8 compilation error in libjli In-Reply-To: References: Message-ID: Hi Sergey , I requested to backport as well 8214854 : JDWP: Unforseen output truncation in logging And my colleague Martin requested 8219142: Remove unused JIMAGE_ResourcePath With 8215009 and those 2 we can build jdk11u-dev with gcc-8 on "our" Linux platforms . Regarding https://bugs.openjdk.java.net/browse/JDK-8254270 We do not do Linux 32bit builds any more in jdk11 . https://bugs.openjdk.java.net/browse/JDK-8220072 is already in jdk11 . Best regards, Matthias -----Original Message----- From: Sergey Nazarkin Sent: Mittwoch, 5. Mai 2021 18:00 To: Baesken, Matthias Cc: jdk-updates-dev at openjdk.java.net Subject: Re: RFR [jdk11]: 8215009: GCC 8 compilation error in libjli * PGP Signed by an unknown key Hi Matthias, do you plan to backport other fixes for gcc8.x? Like 8254270 or 8220072 Thanks, /Sergey > On May 5, 2021, at 16:53, Baesken, Matthias wrote: > > Hello , please review the jdk11 backport of 8215009: GCC 8 compilation error in libjli . > > The patch mostly applies cleanly. However on macOS the file name java_md_macosx.c is different from the file name in jdk/jdk . > > > JBS issue and webrev : > > https://bugs.openjdk.java.net/browse/JDK-8215009 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215009_0_jdk11/ > > (jdk/jdk change was : http://hg.openjdk.java.net/jdk/jdk/rev/f9302cf718c9 ) > > > Thanks, Matthias * Unknown Key * 0xCB9CD8E0 From yan at openjdk.java.net Thu May 6 09:52:13 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 6 May 2021 09:52:13 GMT Subject: [jdk13u-dev] RFR: 8245981: Upgrade to jQuery 3.5.1 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 15:38:32 GMT, Dmitry Cherepanov wrote: > 8245981: Upgrade to jQuery 3.5.1 > > The original patch doesn't apply cleanly. > > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java > > test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java > > test/langtools/jdk/javadoc/tool/api/basic/APITest.java > the files have different context in 15 after [1] so I changed "jquery-3.4.1.js" to "jquery-3.5.1.js" in these files manually. > > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/external/jquery/jquery.js > the file was removed in 15 after [2] so I replaced the file with new version for consistency > > Testing: regression tests test/langtools/jdk/javadoc/ passed > > [1] https://bugs.openjdk.java.net/browse/JDK-8236823 > [2] https://bugs.openjdk.java.net/browse/JDK-8238167 OK, fine with me ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/198 From yan at openjdk.java.net Thu May 6 10:27:32 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 6 May 2021 10:27:32 GMT Subject: [jdk15u-dev] RFR: 8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS Message-ID: Related fixes are in 15 already. Patch applies without adjustments. All-night test finished on win64/32, linux64/32, macos without problems. ------------- Commit messages: - Backport b6a736738ae025604d86924298fdd04a7851b85f Changes: https://git.openjdk.java.net/jdk15u-dev/pull/44/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=44&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260349 Stats: 123 lines in 2 files changed: 120 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/44.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/44/head:pull/44 PR: https://git.openjdk.java.net/jdk15u-dev/pull/44 From dcherepanov at openjdk.java.net Thu May 6 10:48:01 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 6 May 2021 10:48:01 GMT Subject: [jdk13u-dev] Integrated: 8245981: Upgrade to jQuery 3.5.1 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 15:38:32 GMT, Dmitry Cherepanov wrote: > 8245981: Upgrade to jQuery 3.5.1 > > The original patch doesn't apply cleanly. > > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java > > test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java > > test/langtools/jdk/javadoc/tool/api/basic/APITest.java > the files have different context in 15 after [1] so I changed "jquery-3.4.1.js" to "jquery-3.5.1.js" in these files manually. > > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/external/jquery/jquery.js > the file was removed in 15 after [2] so I replaced the file with new version for consistency > > Testing: regression tests test/langtools/jdk/javadoc/ passed > > [1] https://bugs.openjdk.java.net/browse/JDK-8236823 > [2] https://bugs.openjdk.java.net/browse/JDK-8238167 This pull request has now been integrated. Changeset: 8d96cc3e Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/8d96cc3e93cb00b9ce46df98bf05199e358cf333 Stats: 1760 lines in 7 files changed: 786 ins; 238 del; 736 mod 8245981: Upgrade to jQuery 3.5.1 Reviewed-by: yan Backport-of: 0b02c5b5e038db4b86d15a2a99a3a3fd051f406d ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/198 From yan at openjdk.java.net Thu May 6 11:20:12 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 6 May 2021 11:20:12 GMT Subject: [jdk15u-dev] Integrated: 8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:20:55 GMT, Yuri Nesterenko wrote: > Related fixes are in 15 already. Patch applies without adjustments. All-night test finished on win64/32, linux64/32, macos without problems. This pull request has now been integrated. Changeset: f0f89d22 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/f0f89d22bbcb4d32fddc4f9c21573c95c515caea Stats: 123 lines in 2 files changed: 120 ins; 0 del; 3 mod 8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS Backport-of: b6a736738ae025604d86924298fdd04a7851b85f ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/44 From eastig at amazon.co.uk Thu May 6 11:23:54 2021 From: eastig at amazon.co.uk (Astigeevich, Evgeny) Date: Thu, 6 May 2021 11:23:54 +0000 Subject: [11u] RFR: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: <946C6349-00A4-4C6C-8E1A-2FBB9D5105BA@amazon.com> References: <698957E0-3737-47DE-84F3-2EBB9F439EC1@amazon.com> <946C6349-00A4-4C6C-8E1A-2FBB9D5105BA@amazon.com> Message-ID: Hi Paul, Thanks for reviewing. Could you please sponsor this and 8231713? Thanks, Evgeny ?On 05/05/2021, 21:48, "Astigeevich, Evgeny" wrote: ?On 29/04/2021, 18:53, "Hohensee, Paul" wrote: 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 buddyliao at tencent.com Thu May 6 12:13:07 2021 From: buddyliao at tencent.com (=?utf-8?B?YnVkZHlsaWFvKOW7luW9rCk=?=) Date: Thu, 6 May 2021 12:13:07 +0000 Subject: =?utf-8?B?WzExdV0gUkZSIDgyNjYzNTI6IEFkZCBwYXJhbGxlbCBoZWFwIGl0ZXJhdGlv?= =?utf-8?B?biBmb3Igam1hcCDigJNoaXN0bw==?= In-Reply-To: <6BEC0815-C4EC-4B34-8195-407C50E641FE@tencent.com> References: <51C22C0C-781C-41FD-9F5C-FFF58BC05353@tencent.com> <6BEC0815-C4EC-4B34-8195-407C50E641FE@tencent.com> Message-ID: <9990EC05-E2AC-43B5-B9B2-262DD63AE0A2@tencent.com> Dear all, Would you help me to review the following backport from jdk-master? Original bug: https://bugs.openjdk.java.net/browse/JDK-8215624 http://hg.openjdk.java.net/jdk/jdk/rev/b1afb7c82d59 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8266353 Original patch does not apply cleanly to 11u, because jmap command parameter is different between each other, and the code structure has little changed. Notably, I had to change the src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java to make it matches 11u-dev 11u webrev: https://cr.openjdk.java.net/~lzang/BuddyLiao/8266352/webrev01/ Testing: x86_64 build, affected tests, tier1 Thanks, -Buddy From buddyliao at tencent.com Thu May 6 12:13:11 2021 From: buddyliao at tencent.com (=?utf-8?B?YnVkZHlsaWFvKOW7luW9rCk=?=) Date: Thu, 6 May 2021 12:13:11 +0000 Subject: [11u] RFR 8266354: JDK-8215624 causes assert(worker_id < _n_workers) failed: Invalid worker_id In-Reply-To: References: <1CA90AA9-7438-42F4-A92C-E020B20C9915@tencent.com> Message-ID: <0E5272F3-0A1D-4626-B699-7C3C080DE677@tencent.com> Dear all, Would you help me to review the following backport from jdk-master? This backport is bugfix for the prefer backport https://bugs.openjdk.java.net/browse/JDK-8266352 Original bug: https://bugs.openjdk.java.net/browse/JDK-8251570 https://hg.openjdk.java.net/jdk/jdk/rev/dd827a012e43 Original patch does not apply cleanly to 11u, since the code structure has changed. Notably, I had to make it fit with 11u-dev. 11u webrev: https://cr.openjdk.java.net/~lzang/BuddyLiao/8266354/webrev01/ Testing: x86_64 build, affected tests, tier1 Thanks, -Buddy From snazarki at openjdk.java.net Thu May 6 13:33:30 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Thu, 6 May 2021 13:33:30 GMT Subject: [jdk13u-dev] RFR: 8231118: ARM32: Math tests failures Message-ID: Hi! I'd like to backport fixes for Math test failures happens on Raspberry Pi 4 running Raspbian OS 10 ("buster"). The patch applies cleanly. Tests show failure without the patch and success after the patch. Tested: tier1 Rpi4 ------------- Commit messages: - Backport 485115d1b3bc6b67069d65dc8223474dd9850b08 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/199/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=199&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231118 Stats: 49 lines in 6 files changed: 22 ins; 9 del; 18 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/199.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/199/head:pull/199 PR: https://git.openjdk.java.net/jdk13u-dev/pull/199 From hohensee at amazon.com Thu May 6 14:30:17 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 6 May 2021 14:30:17 +0000 Subject: [11u] RFR: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: References: <698957E0-3737-47DE-84F3-2EBB9F439EC1@amazon.com> <946C6349-00A4-4C6C-8E1A-2FBB9D5105BA@amazon.com> Message-ID: <6526C3DE-5DE3-4536-9381-73D86BA1AE22@amazon.com> Done and pushed. Thanks, Paul ?-----Original Message----- From: "Astigeevich, Evgeny" Date: Thursday, May 6, 2021 at 4:23 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] RFR: Missing intrinsics for Math.ceil, floor, rint Hi Paul, Thanks for reviewing. Could you please sponsor this and 8231713? Thanks, Evgeny On 05/05/2021, 21:48, "Astigeevich, Evgeny" wrote: On 29/04/2021, 18:53, "Hohensee, Paul" wrote: 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 From omikhaltcova at openjdk.java.net Thu May 6 16:10:26 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 6 May 2021 16:10:26 GMT Subject: [jdk13u-dev] RFR: 8242184: Default signature algorithm for an RSASSA-PSS key Message-ID: I'd like to backport JDK-8242184 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested via jtreg with "jdk/sun/security". ------------- Commit messages: - Backport d8539a51efe379cacee4093995100bf7fe23a312 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=200&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242184 Stats: 93 lines in 4 files changed: 87 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/200/head:pull/200 PR: https://git.openjdk.java.net/jdk13u-dev/pull/200 From snazarki at openjdk.java.net Thu May 6 16:45:14 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Thu, 6 May 2021 16:45:14 GMT Subject: [jdk13u-dev] Integrated: 8231118: ARM32: Math tests failures In-Reply-To: References: Message-ID: <0b5EQr1gQiDQzeQQKHgpZLCloJfh1wCbCeOxZTNrcdg=.cacc6248-eddd-458a-99db-ceb2c09fa7bd@github.com> On Thu, 6 May 2021 13:26:34 GMT, Sergey Nazarkin wrote: > Hi! > > I'd like to backport fixes for Math test failures happens on Raspberry Pi 4 running Raspbian OS 10 ("buster"). The patch applies cleanly. Tests show failure without the patch and success after the patch. > Tested: tier1 Rpi4 This pull request has now been integrated. Changeset: d46f2971 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/d46f29717e41746d0d78a6876f3a6c6d6b581ae5 Stats: 49 lines in 6 files changed: 22 ins; 9 del; 18 mod 8231118: ARM32: Math tests failures Backport-of: 485115d1b3bc6b67069d65dc8223474dd9850b08 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/199 From omikhaltcova at openjdk.java.net Thu May 6 16:47:55 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 6 May 2021 16:47:55 GMT Subject: [jdk13u-dev] Integrated: 8242184: Default signature algorithm for an RSASSA-PSS key In-Reply-To: References: Message-ID: <8dr_tycSytIYFh_YGaxu42rWYzUz6DoIVCRJdHcurhc=.963c0960-8f33-4ebf-9016-eb4252bf5ea7@github.com> On Thu, 6 May 2021 16:00:27 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8242184 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested via jtreg with "jdk/sun/security". This pull request has now been integrated. Changeset: fac6c491 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/fac6c4915c6f7609c692af13d301f82e1cd0d0ba Stats: 93 lines in 4 files changed: 87 ins; 1 del; 5 mod 8242184: Default signature algorithm for an RSASSA-PSS key Backport-of: d8539a51efe379cacee4093995100bf7fe23a312 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/200 From mdoerr at openjdk.java.net Thu May 6 16:52:10 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 6 May 2021 16:52:10 GMT Subject: [jdk16u] Integrated: 8266288: assert root method not found in witnessed_reabstraction_in_supers is too strong In-Reply-To: References: Message-ID: On Tue, 4 May 2021 21:22:08 GMT, Martin Doerr wrote: > 8266288: assert root method not found in witnessed_reabstraction_in_supers is too strong This pull request has now been integrated. Changeset: 8714642b Author: Martin Doerr URL: https://git.openjdk.java.net/jdk16u/commit/8714642b13a0e062745ec9a2763d8f120f38e043 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8266288: assert root method not found in witnessed_reabstraction_in_supers is too strong Backport-of: 49d04586ed27fc905083d60aa68793d84824c7f3 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/112 From akolarkunnu at openjdk.java.net Thu May 6 18:19:24 2021 From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu) Date: Thu, 6 May 2021 18:19:24 GMT Subject: [jdk16u] RFR: 8262899: TestRedirectLinks fails Message-ID: <5fdLrEqd9xH7N5kvCvb93C7-cpqJIksjUcaRHNC0Ee4=.e9a093db-9f20-490d-a778-dd4c2ee2cf7c@github.com> 8262899: TestRedirectLinks fails ------------- Commit messages: - Backport f17ea9e66b68b987b4c780b4a9f99762b8be403b Changes: https://git.openjdk.java.net/jdk16u/pull/114/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=114&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262899 Stats: 40 lines in 2 files changed: 32 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk16u/pull/114.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/114/head:pull/114 PR: https://git.openjdk.java.net/jdk16u/pull/114 From akolarkunnu at openjdk.java.net Thu May 6 18:41:01 2021 From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu) Date: Thu, 6 May 2021 18:41:01 GMT Subject: [jdk16u] Integrated: 8262899: TestRedirectLinks fails In-Reply-To: <5fdLrEqd9xH7N5kvCvb93C7-cpqJIksjUcaRHNC0Ee4=.e9a093db-9f20-490d-a778-dd4c2ee2cf7c@github.com> References: <5fdLrEqd9xH7N5kvCvb93C7-cpqJIksjUcaRHNC0Ee4=.e9a093db-9f20-490d-a778-dd4c2ee2cf7c@github.com> Message-ID: On Thu, 6 May 2021 18:08:16 GMT, Abdul Kolarkunnu wrote: > 8262899: TestRedirectLinks fails This pull request has now been integrated. Changeset: cb295fb9 Author: Abdul Kolarkunnu Committer: Sean Coffey URL: https://git.openjdk.java.net/jdk16u/commit/cb295fb931a814a73277d1a3b555ce47550cbb11 Stats: 40 lines in 2 files changed: 32 ins; 0 del; 8 mod 8262899: TestRedirectLinks fails Backport-of: f17ea9e66b68b987b4c780b4a9f99762b8be403b ------------- PR: https://git.openjdk.java.net/jdk16u/pull/114 From clanger at openjdk.java.net Thu May 6 20:32:04 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 6 May 2021 20:32:04 GMT Subject: [jdk16u] Integrated: 8265666: Enable AIX build platform to make external debug symbols In-Reply-To: References: Message-ID: On Tue, 4 May 2021 21:43:31 GMT, Christoph Langer wrote: > 8265666: Enable AIX build platform to make external debug symbols This pull request has now been integrated. Changeset: 1116b757 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk16u/commit/1116b75741a804852b723d421649706b5323bc7c Stats: 18 lines in 2 files changed: 7 ins; 9 del; 2 mod 8265666: Enable AIX build platform to make external debug symbols Backport-of: 84b52db931943db5aa2df7edca7103776f2f2092 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/113 From abrygin at azul.com Fri May 7 09:04:45 2021 From: abrygin at azul.com (Andrew Brygin) Date: Fri, 7 May 2021 12:04:45 +0300 Subject: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager Message-ID: <7b7428f8-ae8f-c27a-9330-28f267d98ebe@azul.com> Hello, I would like to propose a backport of 8251367 for 11u: The fix for 8249821: Separate libharfbuzz from libfontmanager is already backported into 11u, so fontmanager.dll now has two dependencies: freetype.dl and harfbuzz.dll which should be handled in the same manner. The absence of explicit loading of harfbuzz.dll affects some exe4j/install4j deployments which do not use standard java/javaw launchers. Original issue: https://bugs.openjdk.java.net/browse/JDK-8251367 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/21c664a5b7e2 Webrev: http://cr.openjdk.java.net/~bae/11u/8251367/webrev.00/ The patch for Awt2dLibraries.gmk required some adjustments due to the file rename (make/modules/java.desktop/lib/Awt2dLibraries.gmk -> make/lib/Awt2dLibraries.gmk) and context differences. Thanks, Andrew From dcherepanov at openjdk.java.net Fri May 7 11:00:14 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Fri, 7 May 2021 11:00:14 GMT Subject: [jdk13u-dev] RFR: 8244087: 2020-04-24 public suffix list update v ff6fcea Message-ID: 8244087: 2020-04-24 public suffix list update v ff6fcea ------------- Commit messages: - Backport 07cb35a9f3122673b8eeae1f3c84fdb6be5c46af Changes: https://git.openjdk.java.net/jdk13u-dev/pull/201/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=201&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244087 Stats: 308 lines in 5 files changed: 201 ins; 67 del; 40 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/201.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/201/head:pull/201 PR: https://git.openjdk.java.net/jdk13u-dev/pull/201 From dcherepanov at openjdk.java.net Fri May 7 12:10:10 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Fri, 7 May 2021 12:10:10 GMT Subject: [jdk13u-dev] Integrated: 8244087: 2020-04-24 public suffix list update v ff6fcea In-Reply-To: References: Message-ID: On Fri, 7 May 2021 10:52:30 GMT, Dmitry Cherepanov wrote: > 8244087: 2020-04-24 public suffix list update v ff6fcea This pull request has now been integrated. Changeset: 56ed2b58 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/56ed2b58a2a246aa24efc7383cd5531c2abe2cbf Stats: 308 lines in 5 files changed: 201 ins; 67 del; 40 mod 8244087: 2020-04-24 public suffix list update v ff6fcea Backport-of: 07cb35a9f3122673b8eeae1f3c84fdb6be5c46af ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/201 From martin.doerr at sap.com Fri May 7 15:55:51 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 7 May 2021 15:55:51 +0000 Subject: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager In-Reply-To: <7b7428f8-ae8f-c27a-9330-28f267d98ebe@azul.com> References: <7b7428f8-ae8f-c27a-9330-28f267d98ebe@azul.com> Message-ID: Hi Andrew, looks like correctly backported. However, the code added to FontManagerNativeLibrary.java was removed again: https://github.com/openjdk/jdk/commit/05fe06a6bafc089c6466ccbdea335e5dbfdaf335 Are you planning to backport that one, too? Best regards, Martin Von: jdk-updates-dev im Auftrag von Andrew Brygin Datum: Freitag, 7. Mai 2021 um 11:07 An: jdk-updates-dev at openjdk.java.net Betreff: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager Hello, I would like to propose a backport of 8251367 for 11u: The fix for 8249821: Separate libharfbuzz from libfontmanager is already backported into 11u, so fontmanager.dll now has two dependencies: freetype.dl and harfbuzz.dll which should be handled in the same manner. The absence of explicit loading of harfbuzz.dll affects some exe4j/install4j deployments which do not use standard java/javaw launchers. Original issue: https://bugs.openjdk.java.net/browse/JDK-8251367 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/21c664a5b7e2 Webrev: http://cr.openjdk.java.net/~bae/11u/8251367/webrev.00/ The patch for Awt2dLibraries.gmk required some adjustments due to the file rename (make/modules/java.desktop/lib/Awt2dLibraries.gmk -> make/lib/Awt2dLibraries.gmk) and context differences. Thanks, Andrew From abrygin at azul.com Fri May 7 16:25:12 2021 From: abrygin at azul.com (Andrew Brygin) Date: Fri, 7 May 2021 19:25:12 +0300 Subject: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager In-Reply-To: References: <7b7428f8-ae8f-c27a-9330-28f267d98ebe@azul.com> Message-ID: <984828bd-b989-580a-d91b-3dbb17172368@azul.com> Hi Martin, yes, I think we have to backport JDK-8255790 as well: it actually reverts the harfbuzz separation (JDK-8249821) for windows, so the problem with exe4j apps will be resolved without modification of FontManagerNativeLibrary.java. Thanks, Andrew On 07/05/2021 18:55, Doerr, Martin wrote: > Hi Andrew, > > ? > > looks like correctly backported. > > However, the code added to FontManagerNativeLibrary.java was removed again: > > https://github.com/openjdk/jdk/commit/05fe06a6bafc089c6466ccbdea335e5dbfdaf335 > > Are you planning to backport that one, too? > > ? > > Best regards, > > Martin > > ? > > ? > > *Von: *jdk-updates-dev im > Auftrag von Andrew Brygin > *Datum: *Freitag, 7. Mai 2021 um 11:07 > *An: *jdk-updates-dev at openjdk.java.net > *Betreff: *[11u] RFR (S): 8251367: [windows] harfbuzz.dll not found > causes failure to load sun.font.SunFontManager > > Hello, > > ?I would like to propose a backport of 8251367 for 11u: > > ?The fix for 8249821: Separate libharfbuzz from libfontmanager is > already backported into 11u, so fontmanager.dll now has two > dependencies: freetype.dl and harfbuzz.dll which should be handled in > the same manner. > > ?The absence of explicit loading of harfbuzz.dll affects some > exe4j/install4j deployments which do not use standard java/javaw launchers. > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8251367 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/21c664a5b7e2 > > Webrev: http://cr.openjdk.java.net/~bae/11u/8251367/webrev.00/ > > > ?The patch for Awt2dLibraries.gmk required some adjustments due to the > file rename (make/modules/java.desktop/lib/Awt2dLibraries.gmk -> > make/lib/Awt2dLibraries.gmk) and context differences. > > Thanks, > Andrew > From martin.doerr at sap.com Fri May 7 16:29:38 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 7 May 2021 16:29:38 +0000 Subject: AW: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager In-Reply-To: <984828bd-b989-580a-d91b-3dbb17172368@azul.com> References: <7b7428f8-ae8f-c27a-9330-28f267d98ebe@azul.com> , <984828bd-b989-580a-d91b-3dbb17172368@azul.com> Message-ID: Hi Andrew, thanks for checking. You can consider your 8251367 backport as reviewed, but I think it should get pushed together with 8255790 if possible. Do you agree? Best regards, Martin Von: Andrew Brygin Datum: Freitag, 7. Mai 2021 um 18:25 An: Doerr, Martin , jdk-updates-dev at openjdk.java.net Betreff: Re: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager Hi Martin, yes, I think we have to backport JDK-8255790 as well: it actually reverts the harfbuzz separation (JDK-8249821) for windows, so the problem with exe4j apps will be resolved without modification of FontManagerNativeLibrary.java. Thanks, Andrew On 07/05/2021 18:55, Doerr, Martin wrote: > Hi Andrew, > > > > looks like correctly backported. > > However, the code added to FontManagerNativeLibrary.java was removed again: > > https://github.com/openjdk/jdk/commit/05fe06a6bafc089c6466ccbdea335e5dbfdaf335 > > Are you planning to backport that one, too? > > > > Best regards, > > Martin > > > > > > *Von: *jdk-updates-dev im > Auftrag von Andrew Brygin > *Datum: *Freitag, 7. Mai 2021 um 11:07 > *An: *jdk-updates-dev at openjdk.java.net > *Betreff: *[11u] RFR (S): 8251367: [windows] harfbuzz.dll not found > causes failure to load sun.font.SunFontManager > > Hello, > > I would like to propose a backport of 8251367 for 11u: > > The fix for 8249821: Separate libharfbuzz from libfontmanager is > already backported into 11u, so fontmanager.dll now has two > dependencies: freetype.dl and harfbuzz.dll which should be handled in > the same manner. > > The absence of explicit loading of harfbuzz.dll affects some > exe4j/install4j deployments which do not use standard java/javaw launchers. > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8251367 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/21c664a5b7e2 > > Webrev: http://cr.openjdk.java.net/~bae/11u/8251367/webrev.00/ > > > The patch for Awt2dLibraries.gmk required some adjustments due to the > file rename (make/modules/java.desktop/lib/Awt2dLibraries.gmk -> > make/lib/Awt2dLibraries.gmk) and context differences. > > Thanks, > Andrew > From florian.david at datadoghq.com Fri May 7 16:34:00 2021 From: florian.david at datadoghq.com (Florian David) Date: Fri, 7 May 2021 18:34:00 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: Hi all, Please find an update to the backport. Comments related to https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005880.html where the previous patch has broken the 11u build have been taken into account: - check_java_thread_in_native is replaced by check_java_thread_in_vm in ObjectSampleCheckpoint::on_rotation - ThreadInVMfromNative transition(thread) is removed. That check is part of the original PR for JDK17 but since some code in JFR was moved from JNI (in 11) to native in 16, this check is not valid here. Build and Tests: - Linux release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". - Windows release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". The run-test-tier1 test suite did not complete entirely because of some issues with paths being too long and "vswhere.exe" not able to be run by the test on my machine. I would feel more confident (especially Windows was broken by the previous backport) if a maintainer could run the test suite on Windows. The "jtreg:jdk/jfr/" test suite ran successfully. Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ Original PR: https://github.com/openjdk/jdk/pull/2780 Thanks, Florian DAVID On Mon, Apr 12, 2021 at 10:38 AM Jaroslav Bachor?k < jaroslav.bachorik at datadoghq.com> wrote: > 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 abrygin at azul.com Fri May 7 16:36:08 2021 From: abrygin at azul.com (Andrew Brygin) Date: Fri, 7 May 2021 19:36:08 +0300 Subject: AW: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager In-Reply-To: References: <7b7428f8-ae8f-c27a-9330-28f267d98ebe@azul.com> <984828bd-b989-580a-d91b-3dbb17172368@azul.com> Message-ID: <016f6b5e-7c1f-b125-1925-b548b4b07f8b@azul.com> Hi Martin, thanks for review. I agree that 8251367 and 8255790 should be pushed together. I will put the fix request comment into 8251367, just as reference to this review thread, but postpone the fix request label until 8255790 will be ready for 11u. Is it OK? Thanks, Andrew On 07/05/2021 19:29, Doerr, Martin wrote: > Hi Andrew, > > ? > > thanks for checking. You can consider your 8251367 backport as reviewed, > but I think it should get pushed together with 8255790 if possible. Do > you agree? > > ? > > Best regards, > > Martin > > ? > > ? > > *Von: *Andrew Brygin > *Datum: *Freitag, 7. Mai 2021 um 18:25 > *An: *Doerr, Martin , > jdk-updates-dev at openjdk.java.net > *Betreff: *Re: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not > found causes failure to load sun.font.SunFontManager > > Hi Martin, > > ?yes, I think we have to backport JDK-8255790 as well: it actually > reverts the harfbuzz separation (JDK-8249821) for windows, so the > problem with exe4j apps will be resolved without modification of > FontManagerNativeLibrary.java. > > Thanks, > Andrew > > On 07/05/2021 18:55, Doerr, Martin wrote: >> Hi Andrew, >> >> ? >> >> looks like correctly backported. >> >> However, the code added to FontManagerNativeLibrary.java was removed > again: >> >> > https://github.com/openjdk/jdk/commit/05fe06a6bafc089c6466ccbdea335e5dbfdaf335 > >> >> Are you planning to backport that one, too? >> >> ? >> >> Best regards, >> >> Martin >> >> ? >> >> ? >> >> *Von: *jdk-updates-dev im >> Auftrag von Andrew Brygin >> *Datum: *Freitag, 7. Mai 2021 um 11:07 >> *An: *jdk-updates-dev at openjdk.java.net >> *Betreff: *[11u] RFR (S): 8251367: [windows] harfbuzz.dll not found >> causes failure to load sun.font.SunFontManager >> >> Hello, >> >> ?I would like to propose a backport of 8251367 for 11u: >> >> ?The fix for 8249821: Separate libharfbuzz from libfontmanager is >> already backported into 11u, so fontmanager.dll now has two >> dependencies: freetype.dl and harfbuzz.dll which should be handled in >> the same manner. >> >> ?The absence of explicit loading of harfbuzz.dll affects some >> exe4j/install4j deployments which do not use standard java/javaw > launchers. >> >> Original issue: https://bugs.openjdk.java.net/browse/JDK-8251367 > >> > >> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/21c664a5b7e2 > >> > >> Webrev: http://cr.openjdk.java.net/~bae/11u/8251367/webrev.00/ > >> > >> >> ?The patch for Awt2dLibraries.gmk required some adjustments due to the >> file rename (make/modules/java.desktop/lib/Awt2dLibraries.gmk -> >> make/lib/Awt2dLibraries.gmk) and context differences. >> >> Thanks, >> Andrew >> > From martin.doerr at sap.com Fri May 7 16:37:21 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 7 May 2021 16:37:21 +0000 Subject: AW: AW: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager In-Reply-To: <016f6b5e-7c1f-b125-1925-b548b4b07f8b@azul.com> References: <7b7428f8-ae8f-c27a-9330-28f267d98ebe@azul.com> <984828bd-b989-580a-d91b-3dbb17172368@azul.com> , <016f6b5e-7c1f-b125-1925-b548b4b07f8b@azul.com> Message-ID: Excellent! Thanks a lot! Best regards, Martin Von: Andrew Brygin Datum: Freitag, 7. Mai 2021 um 18:36 An: Doerr, Martin , jdk-updates-dev at openjdk.java.net Betreff: Re: AW: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager Hi Martin, thanks for review. I agree that 8251367 and 8255790 should be pushed together. I will put the fix request comment into 8251367, just as reference to this review thread, but postpone the fix request label until 8255790 will be ready for 11u. Is it OK? Thanks, Andrew On 07/05/2021 19:29, Doerr, Martin wrote: > Hi Andrew, > > > > thanks for checking. You can consider your 8251367 backport as reviewed, > but I think it should get pushed together with 8255790 if possible. Do > you agree? > > > > Best regards, > > Martin > > > > > > *Von: *Andrew Brygin > *Datum: *Freitag, 7. Mai 2021 um 18:25 > *An: *Doerr, Martin , > jdk-updates-dev at openjdk.java.net > *Betreff: *Re: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not > found causes failure to load sun.font.SunFontManager > > Hi Martin, > > yes, I think we have to backport JDK-8255790 as well: it actually > reverts the harfbuzz separation (JDK-8249821) for windows, so the > problem with exe4j apps will be resolved without modification of > FontManagerNativeLibrary.java. > > Thanks, > Andrew > > On 07/05/2021 18:55, Doerr, Martin wrote: >> Hi Andrew, >> >> >> >> looks like correctly backported. >> >> However, the code added to FontManagerNativeLibrary.java was removed > again: >> >> > https://github.com/openjdk/jdk/commit/05fe06a6bafc089c6466ccbdea335e5dbfdaf335 > >> >> Are you planning to backport that one, too? >> >> >> >> Best regards, >> >> Martin >> >> >> >> >> >> *Von: *jdk-updates-dev im >> Auftrag von Andrew Brygin >> *Datum: *Freitag, 7. Mai 2021 um 11:07 >> *An: *jdk-updates-dev at openjdk.java.net >> *Betreff: *[11u] RFR (S): 8251367: [windows] harfbuzz.dll not found >> causes failure to load sun.font.SunFontManager >> >> Hello, >> >> I would like to propose a backport of 8251367 for 11u: >> >> The fix for 8249821: Separate libharfbuzz from libfontmanager is >> already backported into 11u, so fontmanager.dll now has two >> dependencies: freetype.dl and harfbuzz.dll which should be handled in >> the same manner. >> >> The absence of explicit loading of harfbuzz.dll affects some >> exe4j/install4j deployments which do not use standard java/javaw > launchers. >> >> Original issue: https://bugs.openjdk.java.net/browse/JDK-8251367 > >> > >> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/21c664a5b7e2 > >> > >> Webrev: http://cr.openjdk.java.net/~bae/11u/8251367/webrev.00/ > >> > >> >> The patch for Awt2dLibraries.gmk required some adjustments due to the >> file rename (make/modules/java.desktop/lib/Awt2dLibraries.gmk -> >> make/lib/Awt2dLibraries.gmk) and context differences. >> >> Thanks, >> Andrew >> > From dmitry.chuyko at bell-sw.com Fri May 7 20:11:19 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 7 May 2021 23:11:19 +0300 Subject: [11u] RFR (S) 8248870: AARCH64: I2L/L2I conversions can be skipped for masked positive values Message-ID: Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8248870 aarch64_ad.m4 and aarch64.ad are decorated slightly different in 11u, unmodified ubfizIConvI2LAndI code was inserted similarly after ubfizIConvI2L taking that into account, benchmark part applied cleanly. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8248870/webrev.11u.00/ Testing: tier1, tier2. -- Thanks, -Dmitry From luoziyi at amazon.com Fri May 7 21:29:14 2021 From: luoziyi at amazon.com (Luo, Ziyi) Date: Fri, 7 May 2021 21:29:14 +0000 Subject: [11u] RFR 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards Message-ID: Hi, May I have a review of this backport to 11u: JBS: https://bugs.openjdk.java.net/browse/JDK-8254717 Webrev: http://cr.openjdk.java.net/~luoziyi/8254717/webrev.00 This is almost a clean backport except a missing class sun.security.ec.ed.EdDSAKeyFactory. The class is introduced in JDK-8166597: Crypto support for the EdDSA Signature Algorithm, a new feature in JDK15. IMPORTANT: This patch introduces a regression in JCK17. We addressed it in JDK-8263404 and I prepared the backport as well (I have another RFR for it): http://cr.openjdk.java.net/~luoziyi/8263404/webrev.00/ Upon both backports are ready for merging, please merge 8254717 first. Tests: jtreg jdk:tier1/2 Thanks, Ziyi From luoziyi at amazon.com Fri May 7 21:31:24 2021 From: luoziyi at amazon.com (Luo, Ziyi) Date: Fri, 7 May 2021 21:31:24 +0000 Subject: [11u] RFR 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec Message-ID: <0CF3E26B-2FDA-4133-9AEC-42CAF1A9E4B5@amazon.com> Hi, May I have a review of this backport to 11u: JBS: https://bugs.openjdk.java.net/browse/JDK-8263404 Webrev: http://cr.openjdk.java.net/~luoziyi/8263404/webrev.00 This is almost a clean backport except a minor change in p11-nss-sensitive.txt. The original patch tests SHA3 algorithms in SunPKCS11, a new feature implemented in JDK16 (JDK-8242332). Again, this patch needs to be merged after JDK-8254717 backport. Tests: jtreg jdk:tier1/2 Thanks, Ziyi From snazarki at openjdk.java.net Fri May 7 23:35:22 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Fri, 7 May 2021 23:35:22 GMT Subject: [jdk13u-dev] RFR: 8263676: AArch64: one potential bug in C1 LIRGenerator::generate_address() Message-ID: <7WuRIeY_yAzIEWjZUWOTkrJ1k4q2XHpDx-SHt5VITmk=.26ad86ec-bd36-4640-a097-8b6319f3e282@github.com> Hi! I'd like to backport this small fix of obvious mistake. Applies cleanly. Tested tier1 on aarch64. ------------- Commit messages: - Backport 81ba5784ba866be39612982c637b509c8205e88f Changes: https://git.openjdk.java.net/jdk13u-dev/pull/203/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=203&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263676 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/203.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/203/head:pull/203 PR: https://git.openjdk.java.net/jdk13u-dev/pull/203 From evergizova at openjdk.java.net Sat May 8 00:20:47 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Sat, 8 May 2021 00:20:47 GMT Subject: [jdk15u-dev] RFR: 8244500: jtreg test error in test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java Message-ID: <7dkB3qb4_Yd-BNQQBsfUTOMxcH4G6Our1L4SuJhGqgo=.55378353-802e-42b6-a20d-a11489d7bb72@github.com> I would like to backport JDK-8244500 to 15u as a prerequisite for JDK-8250984. This is test-only fix, applies cleanly. Tested with container tests, the affected tests passed. ------------- Commit messages: - Backport 732d8865dfb56e2afbc13d7e53fb1017b9e8b10e Changes: https://git.openjdk.java.net/jdk15u-dev/pull/46/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=46&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244500 Stats: 25 lines in 3 files changed: 21 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/46.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/46/head:pull/46 PR: https://git.openjdk.java.net/jdk15u-dev/pull/46 From evergizova at openjdk.java.net Sat May 8 00:24:08 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Sat, 8 May 2021 00:24:08 GMT Subject: [jdk15u-dev] RFR: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics Message-ID: I would like to backport JDK-8250627 to 15u for parity with 11u. The patch applies cleanly. Tested with container tests, including new one and tier1. ------------- Commit messages: - Backport e6517d1ae2628f16442e09fd8f48190762517d2e Changes: https://git.openjdk.java.net/jdk15u-dev/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250627 Stats: 175 lines in 7 files changed: 173 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk15u-dev/pull/45 From aph at openjdk.java.net Mon May 10 10:00:38 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 10 May 2021 10:00:38 GMT Subject: [jdk13u-dev] RFR: 8263676: AArch64: one potential bug in C1 LIRGenerator::generate_address() In-Reply-To: <7WuRIeY_yAzIEWjZUWOTkrJ1k4q2XHpDx-SHt5VITmk=.26ad86ec-bd36-4640-a097-8b6319f3e282@github.com> References: <7WuRIeY_yAzIEWjZUWOTkrJ1k4q2XHpDx-SHt5VITmk=.26ad86ec-bd36-4640-a097-8b6319f3e282@github.com> Message-ID: On Fri, 7 May 2021 22:39:25 GMT, Sergey Nazarkin wrote: > Hi! > > I'd like to backport this small fix of obvious mistake. Applies cleanly. Tested tier1 on aarch64. Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/203 From zgu at redhat.com Mon May 10 13:07:50 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 10 May 2021 09:07:50 -0400 Subject: [11u] RFR 8218458: [TESTBUG] runtime/NMT/CheckForProperDetailStackTrace.java fails with Expected stack trace missing from output In-Reply-To: References: <4ba67941-55ca-9989-8655-4f914b2962c1@redhat.com> Message-ID: <56ff8c87-9ff5-54ab-863b-b2abca4503cd@redhat.com> Thanks Harold for catching this. Updated and retested. http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.01/ -Zhengyu On 5/4/21 8:55 AM, Harold Seigel wrote: > Hi Zhengyu, > > Should "locked_create_entry" be changed to "locked_create_entry_or_null" > in the below change? > > ?? + private static String stackTraceAlternate = > ?? + ".*Hashtable.*allocate_new_entry.*\n" + > ?? + ".*ModuleEntryTable.*locked_create_entry.*\n" + > > Thanks, Harold > > On 5/3/2021 5:03 PM, Zhengyu Gu wrote: >> I would like to backport this patch to 11u for parity with Oracle >> 11.0.13. >> >> The original bug: https://bugs.openjdk.java.net/browse/JDK-8218458 >> The original patch: http://hg.openjdk.java.net/jdk/jdk/rev/b02d1d829b09 >> >> The original patch does not apply cleanly to 11u. >> >> 1) CheckForProperDetailStackTrace.java is not in 11u's ProblemList.txt >> 2) 11u does not have JDK-8217660. Therefore, context is bit off in >> ? CheckForProperDetailStackTrace.java, resolved manually. >> >> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.00/ >> >> >> Test: >> ?The test passed on Linux x86_64. >> >> Thanks, >> >> -Zhengyu >> > From omikhaltcova at openjdk.java.net Mon May 10 13:09:05 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 10 May 2021 13:09:05 GMT Subject: [jdk13u-dev] RFR: 8247763: assert(outer->outcnt() == 2) failed: 'only phis' failure in LoopNode::verify_strip_mined() Message-ID: <4tbM49dIwECFcb0-uEbE0v7paKWA4HEImYMA6FPp_2E=.21362912-9333-4491-8095-b36307cb5992@github.com> I'd like to backport JDK-8247763 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with the test attached to the issue. All regular tests passed as well. ------------- Commit messages: - Backport 5adfaa39866f3127000f0779158c65afe1d24007 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/202/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=202&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247763 Stats: 72 lines in 2 files changed: 72 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/202.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/202/head:pull/202 PR: https://git.openjdk.java.net/jdk13u-dev/pull/202 From sgehwolf at redhat.com Mon May 10 13:25:01 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 10 May 2021 15:25:01 +0200 Subject: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 Message-ID: <4a13c739d509305f763a8da9b0f2af4dd1d2b7c3.camel@redhat.com> Hi, Please review this AIX build fix for OpenJDK 11u. The JDK 11u backport of JDK-8247753 included a call to strcasestr for case-insensitive comparison of the set XDG_CURRENT_DESKTOP environment variable. Unfortunately, strcasestr is a GNU extension and isn't available on AIX. The proposed fix is to implement a version of strcasestr AIX-local in java_props_md.c. Note that this is a JDK 11u-specific bug since the backport of JDK-8247753 is different to the version in later JDKs where this comparison is not done in native code, but in Java. Bug: https://bugs.openjdk.java.net/browse/JDK-8266713 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266713/02/webrev/ AIX failed to build prior this patch and builds with this patch after. Manual sanity checks for the strcasestr() impl. Thoughts? Thanks, Severin From harold.seigel at oracle.com Mon May 10 14:12:54 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 10 May 2021 10:12:54 -0400 Subject: [External] : Re: [11u] RFR 8218458: [TESTBUG] runtime/NMT/CheckForProperDetailStackTrace.java fails with Expected stack trace missing from output In-Reply-To: <56ff8c87-9ff5-54ab-863b-b2abca4503cd@redhat.com> References: <4ba67941-55ca-9989-8655-4f914b2962c1@redhat.com> <56ff8c87-9ff5-54ab-863b-b2abca4503cd@redhat.com> Message-ID: Hi Zhengyu, I think this line should also be changed to locked_create_entry_or_null. 83 private static String expectedSymbol = "locked_create_entry"; Thanks, Harold On 5/10/2021 9:07 AM, Zhengyu Gu wrote: > Thanks Harold for catching this. > > Updated and retested. > > http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.01/ > > -Zhengyu > > On 5/4/21 8:55 AM, Harold Seigel wrote: >> Hi Zhengyu, >> >> Should "locked_create_entry" be changed to >> "locked_create_entry_or_null" in the below change? >> >> ??? + private static String stackTraceAlternate = >> ??? + ".*Hashtable.*allocate_new_entry.*\n" + >> ??? + ".*ModuleEntryTable.*locked_create_entry.*\n" + >> >> Thanks, Harold >> >> On 5/3/2021 5:03 PM, Zhengyu Gu wrote: >>> I would like to backport this patch to 11u for parity with Oracle >>> 11.0.13. >>> >>> The original bug: https://bugs.openjdk.java.net/browse/JDK-8218458 >>> The original patch: http://hg.openjdk.java.net/jdk/jdk/rev/b02d1d829b09 >>> >>> The original patch does not apply cleanly to 11u. >>> >>> 1) CheckForProperDetailStackTrace.java is not in 11u's ProblemList.txt >>> 2) 11u does not have JDK-8217660. Therefore, context is bit off in >>> ? CheckForProperDetailStackTrace.java, resolved manually. >>> >>> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.00/ >>> >>> >>> Test: >>> ?The test passed on Linux x86_64. >>> >>> Thanks, >>> >>> -Zhengyu >>> >> > From sgehwolf at redhat.com Mon May 10 16:22:58 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 10 May 2021 18:22:58 +0200 Subject: [11u] RFR: 8196415: Disable SHA-1 Signed JARs Message-ID: Hi, Could I please get a review of this tiny OpenJDK 11 backport for Oracle JDK 11 parity? The JDK 17 patch didn't apply cleanly since JDK-8235710 isn't in JDK 11 with no plan to backport it. I've manually applied the patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8196415 CSR (includes JDK 11): https://bugs.openjdk.java.net/browse/JDK-8264362 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196415/01/webrev/ Thoughts? Thanks, Severin From zgu at redhat.com Mon May 10 16:27:56 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 10 May 2021 12:27:56 -0400 Subject: [11u] RFR 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file Message-ID: <8236d47a-8334-fc47-3c39-c904c62a8a58@redhat.com> I would like to backport this patch to 11u for parity with Oracle 11.0.13. The original bug: https://bugs.openjdk.java.net/browse/JDK-8216184 The original patch: http://hg.openjdk.java.net/jdk/jdk/rev/b7dca420fa0c The original patch does not apply cleanly, due to JDK-8206470 moved surrounding lines (_line_no and _interfaces) in classListParser.cpp down, that resulted merge conflict, and this is the only conflict. 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8216184-11u/webrev.00/ Test: hotspot_cds on Linux x86_64 and Windows 64. Thanks, -Zhengyu From zgu at redhat.com Mon May 10 17:23:50 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 10 May 2021 13:23:50 -0400 Subject: [External] : Re: [11u] RFR 8218458: [TESTBUG] runtime/NMT/CheckForProperDetailStackTrace.java fails with Expected stack trace missing from output In-Reply-To: References: <4ba67941-55ca-9989-8655-4f914b2962c1@redhat.com> <56ff8c87-9ff5-54ab-863b-b2abca4503cd@redhat.com> Message-ID: <1b83eba2-ec0f-4d9f-2c5c-b8fd5e19535d@redhat.com> > > I think this line should also be changed to locked_create_entry_or_null. > > 83 private static String expectedSymbol = "locked_create_entry"; Right, updated: http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.02/ Thanks again, Harold. -Zhengyu > > Thanks, Harold > > On 5/10/2021 9:07 AM, Zhengyu Gu wrote: >> Thanks Harold for catching this. >> >> Updated and retested. >> >> http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.01/ >> >> -Zhengyu >> >> On 5/4/21 8:55 AM, Harold Seigel wrote: >>> Hi Zhengyu, >>> >>> Should "locked_create_entry" be changed to >>> "locked_create_entry_or_null" in the below change? >>> >>> ??? + private static String stackTraceAlternate = >>> ??? + ".*Hashtable.*allocate_new_entry.*\n" + >>> ??? + ".*ModuleEntryTable.*locked_create_entry.*\n" + >>> >>> Thanks, Harold >>> >>> On 5/3/2021 5:03 PM, Zhengyu Gu wrote: >>>> I would like to backport this patch to 11u for parity with Oracle >>>> 11.0.13. >>>> >>>> The original bug: https://bugs.openjdk.java.net/browse/JDK-8218458 >>>> The original patch: http://hg.openjdk.java.net/jdk/jdk/rev/b02d1d829b09 >>>> >>>> The original patch does not apply cleanly to 11u. >>>> >>>> 1) CheckForProperDetailStackTrace.java is not in 11u's ProblemList.txt >>>> 2) 11u does not have JDK-8217660. Therefore, context is bit off in >>>> ? CheckForProperDetailStackTrace.java, resolved manually. >>>> >>>> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.00/ >>>> >>>> >>>> Test: >>>> ?The test passed on Linux x86_64. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>> >> From hohensee at amazon.com Mon May 10 17:36:15 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 10 May 2021 17:36:15 +0000 Subject: [11u] RFR (S) 8248870: AARCH64: I2L/L2I conversions can be skipped for masked positive values Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Friday, May 7, 2021 at 1:12 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (S) 8248870: AARCH64: I2L/L2I conversions can be skipped for masked positive values Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8248870 aarch64_ad.m4 and aarch64.ad are decorated slightly different in 11u, unmodified ubfizIConvI2LAndI code was inserted similarly after ubfizIConvI2L taking that into account, benchmark part applied cleanly. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8248870/webrev.11u.00/ Testing: tier1, tier2. -- Thanks, -Dmitry From martin.doerr at sap.com Mon May 10 17:51:13 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 10 May 2021 17:51:13 +0000 Subject: AW: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 In-Reply-To: <4a13c739d509305f763a8da9b0f2af4dd1d2b7c3.camel@redhat.com> References: <4a13c739d509305f763a8da9b0f2af4dd1d2b7c3.camel@redhat.com> Message-ID: Hi Severin, thank you for addressing this issue! I like the idea of supporting strcasestr on AIX. I?m ok with having it in the same file for now. Seems like you wanted to initialize i, not k. Besides that, the algorithm looks correct to me. The comparisons in the loop would be simpler when using loop limit haystack_len - needle_len, but I leave you free to decide. We don?t have to optimize performance. Best regards, Martin Von: jdk-updates-dev im Auftrag von Severin Gehwolf Datum: Montag, 10. Mai 2021 um 15:26 An: jdk-updates-dev Cc: Baesken, Matthias , Stuefe, Thomas Betreff: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 Hi, Please review this AIX build fix for OpenJDK 11u. The JDK 11u backport of JDK-8247753 included a call to strcasestr for case-insensitive comparison of the set XDG_CURRENT_DESKTOP environment variable. Unfortunately, strcasestr is a GNU extension and isn't available on AIX. The proposed fix is to implement a version of strcasestr AIX-local in java_props_md.c. Note that this is a JDK 11u-specific bug since the backport of JDK-8247753 is different to the version in later JDKs where this comparison is not done in native code, but in Java. Bug: https://bugs.openjdk.java.net/browse/JDK-8266713 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266713/02/webrev/ AIX failed to build prior this patch and builds with this patch after. Manual sanity checks for the strcasestr() impl. Thoughts? Thanks, Severin From sgehwolf at redhat.com Mon May 10 18:39:23 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 10 May 2021 20:39:23 +0200 Subject: AW: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 In-Reply-To: References: <4a13c739d509305f763a8da9b0f2af4dd1d2b7c3.camel@redhat.com> Message-ID: <88bee3b044e1680054e62a69a5e4f8f043887614.camel@redhat.com> Hi Martin, On Mon, 2021-05-10 at 17:51 +0000, Doerr, Martin wrote: > Hi Severin, > ? > thank you for addressing this issue! > I like the idea of supporting strcasestr on AIX. I?m ok with having it > in the same file for now. > ? > Seems like you wanted to initialize i, not k. > Besides that, the algorithm looks correct to me. > The comparisons in the loop would be simpler when using loop limit > haystack_len - needle_len, but I leave you free to decide. We don?t > have to optimize performance. Thanks for the review! Updated webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266713/03/webrev/ I'm not sure I understood your 'haystack_len - needle_len' comment. Anyway, performance shouldn't really be an issue here. Thanks, Severin > ? > Von:jdk-updates-dev im Auftrag > von Severin Gehwolf > Datum: Montag, 10. Mai 2021 um 15:26 > An: jdk-updates-dev > Cc: Baesken, Matthias , Stuefe, Thomas < > thomas.stuefe at sap.com> > Betreff: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of > JDK-8247753 > Hi, > > Please review this AIX build fix for OpenJDK 11u. The JDK 11u backport > of JDK-8247753 included a call to strcasestr for case-insensitive > comparison of the set XDG_CURRENT_DESKTOP environment variable. > Unfortunately, strcasestr is a GNU extension and isn't available on > AIX. The proposed fix is to implement a version of strcasestr AIX-local > in java_props_md.c. Note that this is a JDK 11u-specific bug since the > backport of JDK-8247753 is different to the version in later JDKs where > this comparison is not done in native code, but in Java. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8266713 > webrev: > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266713/02/webrev/ > > AIX failed to build prior this patch and builds with this patch after. > Manual sanity checks for the strcasestr() impl. > > Thoughts? > > Thanks, > Severin From martin.doerr at sap.com Mon May 10 19:36:21 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 10 May 2021 19:36:21 +0000 Subject: AW: AW: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 In-Reply-To: <88bee3b044e1680054e62a69a5e4f8f043887614.camel@redhat.com> References: <4a13c739d509305f763a8da9b0f2af4dd1d2b7c3.camel@redhat.com> , <88bee3b044e1680054e62a69a5e4f8f043887614.camel@redhat.com> Message-ID: Hi Severin, thanks for the update. Looks correct to me, now. > I'm not sure I understood your 'haystack_len - needle_len' comment. You don?t have to check k < haystack_len in the inner loop anymore. But I agree with that performance shouldn?t be an issue. I just like shorter conditions. ?? Best regards, Martin Von: Severin Gehwolf Datum: Montag, 10. Mai 2021 um 21:27 An: Doerr, Martin , jdk-updates-dev Cc: Baesken, Matthias , Stuefe, Thomas Betreff: Re: AW: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 Hi Martin, On Mon, 2021-05-10 at 17:51 +0000, Doerr, Martin wrote: > Hi Severin, > > thank you for addressing this issue! > I like the idea of supporting strcasestr on AIX. I?m ok with having it > in the same file for now. > > Seems like you wanted to initialize i, not k. > Besides that, the algorithm looks correct to me. > The comparisons in the loop would be simpler when using loop limit > haystack_len - needle_len, but I leave you free to decide. We don?t > have to optimize performance. Thanks for the review! Updated webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266713/03/webrev/ I'm not sure I understood your 'haystack_len - needle_len' comment. Anyway, performance shouldn't really be an issue here. Thanks, Severin > > Von:jdk-updates-dev im Auftrag > von Severin Gehwolf > Datum: Montag, 10. Mai 2021 um 15:26 > An: jdk-updates-dev > Cc: Baesken, Matthias , Stuefe, Thomas < > thomas.stuefe at sap.com> > Betreff: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of > JDK-8247753 > Hi, > > Please review this AIX build fix for OpenJDK 11u. The JDK 11u backport > of JDK-8247753 included a call to strcasestr for case-insensitive > comparison of the set XDG_CURRENT_DESKTOP environment variable. > Unfortunately, strcasestr is a GNU extension and isn't available on > AIX. The proposed fix is to implement a version of strcasestr AIX-local > in java_props_md.c. Note that this is a JDK 11u-specific bug since the > backport of JDK-8247753 is different to the version in later JDKs where > this comparison is not done in native code, but in Java. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8266713 > webrev: > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266713/02/webrev/ > > AIX failed to build prior this patch and builds with this patch after. > Manual sanity checks for the strcasestr() impl. > > Thoughts? > > Thanks, > Severin From harold.seigel at oracle.com Mon May 10 20:37:33 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 10 May 2021 16:37:33 -0400 Subject: [External] : Re: [11u] RFR 8218458: [TESTBUG] runtime/NMT/CheckForProperDetailStackTrace.java fails with Expected stack trace missing from output In-Reply-To: <1b83eba2-ec0f-4d9f-2c5c-b8fd5e19535d@redhat.com> References: <4ba67941-55ca-9989-8655-4f914b2962c1@redhat.com> <56ff8c87-9ff5-54ab-863b-b2abca4503cd@redhat.com> <1b83eba2-ec0f-4d9f-2c5c-b8fd5e19535d@redhat.com> Message-ID: <8776c7d7-d4c6-1ea8-05c8-d47245414a02@oracle.com> Hi Zhengyu, The changes look good. Thanks, Harold On 5/10/2021 1:23 PM, Zhengyu Gu wrote: >> >> I think this line should also be changed to locked_create_entry_or_null. >> >> ??? 83 private static String expectedSymbol = "locked_create_entry"; > > Right, updated: > http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.02/ > > Thanks again, Harold. > > -Zhengyu > >> >> Thanks, Harold >> >> On 5/10/2021 9:07 AM, Zhengyu Gu wrote: >>> Thanks Harold for catching this. >>> >>> Updated and retested. >>> >>> http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.01/ >>> >>> -Zhengyu >>> >>> On 5/4/21 8:55 AM, Harold Seigel wrote: >>>> Hi Zhengyu, >>>> >>>> Should "locked_create_entry" be changed to >>>> "locked_create_entry_or_null" in the below change? >>>> >>>> ??? + private static String stackTraceAlternate = >>>> ??? + ".*Hashtable.*allocate_new_entry.*\n" + >>>> ??? + ".*ModuleEntryTable.*locked_create_entry.*\n" + >>>> >>>> Thanks, Harold >>>> >>>> On 5/3/2021 5:03 PM, Zhengyu Gu wrote: >>>>> I would like to backport this patch to 11u for parity with Oracle >>>>> 11.0.13. >>>>> >>>>> The original bug: https://bugs.openjdk.java.net/browse/JDK-8218458 >>>>> The original patch: >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/b02d1d829b09 >>>>> >>>>> The original patch does not apply cleanly to 11u. >>>>> >>>>> 1) CheckForProperDetailStackTrace.java is not in 11u's >>>>> ProblemList.txt >>>>> 2) 11u does not have JDK-8217660. Therefore, context is bit off in >>>>> ? CheckForProperDetailStackTrace.java, resolved manually. >>>>> >>>>> 11u webrev: >>>>> http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.00/ >>>>> >>>>> >>>>> Test: >>>>> ?The test passed on Linux x86_64. >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>> >>> > From zgu at redhat.com Mon May 10 20:49:45 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 10 May 2021 16:49:45 -0400 Subject: [External] : Re: [11u] RFR 8218458: [TESTBUG] runtime/NMT/CheckForProperDetailStackTrace.java fails with Expected stack trace missing from output In-Reply-To: <8776c7d7-d4c6-1ea8-05c8-d47245414a02@oracle.com> References: <4ba67941-55ca-9989-8655-4f914b2962c1@redhat.com> <56ff8c87-9ff5-54ab-863b-b2abca4503cd@redhat.com> <1b83eba2-ec0f-4d9f-2c5c-b8fd5e19535d@redhat.com> <8776c7d7-d4c6-1ea8-05c8-d47245414a02@oracle.com> Message-ID: <54dbe2df-672a-702c-9975-4e71c4f6b989@redhat.com> Thanks, Harold. -Zhengyu On 5/10/21 4:37 PM, Harold Seigel wrote: > Hi Zhengyu, > > The changes look good. > > Thanks, Harold > > On 5/10/2021 1:23 PM, Zhengyu Gu wrote: >>> >>> I think this line should also be changed to locked_create_entry_or_null. >>> >>> ??? 83 private static String expectedSymbol = "locked_create_entry"; >> >> Right, updated: >> http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.02/ >> >> Thanks again, Harold. >> >> -Zhengyu >> >>> >>> Thanks, Harold >>> >>> On 5/10/2021 9:07 AM, Zhengyu Gu wrote: >>>> Thanks Harold for catching this. >>>> >>>> Updated and retested. >>>> >>>> http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.01/ >>>> >>>> -Zhengyu >>>> >>>> On 5/4/21 8:55 AM, Harold Seigel wrote: >>>>> Hi Zhengyu, >>>>> >>>>> Should "locked_create_entry" be changed to >>>>> "locked_create_entry_or_null" in the below change? >>>>> >>>>> ??? + private static String stackTraceAlternate = >>>>> ??? + ".*Hashtable.*allocate_new_entry.*\n" + >>>>> ??? + ".*ModuleEntryTable.*locked_create_entry.*\n" + >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 5/3/2021 5:03 PM, Zhengyu Gu wrote: >>>>>> I would like to backport this patch to 11u for parity with Oracle >>>>>> 11.0.13. >>>>>> >>>>>> The original bug: https://bugs.openjdk.java.net/browse/JDK-8218458 >>>>>> The original patch: >>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/b02d1d829b09 >>>>>> >>>>>> The original patch does not apply cleanly to 11u. >>>>>> >>>>>> 1) CheckForProperDetailStackTrace.java is not in 11u's >>>>>> ProblemList.txt >>>>>> 2) 11u does not have JDK-8217660. Therefore, context is bit off in >>>>>> ? CheckForProperDetailStackTrace.java, resolved manually. >>>>>> >>>>>> 11u webrev: >>>>>> http://cr.openjdk.java.net/~zgu/JDK-8218458-11u/webrev.00/ >>>>>> >>>>>> >>>>>> Test: >>>>>> ?The test passed on Linux x86_64. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> >>>>> >>>> >> > From hohensee at amazon.com Mon May 10 21:12:01 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 10 May 2021 21:12:01 +0000 Subject: [11u] RFR 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards In-Reply-To: References: Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Luo, Ziyi" Date: Friday, May 7, 2021 at 2:29 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards Hi, May I have a review of this backport to 11u: JBS: https://bugs.openjdk.java.net/browse/JDK-8254717 Webrev: http://cr.openjdk.java.net/~luoziyi/8254717/webrev.00 This is almost a clean backport except a missing class sun.security.ec.ed.EdDSAKeyFactory. The class is introduced in JDK-8166597: Crypto support for the EdDSA Signature Algorithm, a new feature in JDK15. IMPORTANT: This patch introduces a regression in JCK17. We addressed it in JDK-8263404 and I prepared the backport as well (I have another RFR for it): http://cr.openjdk.java.net/~luoziyi/8263404/webrev.00/ Upon both backports are ready for merging, please merge 8254717 first. Tests: jtreg jdk:tier1/2 Thanks, Ziyi From hohensee at amazon.com Mon May 10 21:16:34 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 10 May 2021 21:16:34 +0000 Subject: [11u] RFR 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec In-Reply-To: <0CF3E26B-2FDA-4133-9AEC-42CAF1A9E4B5@amazon.com> References: <0CF3E26B-2FDA-4133-9AEC-42CAF1A9E4B5@amazon.com> Message-ID: Lgtm. Tagged, and 8254717 too. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Luo, Ziyi" Date: Friday, May 7, 2021 at 2:32 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec Hi, May I have a review of this backport to 11u: JBS: https://bugs.openjdk.java.net/browse/JDK-8263404 Webrev: http://cr.openjdk.java.net/~luoziyi/8263404/webrev.00 This is almost a clean backport except a minor change in p11-nss-sensitive.txt. The original patch tests SHA3 algorithms in SunPKCS11, a new feature implemented in JDK16 (JDK-8242332). Again, this patch needs to be merged after JDK-8254717 backport. Tests: jtreg jdk:tier1/2 Thanks, Ziyi From rekakovacs at microsoft.com Mon May 10 23:45:18 2021 From: rekakovacs at microsoft.com (Reka Kovacs) Date: Mon, 10 May 2021 23:45:18 +0000 Subject: [EXTERNAL] [11u] RFR 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: <8236d47a-8334-fc47-3c39-c904c62a8a58@redhat.com> References: <8236d47a-8334-fc47-3c39-c904c62a8a58@redhat.com> Message-ID: Hi, I'm a new member of Microsoft's Java Engineering team, and I've been looking to backport this fix as a way to familiarize myself with the contribution process, so I'd be happy to help review it. There is an existing bug for the backport (https://bugs.openjdk.java.net/browse/JDK-8266708), Monica has now assigned it to you. The changes look good, my only note is that if we are already touching the copyright years, it might make sense to update them to 2021. All jtreg tier1 tests pass on Windows x64 and Linux x64. - Reka -----Original Message----- From: jdk-updates-dev On Behalf Of Zhengyu Gu Sent: Monday, May 10, 2021 9:28 AM To: jdk-updates-dev at openjdk.java.net Subject: [EXTERNAL] [11u] RFR 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file I would like to backport this patch to 11u for parity with Oracle 11.0.13. The original bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8216184&data=04%7C01%7Crekakovacs%40microsoft.com%7C9cf27efdff8648bdb16708d913d0a8f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562609175817059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EwQfCaCjRJq%2B2%2FOPJwflgNeS77m61mp%2FtmtGu0OKHoU%3D&reserved=0 The original patch: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2Fb7dca420fa0c&data=04%7C01%7Crekakovacs%40microsoft.com%7C9cf27efdff8648bdb16708d913d0a8f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562609175817059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gSrr9aWqZgrRidr782%2BPgGbc8F0%2FgRn64NyX1%2Bek4gY%3D&reserved=0 The original patch does not apply cleanly, due to JDK-8206470 moved surrounding lines (_line_no and _interfaces) in classListParser.cpp down, that resulted merge conflict, and this is the only conflict. 11u webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~zgu%2FJDK-8216184-11u%2Fwebrev.00%2F&data=04%7C01%7Crekakovacs%40microsoft.com%7C9cf27efdff8648bdb16708d913d0a8f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562609175817059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6N6gJ6Z%2F0zho4RcCKe2KQ17sgdp71uv%2FGQSK1sLZHsE%3D&reserved=0 Test: hotspot_cds on Linux x86_64 and Windows 64. Thanks, -Zhengyu From thomas.stuefe at gmail.com Tue May 11 04:45:51 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 06:45:51 +0200 Subject: [11u] RFR: 8185734: [Windows] Structured Exception Catcher missing around gtest execution Message-ID: Hi, May I please have a review for the downport of this patch. I would like to dowport it since it allows us to run gtests which test signal handling on Windows in 11u. This is a precondition for downporting "8257828 SafeFetch may crash if invoked in non-JavaThreads", which is also in work. JBS: https://bugs.openjdk.java.net/browse/JDK-8185734 Original patch: https://github.com/openjdk/jdk/commit/568dc29b.diff Original PR: https://git.openjdk.java.net/jdk/pull/1757 The original patch does not apply cleanly due to changes done in GTestWrapper.java in the wake of JEP 387. However, the delta is minimal (just one line). 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8185734-Windows-Structured-Exception-Catcher-missing-around-gtest-execution-11u.diff Thank you! Thomas From thomas.stuefe at gmail.com Tue May 11 05:41:38 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 07:41:38 +0200 Subject: [11u] RFR: 8260030: Improve stringStream buffer handling Message-ID: Hi all, I would like to downport the following patch: https://bugs.openjdk.java.net/browse/JDK-8260030 Original patch: https://github.com/openjdk/jdk/commit/d066f2b0.diff Original review: https://github.com/openjdk/jdk/pull/2160 This patch greatly reduces the number of malloc/free calls done when printing small strings to stringStream: In debug, malloc calls from stringStream ~211000 -> 53000. In a release VM, they drop even further, ~85000 down to just about a 1000 calls. It does so by providing stringStream with a small, in-object array as a backing buffer for small streams, and only switches to C-Heap when this buffer is exhausted, which most of the time won't happen. This also provides code parity with upstream, making future fixes easier to downport. The patch does not apply cleanly, since 8238358 (JEP 371: Hidden Classes) changed stringStream::as_string(), adding the option to return the stream content in C-heap and not as resource area. The differences are limited to that function and superficial. The 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260030-improve-stringStream-buffer-handling-11u The patch has been cooking in our internal systems for several weeks now. Thank you! Thomas From thomas.stuefe at gmail.com Tue May 11 06:07:35 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 08:07:35 +0200 Subject: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads Message-ID: Hi, I'd like reviews for this downport, please. Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb Original Review: https://git.openjdk.java.net/jdk/pull/1695 This patch does two things: 1) On Posix platforms it fixes SafeFetch to work in all threads, not only in JavaThreads. In non-JavaThreads before this patch it would crash. The patch is totally trivial. In the signal handler, when handling SafeFetch, there was a condition that Thread != NULL and be a JavaThread. This condition was unnecessary. All SafeFetch handling needs is a valid context. The Patch moves SafeFetch handling out of the is-JavaThread condition. 2) On Windows we did not have the problem; however there is the `Handle_Exception` function handling SafeFetch among other things, which may be called with a non-java thread, but then forcibly casts the Thread* to JavaThread. 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads The original patch does not apply, at all. The reason for this is that we consolidated common functionality of the many cpu+arch signal handlers to one function, in os_posix.cpp. This happened in JDK16 and I do not want to backport this cleanup change to 11. For this patch, it means that the posix-related fixes practically had to be rewritten for each and every signal handler. Each fix is primitive however, since it just moves SafeFetch handling around, but every signal handler is a tiny bit different. I tested this patch for several weeks in our systems on Linux ppc/ppcle/x64/s390/aarch64, AIX, Solaris and Mac, no problems surfaced. I did not test on 32bit arm. Thanks, Thomas From thomas.stuefe at gmail.com Tue May 11 06:15:02 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 08:15:02 +0200 Subject: [11u] RFR 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: <8236d47a-8334-fc47-3c39-c904c62a8a58@redhat.com> References: <8236d47a-8334-fc47-3c39-c904c62a8a58@redhat.com> Message-ID: Hi Zhengyu, seems fine. Cheers, Thomas On Mon, May 10, 2021 at 6:28 PM Zhengyu Gu wrote: > I would like to backport this patch to 11u for parity with Oracle 11.0.13. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8216184 > The original patch: http://hg.openjdk.java.net/jdk/jdk/rev/b7dca420fa0c > > The original patch does not apply cleanly, due to JDK-8206470 moved > surrounding lines (_line_no and _interfaces) in classListParser.cpp > down, that resulted merge conflict, and this is the only conflict. > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8216184-11u/webrev.00/ > > Test: > hotspot_cds on Linux x86_64 and Windows 64. > > Thanks, > > -Zhengyu > > From matthias.baesken at sap.com Tue May 11 06:39:36 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 11 May 2021 06:39:36 +0000 Subject: AW: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 In-Reply-To: References: <4a13c739d509305f763a8da9b0f2af4dd1d2b7c3.camel@redhat.com> , <88bee3b044e1680054e62a69a5e4f8f043887614.camel@redhat.com> Message-ID: Hi Severin, looks good to me as well . Best regards, Matthias >Hi Severin, > >thanks for the update. Looks correct to me, now. > >> I'm not sure I understood your 'haystack_len - needle_len' comment. >You don?t have to check k < haystack_len in the inner loop anymore. >But I agree with that performance shouldn?t be an issue. I just like shorter conditions. ?? From thomas.stuefe at gmail.com Tue May 11 06:56:22 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 08:56:22 +0200 Subject: AW: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 In-Reply-To: References: <4a13c739d509305f763a8da9b0f2af4dd1d2b7c3.camel@redhat.com> <88bee3b044e1680054e62a69a5e4f8f043887614.camel@redhat.com> Message-ID: +1 Thanks for doing this, Severin. On Tue, May 11, 2021 at 8:40 AM Baesken, Matthias wrote: > Hi Severin, looks good to me as well . > > Best regards, Matthias > > > >Hi Severin, > > > >thanks for the update. Looks correct to me, now. > > > >> I'm not sure I understood your 'haystack_len - needle_len' comment. > >You don?t have to check k < haystack_len in the inner loop anymore. > >But I agree with that performance shouldn?t be an issue. I just like > shorter conditions. ?? > > > From ramanand.patil at in.ibm.com Tue May 11 07:11:25 2021 From: ramanand.patil at in.ibm.com (Ramanand Patil) Date: Tue, 11 May 2021 07:11:25 +0000 Subject: AW: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 In-Reply-To: References: , <4a13c739d509305f763a8da9b0f2af4dd1d2b7c3.camel@redhat.com> <88bee3b044e1680054e62a69a5e4f8f043887614.camel@redhat.com> Message-ID: +1 Thank you very much Severin for fixing this. Regards, Ramanand. -----"jdk-updates-dev" wrote: ----- To: "Baesken, Matthias" From: "Thomas St?fe" Sent by: "jdk-updates-dev" Date: 05/11/2021 12:27PM Cc: "Doerr, Martin" , sgehwolf , jdk-updates-dev , "Stuefe, Thomas" Subject: [EXTERNAL] Re: AW: [11u] RFR: 8266713: [AIX] Build failure after 11u backport of JDK-8247753 +1 Thanks for doing this, Severin. On Tue, May 11, 2021 at 8:40 AM Baesken, Matthias wrote: > Hi Severin, looks good to me as well . > > Best regards, Matthias > > > >Hi Severin, > > > >thanks for the update. Looks correct to me, now. > > > >> I'm not sure I understood your 'haystack_len - needle_len' comment. > >You don?t have to check k < haystack_len in the inner loop anymore. > >But I agree with that performance shouldn?t be an issue. I just like > shorter conditions. ?? > > > From omikhaltcova at openjdk.java.net Tue May 11 07:31:49 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Tue, 11 May 2021 07:31:49 GMT Subject: [jdk13u-dev] Integrated: 8247763: assert(outer->outcnt() == 2) failed: 'only phis' failure in LoopNode::verify_strip_mined() In-Reply-To: <4tbM49dIwECFcb0-uEbE0v7paKWA4HEImYMA6FPp_2E=.21362912-9333-4491-8095-b36307cb5992@github.com> References: <4tbM49dIwECFcb0-uEbE0v7paKWA4HEImYMA6FPp_2E=.21362912-9333-4491-8095-b36307cb5992@github.com> Message-ID: On Fri, 7 May 2021 21:48:15 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8247763 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with the test attached to the issue. > All regular tests passed as well. This pull request has now been integrated. Changeset: a6f50e55 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/a6f50e55b108966fe726286131d182622641d81b Stats: 72 lines in 2 files changed: 72 ins; 0 del; 0 mod 8247763: assert(outer->outcnt() == 2) failed: 'only phis' failure in LoopNode::verify_strip_mined() Backport-of: 5adfaa39866f3127000f0779158c65afe1d24007 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/202 From snazarki at openjdk.java.net Tue May 11 08:45:15 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Tue, 11 May 2021 08:45:15 GMT Subject: [jdk13u-dev] Integrated: 8263676: AArch64: one potential bug in C1 LIRGenerator::generate_address() In-Reply-To: <7WuRIeY_yAzIEWjZUWOTkrJ1k4q2XHpDx-SHt5VITmk=.26ad86ec-bd36-4640-a097-8b6319f3e282@github.com> References: <7WuRIeY_yAzIEWjZUWOTkrJ1k4q2XHpDx-SHt5VITmk=.26ad86ec-bd36-4640-a097-8b6319f3e282@github.com> Message-ID: On Fri, 7 May 2021 22:39:25 GMT, Sergey Nazarkin wrote: > Hi! > > I'd like to backport this small fix of obvious mistake. Applies cleanly. Tested tier1 on aarch64. This pull request has now been integrated. Changeset: 36717352 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/36717352c76910e690f5ee8505b44ec189d63f99 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8263676: AArch64: one potential bug in C1 LIRGenerator::generate_address() Reviewed-by: aph Backport-of: 81ba5784ba866be39612982c637b509c8205e88f ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/203 From evergizova at openjdk.java.net Tue May 11 09:41:10 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 11 May 2021 09:41:10 GMT Subject: [jdk15u-dev] Integrated: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics In-Reply-To: References: Message-ID: On Fri, 7 May 2021 18:03:18 GMT, Ekaterina Vergizova wrote: > I would like to backport JDK-8250627 to 15u for parity with 11u. > The patch applies cleanly. > Tested with container tests, including new one and tier1. This pull request has now been integrated. Changeset: ca0a09e6 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/ca0a09e678f6486425f48672dfcf998d22f4e1ab Stats: 175 lines in 7 files changed: 173 ins; 0 del; 2 mod 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics Backport-of: e6517d1ae2628f16442e09fd8f48190762517d2e ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/45 From evergizova at openjdk.java.net Tue May 11 09:44:12 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 11 May 2021 09:44:12 GMT Subject: [jdk15u-dev] Integrated: 8244500: jtreg test error in test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java In-Reply-To: <7dkB3qb4_Yd-BNQQBsfUTOMxcH4G6Our1L4SuJhGqgo=.55378353-802e-42b6-a20d-a11489d7bb72@github.com> References: <7dkB3qb4_Yd-BNQQBsfUTOMxcH4G6Our1L4SuJhGqgo=.55378353-802e-42b6-a20d-a11489d7bb72@github.com> Message-ID: <9i7ngI-_TMu-YpmMVvX3WZlO4uVoaRhMtT5wsHcSDsw=.0746c464-ff18-40d5-9c7b-c5ae0daebd1f@github.com> On Fri, 7 May 2021 20:46:05 GMT, Ekaterina Vergizova wrote: > I would like to backport JDK-8244500 to 15u as a prerequisite for JDK-8250984. > This is test-only fix, applies cleanly. > Tested with container tests, the affected tests passed. This pull request has now been integrated. Changeset: fb513225 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/fb5132254d834ba01a4b65ce64143843e83c674e Stats: 25 lines in 3 files changed: 21 ins; 0 del; 4 mod 8244500: jtreg test error in test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java When the kernel doesn't support swap limits, expect host values instead. Backport-of: 732d8865dfb56e2afbc13d7e53fb1017b9e8b10e ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/46 From evergizova at openjdk.java.net Tue May 11 10:05:17 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 11 May 2021 10:05:17 GMT Subject: [jdk15u-dev] RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities Message-ID: I'd like to backport JDK-8253476 to 15u for parity with 11u. The patch applies cleanly. It is test-only change, the affected test passes after applying the patch. ------------- Commit messages: - Backport 2fe0a5d75ee9434017b3df5cfa713ef895a19866 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/47/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=47&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253476 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/47.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/47/head:pull/47 PR: https://git.openjdk.java.net/jdk15u-dev/pull/47 From abakhtin at openjdk.java.net Tue May 11 10:24:50 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 11 May 2021 10:24:50 GMT Subject: [jdk15u-dev] RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Message-ID: I would like to backport JDK-8241248 to 15u The patch applied clean sun/security/ssl and javax/net/ssl tests passed ------------- Commit messages: - Backport 1603ca23422b03157afb2bd1050524465474b60e Changes: https://git.openjdk.java.net/jdk15u-dev/pull/48/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=48&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241248 Stats: 45 lines in 4 files changed: 40 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/48.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/48/head:pull/48 PR: https://git.openjdk.java.net/jdk15u-dev/pull/48 From martin.doerr at sap.com Tue May 11 11:02:37 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 May 2021 11:02:37 +0000 Subject: AW: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: Hi Thomas, looks good to me. Thanks for fixing it in 11u. Best regards, Martin Von: hotspot-runtime-dev im Auftrag von Thomas St?fe Datum: Dienstag, 11. Mai 2021 um 08:08 An: jdk-updates-dev Cc: Hotspot dev runtime Betreff: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads Hi, I'd like reviews for this downport, please. Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb Original Review: https://git.openjdk.java.net/jdk/pull/1695 This patch does two things: 1) On Posix platforms it fixes SafeFetch to work in all threads, not only in JavaThreads. In non-JavaThreads before this patch it would crash. The patch is totally trivial. In the signal handler, when handling SafeFetch, there was a condition that Thread != NULL and be a JavaThread. This condition was unnecessary. All SafeFetch handling needs is a valid context. The Patch moves SafeFetch handling out of the is-JavaThread condition. 2) On Windows we did not have the problem; however there is the `Handle_Exception` function handling SafeFetch among other things, which may be called with a non-java thread, but then forcibly casts the Thread* to JavaThread. 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads The original patch does not apply, at all. The reason for this is that we consolidated common functionality of the many cpu+arch signal handlers to one function, in os_posix.cpp. This happened in JDK16 and I do not want to backport this cleanup change to 11. For this patch, it means that the posix-related fixes practically had to be rewritten for each and every signal handler. Each fix is primitive however, since it just moves SafeFetch handling around, but every signal handler is a tiny bit different. I tested this patch for several weeks in our systems on Linux ppc/ppcle/x64/s390/aarch64, AIX, Solaris and Mac, no problems surfaced. I did not test on 32bit arm. Thanks, Thomas From thomas.stuefe at gmail.com Tue May 11 11:21:01 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 13:21:01 +0200 Subject: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: Thank you Martin! On Tue, May 11, 2021 at 1:02 PM Doerr, Martin wrote: > Hi Thomas, > > > > looks good to me. Thanks for fixing it in 11u. > > > > Best regards, > > Martin > > > > > > *Von: *hotspot-runtime-dev im > Auftrag von Thomas St?fe > *Datum: *Dienstag, 11. Mai 2021 um 08:08 > *An: *jdk-updates-dev > *Cc: *Hotspot dev runtime > *Betreff: *[11u] RFR: 8257828 SafeFetch may crash if invoked in > non-JavaThreads > > Hi, > > I'd like reviews for this downport, please. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 > Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb > Original Review: https://git.openjdk.java.net/jdk/pull/1695 > > This patch does two things: > > 1) On Posix platforms it fixes SafeFetch to work in all threads, not only > in JavaThreads. In non-JavaThreads before this patch it would crash. > > The patch is totally trivial. In the signal handler, when handling > SafeFetch, there was a condition that Thread != NULL and be a JavaThread. > This condition was unnecessary. All SafeFetch handling needs is a valid > context. The Patch moves SafeFetch handling out of the is-JavaThread > condition. > > 2) On Windows we did not have the problem; however there is the > `Handle_Exception` function handling SafeFetch among other things, which > may be called with a non-java thread, but then forcibly casts the Thread* > to JavaThread. > > 11u patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads > > The original patch does not apply, at all. The reason for this is that we > consolidated common functionality of the many cpu+arch signal handlers to > one function, in os_posix.cpp. This happened in JDK16 and I do not want to > backport this cleanup change to 11. For this patch, it means that the > posix-related fixes practically had to be rewritten for each and every > signal handler. Each fix is primitive however, since it just moves > SafeFetch handling around, but every signal handler is a tiny bit > different. > > I tested this patch for several weeks in our systems on Linux > ppc/ppcle/x64/s390/aarch64, AIX, Solaris and Mac, no problems surfaced. > > I did not test on 32bit arm. > > Thanks, Thomas > From abakhtin at openjdk.java.net Tue May 11 11:21:48 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 11 May 2021 11:21:48 GMT Subject: [jdk13u-dev] RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Message-ID: <1Sh_n10N9HoX4mbxI6cSXpwHUNhBZVvv4jsnnVI-5W4=.e10dbab3-9f39-49b1-a40f-53eca978f3a6@github.com> I would like to backport JDK-8241248 to 13u The patch applied clean sun/security/ssl and javax/net/ssl tests passed ------------- Commit messages: - Backport 1603ca23422b03157afb2bd1050524465474b60e Changes: https://git.openjdk.java.net/jdk13u-dev/pull/204/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=204&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241248 Stats: 45 lines in 4 files changed: 40 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/204/head:pull/204 PR: https://git.openjdk.java.net/jdk13u-dev/pull/204 From yan at openjdk.java.net Tue May 11 12:00:32 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 11 May 2021 12:00:32 GMT Subject: [jdk15u-dev] RFR: 8255880: UI of Swing components is not redrawn after their internal state changed Message-ID: <7wkMJDIFliXqTECbo5uMTNRl5luwJCLNwjVDYCe2K6Y=.b1f1ecff-59f5-4929-8848-a269cb25a498@github.com> The patch applies seamlessly. New test does fail before patch and pass after; automated swing tests OK. ------------- Commit messages: - Backport e8c40bafa51ed73247d2a03a8411cbcb0cdf4efa Changes: https://git.openjdk.java.net/jdk15u-dev/pull/49/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=49&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255880 Stats: 199 lines in 2 files changed: 199 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk15u-dev/pull/49 From abakhtin at openjdk.java.net Tue May 11 12:01:35 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 11 May 2021 12:01:35 GMT Subject: [jdk15u-dev] Integrated: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: References: Message-ID: <3i8kCqWplVe38mfiWJvgjQRcWRbsZ84VMBOxKV6_T5w=.6c4439d9-2831-4099-98ee-53b7d69cb08e@github.com> On Tue, 11 May 2021 10:16:54 GMT, Alexey Bakhtin wrote: > I would like to backport JDK-8241248 to 15u > The patch applied clean > sun/security/ssl and javax/net/ssl tests passed This pull request has now been integrated. Changeset: 2486d30b Author: Alexey Bakhtin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/2486d30b6ec9242fe3b2e47638e75c99aefa7b14 Stats: 45 lines in 4 files changed: 40 ins; 3 del; 2 mod 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Backport-of: 1603ca23422b03157afb2bd1050524465474b60e ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/48 From zgu at redhat.com Tue May 11 12:06:25 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 11 May 2021 08:06:25 -0400 Subject: [EXTERNAL] [11u] RFR 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: References: <8236d47a-8334-fc47-3c39-c904c62a8a58@redhat.com> Message-ID: Hi Reka, Thanks for reviewing. > > The changes look good, my only note is that if we are already touching the copyright years, it might make sense to update them to 2021. > I think it is the convention that we keep patch's copyright years for backports. If possible, we would like to keep backports as clean as possible. -Zhengyu > All jtreg tier1 tests pass on Windows x64 and Linux x64. > > - Reka > > > -----Original Message----- > From: jdk-updates-dev On Behalf Of Zhengyu Gu > Sent: Monday, May 10, 2021 9:28 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [EXTERNAL] [11u] RFR 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file > > I would like to backport this patch to 11u for parity with Oracle 11.0.13. > > The original bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8216184&data=04%7C01%7Crekakovacs%40microsoft.com%7C9cf27efdff8648bdb16708d913d0a8f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562609175817059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EwQfCaCjRJq%2B2%2FOPJwflgNeS77m61mp%2FtmtGu0OKHoU%3D&reserved=0 > The original patch: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2Fb7dca420fa0c&data=04%7C01%7Crekakovacs%40microsoft.com%7C9cf27efdff8648bdb16708d913d0a8f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562609175817059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gSrr9aWqZgrRidr782%2BPgGbc8F0%2FgRn64NyX1%2Bek4gY%3D&reserved=0 > > The original patch does not apply cleanly, due to JDK-8206470 moved surrounding lines (_line_no and _interfaces) in classListParser.cpp down, that resulted merge conflict, and this is the only conflict. > > 11u webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~zgu%2FJDK-8216184-11u%2Fwebrev.00%2F&data=04%7C01%7Crekakovacs%40microsoft.com%7C9cf27efdff8648bdb16708d913d0a8f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637562609175817059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6N6gJ6Z%2F0zho4RcCKe2KQ17sgdp71uv%2FGQSK1sLZHsE%3D&reserved=0 > > Test: > hotspot_cds on Linux x86_64 and Windows 64. > > Thanks, > > -Zhengyu > From evergizova at openjdk.java.net Tue May 11 12:07:00 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 11 May 2021 12:07:00 GMT Subject: [jdk15u-dev] Integrated: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities In-Reply-To: References: Message-ID: On Tue, 11 May 2021 09:58:26 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8253476 to 15u for parity with 11u. > The patch applies cleanly. > It is test-only change, the affected test passes after applying the patch. This pull request has now been integrated. Changeset: daa195ae Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/daa195aed413e8b59bad7b351f592bfa63ad2b8f Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities Backport-of: 2fe0a5d75ee9434017b3df5cfa713ef895a19866 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/47 From yan at openjdk.java.net Tue May 11 12:09:21 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 11 May 2021 12:09:21 GMT Subject: [jdk15u-dev] Integrated: 8255880: UI of Swing components is not redrawn after their internal state changed In-Reply-To: <7wkMJDIFliXqTECbo5uMTNRl5luwJCLNwjVDYCe2K6Y=.b1f1ecff-59f5-4929-8848-a269cb25a498@github.com> References: <7wkMJDIFliXqTECbo5uMTNRl5luwJCLNwjVDYCe2K6Y=.b1f1ecff-59f5-4929-8848-a269cb25a498@github.com> Message-ID: On Tue, 11 May 2021 11:52:29 GMT, Yuri Nesterenko wrote: > The patch applies seamlessly. New test does fail before patch and pass after; automated swing tests OK. This pull request has now been integrated. Changeset: d13fb263 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/d13fb263ff83feba616c269dfd6db174a4567496 Stats: 199 lines in 2 files changed: 199 ins; 0 del; 0 mod 8255880: UI of Swing components is not redrawn after their internal state changed Backport-of: e8c40bafa51ed73247d2a03a8411cbcb0cdf4efa ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/49 From zgu at redhat.com Tue May 11 12:13:52 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 11 May 2021 08:13:52 -0400 Subject: [11u] RFR 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: References: <8236d47a-8334-fc47-3c39-c904c62a8a58@redhat.com> Message-ID: <60b5ac08-4e9f-0aac-5fcd-23152d059634@redhat.com> Thanks, Thomas. Tagged for approval. -Zhengyu On 5/11/21 2:15 AM, Thomas St?fe wrote: > Hi Zhengyu, > > seems fine. > > Cheers, Thomas > > On Mon, May 10, 2021 at 6:28 PM Zhengyu Gu > wrote: > > I would like to backport this patch to 11u for parity with Oracle > 11.0.13. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8216184 > > The original patch: > http://hg.openjdk.java.net/jdk/jdk/rev/b7dca420fa0c > > > The original patch does not apply cleanly, due to JDK-8206470 moved > surrounding lines (_line_no and _interfaces) in classListParser.cpp > down, that resulted merge conflict, and this is the only conflict. > > 11u webrev: > http://cr.openjdk.java.net/~zgu/JDK-8216184-11u/webrev.00/ > > > Test: > ? ?hotspot_cds on Linux x86_64 and Windows 64. > > Thanks, > > -Zhengyu > From rekakovacs at microsoft.com Tue May 11 14:54:56 2021 From: rekakovacs at microsoft.com (Reka Kovacs) Date: Tue, 11 May 2021 14:54:56 +0000 Subject: [EXTERNAL] [11u] RFR 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: References: <8236d47a-8334-fc47-3c39-c904c62a8a58@redhat.com> Message-ID: Ah, that's good to know. Thanks, Zhengyu! - Reka -----Original Message----- From: Zhengyu Gu Sent: Tuesday, May 11, 2021 5:06 AM To: Reka Kovacs ; jdk-updates-dev at openjdk.java.net Subject: Re: [EXTERNAL] [11u] RFR 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file Hi Reka, Thanks for reviewing. > > The changes look good, my only note is that if we are already touching the copyright years, it might make sense to update them to 2021. > I think it is the convention that we keep patch's copyright years for backports. If possible, we would like to keep backports as clean as possible. -Zhengyu > All jtreg tier1 tests pass on Windows x64 and Linux x64. > > - Reka > > > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Zhengyu Gu > Sent: Monday, May 10, 2021 9:28 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [EXTERNAL] [11u] RFR 8216184: CDS/appCDS tests failed on > Windows due to long path to a classlist file > > I would like to backport this patch to 11u for parity with Oracle 11.0.13. > > The original bug: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .openjdk.java.net%2Fbrowse%2FJDK-8216184&data=04%7C01%7Crekakovacs > %40microsoft.com%7Ca0f29e1bc5f24539d20008d914753769%7C72f988bf86f141af > 91ab2d7cd011db47%7C1%7C0%7C637563315938225900%7CUnknown%7CTWFpbGZsb3d8 > eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1 > 000&sdata=uBVtDC2ecOmo3UpIDBUk7KCOsMrlYDy2KSYl6Ev6OIQ%3D&reser > ved=0 The original patch: > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.op > enjdk.java.net%2Fjdk%2Fjdk%2Frev%2Fb7dca420fa0c&data=04%7C01%7Crek > akovacs%40microsoft.com%7Ca0f29e1bc5f24539d20008d914753769%7C72f988bf8 > 6f141af91ab2d7cd011db47%7C1%7C0%7C637563315938225900%7CUnknown%7CTWFpb > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D%7C1000&sdata=6C8LbIivI5tuSskq2IVTU26SytZXIH8OngE1HSG%2BUow%3D& > amp;reserved=0 > > The original patch does not apply cleanly, due to JDK-8206470 moved surrounding lines (_line_no and _interfaces) in classListParser.cpp down, that resulted merge conflict, and this is the only conflict. > > 11u webrev: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open > jdk.java.net%2F~zgu%2FJDK-8216184-11u%2Fwebrev.00%2F&data=04%7C01% > 7Crekakovacs%40microsoft.com%7Ca0f29e1bc5f24539d20008d914753769%7C72f9 > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563315938225900%7CUnknown%7C > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > I6Mn0%3D%7C1000&sdata=15ahtUMRQIwiS1n2pgbjfGhH7QQ5QYJkbh4aNPDB47U% > 3D&reserved=0 > > Test: > hotspot_cds on Linux x86_64 and Windows 64. > > Thanks, > > -Zhengyu > From anleonar at redhat.com Tue May 11 15:02:03 2021 From: anleonar at redhat.com (Andrew Leonard) Date: Tue, 11 May 2021 16:02:03 +0100 Subject: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols Message-ID: Please can I get a review and sponsor for this straight backport (bar build system variable changes) of the jdk-17 patch http://cr.openjdk.java.net/~aleonard/8266818/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8266818 Tested downstream at Adoptium CI using Xlc v13.1: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-aix-ppc64-hotspot/929/ Many thanks Andrew From martin.doerr at sap.com Tue May 11 15:20:26 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 May 2021 15:20:26 +0000 Subject: AW: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols In-Reply-To: References: Message-ID: Hi Andrew, looks good to me. Thanks Martin Von: jdk-updates-dev im Auftrag von Andrew Leonard Datum: Dienstag, 11. Mai 2021 um 17:03 An: jdk-updates-dev at openjdk.java.net Betreff: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols Please can I get a review and sponsor for this straight backport (bar build system variable changes) of the jdk-17 patch http://cr.openjdk.java.net/~aleonard/8266818/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8266818 Tested downstream at Adoptium CI using Xlc v13.1: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-aix-ppc64-hotspot/929/ Many thanks Andrew From martin.doerr at sap.com Tue May 11 16:02:10 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 May 2021 16:02:10 +0000 Subject: AW: [11u] RFR: 8260030: Improve stringStream buffer handling In-Reply-To: References: Message-ID: Hi Thomas, looks good. Thanks for backporting. Best regards, Martin Von: hotspot-runtime-dev im Auftrag von Thomas St?fe Datum: Dienstag, 11. Mai 2021 um 07:42 An: jdk-updates-dev Cc: Hotspot dev runtime Betreff: [11u] RFR: 8260030: Improve stringStream buffer handling Hi all, I would like to downport the following patch: https://bugs.openjdk.java.net/browse/JDK-8260030 Original patch: https://github.com/openjdk/jdk/commit/d066f2b0.diff Original review: https://github.com/openjdk/jdk/pull/2160 This patch greatly reduces the number of malloc/free calls done when printing small strings to stringStream: In debug, malloc calls from stringStream ~211000 -> 53000. In a release VM, they drop even further, ~85000 down to just about a 1000 calls. It does so by providing stringStream with a small, in-object array as a backing buffer for small streams, and only switches to C-Heap when this buffer is exhausted, which most of the time won't happen. This also provides code parity with upstream, making future fixes easier to downport. The patch does not apply cleanly, since 8238358 (JEP 371: Hidden Classes) changed stringStream::as_string(), adding the option to return the stream content in C-heap and not as resource area. The differences are limited to that function and superficial. The 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260030-improve-stringStream-buffer-handling-11u The patch has been cooking in our internal systems for several weeks now. Thank you! Thomas From martin.doerr at sap.com Tue May 11 16:11:55 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 May 2021 16:11:55 +0000 Subject: AW: [11u] RFR (XS): 8243452: JFR: Could not create chunk in repository with over 200 recordings In-Reply-To: <44119E5E-1DA8-45F4-89DC-4D79B65A7032@amazon.com> References: <44119E5E-1DA8-45F4-89DC-4D79B65A7032@amazon.com> Message-ID: Hi Paul, looks good to me. Best regards, Martin Von: jdk-updates-dev im Auftrag von Hohensee, Paul Datum: Donnerstag, 1. April 2021 um 23:30 An: jdk-updates-dev Betreff: [DMARC FAILURE] [11u] RFR (XS): 8243452: JFR: Could not create chunk in repository with over 200 recordings 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 thomas.stuefe at gmail.com Tue May 11 16:28:10 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 18:28:10 +0200 Subject: [11u] RFR: 8260030: Improve stringStream buffer handling In-Reply-To: References: Message-ID: Thank you Martin! On Tue, May 11, 2021 at 6:02 PM Doerr, Martin wrote: > Hi Thomas, > > > > looks good. Thanks for backporting. > > > > Best regards, > > Martin > > > > > > *Von: *hotspot-runtime-dev im > Auftrag von Thomas St?fe > *Datum: *Dienstag, 11. Mai 2021 um 07:42 > *An: *jdk-updates-dev > *Cc: *Hotspot dev runtime > *Betreff: *[11u] RFR: 8260030: Improve stringStream buffer handling > > Hi all, > > I would like to downport the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8260030 > Original patch: https://github.com/openjdk/jdk/commit/d066f2b0.diff > Original review: https://github.com/openjdk/jdk/pull/2160 > > This patch greatly reduces the number of malloc/free calls done when > printing small strings to stringStream: In debug, malloc calls from > stringStream ~211000 -> 53000. In a release VM, they drop even further, > ~85000 down to just about a 1000 calls. It does so by providing > stringStream with a small, in-object array as a backing buffer for small > streams, and only switches to C-Heap when this buffer is exhausted, which > most of the time won't happen. > > This also provides code parity with upstream, making future fixes easier to > downport. > > The patch does not apply cleanly, since 8238358 (JEP 371: Hidden Classes) > changed stringStream::as_string(), adding the option to return the stream > content in C-heap and not as resource area. The differences are limited to > that function and superficial. > > The 11u patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260030-improve-stringStream-buffer-handling-11u > > The patch has been cooking in our internal systems for several weeks now. > > Thank you! > > Thomas > From evergizova at openjdk.java.net Tue May 11 16:59:33 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 11 May 2021 16:59:33 GMT Subject: [jdk15u-dev] RFR: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities Message-ID: I'd like to backport JDK-8250984 to 15u for parity with 11u. The patch applies almost cleanly except for changes in ProblemLists, they are skipped as not applicable to 15u. Tested with tier1 and container tests. Follow-up fix JDK-8257746 is planned to be backported as well. ------------- Commit messages: - Backport 0187567704d79ecf394d4cb656d0ba4c886351f1 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/50/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=50&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250984 Stats: 112 lines in 6 files changed: 56 ins; 8 del; 48 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk15u-dev/pull/50 From hohensee at amazon.com Tue May 11 18:42:13 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 11 May 2021 18:42:13 +0000 Subject: AW: [11u] RFR (XS): 8243452: JFR: Could not create chunk in repository with over 200 recordings Message-ID: Thanks, Martin. Tagged. From: "Doerr, Martin" Date: Tuesday, May 11, 2021 at 9:12 AM To: "Hohensee, Paul" , jdk-updates-dev Subject: AW: [11u] RFR (XS): 8243452: JFR: Could not create chunk in repository with over 200 recordings Hi Paul, looks good to me. Best regards, Martin Von: jdk-updates-dev im Auftrag von Hohensee, Paul Datum: Donnerstag, 1. April 2021 um 23:30 An: jdk-updates-dev Betreff: [DMARC FAILURE] [11u] RFR (XS): 8243452: JFR: Could not create chunk in repository with over 200 recordings 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 hohensee at amazon.com Tue May 11 22:00:24 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 11 May 2021 22:00:24 +0000 Subject: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms Message-ID: <27758308-C0F3-4D68-A5DE-03A1BA190CC4@amazon.com> There?s an extra blank line inserted at the end of java.security. Otherwise lgtm. I?m fine with using KnownOIDs.java from tip. One might object that now it?s in a different location and must be kept sync?ed with tip, but I don?t agree because the backported version must be updated only when a test that needs the update is backported, and if that?s needed it?ll be obvious what to do. Thanks, Paul From: security-dev on behalf of "Doerr, Martin" Date: Friday, April 30, 2021 at 9:35 AM To: "jdk-updates-dev at openjdk.java.net" , security-dev Cc: "Langer, Christoph" Subject: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms 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 abakhtin at openjdk.java.net Wed May 12 07:00:35 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Wed, 12 May 2021 07:00:35 GMT Subject: [jdk13u-dev] Integrated: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: <1Sh_n10N9HoX4mbxI6cSXpwHUNhBZVvv4jsnnVI-5W4=.e10dbab3-9f39-49b1-a40f-53eca978f3a6@github.com> References: <1Sh_n10N9HoX4mbxI6cSXpwHUNhBZVvv4jsnnVI-5W4=.e10dbab3-9f39-49b1-a40f-53eca978f3a6@github.com> Message-ID: On Tue, 11 May 2021 11:12:13 GMT, Alexey Bakhtin wrote: > I would like to backport JDK-8241248 to 13u > The patch applied clean > sun/security/ssl and javax/net/ssl tests passed This pull request has now been integrated. Changeset: 235c8ba2 Author: Alexey Bakhtin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/235c8ba23df3f47f0f6e2b3cb054111612795a63 Stats: 45 lines in 4 files changed: 40 ins; 3 del; 2 mod 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Backport-of: 1603ca23422b03157afb2bd1050524465474b60e ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/204 From yan at openjdk.java.net Wed May 12 07:02:08 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 12 May 2021 07:02:08 GMT Subject: [jdk15u-dev] RFR: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities In-Reply-To: References: Message-ID: On Tue, 11 May 2021 16:51:54 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8250984 to 15u for parity with 11u. > The patch applies almost cleanly except for changes in ProblemLists, they are skipped as not applicable to 15u. > Tested with tier1 and container tests. > Follow-up fix JDK-8257746 is planned to be backported as well. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/50 From matthias.baesken at sap.com Wed May 12 07:47:42 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 May 2021 07:47:42 +0000 Subject: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 Message-ID: Hello, I please review the backport of 8232084 to jdk11 . This is needed to make jdk11 buildable with gcc-9 (tested on linux x86_64) . Changes in the jdk11 backport compared to jdk/jdk : hotspot/cpu/x86/macroAssembler_x86.hpp change is not needed in jdk11 src/hotspot/share/utilities/compilerWarnings_gcc.hpp does not exist in jdk11 so the compilerWarnings_gcc.hpp change goes to compilerWarnings.hpp additionally to be able to build with gcc-9 in make/autoconf/flags-cflags.m4 -Wno-stringop-truncation has to be set (issues in jvmti test coding and liblcms ) (tested to build jdk11u-dev on linux x86_64 with gcc-4.8 and gcc-7 this still works too ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8232084 http://cr.openjdk.java.net/~mbaesken/webrevs/8232084.0_jdk11/ original change : https://hg.openjdk.java.net/jdk/jdk/rev/9f5b92d5a1b2 Thanks, Matthias From yan at openjdk.java.net Wed May 12 07:53:39 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 12 May 2021 07:53:39 GMT Subject: [jdk13u-dev] RFR: 8255880: UI of Swing components is not redrawn after their internal state changed Message-ID: <60YO0PVAKbI_HMsTGYE29ZOtJ1H_v3q-O8Oh3Ag3iSU=.9f449773-5a2c-467f-891f-7601e675e9c1@github.com> The patch applies without modifications, the relevant tests do pass. ------------- Commit messages: - Backport e8c40bafa51ed73247d2a03a8411cbcb0cdf4efa Changes: https://git.openjdk.java.net/jdk13u-dev/pull/205/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=205&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255880 Stats: 199 lines in 2 files changed: 199 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/205.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/205/head:pull/205 PR: https://git.openjdk.java.net/jdk13u-dev/pull/205 From yan at openjdk.java.net Wed May 12 08:05:41 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 12 May 2021 08:05:41 GMT Subject: [jdk13u-dev] Integrated: 8255880: UI of Swing components is not redrawn after their internal state changed In-Reply-To: <60YO0PVAKbI_HMsTGYE29ZOtJ1H_v3q-O8Oh3Ag3iSU=.9f449773-5a2c-467f-891f-7601e675e9c1@github.com> References: <60YO0PVAKbI_HMsTGYE29ZOtJ1H_v3q-O8Oh3Ag3iSU=.9f449773-5a2c-467f-891f-7601e675e9c1@github.com> Message-ID: <1cZZmGondE-tpXZO3lyQI1VZz0J4zuD8ZsmGu4gm4sI=.1f0af4aa-a743-4ad5-a603-a0bb62d1239e@github.com> On Wed, 12 May 2021 07:45:22 GMT, Yuri Nesterenko wrote: > The patch applies without modifications, the relevant tests do pass. This pull request has now been integrated. Changeset: 4d5bb5ed Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/4d5bb5ed1b6ecc6700abdc392ea9d3c87fd14bd3 Stats: 199 lines in 2 files changed: 199 ins; 0 del; 0 mod 8255880: UI of Swing components is not redrawn after their internal state changed Backport-of: e8c40bafa51ed73247d2a03a8411cbcb0cdf4efa ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/205 From anleonar at redhat.com Wed May 12 08:50:18 2021 From: anleonar at redhat.com (Andrew Leonard) Date: Wed, 12 May 2021 09:50:18 +0100 Subject: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols In-Reply-To: References: Message-ID: Thank Martin, much appreciated On Tue, May 11, 2021 at 4:20 PM Doerr, Martin wrote: > Hi Andrew, > > > > looks good to me. > > > > Thanks > > Martin > > > > > > *Von: *jdk-updates-dev im Auftrag > von Andrew Leonard > *Datum: *Dienstag, 11. Mai 2021 um 17:03 > *An: *jdk-updates-dev at openjdk.java.net > *Betreff: *[11u] RFR : 8266818: Enable AIX build platform to make > external debug symbols > > Please can I get a review and sponsor for this straight backport (bar build > system variable changes) of the jdk-17 patch > http://cr.openjdk.java.net/~aleonard/8266818/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8266818 > > Tested downstream at Adoptium CI using Xlc v13.1: > > https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-aix-ppc64-hotspot/929/ > > Many thanks > Andrew > From suenaga at oss.nttdata.com Wed May 12 09:01:55 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 12 May 2021 18:01:55 +0900 Subject: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: Message-ID: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> Hi Matthias, On 2021/05/12 16:47, Baesken, Matthias wrote: > Hello,? I ?please review the backport of? 8232084? to jdk11 . > > This is needed to make? jdk11? buildable with gcc-9?? (tested on linux? x86_64) . > > Changes in the jdk11 backport ?compared to jdk/jdk : > > hotspot/cpu/x86/macroAssembler_x86.hpp? change is not needed in jdk11 > > src/hotspot/share/utilities/compilerWarnings_gcc.hpp?? does not exist in jdk11 so the? compilerWarnings_gcc.hpp change ?goes to? compilerWarnings.hpp > > additionally to be able to build with gcc-9? ?in make/autoconf/flags-cflags.m4? -Wno-stringop-truncation? has to be set (issues in jvmti test coding and liblcms ) I heard that we should disable warnings as narrow as possible in the review. (I forget what ticket it is about) However, to disable warnings in third party libraries like liblcms, we can disable them at the makefile for them. In case of liblcms, it is prefer to disable stringop-truncation at Awt2dLibraries.gmk . Thanks, Yasumasa > (tested to build jdk11u-dev on linux x86_64? with gcc-4.8 and gcc-7 this still works too ) > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8232084 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232084.0_jdk11/ > > original ?change : > > https://hg.openjdk.java.net/jdk/jdk/rev/9f5b92d5a1b2 > > Thanks, Matthias > From goetz.lindenmaier at sap.com Wed May 12 09:25:40 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 12 May 2021 09:25:40 +0000 Subject: [11u notice] Tag jdk-11.0.12+2 delayed Message-ID: Hi, I will not merge jdk11u-dev of yesterday, 5/11 18:00 CET to jdk11u. The build of jdk11u-dev is currently broken on AIX. Consequently, I will not tag jdk11u with jdk-11.0.12+2 now. The issue is already addressed: https://bugs.openjdk.java.net/browse/JDK-8266713 Thanks Severin for looking into this. If the fix is pushed soon, I will push the tag delayed. Else I will just skip this weeks tag and tag the build of 5/18 with 11.0.12+2. Best regards, Goetz. From martin.doerr at sap.com Wed May 12 09:40:33 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 May 2021 09:40:33 +0000 Subject: AW: [11u] RFR: 8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: Hi Thomas, your backport looks good to me. Best regards, Martin Von: jdk-updates-dev im Auftrag von Thomas St?fe Datum: Dienstag, 11. Mai 2021 um 06:46 An: jdk-updates-dev Cc: Hotspot dev runtime Betreff: [11u] RFR: 8185734: [Windows] Structured Exception Catcher missing around gtest execution Hi, May I please have a review for the downport of this patch. I would like to dowport it since it allows us to run gtests which test signal handling on Windows in 11u. This is a precondition for downporting "8257828 SafeFetch may crash if invoked in non-JavaThreads", which is also in work. JBS: https://bugs.openjdk.java.net/browse/JDK-8185734 Original patch: https://github.com/openjdk/jdk/commit/568dc29b.diff Original PR: https://git.openjdk.java.net/jdk/pull/1757 The original patch does not apply cleanly due to changes done in GTestWrapper.java in the wake of JEP 387. However, the delta is minimal (just one line). 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8185734-Windows-Structured-Exception-Catcher-missing-around-gtest-execution-11u.diff Thank you! Thomas From thomas.stuefe at gmail.com Wed May 12 09:41:06 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 12 May 2021 11:41:06 +0200 Subject: [11u] RFR: 8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: Thanks a lot Martin. On Wed, May 12, 2021 at 11:40 AM Doerr, Martin wrote: > Hi Thomas, > > > > your backport looks good to me. > > > > Best regards, > > Martin > > > > > > *Von: *jdk-updates-dev im Auftrag > von Thomas St?fe > *Datum: *Dienstag, 11. Mai 2021 um 06:46 > *An: *jdk-updates-dev > *Cc: *Hotspot dev runtime > *Betreff: *[11u] RFR: 8185734: [Windows] Structured Exception Catcher > missing around gtest execution > > Hi, > > May I please have a review for the downport of this patch. I would like to > dowport it since it allows us to run gtests which test signal handling on > Windows in 11u. This is a precondition for downporting "8257828 SafeFetch > may crash if invoked in non-JavaThreads", which is also in work. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185734 > > Original patch: https://github.com/openjdk/jdk/commit/568dc29b.diff > Original PR: https://git.openjdk.java.net/jdk/pull/1757 > > The original patch does not apply cleanly due to changes done in > GTestWrapper.java in the wake of JEP 387. However, the delta is minimal > (just one line). > > 11u patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8185734-Windows-Structured-Exception-Catcher-missing-around-gtest-execution-11u.diff > > Thank you! > > Thomas > From sgehwolf at redhat.com Wed May 12 09:49:26 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 12 May 2021 11:49:26 +0200 Subject: [11u notice] Tag jdk-11.0.12+2 delayed In-Reply-To: References: Message-ID: <95be03b1809dc2e2319076331734703bee5f5c17.camel@redhat.com> On Wed, 2021-05-12 at 09:25 +0000, Lindenmaier, Goetz wrote: > Hi, > > I will not merge jdk11u-dev of yesterday, 5/11 18:00 CET to jdk11u. > The build of jdk11u-dev is currently broken on AIX. > > Consequently, I will not tag jdk11u with jdk-11.0.12+2 now. > > The issue is already addressed: > https://bugs.openjdk.java.net/browse/JDK-8266713 > Thanks Severin for looking into this. > If the fix is pushed soon, I will push the tag delayed. Else I will > just skip this weeks tag and tag the build of 5/18 with 11.0.12+2. I'll push the fix within the next two hours. Thanks, Severin From martin.doerr at sap.com Wed May 12 09:56:43 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 May 2021 09:56:43 +0000 Subject: AW: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for loopback connections on Windows In-Reply-To: References: , Message-ID: Hi, seems like this one has fallen through the cracks. The 11u webrev looks good to me. If you want to backport both changes at once, please add both bug ids to the commit message. Best regards, Martin Von: jdk-updates-dev im Auftrag von Mat Carter Datum: Montag, 5. April 2021 um 18:29 An: jdk-updates-dev at openjdk.java.net Betreff: Re: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for loopback connections on Windows 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 martin.doerr at sap.com Wed May 12 10:42:17 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 May 2021 10:42:17 +0000 Subject: AW: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms In-Reply-To: <27758308-C0F3-4D68-A5DE-03A1BA190CC4@amazon.com> References: <27758308-C0F3-4D68-A5DE-03A1BA190CC4@amazon.com> Message-ID: Hi Paul, thank you for the review! I?ll remove the extra blank line before pushing. Best regards, Martin Von: Hohensee, Paul Datum: Mittwoch, 12. Mai 2021 um 00:00 An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev Cc: Langer, Christoph Betreff: Re: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms There?s an extra blank line inserted at the end of java.security. Otherwise lgtm. I?m fine with using KnownOIDs.java from tip. One might object that now it?s in a different location and must be kept sync?ed with tip, but I don?t agree because the backported version must be updated only when a test that needs the update is backported, and if that?s needed it?ll be obvious what to do. Thanks, Paul From: security-dev on behalf of "Doerr, Martin" Date: Friday, April 30, 2021 at 9:35 AM To: "jdk-updates-dev at openjdk.java.net" , security-dev Cc: "Langer, Christoph" Subject: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms 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 dcherepanov at openjdk.java.net Wed May 12 10:55:26 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 12 May 2021 10:55:26 GMT Subject: [jdk13u-dev] RFR: 8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 Message-ID: 8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 ------------- Commit messages: - Backport 78825925a5123aff66ae222420dcff8f454190e2 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/206/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=206&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244151 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/206.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/206/head:pull/206 PR: https://git.openjdk.java.net/jdk13u-dev/pull/206 From matthias.baesken at sap.com Wed May 12 11:02:35 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 May 2021 11:02:35 +0000 Subject: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> References: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> Message-ID: >However, to disable warnings in third party libraries like liblcms, we can disable them at the makefile for them. >In case of liblcms, it is prefer to disable stringop-truncation at Awt2dLibraries.gmk . > Hi Yasumasa , are you fine with the rest of the patch ? Regarding disabling of stringop-truncation , I first disabled it only for liblcms but this was not sufficient. (there is indeed another change 8220074 for liblcms that disabled this warning for GCC 8.3 ) There are more issues related to the no-stringop-truncation warning and I did not even found a good place to disable them locally in a nice way . (some strange jvmti related test coding I think those are single file compilations , no real lib??) Best regards, Matthias >On 2021/05/12 16:47, Baesken, Matthias wrote: >> Hello,? I ?please review the backport of? 8232084? to jdk11 . >> >> This is needed to make? jdk11? buildable with gcc-9?? (tested on linux? x86_64) . >> >> Changes in the jdk11 backport ?compared to jdk/jdk : >> >> hotspot/cpu/x86/macroAssembler_x86.hpp? change is not needed in jdk11 >> >> src/hotspot/share/utilities/compilerWarnings_gcc.hpp?? does not exist in jdk11 so the? compilerWarnings_gcc.hpp change ?goes to? compilerWarnings.hpp >> >> additionally to be able to build with gcc-9? ?in make/autoconf/flags-cflags.m4? -Wno-stringop-truncation? has to be set (issues in jvmti test coding and liblcms ) > >I heard that we should disable warnings as narrow as possible in the review. (I forget what ticket it is about) >However, to disable warnings in third party libraries like liblcms, we can disable them at the makefile for them. >In case of liblcms, it is prefer to disable stringop-truncation at Awt2dLibraries.gmk . From suenaga at oss.nttdata.com Wed May 12 11:46:06 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 12 May 2021 20:46:06 +0900 Subject: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> Message-ID: <60c0765d-f6b9-3561-f247-95a341e3d1be@oss.nttdata.com> Hi Matthias, On 2021/05/12 20:02, Baesken, Matthias wrote: > >> However, to disable warnings in third party libraries like liblcms, we can disable them at the makefile for them. >> In case of liblcms, it is prefer to disable stringop-truncation at Awt2dLibraries.gmk . >> > > Hi Yasumasa , are you fine with the rest of the patch ? Yes, looks good to me. > Regarding disabling of stringop-truncation , I first disabled it only for liblcms but this was not sufficient. > (there is indeed another change 8220074 for liblcms that disabled this warning for GCC 8.3 ) > There are more issues related to the no-stringop-truncation warning and I did not even found a good place to disable them locally in a nice way . > (some strange jvmti related test coding I think those are single file compilations , no real lib??) I guess the libraries which you mean are located to build/linux-x86_64-server-fastdebug/images/test/hotspot/jtreg/native . If so, do you see stringop-truncation error on JVMTI tests only? Have you considered to use pragma? If you don't want to use pragma, can you use CFLAGS in JtregNativeHotspot.gmk ? https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/0f3f7aa2ef34/make/test/JtregNativeHotspot.gmk#l210 Thanks, Yasumasa > Best regards, Matthias > > >> On 2021/05/12 16:47, Baesken, Matthias wrote: >>> Hello,? I ?please review the backport of? 8232084? to jdk11 . >>> >>> This is needed to make? jdk11? buildable with gcc-9?? (tested on linux? x86_64) . >>> >>> Changes in the jdk11 backport ?compared to jdk/jdk : >>> >>> hotspot/cpu/x86/macroAssembler_x86.hpp? change is not needed in jdk11 >>> >>> src/hotspot/share/utilities/compilerWarnings_gcc.hpp?? does not exist in jdk11 so the? compilerWarnings_gcc.hpp change ?goes to? compilerWarnings.hpp >>> >>> additionally to be able to build with gcc-9? ?in make/autoconf/flags-cflags.m4? -Wno-stringop-truncation? has to be set (issues in jvmti test coding and liblcms ) >> >> I heard that we should disable warnings as narrow as possible in the review. (I forget what ticket it is about) >> However, to disable warnings in third party libraries like liblcms, we can disable them at the makefile for them. >> In case of liblcms, it is prefer to disable stringop-truncation at Awt2dLibraries.gmk . > > > From martin.doerr at sap.com Wed May 12 15:04:00 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 May 2021 15:04:00 +0000 Subject: AW: [11u] RFR: jnf_removal, series of patches In-Reply-To: References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com>, Message-ID: Hi Vladimir, sorry for the long delay. There are currently many 11u backports and too few reviewers working on them. I have started to look at your changes, but it may take some more time. Best regards, Martin Von: jdk-updates-dev im Auftrag von Vladimir Kempik Datum: Freitag, 23. April 2021 um 09:38 An: jdk-updates-dev Betreff: Re: [11u] RFR: jnf_removal, series of patches 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 martin.doerr at sap.com Wed May 12 15:13:56 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 May 2021 15:13:56 +0000 Subject: AW: [11u] RFR: 8196415: Disable SHA-1 Signed JARs In-Reply-To: References: Message-ID: Hi Severin, thanks for backporting it! We should have the same security changes as 11.0.12-oracle. Looks good. Best regards, Martin Von: jdk-updates-dev im Auftrag von Severin Gehwolf Datum: Montag, 10. Mai 2021 um 18:23 An: jdk-updates-dev Betreff: [11u] RFR: 8196415: Disable SHA-1 Signed JARs Hi, Could I please get a review of this tiny OpenJDK 11 backport for Oracle JDK 11 parity? The JDK 17 patch didn't apply cleanly since JDK-8235710 isn't in JDK 11 with no plan to backport it. I've manually applied the patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8196415 CSR (includes JDK 11): https://bugs.openjdk.java.net/browse/JDK-8264362 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196415/01/webrev/ Thoughts? Thanks, Severin From snazarki at openjdk.java.net Wed May 12 15:25:29 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 12 May 2021 15:25:29 GMT Subject: [jdk15u-dev] RFR: 8264821: DirectIOTest fails on a system with large block size Message-ID: I'd like to backport this fix for parity with jdk17/13/11. The patch applies cleanly. ------------- Commit messages: - Backport 7e4cd480206891550828d1fdfebae57ecc19ed37 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/51/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=51&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264821 Stats: 33 lines in 1 file changed: 7 ins; 8 del; 18 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/51.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/51/head:pull/51 PR: https://git.openjdk.java.net/jdk15u-dev/pull/51 From christoph.langer at sap.com Wed May 12 15:26:36 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 12 May 2021 15:26:36 +0000 Subject: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for loopback connections on Windows In-Reply-To: References: , Message-ID: Hi Mat, yes, sorry for ignoring this backport for so long. I see that you made a complementary change to src/java.base/windows/native/libnet/PlainSocketImpl.c for JDK-8250521. You're right in that PlainSocketImpl is only existing in head jdk/jdk as a fallback. I however would very much prefer if you could do this change in head first and then backport it. There should still be active regression tests for PlainSocketImpl in head. Could you please consider that? Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Doerr, Martin > Sent: Mittwoch, 12. Mai 2021 11:57 > To: Mat Carter ; jdk-updates- > dev at openjdk.java.net > Subject: [DMARC FAILURE] AW: [11u] RFR: 8250521 - Configure initial RTO to > use minimal retry for loopback connections on Windows > > Hi, > > seems like this one has fallen through the cracks. > > The 11u webrev looks good to me. > If you want to backport both changes at once, please add both bug ids to the > commit message. > > Best regards, > Martin > > > Von: jdk-updates-dev im > Auftrag von Mat Carter > Datum: Montag, 5. April 2021 um 18:29 > An: jdk-updates-dev at openjdk.java.net dev at openjdk.java.net> > Betreff: Re: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for > loopback connections on Windows > 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 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%7Cf7e7 > 3bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C > 1%7C0%7C637469615655279564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > &sdata=iFXbQOHEvBhOnkA6TlLy30Bxk8FXxIXRm8GNhQptQR8%3D&am > p;reserved=0 > Original fix: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.o > penjdk.java.net%2Fjdk%2Fjdk%2Frev%2F035cdb28aa4c&data=04%7C01 > %7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3ce > a9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655279 > 564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7qBKPLtXpedI > DcVk8rXoEHl8BZYQh5kOitWMNEjqG8Y%3D&reserved=0 > Original webrev: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openj > dk.java.net%2F~adityam%2Fnikola%2Ffast_connect_loopback_3%2F&d > ata=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f931 > 3b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374 > 69615655279564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SE6 > 5puvz3q6D4A04QEYIhze%2BzWfE3RLbNnUVpRkWM%2BA%3D&reserve > d=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%7Cf7e7 > 3bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C > 1%7C0%7C637469615655289515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > &sdata=MBxv58ht3VnIvMjfn4JzHXx7CNO6RKdCU25oO0JQ7dA%3D&am > p;reserved=0 > Original fix: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fopenjdk%2Fjdk%2Fcommit%2F7e01bc96&data=04%7C01%7 > Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c > %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515 > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IWfdxpo06CJLxQRs > o1%2Fne%2FVW64f8GEIbKMS2Wdkrq3E%3D&reserved=0 > Original PR: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fopenjdk%2Fjdk%2Fpull%2F1523&data=04%7C01%7Cmatthe > w.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f9 > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515%7CUnk > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eACOp2IEdvd6vEB4qPNjkYl > ufUGq6fgjF6kFeVky9rg%3D&reserved=0 > > webrev for 11u: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openj > dk.java.net%2F~adityam%2Fmat%2F8250521_jdk11%2F&data=04%7C01 > %7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3ce > a9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289 > 515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dvT%2FQBwf7 > Pv8%2FrOWCpuYNUbK%2Fu23qxAs5xKNf64O2%2FI%3D&reserved=0 > > Thanks in advance > Mat From matthias.baesken at sap.com Wed May 12 15:37:15 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 May 2021 15:37:15 +0000 Subject: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <60c0765d-f6b9-3561-f247-95a341e3d1be@oss.nttdata.com> References: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> <60c0765d-f6b9-3561-f247-95a341e3d1be@oss.nttdata.com> Message-ID: Hi , here is a new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8232084.1_jdk11/ >> >>> However, to disable warnings in third party libraries like liblcms, we can disable them at the makefile for them. >>> In case of liblcms, it is prefer to disable stringop-truncation at Awt2dLibraries.gmk . >>> >> >> Hi Yasumasa , are you fine with the rest of the patch ? > >Yes, looks good to me. > > >> Regarding disabling of stringop-truncation , I first disabled it only for liblcms but this was not sufficient. >> (there is indeed another change 8220074 for liblcms that disabled this warning for GCC 8.3 ) >> There are more issues related to the no-stringop-truncation warning and I did not even found a good place to disable them locally in a nice way . >> (some strange jvmti related test coding I think those are single file compilations , no real lib??) > > I guess the libraries which you mean are located to build/linux-x86_64-server-fastdebug/images/test/hotspot/jtreg/native . > If so, do you see stringop-truncation error on JVMTI tests only? Have you considered to use pragma? > If you don't want to use pragma, can you use CFLAGS in JtregNativeHotspot.gmk ? > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/0f3f7aa2ef34/make/test/JtregNativeHotspot.gmk#l210 Unfortunately the jvmti_tools.c is included into a ton of compilation units so setting it in JtregNativeHotspot.gmk does not look good to me. But the pragma works, did that . Additionally the liblcms needs the stringop-truncation disabling as well . Best regards, Matthias From martin.doerr at sap.com Wed May 12 15:48:50 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 May 2021 15:48:50 +0000 Subject: AW: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> <60c0765d-f6b9-3561-f247-95a341e3d1be@oss.nttdata.com>, Message-ID: Hi Matthias, looks good to me. Thanks for the update and for doing this backport! Supporting more GCC versions is a good thing! Best regards, Martin Von: Baesken, Matthias Datum: Mittwoch, 12. Mai 2021 um 17:37 An: Yasumasa Suenaga , jdk-updates-dev Cc: Doerr, Martin Betreff: RE: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 Hi , here is a new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8232084.1_jdk11/ >> >>> However, to disable warnings in third party libraries like liblcms, we can disable them at the makefile for them. >>> In case of liblcms, it is prefer to disable stringop-truncation at Awt2dLibraries.gmk . >>> >> >> Hi Yasumasa , are you fine with the rest of the patch ? > >Yes, looks good to me. > > >> Regarding disabling of stringop-truncation , I first disabled it only for liblcms but this was not sufficient. >> (there is indeed another change 8220074 for liblcms that disabled this warning for GCC 8.3 ) >> There are more issues related to the no-stringop-truncation warning and I did not even found a good place to disable them locally in a nice way . >> (some strange jvmti related test coding I think those are single file compilations , no real lib??) > > I guess the libraries which you mean are located to build/linux-x86_64-server-fastdebug/images/test/hotspot/jtreg/native . > If so, do you see stringop-truncation error on JVMTI tests only? Have you considered to use pragma? > If you don't want to use pragma, can you use CFLAGS in JtregNativeHotspot.gmk ? > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/0f3f7aa2ef34/make/test/JtregNativeHotspot.gmk#l210 Unfortunately the jvmti_tools.c is included into a ton of compilation units so setting it in JtregNativeHotspot.gmk does not look good to me. But the pragma works, did that . Additionally the liblcms needs the stringop-truncation disabling as well . Best regards, Matthias From dmitry.chuyko at bell-sw.com Wed May 12 17:03:54 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 12 May 2021 20:03:54 +0300 Subject: [11u] RFR (S) 8249189: AARCH64: more L2I conversions can be skipped Message-ID: Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8249189 aarch64_ad.m4 and aarch64.ad are decorated different in 11u. Nevertheless changes are very straightforward. aarch64_ad.m4 Reapplied changes for UBFIZ_INSN and it's usages. aarch64.ad Following the original patch: operand immL_positive_bitmaskI added after operand immI_bitmask, instruct ubfizwIConvI2L and ubfizLConvL2I added between ubfizL and ubfizIConvI2L, instruct ubfizLConvL2Ix added after ubfizIConvI2L. Mask type is changed long to keep it in line with the rest of the .ad, and thus the diff structure is close to the original. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8249189/webrev.11u.00/ Testing: compiler/c2/TestSkipLongToIntCast.java, tier1, tier2. Generated part of aarch64.ad file matches the output of 'm4 aarch64_ad.m4'. -- Thanks, -Dmitry From yan at openjdk.java.net Wed May 12 18:26:39 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 12 May 2021 18:26:39 GMT Subject: [jdk13u-dev] RFR: 8232084: HotSpot build failed with GCC 9.2.1 Message-ID: Following discussion after https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-May/006150.html, in addition to the original fix I have disabled gcc warninig "stringop-truncation" for lcms in Awt2dLibraries.gmk and for dt_socket in Lib-jdk.jdwp.agent.gmk. A problem with jvmti_tools.c doesn't exist in jdk13 after JDK-8209611 Verified on Ubuntu 20.04 with gcc 9.3.0 and Ubuntu 18.04 with gcc 7.5.0, release and fastdebug builds of "images" and "test-image" targets, tier1 and separately vmTestbase tests. ------------- Commit messages: - Backport 11fbd78f27a338af850256a468a93dc257a4d3ac Changes: https://git.openjdk.java.net/jdk13u-dev/pull/207/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=207&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232084 Stats: 20 lines in 6 files changed: 18 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk13u-dev/pull/207 From snazarki at openjdk.java.net Wed May 12 18:38:49 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 12 May 2021 18:38:49 GMT Subject: [jdk15u-dev] RFR: 8263361: Incorrect arraycopy stub selected by C2 for SATB collectors Message-ID: Hi! I'd like to backport this patch that fixes hotspot debug builds crash. The patch doesn't apply cleanly due to miss of 8252848. The manual fix is required for **macroArrayCopy.cpp:553**: rename **dest_uninitialized** to **acopy_to_uninitialized** Pass tier(1,2} ------------- Commit messages: - Backport 5d87a21991b964e1c50495dc2dc982db425830b5 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/52/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=52&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263361 Stats: 42 lines in 3 files changed: 10 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk15u-dev/pull/52 From snazarki at openjdk.java.net Wed May 12 19:04:46 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 12 May 2021 19:04:46 GMT Subject: [jdk13u-dev] RFR: 8248043: Need to eliminate excessive i2l conversions Message-ID: <4qEmgj4ostjjKDbCdTTtz9viobTPRNuEcJBo34npogQ=.2fef1822-e5ea-477f-a8d1-ddc770cdddce@github.com> Hi! I'd like to backport this fix for parity with jdk17/11. The change improves performance slightly and covered by test. Original patch applies cleanly. Tested by new tests and aarch64 tier1. ------------- Commit messages: - Backport 6d137a36169956171bfd0afef91e8ce29b568e33 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/208/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=208&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248043 Stats: 201 lines in 4 files changed: 201 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/208.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/208/head:pull/208 PR: https://git.openjdk.java.net/jdk13u-dev/pull/208 From zgu at openjdk.java.net Wed May 12 19:15:15 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 12 May 2021 19:15:15 GMT Subject: [jdk16u] Integrated: 8265239: Shenandoah: Shenandoah heap region count could be off by 1 In-Reply-To: <4gX1MDzg8uD2mx_Ee317259s2FQrCJTWEWFnrUuaJtY=.cf0d82b1-14a0-4bd1-97d9-79a85873af4a@github.com> References: <4gX1MDzg8uD2mx_Ee317259s2FQrCJTWEWFnrUuaJtY=.cf0d82b1-14a0-4bd1-97d9-79a85873af4a@github.com> Message-ID: <4tNRKjM1VPcq_XYgKBeP7H_nkin8Q-rZfGnjuANY8-U=.a3c4e847-8237-42b0-b0b2-29395abd11ff@github.com> On Mon, 26 Apr 2021 18:48:50 GMT, Zhengyu Gu wrote: > 8265239: Shenandoah: Shenandoah heap region count could be off by 1 This pull request has now been integrated. Changeset: 319621c3 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk16u/commit/319621c31ccb639f3fcaaa63585c0feb4c0e3bb2 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod 8265239: Shenandoah: Shenandoah heap region count could be off by 1 Backport-of: ff5bb8cf693c58a14063a351f535e3a55e51e8db ------------- PR: https://git.openjdk.java.net/jdk16u/pull/110 From hohensee at amazon.com Wed May 12 21:27:32 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 12 May 2021 21:27:32 +0000 Subject: [11u] RFR (S) 8249189: AARCH64: more L2I conversions can be skipped Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Wednesday, May 12, 2021 at 10:06 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (S) 8249189: AARCH64: more L2I conversions can be skipped Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8249189 aarch64_ad.m4 and aarch64.ad are decorated different in 11u. Nevertheless changes are very straightforward. aarch64_ad.m4 Reapplied changes for UBFIZ_INSN and it's usages. aarch64.ad Following the original patch: operand immL_positive_bitmaskI added after operand immI_bitmask, instruct ubfizwIConvI2L and ubfizLConvL2I added between ubfizL and ubfizIConvI2L, instruct ubfizLConvL2Ix added after ubfizIConvI2L. Mask type is changed long to keep it in line with the rest of the .ad, and thus the diff structure is close to the original. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8249189/webrev.11u.00/ Testing: compiler/c2/TestSkipLongToIntCast.java, tier1, tier2. Generated part of aarch64.ad file matches the output of 'm4 aarch64_ad.m4'. -- Thanks, -Dmitry From suenaga at oss.nttdata.com Thu May 13 04:41:12 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 13 May 2021 13:41:12 +0900 Subject: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> <60c0765d-f6b9-3561-f247-95a341e3d1be@oss.nttdata.com> Message-ID: Hi Matthias, Your change looks good. Thank you for fixing them! However I'm not sure we can include backport of 8220074 (LCMS) to this (8232084). Can we merge them to single commit? Thanks, Yasumasa On 2021/05/13 0:37, Baesken, Matthias wrote: > Hi , here is a new webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232084.1_jdk11/ > >>> >>>> However, to disable warnings in third party libraries like liblcms, we can disable them at the makefile for them. >>>> In case of liblcms, it is prefer to disable stringop-truncation at Awt2dLibraries.gmk . >>>> >>> >>> Hi Yasumasa , are you fine with the rest of the patch ? >> >> Yes, looks good to me. >> >> >>> Regarding disabling of stringop-truncation , I first disabled it only for liblcms but this was not sufficient. >>> (there is indeed another change 8220074 for liblcms that disabled this warning for GCC 8.3 ) >>> There are more issues related to the no-stringop-truncation warning and I did not even found a good place to disable them locally in a nice way . >>> (some strange jvmti related test coding I think those are single file compilations , no real lib??) >> >> I guess the libraries which you mean are located to build/linux-x86_64-server-fastdebug/images/test/hotspot/jtreg/native . >> If so, do you see stringop-truncation error on JVMTI tests only? Have you considered to use pragma? >> If you don't want to use pragma, can you use CFLAGS in JtregNativeHotspot.gmk ? >> >> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/0f3f7aa2ef34/make/test/JtregNativeHotspot.gmk#l210 > > > Unfortunately the jvmti_tools.c is included into a ton of compilation units so setting it in JtregNativeHotspot.gmk does not look good to me. > But the pragma works, did that . > Additionally the liblcms needs the stringop-truncation disabling as well . > > Best regards, Matthias > From snazarki at openjdk.java.net Thu May 13 07:10:13 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Thu, 13 May 2021 07:10:13 GMT Subject: [jdk15u-dev] Integrated: 8264821: DirectIOTest fails on a system with large block size In-Reply-To: References: Message-ID: On Wed, 12 May 2021 15:17:48 GMT, Sergey Nazarkin wrote: > I'd like to backport this fix for parity with jdk17/13/11. The patch applies cleanly. This pull request has now been integrated. Changeset: 631defc8 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/631defc80ace3a4e28bdf5989222e396955be736 Stats: 33 lines in 1 file changed: 7 ins; 8 del; 18 mod 8264821: DirectIOTest fails on a system with large block size Backport-of: 7e4cd480206891550828d1fdfebae57ecc19ed37 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/51 From snazarki at openjdk.java.net Thu May 13 08:55:13 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Thu, 13 May 2021 08:55:13 GMT Subject: [jdk13u-dev] Integrated: 8248043: Need to eliminate excessive i2l conversions In-Reply-To: <4qEmgj4ostjjKDbCdTTtz9viobTPRNuEcJBo34npogQ=.2fef1822-e5ea-477f-a8d1-ddc770cdddce@github.com> References: <4qEmgj4ostjjKDbCdTTtz9viobTPRNuEcJBo34npogQ=.2fef1822-e5ea-477f-a8d1-ddc770cdddce@github.com> Message-ID: On Wed, 12 May 2021 18:58:02 GMT, Sergey Nazarkin wrote: > Hi! > > I'd like to backport this fix for parity with jdk17/11. The change improves performance slightly and covered by test. > > Original patch applies cleanly. Tested by new tests and aarch64 tier1. This pull request has now been integrated. Changeset: 613eb445 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/613eb44507694551f8dc6f8de545a9c0a752705d Stats: 201 lines in 4 files changed: 201 ins; 0 del; 0 mod 8248043: Need to eliminate excessive i2l conversions Backport-of: 6d137a36169956171bfd0afef91e8ce29b568e33 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/208 From evergizova at openjdk.java.net Thu May 13 09:45:13 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 13 May 2021 09:45:13 GMT Subject: [jdk15u-dev] Integrated: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities In-Reply-To: References: Message-ID: On Tue, 11 May 2021 16:51:54 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8250984 to 15u for parity with 11u. > The patch applies almost cleanly except for changes in ProblemLists, they are skipped as not applicable to 15u. > Tested with tier1 and container tests. > Follow-up fix JDK-8257746 is planned to be backported as well. This pull request has now been integrated. Changeset: 4d0f9059 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/4d0f9059652b359a4f7e303550a6f7b8db564738 Stats: 112 lines in 6 files changed: 56 ins; 8 del; 48 mod 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities Reviewed-by: yan Backport-of: 0187567704d79ecf394d4cb656d0ba4c886351f1 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/50 From vkempik at azul.com Thu May 13 10:37:31 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 13 May 2021 10:37:31 +0000 Subject: [11u] RFR: jnf_removal, series of patches In-Reply-To: References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com> Message-ID: <0128E1E9-E9D4-470C-B0EB-F766EC7C8C9E@azul.com> Thanks for response Martin Looking forward to it > 12 ??? 2021 ?., ? 18:04, Doerr, Martin ???????(?): > > Hi Vladimir, > > sorry for the long delay. There are currently many 11u backports and too few reviewers working on them. > I have started to look at your changes, but it may take some more time. > > Best regards, > Martin > > > Von: jdk-updates-dev im Auftrag von Vladimir Kempik > Datum: Freitag, 23. April 2021 um 09:38 > An: jdk-updates-dev > Betreff: Re: [11u] RFR: jnf_removal, series of patches > > 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 bae at openjdk.java.net Thu May 13 11:13:54 2021 From: bae at openjdk.java.net (Andrew Brygin) Date: Thu, 13 May 2021 11:13:54 GMT Subject: [jdk13u-dev] RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: Message-ID: On Wed, 12 May 2021 18:18:06 GMT, Yuri Nesterenko wrote: > Following discussion after https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-May/006150.html, in addition to the original fix I have disabled gcc warninig "stringop-truncation" for lcms in Awt2dLibraries.gmk and for dt_socket in Lib-jdk.jdwp.agent.gmk. > A problem with jvmti_tools.c doesn't exist in jdk13 after JDK-8209611 > > Verified on Ubuntu 20.04 with gcc 9.3.0 and Ubuntu 18.04 with gcc 7.5.0, release and fastdebug builds of "images" and "test-image" targets, tier1 and separately vmTestbase tests. The change looks fine to me. ------------- Marked as reviewed by bae (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/207 From yan at openjdk.java.net Thu May 13 11:25:33 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 13 May 2021 11:25:33 GMT Subject: [jdk13u-dev] Integrated: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: Message-ID: On Wed, 12 May 2021 18:18:06 GMT, Yuri Nesterenko wrote: > Following discussion after https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-May/006150.html, in addition to the original fix I have disabled gcc warninig "stringop-truncation" for lcms in Awt2dLibraries.gmk and for dt_socket in Lib-jdk.jdwp.agent.gmk. > A problem with jvmti_tools.c doesn't exist in jdk13 after JDK-8209611 > > Verified on Ubuntu 20.04 with gcc 9.3.0 and Ubuntu 18.04 with gcc 7.5.0, release and fastdebug builds of "images" and "test-image" targets, tier1 and separately vmTestbase tests. This pull request has now been integrated. Changeset: c87d3999 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/c87d39999fb84d4ffa60ae543744930821a46b08 Stats: 20 lines in 6 files changed: 18 ins; 0 del; 2 mod 8232084: HotSpot build failed with GCC 9.2.1 Reviewed-by: bae Backport-of: 11fbd78f27a338af850256a468a93dc257a4d3ac ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/207 From yan at openjdk.java.net Thu May 13 12:07:30 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 13 May 2021 12:07:30 GMT Subject: [jdk15u-dev] RFR: 8247432: Update IANA Language Subtag Registry to Version 2020-09-29 Message-ID: This update should be ported to 15u, too. ------------- Commit messages: - Backport ae0ca743f5646a5312566a6a65ec8929fca4b372 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/53/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=53&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247432 Stats: 52 lines in 2 files changed: 44 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk15u-dev/pull/53 From yan at openjdk.java.net Thu May 13 12:14:06 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 13 May 2021 12:14:06 GMT Subject: [jdk15u-dev] Integrated: 8247432: Update IANA Language Subtag Registry to Version 2020-09-29 In-Reply-To: References: Message-ID: On Thu, 13 May 2021 11:59:59 GMT, Yuri Nesterenko wrote: > This update should be ported to 15u, too. This pull request has now been integrated. Changeset: 22d0aab9 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/22d0aab9022e29e3b4db75ea4e236d74184c0204 Stats: 52 lines in 2 files changed: 44 ins; 5 del; 3 mod 8247432: Update IANA Language Subtag Registry to Version 2020-09-29 Backport-of: ae0ca743f5646a5312566a6a65ec8929fca4b372 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/53 From evergizova at openjdk.java.net Thu May 13 12:37:28 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 13 May 2021 12:37:28 GMT Subject: [jdk15u-dev] RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Message-ID: I'd like to backport JDK-8257746 to 15u as follow-up fix for JDK-8250984 that is already included to 15u. The patch applies cleanly. Tested with tier1 and container tests. ------------- Commit messages: - Backport abc4300de9c7a298c359fb585d3b0570a98df5cb Changes: https://git.openjdk.java.net/jdk15u-dev/pull/54/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=54&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257746 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/54.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/54/head:pull/54 PR: https://git.openjdk.java.net/jdk15u-dev/pull/54 From evergizova at openjdk.java.net Thu May 13 12:56:14 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 13 May 2021 12:56:14 GMT Subject: [jdk15u-dev] Integrated: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines In-Reply-To: References: Message-ID: On Thu, 13 May 2021 12:30:31 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8257746 to 15u as follow-up fix for JDK-8250984 that is already included to 15u. > The patch applies cleanly. > Tested with tier1 and container tests. This pull request has now been integrated. Changeset: 0be19d28 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/0be19d285688c5c39f7535c0af5332fb7c672079 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Backport-of: abc4300de9c7a298c359fb585d3b0570a98df5cb ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/54 From yan at openjdk.java.net Thu May 13 13:47:11 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 13 May 2021 13:47:11 GMT Subject: [jdk15u-dev] RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8 on Japanese Windows. Message-ID: The issue reported in 15, too, and should be backported here. ------------- Commit messages: - Backport e15e30fef22ddffcaef9449648ae93b407a7b598 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/55/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=55&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249215 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/55.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/55/head:pull/55 PR: https://git.openjdk.java.net/jdk15u-dev/pull/55 From yan at openjdk.java.net Thu May 13 14:05:57 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 13 May 2021 14:05:57 GMT Subject: [jdk15u-dev] Integrated: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8 on Japanese Windows. In-Reply-To: References: Message-ID: On Thu, 13 May 2021 13:38:50 GMT, Yuri Nesterenko wrote: > The issue reported in 15, too, and should be backported here. This pull request has now been integrated. Changeset: 30458d46 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/30458d46a81d6d86b95fe05356c9ffe14b1a703a Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8 on Japanese Windows. Backport-of: e15e30fef22ddffcaef9449648ae93b407a7b598 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/55 From aph at redhat.com Thu May 13 14:39:47 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 May 2021 15:39:47 +0100 Subject: [11u] RFR (S) 8249189: AARCH64: more L2I conversions can be skipped In-Reply-To: References: Message-ID: <531dc9a4-83f0-681e-a1ec-b34ebe78a102@redhat.com> On 5/12/21 6:03 PM, Dmitry Chuyko wrote: > Hello, > > Original RFE: https://bugs.openjdk.java.net/browse/JDK-8249189 > > aarch64_ad.m4 and aarch64.ad are decorated different in 11u. > Nevertheless changes are very straightforward. > > aarch64_ad.m4 > Reapplied changes for UBFIZ_INSN and it's usages. > > aarch64.ad > Following the original patch: operand immL_positive_bitmaskI added after > operand immI_bitmask, instruct ubfizwIConvI2L and ubfizLConvL2I added > between ubfizL and ubfizIConvI2L, instruct ubfizLConvL2Ix added after > ubfizIConvI2L. > > Mask type is changed long to keep it in line with the rest of the .ad, > and thus the diff structure is close to the original. > > 11u webrev: http://cr.openjdk.java.net/~dchuyko/8249189/webrev.11u.00/ > > Testing: compiler/c2/TestSkipLongToIntCast.java, tier1, tier2. > > Generated part of aarch64.ad file matches the output of 'm4 aarch64_ad.m4'. Is this tested anywhere? -- 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 dmitry.chuyko at bell-sw.com Thu May 13 15:51:21 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 13 May 2021 18:51:21 +0300 Subject: [11u] RFR (S) 8249189: AARCH64: more L2I conversions can be skipped In-Reply-To: <531dc9a4-83f0-681e-a1ec-b34ebe78a102@redhat.com> References: <531dc9a4-83f0-681e-a1ec-b34ebe78a102@redhat.com> Message-ID: <746a3fa3-9a9d-aed2-e400-57f03eb21aae@bell-sw.com> On 5/13/21 5:39 PM, Andrew Haley wrote: > On 5/12/21 6:03 PM, Dmitry Chuyko wrote: >> .......... >> >> Testing: compiler/c2/TestSkipLongToIntCast.java, tier1, tier2. >> >> Generated part of aarch64.ad file matches the output of 'm4 aarch64_ad.m4'. > Is this tested anywhere? > Yes, as above. Manual test TestConversionSkip [1] from the original review also passed. -Dmitry [1] https://cr.openjdk.java.net/~bulasevich/8249189/webrev.02/TestConversionSkip.java From alexey at azul.com Thu May 13 19:35:20 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 13 May 2021 19:35:20 +0000 Subject: [11u] RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Message-ID: <5F4FAC88-87B4-411E-A4FF-266FAED4013F@azul.com> Hello, Could you please review the jdk11 backport of JDK-8242148: JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 Webrev 11u: http://cr.openjdk.java.net/~abakhtin/8241248_11u/webrev.v0/ Original patch: https://github.com/openjdk/jdk/commit/1603ca23422b03157afb2bd1050524465474b60e.patch The patch is not applied clean for PreSharedKeyExtension.java and ServerHello.java files because of JDK-8211018 ?Session Resumption without Server-Side State? [1] is not backported to JDK11 The merge is trivial. Test from the bug report is passed sun/security/ssl and javax/net/ssl jtreg tests passed [1] https://bugs.openjdk.java.net/browse/JDK-8211018 Regards Alexey From github.com+75672469+larry-n at openjdk.java.net Thu May 13 21:47:59 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Thu, 13 May 2021 21:47:59 GMT Subject: [jdk13u-dev] RFR: 8227080: (fs) Files.newInputStream(...).skip(n) is slow Message-ID: Backport c6c82dd736db6ff96a0f82862e416a9513633cd6 ------------- Commit messages: - 8227080: (fs) Files.newInputStream(...).skip(n) is slow Changes: https://git.openjdk.java.net/jdk13u-dev/pull/209/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=209&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8227080 Stats: 63 lines in 2 files changed: 56 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/209.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/209/head:pull/209 PR: https://git.openjdk.java.net/jdk13u-dev/pull/209 From matthias.baesken at sap.com Fri May 14 06:50:56 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 14 May 2021 06:50:56 +0000 Subject: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> <60c0765d-f6b9-3561-f247-95a341e3d1be@oss.nttdata.com> Message-ID: Hi Yasumasa , sure we can do the backport of 8220074 (LCMS) as a single commit. I updated https://bugs.openjdk.java.net/browse/JDK-8220074 accordingly (and linked in the comments to this review, hope that?s fine with you) . Best regards, Matthias >Your change looks good. Thank you for fixing them! >However I'm not sure we can include backport of 8220074 (LCMS) to this (8232084). >Can we merge them to single commit? From christoph.langer at sap.com Fri May 14 08:07:27 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 14 May 2021 08:07:27 +0000 Subject: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> <60c0765d-f6b9-3561-f247-95a341e3d1be@oss.nttdata.com> Message-ID: Hi Matthias, looking at JDK-8220074, I think you should push this as a single commit and extract it out of the commit for JDK-8232084. But no need for another webrev. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Baesken, Matthias > Sent: Freitag, 14. Mai 2021 08:51 > To: Yasumasa Suenaga ; jdk-updates-dev updates-dev at openjdk.java.net> > Cc: Doerr, Martin > Subject: RE: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 > > Hi Yasumasa , sure we can do the backport of 8220074 (LCMS) as a single > commit. > I updated > https://bugs.openjdk.java.net/browse/JDK-8220074 > > accordingly (and linked in the comments to this review, hope that?s fine with > you) . > > Best regards, Matthias > > > >Your change looks good. Thank you for fixing them! > >However I'm not sure we can include backport of 8220074 (LCMS) to this > (8232084). > >Can we merge them to single commit? > > > From suenaga at oss.nttdata.com Fri May 14 09:19:10 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 14 May 2021 18:19:10 +0900 Subject: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <341411ca-a784-2e1f-1a42-8ce2a2b5ca7d@oss.nttdata.com> <60c0765d-f6b9-3561-f247-95a341e3d1be@oss.nttdata.com> Message-ID: <11cee25de8596d552decaaf6786d36d9@oss.nttdata.com> Hi Matthias, I agree with Christoph. Thanks, Yasumasa 2021-05-14 17:07 ? Langer, Christoph ????????: > Hi Matthias, > > looking at JDK-8220074, I think you should push this as a single > commit and extract it out of the commit for JDK-8232084. But no need > for another webrev. > > Best regards > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Baesken, Matthias >> Sent: Freitag, 14. Mai 2021 08:51 >> To: Yasumasa Suenaga ; jdk-updates-dev > updates-dev at openjdk.java.net> >> Cc: Doerr, Martin >> Subject: RE: RFR [jdk11]: 8232084: HotSpot build failed with GCC 9.2.1 >> >> Hi Yasumasa , sure we can do the backport of 8220074 (LCMS) as a >> single >> commit. >> I updated >> https://bugs.openjdk.java.net/browse/JDK-8220074 >> >> accordingly (and linked in the comments to this review, hope that?s >> fine with >> you) . >> >> Best regards, Matthias >> >> >> >Your change looks good. Thank you for fixing them! >> >However I'm not sure we can include backport of 8220074 (LCMS) to this >> (8232084). >> >Can we merge them to single commit? >> >> >> From github.com+75672469+larry-n at openjdk.java.net Fri May 14 09:23:51 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Fri, 14 May 2021 09:23:51 GMT Subject: [jdk13u-dev] Withdrawn: 8227080: (fs) Files.newInputStream(...).skip(n) is slow In-Reply-To: References: Message-ID: <8UkrKO0BkJ2c_0ktEUOVBJDN0AOPwMsjbWx8wbo1RkU=.fa9b4913-ec9b-4a3b-ab42-37b1de4eb417@github.com> On Thu, 13 May 2021 20:23:02 GMT, Larry-N wrote: > Backport c6c82dd736db6ff96a0f82862e416a9513633cd6 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/209 From github.com+75672469+larry-n at openjdk.java.net Fri May 14 09:34:11 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Fri, 14 May 2021 09:34:11 GMT Subject: [jdk13u-dev] RFR: 8227080: (fs) Files.newInputStream(...).skip(n) is slow Message-ID: Backport JDK-8227080: (fs) Files.newInputStream(...).skip(n) is slow. Another bug JDK-8227609 should be backported after this. ------------- Commit messages: - Backport c6c82dd736db6ff96a0f82862e416a9513633cd6 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/210/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=210&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8227080 Stats: 63 lines in 2 files changed: 56 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/210.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/210/head:pull/210 PR: https://git.openjdk.java.net/jdk13u-dev/pull/210 From vlivanov at openjdk.java.net Fri May 14 09:51:08 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 14 May 2021 09:51:08 GMT Subject: [jdk16u] Integrated: 8267117: sun/hotspot/whitebox/CPUInfoTest.java fails on Ice Lake Message-ID: 8267117: sun/hotspot/whitebox/CPUInfoTest.java fails on Ice Lake ------------- Commit messages: - Backport 2a2f105a56bba3a180658f0b0151240676478ba4 Changes: https://git.openjdk.java.net/jdk16u/pull/115/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=115&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267117 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/115.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/115/head:pull/115 PR: https://git.openjdk.java.net/jdk16u/pull/115 From vlivanov at openjdk.java.net Fri May 14 09:51:09 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 14 May 2021 09:51:09 GMT Subject: [jdk16u] Integrated: 8267117: sun/hotspot/whitebox/CPUInfoTest.java fails on Ice Lake In-Reply-To: References: Message-ID: On Fri, 14 May 2021 09:38:52 GMT, Vladimir Ivanov wrote: > 8267117: sun/hotspot/whitebox/CPUInfoTest.java fails on Ice Lake This pull request has now been integrated. Changeset: d917b81b Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk16u/commit/d917b81bc941ef184177f2eff4120c51962bc9e8 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8267117: sun/hotspot/whitebox/CPUInfoTest.java fails on Ice Lake Backport-of: 2a2f105a56bba3a180658f0b0151240676478ba4 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/115 From github.com+75672469+larry-n at openjdk.java.net Fri May 14 10:48:41 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Fri, 14 May 2021 10:48:41 GMT Subject: [jdk13u-dev] Integrated: 8227080: (fs) Files.newInputStream(...).skip(n) is slow In-Reply-To: References: Message-ID: <8Mli46XfDQioMgXPh7zT2XMZ0uiw3zIi7jM-M-iFXKI=.ac20852e-80a2-45fd-bfa7-389c03ed1b74@github.com> On Fri, 14 May 2021 09:26:34 GMT, Larry-N wrote: > Backport JDK-8227080: (fs) Files.newInputStream(...).skip(n) is slow. > Another bug JDK-8227609 should be backported after this. This pull request has now been integrated. Changeset: 0b0db80d Author: Ilarion Nakonechnyy Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/0b0db80d1283741205950136e8d9f89af3933e88 Stats: 63 lines in 2 files changed: 56 ins; 2 del; 5 mod 8227080: (fs) Files.newInputStream(...).skip(n) is slow Backport-of: c6c82dd736db6ff96a0f82862e416a9513633cd6 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/210 From aph at redhat.com Fri May 14 13:22:42 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 May 2021 14:22:42 +0100 Subject: [11u] RFR (S) 8249189: AARCH64: more L2I conversions can be skipped In-Reply-To: <746a3fa3-9a9d-aed2-e400-57f03eb21aae@bell-sw.com> References: <531dc9a4-83f0-681e-a1ec-b34ebe78a102@redhat.com> <746a3fa3-9a9d-aed2-e400-57f03eb21aae@bell-sw.com> Message-ID: <84fef13e-0ece-f7a3-b129-a1a8574cd02a@redhat.com> On 5/13/21 4:51 PM, Dmitry Chuyko wrote: > On 5/13/21 5:39 PM, Andrew Haley wrote: >> On 5/12/21 6:03 PM, Dmitry Chuyko wrote: >>> .......... >>> >>> Testing: compiler/c2/TestSkipLongToIntCast.java, tier1, tier2. >>> >>> Generated part of aarch64.ad file matches the output of 'm4 aarch64_ad.m4'. >> Is this tested anywhere? >> > Yes, as above. Manual test TestConversionSkip [1] from the original > review also passed. OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dcherepanov at openjdk.java.net Fri May 14 13:21:48 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Fri, 14 May 2021 13:21:48 GMT Subject: [jdk13u-dev] Integrated: 8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 In-Reply-To: References: Message-ID: On Wed, 12 May 2021 10:49:24 GMT, Dmitry Cherepanov wrote: > 8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 This pull request has now been integrated. Changeset: 49e369c8 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/49e369c80aef64da6f971b0bc57d292004da7f63 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 Updated from 1.8.24 to 1.8.26 Backport-of: 78825925a5123aff66ae222420dcff8f454190e2 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/206 From rekakovacs at microsoft.com Fri May 14 22:52:18 2021 From: rekakovacs at microsoft.com (Reka Kovacs) Date: Fri, 14 May 2021 22:52:18 +0000 Subject: [11u] 8251031: Some vmTestbase/nsk/monitoring/RuntimeMXBean tests fail with hostnames starting from digits Message-ID: Hi, Could someone please sponsor this approved backport to jdk11u? It is a one-line fix that applies cleanly and eliminates several test failures on our internal pipelines. Affected tests and tier1 passes on Linux x64 and Windows x64. Original bug: https://bugs.openjdk.java.net/browse/JDK-8251031 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/5b555568ac4a Please find the changeset below. Thank you, Reka # HG changeset patch # User jiefu # Date 1596596058 -28800 # Wed Aug 05 10:54:18 2020 +0800 # Node ID 0cb730e192ac810dbf227b0f0415a4870291b491 # Parent 8ef49d1c1654eb058604d759b6f47ba6b95c6de3 8251031: Some vmTestbase/nsk/monitoring/RuntimeMXBean tests fail with hostnames starting from digits Reviewed-by: dholmes, cjplummer, sspitsyn diff --git a/test/hotspot/jtreg/vmTestbase/nsk/monitoring/RuntimeMXBean/RuntimeMXBean006/RuntimeMXBean006.java b/test/hotspot/jtreg/vmTestbase/nsk/monitoring/RuntimeMXBean/RuntimeMXBean006/RuntimeMXBean006.java --- a/test/hotspot/jtreg/vmTestbase/nsk/monitoring/RuntimeMXBean/RuntimeMXBean006/RuntimeMXBean006.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/monitoring/RuntimeMXBean/RuntimeMXBean006/RuntimeMXBean006.java @@ -57,7 +57,8 @@ public void initialize() { runtime = monitoringFactory.getRuntimeMXBean(); /* Name should be on the format @. */ - namePattern = Pattern.compile("^[0-9]+@(([a-zA-Z]|[a-zA-Z][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*([A-Za-z]|[A-Za-z][A-Za-z0-9\\-]*[A-Za-z0-9])$"); + namePattern = Pattern.compile("^[0-9]+@(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*" + + "[a-zA-Z0-9])\\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\\-]*[A-Za-z0-9])$"); } private void testGetName() { From phh at openjdk.java.net Sat May 15 00:23:23 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Sat, 15 May 2021 00:23:23 GMT Subject: [jdk16u] Integrated: 8260308: Update LogCompilation junit to 4.13.1 Message-ID: Hi all, this pull request contains a backport of commit ef247ab2 from the openjdk/jdk repository. The commit being backported was authored by Dan Lutker on 25 Jan 2021 and was reviewed by Eric Caspole and Igor Ignatyev. Thanks! ------------- Commit messages: - Backport ef247ab276b6f687a2ac0e0700d0de91bd3df8a8 Changes: https://git.openjdk.java.net/jdk16u/pull/116/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=116&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260308 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/116.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/116/head:pull/116 PR: https://git.openjdk.java.net/jdk16u/pull/116 From phh at openjdk.java.net Sat May 15 00:23:24 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Sat, 15 May 2021 00:23:24 GMT Subject: [jdk16u] Integrated: 8260308: Update LogCompilation junit to 4.13.1 In-Reply-To: References: Message-ID: On Sat, 15 May 2021 00:15:15 GMT, Paul Hohensee wrote: > Hi all, > > this pull request contains a backport of commit ef247ab2 from the openjdk/jdk repository. > > The commit being backported was authored by Dan Lutker on 25 Jan 2021 and was reviewed by Eric Caspole and Igor Ignatyev. > > Thanks! This pull request has now been integrated. Changeset: 860ca3fd Author: Paul Hohensee URL: https://git.openjdk.java.net/jdk16u/commit/860ca3fd7541ae99d6a6b4adc4f7e81f09d4c641 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8260308: Update LogCompilation junit to 4.13.1 Backport-of: ef247ab276b6f687a2ac0e0700d0de91bd3df8a8 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/116 From omikhaltcova at openjdk.java.net Sun May 16 12:16:42 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Sun, 16 May 2021 12:16:42 GMT Subject: [jdk15u-dev] RFR: 8249608: Vector register used by C2 compiled method corrupted at safepoint Message-ID: I'd like to backport JDK-8249608 to jdk15u for parity with jdk11u. The original patch applied cleanly. ------------- Commit messages: - Backport 970e251a54d3b8871d3b948c1632c124f248cb01 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/56/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=56&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249608 Stats: 105 lines in 2 files changed: 104 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk15u-dev/pull/56 From omikhaltcova at openjdk.java.net Mon May 17 07:01:52 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 17 May 2021 07:01:52 GMT Subject: [jdk13u-dev] RFR: 8249608: Vector register used by C2 compiled method corrupted at safepoint Message-ID: I'd like to backport JDK-8249608 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with tier1, tier2. ------------- Commit messages: - Backport 970e251a54d3b8871d3b948c1632c124f248cb01 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/211/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=211&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249608 Stats: 105 lines in 2 files changed: 104 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/211.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/211/head:pull/211 PR: https://git.openjdk.java.net/jdk13u-dev/pull/211 From omikhaltcova at openjdk.java.net Mon May 17 09:01:35 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 17 May 2021 09:01:35 GMT Subject: [jdk15u-dev] Integrated: 8249608: Vector register used by C2 compiled method corrupted at safepoint In-Reply-To: References: Message-ID: <093PYvIRKLt2juVhixxluaWHRmrfLBlAURAUaVYfAW0=.7e758e8e-b649-4b9f-8eee-af2a865e4fed@github.com> On Sun, 16 May 2021 12:06:28 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8249608 to jdk15u for parity with jdk11u. > The original patch applied cleanly. > Tested with tier1, tier2. This pull request has now been integrated. Changeset: 73ab6693 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/73ab6693acee20bebfa35aaff874d79978e63808 Stats: 105 lines in 2 files changed: 104 ins; 0 del; 1 mod 8249608: Vector register used by C2 compiled method corrupted at safepoint Always update 'max_vlen_in_bytes'. Backport-of: 970e251a54d3b8871d3b948c1632c124f248cb01 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/56 From omikhaltcova at openjdk.java.net Mon May 17 09:01:38 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 17 May 2021 09:01:38 GMT Subject: [jdk13u-dev] Integrated: 8249608: Vector register used by C2 compiled method corrupted at safepoint In-Reply-To: References: Message-ID: <5ncMbvjiES2_QEpw-pXVfprpzFB_8jpkY-LttUYXi0E=.3b8b9f85-17f5-4338-9af2-f74ee75dae96@github.com> On Sun, 16 May 2021 11:40:23 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8249608 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with tier1, tier2. This pull request has now been integrated. Changeset: afdd8248 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/afdd824826cc7e4b8a36a33299bb3dd7574ebe03 Stats: 105 lines in 2 files changed: 104 ins; 0 del; 1 mod 8249608: Vector register used by C2 compiled method corrupted at safepoint Always update 'max_vlen_in_bytes'. Backport-of: 970e251a54d3b8871d3b948c1632c124f248cb01 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/211 From coffeys at openjdk.java.net Mon May 17 09:26:42 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 17 May 2021 09:26:42 GMT Subject: [jdk16u] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs Message-ID: Performance issues reported after changes from https://bugs.openjdk.java.net/browse/JDK-8196415 Request to back out from July release and work a better solution for later update release. Reviewer request: @seanjmullan ------------- Commit messages: - 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs Changes: https://git.openjdk.java.net/jdk16u/pull/117/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=117&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267100 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/117.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/117/head:pull/117 PR: https://git.openjdk.java.net/jdk16u/pull/117 From yan at openjdk.java.net Mon May 17 09:46:48 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 17 May 2021 09:46:48 GMT Subject: [jdk13u-dev] RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows Message-ID: Applies clean with only a copyright year difference. Full night run completed without visible issues. ------------- Commit messages: - Backport ebdc80ead9b2ffd5f0d1e16ca6b8bab94b5ae6f3 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=212&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252883 Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk13u-dev/pull/212 From sgehwolf at redhat.com Mon May 17 10:25:01 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 17 May 2021 12:25:01 +0200 Subject: AW: [11u] RFR: 8196415: Disable SHA-1 Signed JARs In-Reply-To: References: Message-ID: On Wed, 2021-05-12 at 15:13 +0000, Doerr, Martin wrote: > Hi Severin, > ? > thanks for backporting it! We should have the same security changes > as 11.0.12-oracle. Looks good. > Thanks for the review! I'll hold off on integrating this for now due to JDK-8267100. Thanks, Severin From martin.doerr at sap.com Mon May 17 10:33:38 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 17 May 2021 10:33:38 +0000 Subject: AW: AW: [11u] RFR: 8196415: Disable SHA-1 Signed JARs In-Reply-To: References: , Message-ID: Hi Severin, excellent. I guess it will get retried in a later release when a performance fix is available (JDK-8266971). Best regards, Martin Von: Severin Gehwolf Datum: Montag, 17. Mai 2021 um 12:25 An: Doerr, Martin , jdk-updates-dev Betreff: Re: AW: [11u] RFR: 8196415: Disable SHA-1 Signed JARs On Wed, 2021-05-12 at 15:13 +0000, Doerr, Martin wrote: > Hi Severin, > > thanks for backporting it! We should have the same security changes > as 11.0.12-oracle. Looks good. > Thanks for the review! I'll hold off on integrating this for now due to JDK-8267100. Thanks, Severin From evergizova at openjdk.java.net Mon May 17 11:04:17 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Mon, 17 May 2021 11:04:17 GMT Subject: [jdk15u-dev] RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem Message-ID: I'd like to backport JDK-8255908 to 15u for parity with 11u. The patch applies cleanly. Tested with tier1 and container tests. ------------- Commit messages: - Backport 8d9cf48e813dee9567340720978392e04f736e65 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/57/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=57&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255908 Stats: 23 lines in 4 files changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/57.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/57/head:pull/57 PR: https://git.openjdk.java.net/jdk15u-dev/pull/57 From mullan at openjdk.java.net Mon May 17 12:11:23 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 17 May 2021 12:11:23 GMT Subject: [jdk16u] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:20:18 GMT, Sean Coffey wrote: > Performance issues reported after changes from https://bugs.openjdk.java.net/browse/JDK-8196415 > > Request to back out from July release and work a better solution for later update release. > Reviewer request: @seanjmullan Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/117 From github.com+75672469+larry-n at openjdk.java.net Mon May 17 12:26:31 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Mon, 17 May 2021 12:26:31 GMT Subject: [jdk13u-dev] RFR: 8227609: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size Message-ID: Backport fix JDK-8227609 (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size ------------- Commit messages: - Backport 3155cd829b56d9d44f47b607bad34db27d8b6d6a Changes: https://git.openjdk.java.net/jdk13u-dev/pull/213/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=213&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8227609 Stats: 181 lines in 3 files changed: 134 ins; 39 del; 8 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/213/head:pull/213 PR: https://git.openjdk.java.net/jdk13u-dev/pull/213 From github.com+75672469+larry-n at openjdk.java.net Mon May 17 12:45:45 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Mon, 17 May 2021 12:45:45 GMT Subject: [jdk13u-dev] Integrated: 8227609: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size In-Reply-To: References: Message-ID: On Mon, 17 May 2021 12:17:12 GMT, Larry-N wrote: > Backport fix JDK-8227609 (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size This pull request has now been integrated. Changeset: 32036b2b Author: Ilarion Nakonechnyy Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/32036b2b5c31dff8d124f9a5e37c0ceb979ee777 Stats: 181 lines in 3 files changed: 134 ins; 39 del; 8 mod 8227609: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size Backport-of: 3155cd829b56d9d44f47b607bad34db27d8b6d6a ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/213 From evergizova at openjdk.java.net Mon May 17 12:47:54 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Mon, 17 May 2021 12:47:54 GMT Subject: [jdk15u-dev] Integrated: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem In-Reply-To: References: Message-ID: On Mon, 17 May 2021 10:57:03 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8255908 to 15u for parity with 11u. > The patch applies cleanly. > Tested with tier1 and container tests. This pull request has now been integrated. Changeset: fb539676 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/fb5396763c6844d345ce4bc322030566e8b78c23 Stats: 23 lines in 4 files changed: 21 ins; 0 del; 2 mod 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem Backport-of: 8d9cf48e813dee9567340720978392e04f736e65 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/57 From martin.doerr at sap.com Mon May 17 13:09:04 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 17 May 2021 13:09:04 +0000 Subject: AW: [11u] RFR: jnf_removal, series of patches In-Reply-To: <0128E1E9-E9D4-470C-B0EB-F766EC7C8C9E@azul.com> References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com> , <0128E1E9-E9D4-470C-B0EB-F766EC7C8C9E@azul.com> Message-ID: Hi Vladimir, do you have individual patches? I?ve spent some time reviewing the files, but it?s often hard to find from which original sources they came from. I don?t necessarily need individual webrevs, but it would help a lot to have individual patches uploaded. Please note that NSApplicationAWT.m needs to get rebased, but it?s trivial to resolve. Best regards, Martin Von: Vladimir Kempik Datum: Donnerstag, 13. Mai 2021 um 12:37 An: Doerr, Martin Cc: jdk-updates-dev Betreff: Re: [11u] RFR: jnf_removal, series of patches Thanks for response Martin Looking forward to it 12 ??? 2021 ?., ? 18:04, Doerr, Martin > ???????(?): Hi Vladimir, sorry for the long delay. There are currently many 11u backports and too few reviewers working on them. I have started to look at your changes, but it may take some more time. Best regards, Martin Von: jdk-updates-dev > im Auftrag von Vladimir Kempik > Datum: Freitag, 23. April 2021 um 09:38 An: jdk-updates-dev > Betreff: Re: [11u] RFR: jnf_removal, series of patches 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 evergizova at openjdk.java.net Mon May 17 13:44:07 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Mon, 17 May 2021 13:44:07 GMT Subject: [jdk15u-dev] RFR: 8251257: NMT: jcmd VM.native_memory scale=1 crashes target VM Message-ID: I'd like to backport JDK-8251257 to 15u for parity with 11u. The patch applies cleanly. Tested with tier1 and nmt tests. ------------- Commit messages: - Backport 6df465de7309e90bc4de8da66c7059035ffc9bef Changes: https://git.openjdk.java.net/jdk15u-dev/pull/58/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=58&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251257 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/58.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/58/head:pull/58 PR: https://git.openjdk.java.net/jdk15u-dev/pull/58 From mullan at openjdk.java.net Mon May 17 13:47:02 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 17 May 2021 13:47:02 GMT Subject: [jdk16u] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:20:18 GMT, Sean Coffey wrote: > Performance issues reported after changes from https://bugs.openjdk.java.net/browse/JDK-8196415 > > Request to back out from July release and work a better solution for later update release. > Reviewer request: @seanjmullan Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/117 From evergizova at openjdk.java.net Mon May 17 14:04:00 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Mon, 17 May 2021 14:04:00 GMT Subject: [jdk15u-dev] Integrated: 8251257: NMT: jcmd VM.native_memory scale=1 crashes target VM In-Reply-To: References: Message-ID: On Mon, 17 May 2021 13:35:53 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8251257 to 15u for parity with 11u. > The patch applies cleanly. > Tested with tier1 and nmt tests. This pull request has now been integrated. Changeset: 723da963 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/723da963557c23713cc5ae0fcbd6d8d0cfb77d67 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod 8251257: NMT: jcmd VM.native_memory scale=1 crashes target VM Backport-of: 6df465de7309e90bc4de8da66c7059035ffc9bef ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/58 From coffeys at openjdk.java.net Mon May 17 15:39:06 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 17 May 2021 15:39:06 GMT Subject: [jdk16u] Integrated: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:20:18 GMT, Sean Coffey wrote: > Performance issues reported after changes from https://bugs.openjdk.java.net/browse/JDK-8196415 > > Request to back out from July release and work a better solution for later update release. > Reviewer request: @seanjmullan This pull request has now been integrated. Changeset: e84e1858 Author: Sean Coffey URL: https://git.openjdk.java.net/jdk16u/commit/e84e18580d764f612b9afaee7a470cde856a6bcc Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk16u/pull/117 From vkempik at azul.com Mon May 17 15:50:56 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Mon, 17 May 2021 15:50:56 +0000 Subject: [11u] RFR: jnf_removal, series of patches In-Reply-To: References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com> <0128E1E9-E9D4-470C-B0EB-F766EC7C8C9E@azul.com> Message-ID: Hello Martin Here they are http://cr.openjdk.java.net/~vkempik/jnf_removal_11u/ Was applying cleanly about a month ago Slight rebasing might be needed, but it?s trivial Regards, Vladimir > 17 ??? 2021 ?., ? 16:09, Doerr, Martin ???????(?): > > Hi Vladimir, > > do you have individual patches? > I?ve spent some time reviewing the files, but it?s often hard to find from which original sources they came from. > I don?t necessarily need individual webrevs, but it would help a lot to have individual patches uploaded. > > Please note that NSApplicationAWT.m needs to get rebased, but it?s trivial to resolve. > > Best regards, > Martin > > > Von: Vladimir Kempik > Datum: Donnerstag, 13. Mai 2021 um 12:37 > An: Doerr, Martin > Cc: jdk-updates-dev > Betreff: Re: [11u] RFR: jnf_removal, series of patches > > Thanks for response Martin > Looking forward to it > > > 12 ??? 2021 ?., ? 18:04, Doerr, Martin > ???????(?): > > Hi Vladimir, > > sorry for the long delay. There are currently many 11u backports and too few reviewers working on them. > I have started to look at your changes, but it may take some more time. > > Best regards, > Martin > > > Von: jdk-updates-dev > im Auftrag von Vladimir Kempik > > Datum: Freitag, 23. April 2021 um 09:38 > An: jdk-updates-dev > > Betreff: Re: [11u] RFR: jnf_removal, series of patches > > 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 Matthew.Carter at microsoft.com Mon May 17 16:39:38 2021 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Mon, 17 May 2021 16:39:38 +0000 Subject: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for loopback connections on Windows In-Reply-To: References: , , Message-ID: Hi Christoph / Martin Thanks for the feedback, I've created a JBS issue [1] for adding support to PlainSocketImpl on tip, once this new PR is completed I'll update the commit message for the backport to include all 3 JBS bug ids [1,2,3] In the meantime I'll remove the jdk11u-fix-request tag and add it back once its ready Cheers Mat [1] https://bugs.openjdk.java.net/browse/JDK-8267256 [2] https://bugs.openjdk.java.net/browse/JDK-8250521 [3] https://bugs.openjdk.java.net/browse/JDK-8255264 Sent from Outlook From: Langer, Christoph Sent: Wednesday, May 12, 2021 8:26 AM To: Mat Carter Cc: jdk-updates-dev at openjdk.java.net ; Doerr, Martin Subject: RE: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for loopback connections on Windows ? Hi Mat, yes, sorry for ignoring this backport for so long. I see that you made a complementary change to src/java.base/windows/native/libnet/PlainSocketImpl.c for JDK-8250521. You're right in that PlainSocketImpl is only existing in head jdk/jdk as a fallback. I however would very much prefer if you could do this change in head first and then backport it. There should still be active regression tests for PlainSocketImpl in head. Could you please consider that? Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Doerr, Martin > Sent: Mittwoch, 12. Mai 2021 11:57 > To: Mat Carter ; jdk-updates- > dev at openjdk.java.net > Subject: [DMARC FAILURE] AW: [11u] RFR: 8250521 - Configure initial RTO to > use minimal retry for loopback connections on Windows > > Hi, > > seems like this one has fallen through the cracks. > > The 11u webrev looks good to me. > If you want to backport both changes at once, please add both bug ids to the > commit message. > > Best regards, > Martin > > > Von: jdk-updates-dev im > Auftrag von Mat Carter > Datum: Montag, 5. April 2021 um 18:29 > An: jdk-updates-dev at openjdk.java.net dev at openjdk.java.net> > Betreff: Re: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for > loopback connections on Windows > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250521&data=04%7C01%7CMatthew.Carter%40microsoft.com%7Cc59c13675e10446ab41f08d9155a56ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637564300023508503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kbvjmgzC7k1CJHLsU18mD%2FHudswVDNWJttLUUGj5V2w%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8255264&data=04%7C01%7CMatthew.Carter%40microsoft.com%7Cc59c13675e10446ab41f08d9155a56ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637564300023508503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XJbY6JQSXNTYMy8pla7L5a7WJTz1vXDia02CSUWpMyM%3D&reserved=0 > > 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 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%7Cf7e7 > 3bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C > 1%7C0%7C637469615655279564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > &sdata=iFXbQOHEvBhOnkA6TlLy30Bxk8FXxIXRm8GNhQptQR8%3D&am > p;reserved=0 > Original fix: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.o > penjdk.java.net%2Fjdk%2Fjdk%2Frev%2F035cdb28aa4c&data=04%7C01 > %7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3ce > a9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655279 > 564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7qBKPLtXpedI > DcVk8rXoEHl8BZYQh5kOitWMNEjqG8Y%3D&reserved=0 > Original webrev: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openj > dk.java.net%2F~adityam%2Fnikola%2Ffast_connect_loopback_3%2F&d > ata=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f931 > 3b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374 > 69615655279564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SE6 > 5puvz3q6D4A04QEYIhze%2BzWfE3RLbNnUVpRkWM%2BA%3D&reserve > d=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%7Cf7e7 > 3bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C > 1%7C0%7C637469615655289515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > &sdata=MBxv58ht3VnIvMjfn4JzHXx7CNO6RKdCU25oO0JQ7dA%3D&am > p;reserved=0 > Original fix: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fopenjdk%2Fjdk%2Fcommit%2F7e01bc96&data=04%7C01%7 > Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c > %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515 > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IWfdxpo06CJLxQRs > o1%2Fne%2FVW64f8GEIbKMS2Wdkrq3E%3D&reserved=0 > Original PR: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fopenjdk%2Fjdk%2Fpull%2F1523&data=04%7C01%7Cmatthe > w.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f9 > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515%7CUnk > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eACOp2IEdvd6vEB4qPNjkYl > ufUGq6fgjF6kFeVky9rg%3D&reserved=0 > > webrev for 11u: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openj > dk.java.net%2F~adityam%2Fmat%2F8250521_jdk11%2F&data=04%7C01 > %7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3ce > a9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289 > 515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dvT%2FQBwf7 > Pv8%2FrOWCpuYNUbK%2Fu23qxAs5xKNf64O2%2FI%3D&reserved=0 > > Thanks in advance > Mat From dcherepanov at openjdk.java.net Mon May 17 16:47:49 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Mon, 17 May 2021 16:47:49 GMT Subject: [jdk13u-dev] RFR: 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 Message-ID: 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 ------------- Commit messages: - Backport 381e90eb6bd62416a07cf883c1588ade3287d140 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/214/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=214&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8229243 Stats: 229 lines in 12 files changed: 167 ins; 18 del; 44 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/214.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/214/head:pull/214 PR: https://git.openjdk.java.net/jdk13u-dev/pull/214 From hohensee at amazon.com Mon May 17 18:11:22 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 17 May 2021 18:11:22 +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: <6E00186C-5E38-4539-BE95-5392549B0625@amazon.com> Hi, Evgeny. I reviewed this backport last month and tagged the issue. Waiting on maintainer (Christoph?) approval. Thanks, Paul From: compiler-dev on behalf of "Astigeevich, Evgeny" Date: Saturday, May 15, 2021 at 3:05 PM 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 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 christoph.langer at sap.com Mon May 17 18:19:59 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 17 May 2021 18:19:59 +0000 Subject: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for loopback connections on Windows In-Reply-To: References: , , Message-ID: Hi Mat, sounds great ?? I've modified JDK-8267256 a little bit to make it a correct open bug for JDK17. It's also no backport of the other two items as you had linked. Only a relates-to. You can ping me when you have a PR for jdk/jdk and I might be able to help you in reviewing. Best regards Christoph > -----Original Message----- > From: Mat Carter > Sent: Montag, 17. Mai 2021 18:40 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net; Doerr, Martin > > Subject: Re: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for > loopback connections on Windows > > Hi Christoph / Martin > > Thanks for the feedback, I've created a JBS issue [1] for adding support to > PlainSocketImpl on tip, once this new PR is completed I'll update the commit > message for the backport to include all 3 JBS bug ids [1,2,3] > > In the meantime I'll remove the jdk11u-fix-request tag and add it back once > its ready > > Cheers > Mat > > [1] https://bugs.openjdk.java.net/browse/JDK-8267256 > [2] https://bugs.openjdk.java.net/browse/JDK-8250521 > [3] https://bugs.openjdk.java.net/browse/JDK-8255264 > > Sent from Outlook > > > From: Langer, Christoph > Sent: Wednesday, May 12, 2021 8:26 AM > To: Mat Carter > Cc: jdk-updates-dev at openjdk.java.net dev at openjdk.java.net>; Doerr, Martin > Subject: RE: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry for > loopback connections on Windows > > Hi Mat, > > yes, sorry for ignoring this backport for so long. > > I see that you made a complementary change to > src/java.base/windows/native/libnet/PlainSocketImpl.c for JDK-8250521. > You're right in that PlainSocketImpl is only existing in head jdk/jdk as a > fallback. I however would very much prefer if you could do this change in > head first and then backport it. There should still be active regression tests > for PlainSocketImpl in head. Could you please consider that? > > Thanks > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Doerr, Martin > > Sent: Mittwoch, 12. Mai 2021 11:57 > > To: Mat Carter ; jdk-updates- > > dev at openjdk.java.net > > Subject: [DMARC FAILURE] AW: [11u] RFR: 8250521 - Configure initial RTO > to > > use minimal retry for loopback connections on Windows > > > > Hi, > > > > seems like this one has fallen through the cracks. > > > > The 11u webrev looks good to me. > > If you want to backport both changes at once, please add both bug ids to > the > > commit message. > > > > Best regards, > > Martin > > > > > > Von: jdk-updates-dev im > > Auftrag von Mat Carter > > Datum: Montag, 5. April 2021 um 18:29 > > An: jdk-updates-dev at openjdk.java.net > dev at openjdk.java.net> > > Betreff: Re: [11u] RFR: 8250521 - Configure initial RTO to use minimal retry > for > > loopback connections on Windows > > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .openjdk.java.net%2Fbrowse%2FJDK- > 8250521&data=04%7C01%7CMatthew.Carter%40microsoft.com%7Cc59c > 13675e10446ab41f08d9155a56ba%7C72f988bf86f141af91ab2d7cd011db47%7 > C1%7C0%7C637564300023508503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100 > 0&sdata=kbvjmgzC7k1CJHLsU18mD%2FHudswVDNWJttLUUGj5V2w%3 > D&reserved=0 > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .openjdk.java.net%2Fbrowse%2FJDK- > 8255264&data=04%7C01%7CMatthew.Carter%40microsoft.com%7Cc59c > 13675e10446ab41f08d9155a56ba%7C72f988bf86f141af91ab2d7cd011db47%7 > C1%7C0%7C637564300023508503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100 > 0&sdata=XJbY6JQSXNTYMy8pla7L5a7WJTz1vXDia02CSUWpMyM%3D&a > mp;reserved=0 > > > > 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 > 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%7Cf7e7 > > > 3bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C > > > 1%7C0%7C637469615655279564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > > > &sdata=iFXbQOHEvBhOnkA6TlLy30Bxk8FXxIXRm8GNhQptQR8%3D&am > > p;reserved=0 > > Original fix: > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.o > > > penjdk.java.net%2Fjdk%2Fjdk%2Frev%2F035cdb28aa4c&data=04%7C01 > > > %7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3ce > > > a9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655279 > > 564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > > > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7qBKPLtXpedI > > DcVk8rXoEHl8BZYQh5kOitWMNEjqG8Y%3D&reserved=0 > > Original webrev: > > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openj > > > dk.java.net%2F~adityam%2Fnikola%2Ffast_connect_loopback_3%2F&d > > > ata=04%7C01%7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f931 > > > 3b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374 > > > 69615655279564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > > > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SE6 > > > 5puvz3q6D4A04QEYIhze%2BzWfE3RLbNnUVpRkWM%2BA%3D&reserve > > d=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%7Cf7e7 > > > 3bbae0c442f9313b08d8bf3cea9c%7C72f988bf86f141af91ab2d7cd011db47%7C > > > 1%7C0%7C637469615655289515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > > > &sdata=MBxv58ht3VnIvMjfn4JzHXx7CNO6RKdCU25oO0JQ7dA%3D&am > > p;reserved=0 > > Original fix: > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > > ub.com%2Fopenjdk%2Fjdk%2Fcommit%2F7e01bc96&data=04%7C01%7 > > > Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c > > > %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515 > > > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IWfdxpo06CJLxQRs > > o1%2Fne%2FVW64f8GEIbKMS2Wdkrq3E%3D&reserved=0 > > Original PR: > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > > ub.com%2Fopenjdk%2Fjdk%2Fpull%2F1523&data=04%7C01%7Cmatthe > > > w.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3cea9c%7C72f9 > > > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289515%7CUnk > > > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > > > k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eACOp2IEdvd6vEB4qPNjkYl > > ufUGq6fgjF6kFeVky9rg%3D&reserved=0 > > > > webrev for 11u: > > > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openj > > > dk.java.net%2F~adityam%2Fmat%2F8250521_jdk11%2F&data=04%7C01 > > > %7Cmatthew.carter%40microsoft.com%7Cf7e73bbae0c442f9313b08d8bf3ce > > > a9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637469615655289 > > 515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > > > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dvT%2FQBwf7 > > Pv8%2FrOWCpuYNUbK%2Fu23qxAs5xKNf64O2%2FI%3D&reserved=0 > > > > Thanks in advance > > Mat From christoph.langer at sap.com Mon May 17 18:23:37 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 17 May 2021 18:23:37 +0000 Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow In-Reply-To: <6E00186C-5E38-4539-BE95-5392549B0625@amazon.com> References: <79357B63-E29D-451A-A810-004F17189BDD@amazon.com> <6E00186C-5E38-4539-BE95-5392549B0625@amazon.com> Message-ID: Hi Paul, you not only requested approval. You also got it and then pushed (on 21st of April). ?? I guess Evgeny?s mail popped up again on the mailing list for some reason? Cheers Christoph From: compiler-dev On Behalf Of Hohensee, Paul Sent: Montag, 17. Mai 2021 20:11 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 Hi, Evgeny. I reviewed this backport last month and tagged the issue. Waiting on maintainer (Christoph?) approval. Thanks, Paul From: compiler-dev > on behalf of "Astigeevich, Evgeny" > Date: Saturday, May 15, 2021 at 3:05 PM 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 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 hohensee at amazon.com Mon May 17 18:30:49 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 17 May 2021 18:30:49 +0000 Subject: [11u] RFR 8177068: incomplete classpath causes NPE in Flow Message-ID: That?s what I get for not actually looking at the issue before responding? :) From: "Langer, Christoph" Date: Monday, May 17, 2021 at 11:24 AM To: "Hohensee, Paul" , "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 Hi Paul, you not only requested approval. You also got it and then pushed (on 21st of April). ?? I guess Evgeny?s mail popped up again on the mailing list for some reason? Cheers Christoph From: compiler-dev On Behalf Of Hohensee, Paul Sent: Montag, 17. Mai 2021 20:11 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 Hi, Evgeny. I reviewed this backport last month and tagged the issue. Waiting on maintainer (Christoph?) approval. Thanks, Paul From: compiler-dev > on behalf of "Astigeevich, Evgeny" > Date: Saturday, May 15, 2021 at 3:05 PM 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 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 rekakovacs at microsoft.com Mon May 17 23:16:11 2021 From: rekakovacs at microsoft.com (Reka Kovacs) Date: Mon, 17 May 2021 23:16:11 +0000 Subject: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 Message-ID: Hi, I would like to backport this change as it eliminates build failures on Windows with VS2019, which is now the generally recommended version of Visual Studio. Could someone please review? Original bug: https://bugs.openjdk.java.net/browse/JDK-8241087 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c616656f7e01 Bug for backport: https://bugs.openjdk.java.net/browse/JDK-8254634 Webrev: http://cr.openjdk.java.net/~mbeckwit/8241087/webrev.00/ The original patch does not apply cleanly to jdk11u, because the copyright year in awt_DnDDT.cpp has already been changed to 2021. The updated patch does not touch that line. Monica kindly hosted the webrev for me. Tested: build and tier1 on x86_64 Windows, Linux and MacOS. Thank you, Reka From martin.doerr at sap.com Tue May 18 12:07:13 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 18 May 2021 12:07:13 +0000 Subject: AW: [11u] RFR: jnf_removal, series of patches In-Reply-To: References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com> <0128E1E9-E9D4-470C-B0EB-F766EC7C8C9E@azul.com> , Message-ID: Hi Vladimir, thanks for doing all the work. I?ve reviewed your changes. JDK-8257858 1_ - Applies almost clean, few gmk files had different filename and few copyright year issues, context difference in gmk files All good. JDK-8257853 2_ - Not clean, most of issues were in CPrinterJob and JavaAccessibility due to changes in jdk12+. Rest was mostly context code difference. This one is tough but looks good. JDK-8259343 3_ - Clean, only gmk file renames were needed Good. JDK-8259651 4_ - Not clean, have to remove some changes to parts which are missing in jdk11: CMenuBar: ActivateDefaultMenuBar, Accessebility: titleChanged, getMultiClickTime Makes sense. Looks good. JDK-8259869 5_ - Almost Clean, slight Context code difference in CGLLayer.h Good. JDK-8260616 6_ - not clean, Missing CommonTextAccessibility.m in jdk11. Some Context code difference. Right. Good. Please make sure to push the 11 commits with the correct bug IDs in the commit messages for each of them. We need to keep track of all backported changes. Best regards, Martin Von: Vladimir Kempik Datum: Montag, 17. Mai 2021 um 17:51 An: Doerr, Martin Cc: jdk-updates-dev Betreff: Re: [11u] RFR: jnf_removal, series of patches Hello Martin Here they are http://cr.openjdk.java.net/~vkempik/jnf_removal_11u/ Was applying cleanly about a month ago Slight rebasing might be needed, but it?s trivial Regards, Vladimir 17 ??? 2021 ?., ? 16:09, Doerr, Martin > ???????(?): Hi Vladimir, do you have individual patches? I?ve spent some time reviewing the files, but it?s often hard to find from which original sources they came from. I don?t necessarily need individual webrevs, but it would help a lot to have individual patches uploaded. Please note that NSApplicationAWT.m needs to get rebased, but it?s trivial to resolve. Best regards, Martin Von: Vladimir Kempik > Datum: Donnerstag, 13. Mai 2021 um 12:37 An: Doerr, Martin > Cc: jdk-updates-dev > Betreff: Re: [11u] RFR: jnf_removal, series of patches Thanks for response Martin Looking forward to it 12 ??? 2021 ?., ? 18:04, Doerr, Martin > ???????(?): Hi Vladimir, sorry for the long delay. There are currently many 11u backports and too few reviewers working on them. I have started to look at your changes, but it may take some more time. Best regards, Martin Von: jdk-updates-dev > im Auftrag von Vladimir Kempik > Datum: Freitag, 23. April 2021 um 09:38 An: jdk-updates-dev > Betreff: Re: [11u] RFR: jnf_removal, series of patches 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 vkempik at azul.com Tue May 18 12:12:53 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 18 May 2021 12:12:53 +0000 Subject: [11u] RFR: jnf_removal, series of patches In-Reply-To: References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com> <0128E1E9-E9D4-470C-B0EB-F766EC7C8C9E@azul.com> Message-ID: <7E83D25B-717E-4F73-9467-0F5E13BB2857@azul.com> Hello Martin, thanks for checking this. Just in case, what do you mean by "Please make sure to push the 11 commits with the correct bug IDs in the commit messages for each of them. We need to keep track of all backported changes.? ? in the patches I have sent you, it has 11 different commits, anything wrong with them there ? I have a plan to push 11 separate commits in one push command, so history is kept good and little chance anyone will be building incomplete job (without some bugfixes for jnf removal). Regards, Vladimir > 18 ??? 2021 ?., ? 15:07, Doerr, Martin ???????(?): > > Hi Vladimir, > > thanks for doing all the work. I?ve reviewed your changes. > > JDK-8257858 > 1_ - Applies almost clean, few gmk files had different filename and few copyright year issues, context difference in gmk files > All good. > > JDK-8257853 > 2_ - Not clean, most of issues were in CPrinterJob and JavaAccessibility due to changes in jdk12+. Rest was mostly context code difference. > This one is tough but looks good. > > JDK-8259343 > 3_ - Clean, only gmk file renames were needed > Good. > > JDK-8259651 > 4_ - Not clean, have to remove some changes to parts which are missing in jdk11: CMenuBar: ActivateDefaultMenuBar, Accessebility: titleChanged, getMultiClickTime > Makes sense. Looks good. > > JDK-8259869 > 5_ - Almost Clean, slight Context code difference in CGLLayer.h > Good. > > JDK-8260616 > 6_ - not clean, Missing CommonTextAccessibility.m in jdk11. Some Context code difference. > Right. Good. > > Please make sure to push the 11 commits with the correct bug IDs in the commit messages for each of them. We need to keep track of all backported changes. > > Best regards, > Martin > > > Von: Vladimir Kempik > > Datum: Montag, 17. Mai 2021 um 17:51 > An: Doerr, Martin > > Cc: jdk-updates-dev > > Betreff: Re: [11u] RFR: jnf_removal, series of patches > > Hello Martin > Here they are http://cr.openjdk.java.net/~vkempik/jnf_removal_11u/ > Was applying cleanly about a month ago > Slight rebasing might be needed, but it?s trivial > > Regards, Vladimir > > > > > 17 ??? 2021 ?., ? 16:09, Doerr, Martin > ???????(?): > > Hi Vladimir, > > do you have individual patches? > I?ve spent some time reviewing the files, but it?s often hard to find from which original sources they came from. > I don?t necessarily need individual webrevs, but it would help a lot to have individual patches uploaded. > > Please note that NSApplicationAWT.m needs to get rebased, but it?s trivial to resolve. > > Best regards, > Martin > > > Von: Vladimir Kempik > > Datum: Donnerstag, 13. Mai 2021 um 12:37 > An: Doerr, Martin > > Cc: jdk-updates-dev > > Betreff: Re: [11u] RFR: jnf_removal, series of patches > > Thanks for response Martin > Looking forward to it > > > 12 ??? 2021 ?., ? 18:04, Doerr, Martin > ???????(?): > > Hi Vladimir, > > sorry for the long delay. There are currently many 11u backports and too few reviewers working on them. > I have started to look at your changes, but it may take some more time. > > Best regards, > Martin > > > Von: jdk-updates-dev > im Auftrag von Vladimir Kempik > > Datum: Freitag, 23. April 2021 um 09:38 > An: jdk-updates-dev > > Betreff: Re: [11u] RFR: jnf_removal, series of patches > > 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 evergizova at openjdk.java.net Tue May 18 12:17:55 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 18 May 2021 12:17:55 GMT Subject: [jdk15u-dev] RFR: 8256809: Annotation processing causes NPE during flow analysis Message-ID: I'd like to backport JDK-8256809 to 15u for parity with 11u. The patch applies cleanly. Tested with tier1; new test fails without the patch, passes with it. ------------- Commit messages: - Backport 8ddf5e172b5d3fcd0aafa50c9019ee16ef038825 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/59/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=59&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256809 Stats: 160 lines in 2 files changed: 159 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/59/head:pull/59 PR: https://git.openjdk.java.net/jdk15u-dev/pull/59 From evergizova at openjdk.java.net Tue May 18 12:30:24 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 18 May 2021 12:30:24 GMT Subject: [jdk15u-dev] Integrated: 8256809: Annotation processing causes NPE during flow analysis In-Reply-To: References: Message-ID: On Tue, 18 May 2021 12:12:50 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8256809 to 15u for parity with 11u. > The patch applies cleanly. > Tested with tier1; new test fails without the patch, passes with it. This pull request has now been integrated. Changeset: 14df1203 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/14df1203caef52594671e6c828cebe552a8dd7ee Stats: 160 lines in 2 files changed: 159 ins; 0 del; 1 mod 8256809: Annotation processing causes NPE during flow analysis Backport-of: 8ddf5e172b5d3fcd0aafa50c9019ee16ef038825 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/59 From martin.doerr at sap.com Tue May 18 12:30:55 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 18 May 2021 12:30:55 +0000 Subject: AW: [11u] RFR: jnf_removal, series of patches In-Reply-To: <7E83D25B-717E-4F73-9467-0F5E13BB2857@azul.com> References: <5E853790-B01E-4829-A730-0ADB8DC146ED@azul.com> <1C7D8D87-3265-4964-AC19-4124712E0BB3@azul.com> <0128E1E9-E9D4-470C-B0EB-F766EC7C8C9E@azul.com> , <7E83D25B-717E-4F73-9467-0F5E13BB2857@azul.com> Message-ID: Hi Vladimir, pushing them at once is fine. I just wanted to make sure that the individual commits will be visible correctly in the history and in JBS. I had only asked because the webrev shows everything together in one change. There?s nothing wrong with your commits. Best regards, Martin Von: Vladimir Kempik Datum: Dienstag, 18. Mai 2021 um 14:13 An: Doerr, Martin Cc: jdk-updates-dev Betreff: Re: [11u] RFR: jnf_removal, series of patches Hello Martin, thanks for checking this. Just in case, what do you mean by "Please make sure to push the 11 commits with the correct bug IDs in the commit messages for each of them. We need to keep track of all backported changes.? ? in the patches I have sent you, it has 11 different commits, anything wrong with them there ? I have a plan to push 11 separate commits in one push command, so history is kept good and little chance anyone will be building incomplete job (without some bugfixes for jnf removal). Regards, Vladimir 18 ??? 2021 ?., ? 15:07, Doerr, Martin > ???????(?): Hi Vladimir, thanks for doing all the work. I?ve reviewed your changes. JDK-8257858 1_ - Applies almost clean, few gmk files had different filename and few copyright year issues, context difference in gmk files All good. JDK-8257853 2_ - Not clean, most of issues were in CPrinterJob and JavaAccessibility due to changes in jdk12+. Rest was mostly context code difference. This one is tough but looks good. JDK-8259343 3_ - Clean, only gmk file renames were needed Good. JDK-8259651 4_ - Not clean, have to remove some changes to parts which are missing in jdk11: CMenuBar: ActivateDefaultMenuBar, Accessebility: titleChanged, getMultiClickTime Makes sense. Looks good. JDK-8259869 5_ - Almost Clean, slight Context code difference in CGLLayer.h Good. JDK-8260616 6_ - not clean, Missing CommonTextAccessibility.m in jdk11. Some Context code difference. Right. Good. Please make sure to push the 11 commits with the correct bug IDs in the commit messages for each of them. We need to keep track of all backported changes. Best regards, Martin Von: Vladimir Kempik > Datum: Montag, 17. Mai 2021 um 17:51 An: Doerr, Martin > Cc: jdk-updates-dev > Betreff: Re: [11u] RFR: jnf_removal, series of patches Hello Martin Here they are http://cr.openjdk.java.net/~vkempik/jnf_removal_11u/ Was applying cleanly about a month ago Slight rebasing might be needed, but it?s trivial Regards, Vladimir 17 ??? 2021 ?., ? 16:09, Doerr, Martin > ???????(?): Hi Vladimir, do you have individual patches? I?ve spent some time reviewing the files, but it?s often hard to find from which original sources they came from. I don?t necessarily need individual webrevs, but it would help a lot to have individual patches uploaded. Please note that NSApplicationAWT.m needs to get rebased, but it?s trivial to resolve. Best regards, Martin Von: Vladimir Kempik > Datum: Donnerstag, 13. Mai 2021 um 12:37 An: Doerr, Martin > Cc: jdk-updates-dev > Betreff: Re: [11u] RFR: jnf_removal, series of patches Thanks for response Martin Looking forward to it 12 ??? 2021 ?., ? 18:04, Doerr, Martin > ???????(?): Hi Vladimir, sorry for the long delay. There are currently many 11u backports and too few reviewers working on them. I have started to look at your changes, but it may take some more time. Best regards, Martin Von: jdk-updates-dev > im Auftrag von Vladimir Kempik > Datum: Freitag, 23. April 2021 um 09:38 An: jdk-updates-dev > Betreff: Re: [11u] RFR: jnf_removal, series of patches 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 evergizova at openjdk.java.net Tue May 18 12:46:43 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 18 May 2021 12:46:43 GMT Subject: [jdk15u-dev] RFR: 8261022: Fix incorrect result of Math.abs() with char type Message-ID: I'd like to backport JDK-8261022 to 15u for parity with 11u. The patch applies cleanly, but requires a modification due to absence of VectorNode::is_shift_opcode in 15u (JDK-8257625 is not in 15u), replaced by similar VectorNode::is_shift. Tested with tier1; new test fails without the patch, passes with it. ------------- Commit messages: - Backport 7a2db858e0e81f2ba17c3554386bb6a833318b3d Changes: https://git.openjdk.java.net/jdk15u-dev/pull/60/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=60&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261022 Stats: 77 lines in 2 files changed: 66 ins; 1 del; 10 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/60/head:pull/60 PR: https://git.openjdk.java.net/jdk15u-dev/pull/60 From yan at openjdk.java.net Tue May 18 13:28:58 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 18 May 2021 13:28:58 GMT Subject: [jdk15u-dev] RFR: 8261022: Fix incorrect result of Math.abs() with char type In-Reply-To: References: Message-ID: On Tue, 18 May 2021 12:39:46 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8261022 to 15u for parity with 11u. > The patch applies cleanly, but requires a modification due to absence of VectorNode::is_shift_opcode in 15u (JDK-8257625 is not in 15u), replaced by similar VectorNode::is_shift. > Tested with tier1; new test fails without the patch, passes with it. OK with me: in 11 the change is about the same ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk15u-dev/pull/60 From dmitry.chuyko at bell-sw.com Tue May 18 14:48:19 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 18 May 2021 17:48:19 +0300 Subject: [11u] RFR (S) 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller Message-ID: <30a78114-1805-92a8-bc40-e40a3bb20b31@bell-sw.com> Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8253048 Preconditions are met in 11u: stub genertor logic is to "save the bottom 64 bits of each value stored in v8-v15; it is the responsibility of the caller to preserve larger values.", add_call_kills() logic is present. Original patch does not apply cleanly (JDK-8231441 - initial SVE - is not in 11u, some other changes as well). But it was rather simply reproduced: src/hotspot/cpu/aarch64/aarch64.ad 'reg_def V<8-15>, V<8-15>_H' are made 'SOC, SOE...' instead of 'SOC, SOC...' src/hotspot/cpu/aarch64/macroAssembler_aarch64_trig.cpp Replaced v10 usages by v24. No other references of v8-v15 in macroAssembler-aarch64*. In assembler_aarch64.cpp there are still usages generated by aarch64-asmtest.py. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8253048/webrev.11u.00/ Testing: tier1, tier2. Opto assembly check for the test [1] from original review shows 'stack bang size=48' -> 'stack bang size=32' around nanoTime call. [1] http://cr.openjdk.java.net/~jzhu/8253048/Test.java -- Thanks, -Dmitry From martin.doerr at sap.com Tue May 18 15:02:35 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 18 May 2021 15:02:35 +0000 Subject: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" Message-ID: Hi, JDK-8266293 is backported to 11.0.12-oracle. The included test shows that the fix is required in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8266293 Original change: https://git.openjdk.java.net/jdk/commit/04f71126479f9c39aa71e8aebe7196d72fc16796 It applies almost cleanly. Only the bug id addition in the test had to get done manually. However, the new code needs an adaptation because JDK11u doesn't contain KnownOIDs. One of the original author?s comments says: "Backporters might need to check case-insensitive equality to both "PBEWithMD5AndDES" and "1.2.840.113549.1.5.3" because both the algorithm name and OID can be specified through the system property." I've followed this suggestion directly. It should also be possible to do something tricky with AlgorithmId.pbeWithMD5AndDES_oid, but that seems to be more error-prone, so that is not my first choice for a backport. 11u backport: http://cr.openjdk.java.net/~mdoerr/8266293_keyprotection_11u/webrev.00/ Please review. Best regards, Martin From yan at openjdk.java.net Wed May 19 07:28:20 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 07:28:20 GMT Subject: [jdk13u-dev] Integrated: 8241829: Cleanup the code for PrinterJob on windows Message-ID: The regular nightly testing runs OK. Applies clean. Will be ported together with 8262829 crash fix. ------------- Commit messages: - Backport a62b24f573c418b2b30f18e72bfdb96359acc890 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/215/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=215&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241829 Stats: 134 lines in 3 files changed: 58 ins; 55 del; 21 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/215.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/215/head:pull/215 PR: https://git.openjdk.java.net/jdk13u-dev/pull/215 From yan at openjdk.java.net Wed May 19 07:28:23 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 07:28:23 GMT Subject: [jdk13u-dev] Integrated: 8241829: Cleanup the code for PrinterJob on windows In-Reply-To: References: Message-ID: On Wed, 19 May 2021 07:14:54 GMT, Yuri Nesterenko wrote: > The regular nightly testing runs OK. Applies clean. Will be ported together with 8262829 crash fix. This pull request has now been integrated. Changeset: 5650831d Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/5650831d485f3d3bf48685b53477eaefe71395da Stats: 134 lines in 3 files changed: 58 ins; 55 del; 21 mod 8241829: Cleanup the code for PrinterJob on windows Backport-of: a62b24f573c418b2b30f18e72bfdb96359acc890 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/215 From yan at openjdk.java.net Wed May 19 07:39:10 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 07:39:10 GMT Subject: [jdk13u-dev] Integrated: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() Message-ID: I'd like to port a fix for this crash here, too. Skara says "clean"; nightly testing run pass. ------------- Commit messages: - Backport a6e34b3d1c6e2e278fe2d26d7e9028898a1c01b6 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/216/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=216&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262829 Stats: 20 lines in 1 file changed: 13 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk13u-dev/pull/216 From yan at openjdk.java.net Wed May 19 07:39:11 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 07:39:11 GMT Subject: [jdk13u-dev] Integrated: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() In-Reply-To: References: Message-ID: <3n8ECxExw1vIisZ2yxbDhLvXWULcS1ZgxKufnXo_fVc=.aacb2625-8527-4cde-8839-59a35c4286e7@github.com> On Wed, 19 May 2021 07:29:30 GMT, Yuri Nesterenko wrote: > I'd like to port a fix for this crash here, too. Skara says "clean"; nightly testing run pass. This pull request has now been integrated. Changeset: 23aded5c Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/23aded5cea9113a53f99bc57db0944184a0ccea1 Stats: 20 lines in 1 file changed: 13 ins; 0 del; 7 mod 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() Backport-of: a6e34b3d1c6e2e278fe2d26d7e9028898a1c01b6 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/216 From yan at openjdk.java.net Wed May 19 08:04:47 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 08:04:47 GMT Subject: [jdk15u-dev] RFR: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() Message-ID: This crash fix should be ported here. Skara says "clean", and it is. ------------- Commit messages: - Backport a6e34b3d1c6e2e278fe2d26d7e9028898a1c01b6 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/61/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=61&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262829 Stats: 20 lines in 1 file changed: 13 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk15u-dev/pull/61 From yan at openjdk.java.net Wed May 19 08:08:59 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 08:08:59 GMT Subject: [jdk15u-dev] Integrated: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() In-Reply-To: References: Message-ID: On Wed, 19 May 2021 07:57:27 GMT, Yuri Nesterenko wrote: > This crash fix should be ported here. Skara says "clean", and it is. This pull request has now been integrated. Changeset: 31a8f04b Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/31a8f04bad9d8ad32012dfcb375bc04dcf4638b9 Stats: 20 lines in 1 file changed: 13 ins; 0 del; 7 mod 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() Backport-of: a6e34b3d1c6e2e278fe2d26d7e9028898a1c01b6 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/61 From evergizova at openjdk.java.net Wed May 19 08:31:44 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 19 May 2021 08:31:44 GMT Subject: [jdk15u-dev] Integrated: 8261022: Fix incorrect result of Math.abs() with char type In-Reply-To: References: Message-ID: On Tue, 18 May 2021 12:39:46 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8261022 to 15u for parity with 11u. > The patch applies cleanly, but requires a modification due to absence of VectorNode::is_shift_opcode in 15u (JDK-8257625 is not in 15u), replaced by similar VectorNode::is_shift. > Tested with tier1; new test fails without the patch, passes with it. This pull request has now been integrated. Changeset: 2a1129e7 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk15u-dev/commit/2a1129e7951eb0652e9e5237099b4d27951d89be Stats: 77 lines in 2 files changed: 66 ins; 1 del; 10 mod 8261022: Fix incorrect result of Math.abs() with char type Reviewed-by: yan Backport-of: 7a2db858e0e81f2ba17c3554386bb6a833318b3d ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/60 From goetz.lindenmaier at sap.com Wed May 19 10:10:07 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 19 May 2021 10:10:07 +0000 Subject: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" In-Reply-To: References: Message-ID: Hi Martin, This looks good to me. The adaption makes sense. Best regards, Goetz. From: security-dev On Behalf Of Doerr, Martin Sent: Dienstag, 18. Mai 2021 17:03 To: jdk-updates-dev at openjdk.java.net; security-dev Subject: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" Hi, JDK-8266293 is backported to 11.0.12-oracle. The included test shows that the fix is required in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8266293 Original change: https://git.openjdk.java.net/jdk/commit/04f71126479f9c39aa71e8aebe7196d72fc16796 It applies almost cleanly. Only the bug id addition in the test had to get done manually. However, the new code needs an adaptation because JDK11u doesn't contain KnownOIDs. One of the original author's comments says: "Backporters might need to check case-insensitive equality to both "PBEWithMD5AndDES" and "1.2.840.113549.1.5.3" because both the algorithm name and OID can be specified through the system property." I've followed this suggestion directly. It should also be possible to do something tricky with AlgorithmId.pbeWithMD5AndDES_oid, but that seems to be more error-prone, so that is not my first choice for a backport. 11u backport: http://cr.openjdk.java.net/~mdoerr/8266293_keyprotection_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Wed May 19 10:17:24 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 19 May 2021 10:17:24 +0000 Subject: AW: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" In-Reply-To: References: , Message-ID: Hi G?tz, thank you for the review! Best regards, Martin Von: Lindenmaier, Goetz Datum: Mittwoch, 19. Mai 2021 um 12:10 An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev Betreff: RE: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" Hi Martin, This looks good to me. The adaption makes sense. Best regards, Goetz. From: security-dev On Behalf Of Doerr, Martin Sent: Dienstag, 18. Mai 2021 17:03 To: jdk-updates-dev at openjdk.java.net; security-dev Subject: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" Hi, JDK-8266293 is backported to 11.0.12-oracle. The included test shows that the fix is required in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8266293 Original change: https://git.openjdk.java.net/jdk/commit/04f71126479f9c39aa71e8aebe7196d72fc16796 It applies almost cleanly. Only the bug id addition in the test had to get done manually. However, the new code needs an adaptation because JDK11u doesn't contain KnownOIDs. One of the original author?s comments says: "Backporters might need to check case-insensitive equality to both "PBEWithMD5AndDES" and "1.2.840.113549.1.5.3" because both the algorithm name and OID can be specified through the system property." I've followed this suggestion directly. It should also be possible to do something tricky with AlgorithmId.pbeWithMD5AndDES_oid, but that seems to be more error-prone, so that is not my first choice for a backport. 11u backport: http://cr.openjdk.java.net/~mdoerr/8266293_keyprotection_11u/webrev.00/ Please review. Best regards, Martin From yan at openjdk.java.net Wed May 19 11:35:53 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 11:35:53 GMT Subject: [jdk13u-dev] Integrated: 8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version Message-ID: The change should be backported to 13u too, to keep it up to date. Applies cleanly, test do pass. ------------- Commit messages: - Backport e5e24ad08091b1b256cbc064320766b24036daf0 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/217/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=217&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241082 Stats: 25 lines in 3 files changed: 16 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/217.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/217/head:pull/217 PR: https://git.openjdk.java.net/jdk13u-dev/pull/217 From yan at openjdk.java.net Wed May 19 11:35:54 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 11:35:54 GMT Subject: [jdk13u-dev] Integrated: 8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version In-Reply-To: References: Message-ID: <7Wggd6TSu3YWFkgWn8ZTKsNI11arxOMgva_HmyqoD_Y=.4e4c8833-61f0-4433-b99d-6f4a068bb8fe@github.com> On Wed, 19 May 2021 11:22:39 GMT, Yuri Nesterenko wrote: > The change should be backported to 13u too, to keep it up to date. Applies cleanly, test do pass. This pull request has now been integrated. Changeset: ab400f76 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/ab400f766334920465ff1c112c6472a7e124a834 Stats: 25 lines in 3 files changed: 16 ins; 3 del; 6 mod 8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version Backport-of: e5e24ad08091b1b256cbc064320766b24036daf0 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/217 From yan at openjdk.java.net Wed May 19 12:04:45 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 12:04:45 GMT Subject: [jdk13u-dev] RFR: 8242010: Update IANA Language Subtag Registry to Version 2020-04-01 Message-ID: should be backported for consistency. Applies cleanly; tests do pass. ------------- Commit messages: - Backport 51a5e9ca3ce53ff75be4eb0aed2d55c109cf5094 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/218/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=218&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242010 Stats: 296 lines in 5 files changed: 259 ins; 7 del; 30 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/218.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/218/head:pull/218 PR: https://git.openjdk.java.net/jdk13u-dev/pull/218 From yan at openjdk.java.net Wed May 19 12:17:51 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 12:17:51 GMT Subject: [jdk13u-dev] Integrated: 8242010: Update IANA Language Subtag Registry to Version 2020-04-01 In-Reply-To: References: Message-ID: <-6DsbbCq9nBE9PjUakZKKlHFPtLOFY6oPH0LmAQTBHE=.f3bcff6c-4871-4cf8-a513-5a54964cd61c@github.com> On Wed, 19 May 2021 11:57:09 GMT, Yuri Nesterenko wrote: > should be backported for consistency. Applies cleanly; tests do pass. This pull request has now been integrated. Changeset: 9e591146 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/9e591146898c596b90071e5db66f64b08a73ca82 Stats: 296 lines in 5 files changed: 259 ins; 7 del; 30 mod 8242010: Update IANA Language Subtag Registry to Version 2020-04-01 Backport-of: 51a5e9ca3ce53ff75be4eb0aed2d55c109cf5094 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/218 From yan at openjdk.java.net Wed May 19 12:54:06 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 12:54:06 GMT Subject: [jdk13u-dev] Integrated: 8247432: Update IANA Language Subtag Registry to Version 2020-09-29 Message-ID: <_i-c8Ur9ppnvHAYAy0hFzjkv0OxvQu-szQ6K4fLgOC8=.4a69ee36-2630-4b07-b9af-d607e1f3eb54@github.com> should be ported here, too, after 8241082 and 8242010. Applies cleanly. ------------- Commit messages: - Backport ae0ca743f5646a5312566a6a65ec8929fca4b372 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/219/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=219&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247432 Stats: 52 lines in 2 files changed: 44 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/219.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/219/head:pull/219 PR: https://git.openjdk.java.net/jdk13u-dev/pull/219 From yan at openjdk.java.net Wed May 19 12:54:07 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 19 May 2021 12:54:07 GMT Subject: [jdk13u-dev] Integrated: 8247432: Update IANA Language Subtag Registry to Version 2020-09-29 In-Reply-To: <_i-c8Ur9ppnvHAYAy0hFzjkv0OxvQu-szQ6K4fLgOC8=.4a69ee36-2630-4b07-b9af-d607e1f3eb54@github.com> References: <_i-c8Ur9ppnvHAYAy0hFzjkv0OxvQu-szQ6K4fLgOC8=.4a69ee36-2630-4b07-b9af-d607e1f3eb54@github.com> Message-ID: On Wed, 19 May 2021 12:43:54 GMT, Yuri Nesterenko wrote: > should be ported here, too, after 8241082 and 8242010. Applies cleanly. This pull request has now been integrated. Changeset: 35a16464 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/35a1646413541efd76aff4efd5a782ee1cf3c4a5 Stats: 52 lines in 2 files changed: 44 ins; 5 del; 3 mod 8247432: Update IANA Language Subtag Registry to Version 2020-09-29 Backport-of: ae0ca743f5646a5312566a6a65ec8929fca4b372 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/219 From dcherepanov at openjdk.java.net Wed May 19 13:46:09 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 19 May 2021 13:46:09 GMT Subject: [jdk13u-dev] Integrated: 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 In-Reply-To: References: Message-ID: <1ssjjIYtMaGri8BS2m_nGorJYdvh43ahNGQsHNRAXqg=.e8fd3011-9c85-45e9-b7fc-f71e7261542d@github.com> On Mon, 17 May 2021 16:38:26 GMT, Dmitry Cherepanov wrote: > 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 This pull request has now been integrated. Changeset: fd68584c Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/fd68584c37e7fb28ef570edc3dbe0a25b913b520 Stats: 229 lines in 12 files changed: 167 ins; 18 del; 44 mod 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 For CK_GCM_PARAMS, try the spec definition first before falling back to the header file definition Backport-of: 381e90eb6bd62416a07cf883c1588ade3287d140 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/214 From florian.david at datadoghq.com Wed May 19 14:25:51 2021 From: florian.david at datadoghq.com (Florian David) Date: Wed, 19 May 2021 16:25:51 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: Hi, I'm re-sending this email since Martin Doerr didn't receive it and found it with the mailing list archives, so maybe others miss it. Martin reported that he doesn't see test errors anymore with this webrev. Hi all, Please find an update to the backport. Comments related to https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005880.html where the previous patch has broken the 11u build have been taken into account: - check_java_thread_in_native is replaced by check_java_thread_in_vm in ObjectSampleCheckpoint::on_rotation - ThreadInVMfromNative transition(thread) is removed. That check is part of the original PR for JDK17 but since some code in JFR was moved from JNI (in 11) to native in 16, this check is not valid here. Build and Tests: - Linux release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". - Windows release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". The run-test-tier1 test suite did not complete entirely because of some issues with paths being too long and "vswhere.exe" not able to be run by the test on my machine. I would feel more confident (especially Windows was broken by the previous backport) if a maintainer could run the test suite on Windows. The "jtreg:jdk/jfr/" test suite ran successfully. Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ Original PR: https://github.com/openjdk/jdk/pull/2780 Thanks, Florian DAVID On Fri, May 7, 2021 at 6:34 PM Florian David wrote: > Hi all, > > Please find an update to the backport. Comments related to > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005880.html > > where the previous patch has broken the 11u build have been taken into > account: > > - check_java_thread_in_native is replaced by check_java_thread_in_vm > in ObjectSampleCheckpoint::on_rotation > - ThreadInVMfromNative transition(thread) is removed. That check is part > of the original PR for JDK17 but since > some code in JFR was moved from JNI (in 11) to native in 16, this check is > not valid here. > > Build and Tests: > - Linux release and fastdebug builds. Tested with make run-test-tier1 && > make run-test TEST="jtreg:jdk/jfr/". > - Windows release and fastdebug builds. Tested with make run-test-tier1 && > make run-test TEST="jtreg:jdk/jfr/". The > run-test-tier1 test suite did not complete entirely because of some issues > with paths being too long and > "vswhere.exe" not able to be run by the test on my machine. I would feel > more confident (especially Windows was broken > by the previous backport) if a maintainer could run the test suite on > Windows. The "jtreg:jdk/jfr/" test suite ran successfully. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ > Original PR: https://github.com/openjdk/jdk/pull/2780 > > Thanks, > Florian DAVID > > On Mon, Apr 12, 2021 at 10:38 AM Jaroslav Bachor?k < > jaroslav.bachorik at datadoghq.com> wrote: > >> 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 dcherepanov at openjdk.java.net Wed May 19 15:09:19 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 19 May 2021 15:09:19 GMT Subject: [jdk15u-dev] RFR: 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Message-ID: 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files ------------- Commit messages: - Backport 7d8985243d472db19dd416a5d9fe116737d3b327 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/62/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=62&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244154 Stats: 1818 lines in 7 files changed: 1215 ins; 69 del; 534 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/62.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/62/head:pull/62 PR: https://git.openjdk.java.net/jdk15u-dev/pull/62 From dcherepanov at openjdk.java.net Wed May 19 15:10:56 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 19 May 2021 15:10:56 GMT Subject: [jdk13u-dev] RFR: 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Message-ID: <8jQEAB2KL6EkAAkXJ2kQL7zJluxXWYQbOO_Sr7-uQvQ=.bc492c24-d8da-4192-b6f4-a5a36e040d31@github.com> 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files ------------- Commit messages: - Backport 7d8985243d472db19dd416a5d9fe116737d3b327 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/220/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=220&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244154 Stats: 1818 lines in 7 files changed: 1215 ins; 69 del; 534 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/220.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/220/head:pull/220 PR: https://git.openjdk.java.net/jdk13u-dev/pull/220 From buddyliao at tencent.com Thu May 6 07:45:09 2021 From: buddyliao at tencent.com (=?utf-8?B?YnVkZHlsaWFvKOW7luW9rCk=?=) Date: Thu, 6 May 2021 07:45:09 +0000 Subject: =?utf-8?B?Rlc6IFsxMXVdIFJGUiA4MjY2MzUyOiBBZGQgcGFyYWxsZWwgaGVhcCBpdGVy?= =?utf-8?B?YXRpb24gZm9yIGptYXAg4oCTaGlzdG8=?= In-Reply-To: <51C22C0C-781C-41FD-9F5C-FFF58BC05353@tencent.com> References: <51C22C0C-781C-41FD-9F5C-FFF58BC05353@tencent.com> Message-ID: <6BEC0815-C4EC-4B34-8195-407C50E641FE@tencent.com> Thank you for Alan?s reminder, add jdk-updates-dev Buddy ???: "buddyliao(??)" ??: 2021?5?6? ??? ??11:48 ???: "core-libs-dev at openjdk.java.net" ??: [11u] RFR 8266352: Add parallel heap iteration for jmap ?histo Dear all, Would you help me to review the following backport from jdk-master? Original bug: https://bugs.openjdk.java.net/browse/JDK-8215624 http://hg.openjdk.java.net/jdk/jdk/rev/b1afb7c82d59 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8266353 Original patch does not apply cleanly to 11u, because jmap command parameter is different between each other, and the code structure has little changed. Notably, I had to change the src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java to make it matches 11u-dev 11u webrev: https://cr.openjdk.java.net/~lzang/BuddyLiao/8266352/webrev01/ Testing: x86_64 build, affected tests, tier1 Thanks, -Buddy From buddyliao at tencent.com Thu May 6 07:46:07 2021 From: buddyliao at tencent.com (=?utf-8?B?YnVkZHlsaWFvKOW7luW9rCk=?=) Date: Thu, 6 May 2021 07:46:07 +0000 Subject: FW: [11u] RFR 8266354: JDK-8215624 causes assert(worker_id < _n_workers) failed: Invalid worker_id In-Reply-To: <1CA90AA9-7438-42F4-A92C-E020B20C9915@tencent.com> References: <1CA90AA9-7438-42F4-A92C-E020B20C9915@tencent.com> Message-ID: Thank you for Alan?s reminder, add jdk-updates-dev Buddy ???: "buddyliao(??)" ??: 2021?5?6? ??? ??11:56 ???: "core-libs-dev at openjdk.java.net" ??: [11u] RFR 8266354: JDK-8215624 causes assert(worker_id < _n_workers) failed: Invalid worker_id Dear all, Would you help me to review the following backport from jdk-master? This backport is bugfix for the prefer backport https://bugs.openjdk.java.net/browse/JDK-8266352 Original bug: https://bugs.openjdk.java.net/browse/JDK-8251570 https://hg.openjdk.java.net/jdk/jdk/rev/dd827a012e43 Original patch does not apply cleanly to 11u, since the code structure has changed. Notably, I had to make it fit with 11u-dev. 11u webrev: https://cr.openjdk.java.net/~lzang/BuddyLiao/8266354/webrev01/ Testing: x86_64 build, affected tests, tier1 Thanks, -Buddy From adinn at redhat.com Thu May 13 09:32:17 2021 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 13 May 2021 10:32:17 +0100 Subject: [External] : AW: Resigning as PowerPC/AIX Port Project Lead In-Reply-To: <5addb455-5353-e833-c8f7-f35e72f319dc@oracle.com> References: <5addb455-5353-e833-c8f7-f35e72f319dc@oracle.com> Message-ID: Hi Volker, Dalibor et al, I'd very much like to second and amplify Dalibor's message. Integration of the PowerPC/AIX Port into OpenJDK paved the way for subsequent merging of the AArch64 port. The smoothness of that latter integration is clear evidence of how good and how thorough a job Volker and his team did. Many thanks for all your hard work, Volker! regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 12/05/2021 16:03, Dalibor Topic wrote: > Hi Volker & team, > > Thank you all for your efforts on the port, and in particular to Volker > for having stepped up as Project Lead and having contributed a lot of > effort to make the PowerPC/AIX Port the exemplary porting Project within > the Porters Group in terms of its documentation, JEP, and integration > into mainline that all the subsequent ports could and did heavily > benefit from. > > In my capacity as the Porters Group Lead, I'll be happy to appoint > Martin as the new Project Lead, and to wish him ongoing success. > > I'll send a separate e-mail to that effect to the ppc-aix-port-dev > mailing list, and let the Registrar know about the change. > > cheers, > dalibor topic > > On 12.05.2021 16:00, Doerr, Martin wrote: >> Hi Volker and G?tz, >> >> thank you for all the work you have done regarding the PowerPC/AIX Port! >> >> The job was often tough, but you never gave up. It was a great >> achievement which I?d like to emphasize again. >> >> I appreciate the nomination as new lead and I?ll be glad to accept. >> I?m looking forward to continue the collaboration with IBM/RedHat and >> Oracle. >> >> Best regards, >> >> Martin >> >> *Von: *Lindenmaier, Goetz >> *Datum: *Mittwoch, 12. Mai 2021 um 15:40 >> *An: *Volker Simonis , ppc-aix-port-dev >> , porters-dev at openjdk.java.net >> , discuss at openjdk.java.net >> , Doerr, Martin , >> jdk-dev , jdk-updates-dev at openjdk.java.net >> , jdk8u-dev at openjdk.java.net >> >> *Cc: *Dalibor Topic , 'Tim Ellison' >> >> *Betreff: *RE: Resigning as PowerPC/AIX Port Project Lead >> >> Hi >> >> Volker, many thanks for initiating and driving the ppc/aix >> port up to now! >> >> And yes, SAP proposes Martin Doerr[1] as new lead of the >> PowerPC/AIX Port Project [2][3][4]. >> >> In the future, SAP will concentrate on supporting >> linuxppc64le (little endian) in jdk/jdk, jdk17 and jdk11. I.e., SAP >> will assure best quality by continuously building and testing these >> repositories.? IBM will take the responsibility of the AIX port. >> >> The linuxppc64 (big endian) port will be discontinued [5] as it >> is nowadays superseded by the little endian port. SAP will also >> terminate its testing efforts of the ppc platforms in OpenJDK 8u [6]. >> IBM will continue the support of linuxppc64 (le, be) in 8 and 11. >> >> Naturally, SAP will always respond to issues raised against the >> linuxppc64, linuxppc64le or aixppc64 ports in any jdk version >> with appropriate effort. >> >> Best regards, >> Goetz and Tim >> >> [1] http://openjdk.java.net/census#mdoerr >> >> [2] http://openjdk.java.net/census#ppc-aix-port >> >> [3] http://openjdk.java.net/projects/ppc-aix-port/ >> >> [4] https://wiki.openjdk.java.net/display/PPCAIXPort >> >> [5] The last releases where SAP tests linuxppc64 will be 11.0.12 and 17. >> [6] The last release of 8 where SAP tests linuxppc64 and aix will be >> ???? the July 2021 security update. >> >> >> >> >> ?> -----Original Message----- >> ?> From: Volker Simonis >> ?> Sent: Wednesday, May 12, 2021 3:26 PM >> ?> To: ppc-aix-port-dev ; porters- >> ?> dev at openjdk.java.net; discuss at openjdk.java.net >> ?> Cc: Dalibor Topic ; Lindenmaier, Goetz >> ?> >> ?> Subject: Resigning as PowerPC/AIX Port Project Lead >> ?> >> ?> I hereby resign as PowerPC/AIX Port Project Lead. >> ?> >> ?> The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. >> ?> It was the first externally contributed, full OpenJDK port and paved >> ?> the way for subsequent porting projects like aarch64 and s390. It was >> ?> also the beginning of a fruitful cooperation between SAP, IBM and >> ?> Oracle who have all contributed to the success of this project. >> ?> >> ?> While PowerPC and especially AIX can still be seen as "niche" >> ?> platforms, the presence of the PowerPC/AIX Port in the OpenJDK main >> ?> line has helped to considerably improve and streamline the whole code >> ?> base. I hope this mutually beneficial collaboration will continue in >> ?> the future and would like to propose Martin Doerr (mdoerr [3]) as new >> ?> Project Lead. >> ?> >> ?> Martin is a true PowerPC/Itanium expert and a real memory model >> ?> wizard. He's a long term member of the SAP JVM team, an OpenJDK >> ?> Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. >> ?> >> ?> In the end, and according to the OpenJDK Bylaws, the Lead of the >> ?> sponsoring group (Dalibor Topic from the Porters Group) needs to >> ?> assign a new Project Lead [4]. I for myself can't think of any better >> ?> candidate and warmly recommend Martin for this position. >> ?> >> ?> Thank you and best regards, >> ?> Volker >> ?> >> ?> [1] https://wiki.openjdk.java.net/display/PPCAIXPort >> >> ?> [2] http://mail.openjdk.java.net/pipermail/announce/2012- >> >> ?> May/000125.html >> ?> [3] http://openjdk.java.net/census#mdoerr >> >> ?> [4] http://openjdk.java.net/bylaws#project-lead >> >> > From kevin.rushforth at oracle.com Wed May 5 21:28:51 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 5 May 2021 14:28:51 -0700 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: <514f2310-3d79-eea4-a19c-4cfe113221a9@oracle.com> No, the Skara tooling will squash them into a single commit. You can still list all bugs in that commit, and it will create a backport record for each, but if they are in a single PR, then there will be one commit pushed to the repo. -- Kevin On 5/5/2021 2:15 PM, Langer, Christoph wrote: > Hi, > > just had a quick look at the PR. Since it contains several changes which are backports of a JBS bug item each, we should talk to the Skara folks on whether it's possible to merge such PRs somehow without squashing and with creating backports items in JBS for each change. > > Best regards > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Bernhard Urban-Forster >> Sent: Freitag, 30. April 2021 23:10 >> To: aph ; 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 > aarch64 at microsoft.com> >> Subject: Re: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u >> >> 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. >> > ww.redhat.com%2F&data=04%7C01%7Cbeurba%40microsoft.com%7C7 >> 5b981562be84529033908d8efad0888%7C72f988bf86f141af91ab2d7cd011db47 >> %7C1%7C0%7C637522873741905341%7CUnknown%7CTWFpbGZsb3d8eyJWIj >> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1 >> 000&sdata=gq599kym0%2BA8M%2BYjHUKR84Mw5od3vS2dLZ5PfjI1%2F >> Ig%3D&reserved=0> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkey >> base.io%2Fandrewhaley&data=04%7C01%7Cbeurba%40microsoft.com >> %7C75b981562be84529033908d8efad0888%7C72f988bf86f141af91ab2d7cd01 >> 1db47%7C1%7C0%7C637522873741905341%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 >> D%7C1000&sdata=I0HxiyMAwKx1sYxvy8%2Fs8arCVLjO0g2LFDOJKGkMP >> ak%3D&reserved=0 >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Wed May 12 13:40:02 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 12 May 2021 13:40:02 +0000 Subject: Resigning as PowerPC/AIX Port Project Lead In-Reply-To: References: Message-ID: Hi Volker, many thanks for initiating and driving the ppc/aix port up to now! And yes, SAP proposes Martin Doerr[1] as new lead of the PowerPC/AIX Port Project [2][3][4]. In the future, SAP will concentrate on supporting linuxppc64le (little endian) in jdk/jdk, jdk17 and jdk11. I.e., SAP will assure best quality by continuously building and testing these repositories. IBM will take the responsibility of the AIX port. The linuxppc64 (big endian) port will be discontinued [5] as it is nowadays superseded by the little endian port. SAP will also terminate its testing efforts of the ppc platforms in OpenJDK 8u [6]. IBM will continue the support of linuxppc64 (le, be) in 8 and 11. Naturally, SAP will always respond to issues raised against the linuxppc64, linuxppc64le or aixppc64 ports in any jdk version with appropriate effort. Best regards, Goetz and Tim [1] http://openjdk.java.net/census#mdoerr [2] http://openjdk.java.net/census#ppc-aix-port [3] http://openjdk.java.net/projects/ppc-aix-port/ [4] https://wiki.openjdk.java.net/display/PPCAIXPort [5] The last releases where SAP tests linuxppc64 will be 11.0.12 and 17. [6] The last release of 8 where SAP tests linuxppc64 and aix will be the July 2021 security update. > -----Original Message----- > From: Volker Simonis > Sent: Wednesday, May 12, 2021 3:26 PM > To: ppc-aix-port-dev ; porters- > dev at openjdk.java.net; discuss at openjdk.java.net > Cc: Dalibor Topic ; Lindenmaier, Goetz > > Subject: Resigning as PowerPC/AIX Port Project Lead > > I hereby resign as PowerPC/AIX Port Project Lead. > > The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. > It was the first externally contributed, full OpenJDK port and paved > the way for subsequent porting projects like aarch64 and s390. It was > also the beginning of a fruitful cooperation between SAP, IBM and > Oracle who have all contributed to the success of this project. > > While PowerPC and especially AIX can still be seen as "niche" > platforms, the presence of the PowerPC/AIX Port in the OpenJDK main > line has helped to considerably improve and streamline the whole code > base. I hope this mutually beneficial collaboration will continue in > the future and would like to propose Martin Doerr (mdoerr [3]) as new > Project Lead. > > Martin is a true PowerPC/Itanium expert and a real memory model > wizard. He's a long term member of the SAP JVM team, an OpenJDK > Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. > > In the end, and according to the OpenJDK Bylaws, the Lead of the > sponsoring group (Dalibor Topic from the Porters Group) needs to > assign a new Project Lead [4]. I for myself can't think of any better > candidate and warmly recommend Martin for this position. > > Thank you and best regards, > Volker > > [1] https://wiki.openjdk.java.net/display/PPCAIXPort > [2] http://mail.openjdk.java.net/pipermail/announce/2012- > May/000125.html > [3] http://openjdk.java.net/census#mdoerr > [4] http://openjdk.java.net/bylaws#project-lead From martin.doerr at sap.com Wed May 12 14:00:37 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 May 2021 14:00:37 +0000 Subject: AW: Resigning as PowerPC/AIX Port Project Lead In-Reply-To: References: , Message-ID: Hi Volker and G?tz, thank you for all the work you have done regarding the PowerPC/AIX Port! The job was often tough, but you never gave up. It was a great achievement which I?d like to emphasize again. I appreciate the nomination as new lead and I?ll be glad to accept. I?m looking forward to continue the collaboration with IBM/RedHat and Oracle. Best regards, Martin Von: Lindenmaier, Goetz Datum: Mittwoch, 12. Mai 2021 um 15:40 An: Volker Simonis , ppc-aix-port-dev , porters-dev at openjdk.java.net , discuss at openjdk.java.net , Doerr, Martin , jdk-dev , jdk-updates-dev at openjdk.java.net , jdk8u-dev at openjdk.java.net Cc: Dalibor Topic , 'Tim Ellison' Betreff: RE: Resigning as PowerPC/AIX Port Project Lead Hi Volker, many thanks for initiating and driving the ppc/aix port up to now! And yes, SAP proposes Martin Doerr[1] as new lead of the PowerPC/AIX Port Project [2][3][4]. In the future, SAP will concentrate on supporting linuxppc64le (little endian) in jdk/jdk, jdk17 and jdk11. I.e., SAP will assure best quality by continuously building and testing these repositories. IBM will take the responsibility of the AIX port. The linuxppc64 (big endian) port will be discontinued [5] as it is nowadays superseded by the little endian port. SAP will also terminate its testing efforts of the ppc platforms in OpenJDK 8u [6]. IBM will continue the support of linuxppc64 (le, be) in 8 and 11. Naturally, SAP will always respond to issues raised against the linuxppc64, linuxppc64le or aixppc64 ports in any jdk version with appropriate effort. Best regards, Goetz and Tim [1] http://openjdk.java.net/census#mdoerr [2] http://openjdk.java.net/census#ppc-aix-port [3] http://openjdk.java.net/projects/ppc-aix-port/ [4] https://wiki.openjdk.java.net/display/PPCAIXPort [5] The last releases where SAP tests linuxppc64 will be 11.0.12 and 17. [6] The last release of 8 where SAP tests linuxppc64 and aix will be the July 2021 security update. > -----Original Message----- > From: Volker Simonis > Sent: Wednesday, May 12, 2021 3:26 PM > To: ppc-aix-port-dev ; porters- > dev at openjdk.java.net; discuss at openjdk.java.net > Cc: Dalibor Topic ; Lindenmaier, Goetz > > Subject: Resigning as PowerPC/AIX Port Project Lead > > I hereby resign as PowerPC/AIX Port Project Lead. > > The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. > It was the first externally contributed, full OpenJDK port and paved > the way for subsequent porting projects like aarch64 and s390. It was > also the beginning of a fruitful cooperation between SAP, IBM and > Oracle who have all contributed to the success of this project. > > While PowerPC and especially AIX can still be seen as "niche" > platforms, the presence of the PowerPC/AIX Port in the OpenJDK main > line has helped to considerably improve and streamline the whole code > base. I hope this mutually beneficial collaboration will continue in > the future and would like to propose Martin Doerr (mdoerr [3]) as new > Project Lead. > > Martin is a true PowerPC/Itanium expert and a real memory model > wizard. He's a long term member of the SAP JVM team, an OpenJDK > Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. > > In the end, and according to the OpenJDK Bylaws, the Lead of the > sponsoring group (Dalibor Topic from the Porters Group) needs to > assign a new Project Lead [4]. I for myself can't think of any better > candidate and warmly recommend Martin for this position. > > Thank you and best regards, > Volker > > [1] https://wiki.openjdk.java.net/display/PPCAIXPort > [2] http://mail.openjdk.java.net/pipermail/announce/2012- > May/000125.html > [3] http://openjdk.java.net/census#mdoerr > [4] http://openjdk.java.net/bylaws#project-lead From dalibor.topic at oracle.com Wed May 12 15:03:19 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 12 May 2021 17:03:19 +0200 Subject: [External] : AW: Resigning as PowerPC/AIX Port Project Lead In-Reply-To: References: Message-ID: <5addb455-5353-e833-c8f7-f35e72f319dc@oracle.com> Hi Volker & team, Thank you all for your efforts on the port, and in particular to Volker for having stepped up as Project Lead and having contributed a lot of effort to make the PowerPC/AIX Port the exemplary porting Project within the Porters Group in terms of its documentation, JEP, and integration into mainline that all the subsequent ports could and did heavily benefit from. In my capacity as the Porters Group Lead, I'll be happy to appoint Martin as the new Project Lead, and to wish him ongoing success. I'll send a separate e-mail to that effect to the ppc-aix-port-dev mailing list, and let the Registrar know about the change. cheers, dalibor topic On 12.05.2021 16:00, Doerr, Martin wrote: > Hi Volker and G?tz, > > thank you for all the work you have done regarding the PowerPC/AIX Port! > > The job was often tough, but you never gave up. It was a great > achievement which I?d like to emphasize again. > > I appreciate the nomination as new lead and I?ll be glad to accept. I?m > looking forward to continue the collaboration with IBM/RedHat and Oracle. > > Best regards, > > Martin > > *Von: *Lindenmaier, Goetz > *Datum: *Mittwoch, 12. Mai 2021 um 15:40 > *An: *Volker Simonis , ppc-aix-port-dev > , porters-dev at openjdk.java.net > , discuss at openjdk.java.net > , Doerr, Martin , > jdk-dev , jdk-updates-dev at openjdk.java.net > , jdk8u-dev at openjdk.java.net > > *Cc: *Dalibor Topic , 'Tim Ellison' > > *Betreff: *RE: Resigning as PowerPC/AIX Port Project Lead > > Hi > > Volker, many thanks for initiating and driving the ppc/aix > port up to now! > > And yes, SAP proposes Martin Doerr[1] as new lead of the > PowerPC/AIX Port Project [2][3][4]. > > In the future, SAP will concentrate on supporting > linuxppc64le (little endian) in jdk/jdk, jdk17 and jdk11. I.e., SAP > will assure best quality by continuously building and testing these > repositories.? IBM will take the responsibility of the AIX port. > > The linuxppc64 (big endian) port will be discontinued [5] as it > is nowadays superseded by the little endian port. SAP will also > terminate its testing efforts of the ppc platforms in OpenJDK 8u [6]. > IBM will continue the support of linuxppc64 (le, be) in 8 and 11. > > Naturally, SAP will always respond to issues raised against the > linuxppc64, linuxppc64le or aixppc64 ports in any jdk version > with appropriate effort. > > Best regards, > Goetz and Tim > > [1] http://openjdk.java.net/census#mdoerr > > [2] http://openjdk.java.net/census#ppc-aix-port > > [3] http://openjdk.java.net/projects/ppc-aix-port/ > > [4] https://wiki.openjdk.java.net/display/PPCAIXPort > > [5] The last releases where SAP tests linuxppc64 will be 11.0.12 and 17. > [6] The last release of 8 where SAP tests linuxppc64 and aix will be > ??? the July 2021 security update. > > > > > > -----Original Message----- > > From: Volker Simonis > > Sent: Wednesday, May 12, 2021 3:26 PM > > To: ppc-aix-port-dev ; porters- > > dev at openjdk.java.net; discuss at openjdk.java.net > > Cc: Dalibor Topic ; Lindenmaier, Goetz > > > > Subject: Resigning as PowerPC/AIX Port Project Lead > > > > I hereby resign as PowerPC/AIX Port Project Lead. > > > > The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. > > It was the first externally contributed, full OpenJDK port and paved > > the way for subsequent porting projects like aarch64 and s390. It was > > also the beginning of a fruitful cooperation between SAP, IBM and > > Oracle who have all contributed to the success of this project. > > > > While PowerPC and especially AIX can still be seen as "niche" > > platforms, the presence of the PowerPC/AIX Port in the OpenJDK main > > line has helped to considerably improve and streamline the whole code > > base. I hope this mutually beneficial collaboration will continue in > > the future and would like to propose Martin Doerr (mdoerr [3]) as new > > Project Lead. > > > > Martin is a true PowerPC/Itanium expert and a real memory model > > wizard. He's a long term member of the SAP JVM team, an OpenJDK > > Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. > > > > In the end, and according to the OpenJDK Bylaws, the Lead of the > > sponsoring group (Dalibor Topic from the Porters Group) needs to > > assign a new Project Lead [4]. I for myself can't think of any better > > candidate and warmly recommend Martin for this position. > > > > Thank you and best regards, > > Volker > > > > [1] https://wiki.openjdk.java.net/display/PPCAIXPort > > > [2] http://mail.openjdk.java.net/pipermail/announce/2012- > > > May/000125.html > > [3] http://openjdk.java.net/census#mdoerr > > > [4] http://openjdk.java.net/bylaws#project-lead > > -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From vkempik at openjdk.java.net Wed May 19 18:22:36 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Wed, 19 May 2021 18:22:36 GMT Subject: [jdk15u-dev] RFR: 8261395: C1 crash "cannot make java calls from the native compiler" Message-ID: Please review backport of JDK-8261395 to jdk15u-dev Two chunks of instanceKlass.cpp wasn't applyting clean, slight mod were needed. Testcase were adapted for jdk15 in testlibrary related header. Test case fails before patch and passes after. ------------- Commit messages: - Backport e828a939a8155a3b4ab26811a405bb4e4b2b99e8 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/63/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=63&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261395 Stats: 226 lines in 4 files changed: 167 ins; 40 del; 19 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/63.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/63/head:pull/63 PR: https://git.openjdk.java.net/jdk15u-dev/pull/63 From snazarkin at azul.com Wed May 19 18:41:14 2021 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 19 May 2021 18:41:14 +0000 Subject: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: <53640CDE-B41D-4E3E-8861-96C8A54E9C32@azul.com> Checked on arm32: new test fails without patch and passes with the patch > On May 11, 2021, at 09:07, Thomas St?fe wrote: > > Hi, > > I'd like reviews for this downport, please. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 > Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb > Original Review: https://git.openjdk.java.net/jdk/pull/1695 > > This patch does two things: > > 1) On Posix platforms it fixes SafeFetch to work in all threads, not only > in JavaThreads. In non-JavaThreads before this patch it would crash. > > The patch is totally trivial. In the signal handler, when handling > SafeFetch, there was a condition that Thread != NULL and be a JavaThread. > This condition was unnecessary. All SafeFetch handling needs is a valid > context. The Patch moves SafeFetch handling out of the is-JavaThread > condition. > > 2) On Windows we did not have the problem; however there is the > `Handle_Exception` function handling SafeFetch among other things, which > may be called with a non-java thread, but then forcibly casts the Thread* > to JavaThread. > > 11u patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads > > The original patch does not apply, at all. The reason for this is that we > consolidated common functionality of the many cpu+arch signal handlers to > one function, in os_posix.cpp. This happened in JDK16 and I do not want to > backport this cleanup change to 11. For this patch, it means that the > posix-related fixes practically had to be rewritten for each and every > signal handler. Each fix is primitive however, since it just moves > SafeFetch handling around, but every signal handler is a tiny bit different. > > I tested this patch for several weeks in our systems on Linux > ppc/ppcle/x64/s390/aarch64, AIX, Solaris and Mac, no problems surfaced. > > I did not test on 32bit arm. > > Thanks, Thomas From sgehwolf at redhat.com Wed May 19 18:52:56 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 19 May 2021 20:52:56 +0200 Subject: [11u] RFR: 8266929: Unable to use algorithms from 3p providers Message-ID: <057751d07319ebbda5095570823147859b330545.camel@redhat.com> Hi, Please review this regression fix for 11.0.11+9. JDK-8249906 got introduced as part of this update which ended up in code changes which may yield to earlier initialization of AlgorithmId's OID cache. After, JDK-8249906, the initialization of the OID cache might happen at jar file verification time (when signed jars are in play). At that time a reduced set of security providers are available. Since the OID cache is never refreshed, a NoSuchAlgorithmException might be thrown later on when trying to look up an algorithm provided by a third party provider even though the algorithm provider got added to the list of available providers (via Security.addProvider() or via a config file). Bug: https://bugs.openjdk.java.net/browse/JDK-8266929 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266929/jdk11/01/webrev/ The proposed fix adds a hard-coded OID mapping to AlgorithmId.algOID() method so as to avoid initializing the OID cache at jar-file verification time. Adding SHA256WithRSA to that list seems sufficient as the JDK providers seem to be signed with that signature. More info on the bug. With this patch JDK 11u would be back at 11.0.11+8 behaviour. Patch kindly provided by Sean Mullan. Note that a separate bug has been filed for the OID cache not being refreshed: JDK-8267397. This bug affects JDK 17 and JDK 16 as well. Testing: tier1 and :jdk_security. No regressions noted. Passes the reproducer of the bug post-patch (fails before). Thoughts? Thanks, Severin From evergizova at openjdk.java.net Wed May 19 19:02:59 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 19 May 2021 19:02:59 GMT Subject: [jdk13u-dev] RFR: 8243452: JFR: Could not create chunk in repository with over 200 recordings Message-ID: I'd like to backport JDK-8243452 to 13u for parity with 11u. The patch doesn't apply cleanly due to context difference in jdk/jfr/internal/RepositoryChunk.java (JDK-8244463 is not in 13u), reapplied manually. Tested with tier1 and jdk/jfr tests; the test attached to the issue fails without the patch, passes with it. ------------- Commit messages: - Backport 6dd84434934544542137f7b7567158e067e68590 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/221/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=221&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243452 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/221.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/221/head:pull/221 PR: https://git.openjdk.java.net/jdk13u-dev/pull/221 From minqi at openjdk.java.net Wed May 19 20:01:19 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 19 May 2021 20:01:19 GMT Subject: [jdk16u] RFR: 8267345: VM crashes during dumping classlist with -Xshare:dump option Message-ID: Hi, Please review The problem is caused by JDK-8247536: Support for pre-generated java.lang.invoke classes in CDS static archive Usually the dump with an appointed class list file, -XX:SharedClassListFile=, the 'classlist' is collected by pre-run the application with -XX:DumpLoadedClassList, so it is rare case using -Xshare:dump and -XX:DumpLoadedClassList together, though we can do that. It is reproducible by run java -Xshare:dump -XX:DumpLoadedClassList= The problem happened when regenerating lambda form invoker's holder classes, with which the re-generated class stream without a source associated (class is generated on fly). Referencing to NULL source failed. Fix checks if source is valid. Tests: tier1,tier2,tier3,tier4 Thanks Yumin ------------- Commit messages: - 8267345: VM crashes during dumping classlist with -Xshare:dump option Changes: https://git.openjdk.java.net/jdk16u/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=119&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267345 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk16u/pull/119 From iklam at openjdk.java.net Wed May 19 21:15:43 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 19 May 2021 21:15:43 GMT Subject: [jdk16u] RFR: 8267345: VM crashes during dumping classlist with -Xshare:dump option In-Reply-To: References: Message-ID: <-Ryc4lbxv4lVgTKGxWFdULqfNEMsOwfnrXFo46Zj68U=.913d4472-95c6-4f3c-be7e-45ef37b0836f@github.com> On Wed, 19 May 2021 19:46:58 GMT, Yumin Qi wrote: > Hi, Please review > The problem is caused by JDK-8247536: Support for pre-generated java.lang.invoke classes in CDS static archive > Usually the dump with an appointed class list file, -XX:SharedClassListFile=, the 'classlist' is collected by pre-run the application with -XX:DumpLoadedClassList, so it is rare case using -Xshare:dump and -XX:DumpLoadedClassList together, though we can do that. > It is reproducible by run > java -Xshare:dump -XX:DumpLoadedClassList= > The problem happened when regenerating lambda form invoker's holder classes, with which the re-generated class stream without a source associated (class is generated on fly). Referencing to NULL source failed. Fix checks if source is valid. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Changes requested by iklam (Reviewer). src/hotspot/share/oops/instanceKlass.cpp line 4244: > 4242: // These classes can't be loaded from the archive during runtime. > 4243: if (!stream->from_boot_loader_modules_image() && > 4244: (stream->source() == NULL || strncmp(stream->source(), "jrt:", 4) != 0)) { I think the following block on line 4256 should also be changed if (skip && stream->source() != NULL) { tty->print_cr("skip writing class %s from source %s to classlist file", name()->as_C_string(), stream->source()); } else { ------------- PR: https://git.openjdk.java.net/jdk16u/pull/119 From lutkerd at amazon.com Wed May 19 21:47:00 2021 From: lutkerd at amazon.com (Lutker, Dan) Date: Wed, 19 May 2021 21:47:00 +0000 Subject: [11u] RFR: 8266929: Unable to use algorithms from 3p providers In-Reply-To: <057751d07319ebbda5095570823147859b330545.camel@redhat.com> References: <057751d07319ebbda5095570823147859b330545.camel@redhat.com> Message-ID: Hi Severin, All of the algorithms supported by jarsigner should be added, based on the "Supported Algorithms" table on [1] we should have to add SHA256withRSA, SHA384withRSA and SHA512withRSA. -Dan [1] https://docs.oracle.com/en/java/javase/11/tools/jarsigner.html ?On 5/19/21, 11:53 AM, "Severin Gehwolf" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi, Please review this regression fix for 11.0.11+9. JDK-8249906 got introduced as part of this update which ended up in code changes which may yield to earlier initialization of AlgorithmId's OID cache. After, JDK-8249906, the initialization of the OID cache might happen at jar file verification time (when signed jars are in play). At that time a reduced set of security providers are available. Since the OID cache is never refreshed, a NoSuchAlgorithmException might be thrown later on when trying to look up an algorithm provided by a third party provider even though the algorithm provider got added to the list of available providers (via Security.addProvider() or via a config file). Bug: https://bugs.openjdk.java.net/browse/JDK-8266929 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266929/jdk11/01/webrev/ The proposed fix adds a hard-coded OID mapping to AlgorithmId.algOID() method so as to avoid initializing the OID cache at jar-file verification time. Adding SHA256WithRSA to that list seems sufficient as the JDK providers seem to be signed with that signature. More info on the bug. With this patch JDK 11u would be back at 11.0.11+8 behaviour. Patch kindly provided by Sean Mullan. Note that a separate bug has been filed for the OID cache not being refreshed: JDK-8267397. This bug affects JDK 17 and JDK 16 as well. Testing: tier1 and :jdk_security. No regressions noted. Passes the reproducer of the bug post-patch (fails before). Thoughts? Thanks, Severin From minqi at openjdk.java.net Wed May 19 23:25:59 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 19 May 2021 23:25:59 GMT Subject: [jdk16u] RFR: 8267345: VM crashes during dumping classlist with -Xshare:dump option In-Reply-To: <-Ryc4lbxv4lVgTKGxWFdULqfNEMsOwfnrXFo46Zj68U=.913d4472-95c6-4f3c-be7e-45ef37b0836f@github.com> References: <-Ryc4lbxv4lVgTKGxWFdULqfNEMsOwfnrXFo46Zj68U=.913d4472-95c6-4f3c-be7e-45ef37b0836f@github.com> Message-ID: <8FeZjYYPAZ5ze4rp8EeHRqqr3Vx0TPH6iMIu8_MEKsA=.f6ac84df-f20f-4c9a-a27b-3f7476c07c87@github.com> On Wed, 19 May 2021 21:11:50 GMT, Ioi Lam wrote: >> Hi, Please review >> The problem is caused by JDK-8247536: Support for pre-generated java.lang.invoke classes in CDS static archive >> Usually the dump with an appointed class list file, -XX:SharedClassListFile=, the 'classlist' is collected by pre-run the application with -XX:DumpLoadedClassList, so it is rare case using -Xshare:dump and -XX:DumpLoadedClassList together, though we can do that. >> It is reproducible by run >> java -Xshare:dump -XX:DumpLoadedClassList= >> The problem happened when regenerating lambda form invoker's holder classes, with which the re-generated class stream without a source associated (class is generated on fly). Referencing to NULL source failed. Fix checks if source is valid. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > src/hotspot/share/oops/instanceKlass.cpp line 4244: > >> 4242: // These classes can't be loaded from the archive during runtime. >> 4243: if (!stream->from_boot_loader_modules_image() && >> 4244: (stream->source() == NULL || strncmp(stream->source(), "jrt:", 4) != 0)) { > > I think the following block on line 4256 should also be changed > > if (skip && stream->source() != NULL) { > tty->print_cr("skip writing class %s from source %s to classlist file", > name()->as_C_string(), stream->source()); > } else { In fact, the printout (no change) like: skip writing class java/lang/invoke/BoundMethodHandle$Species_LL from source (null) to classlist file skip writing class java/lang/invoke/BoundMethodHandle$Species_LLL from source (null) to classlist file skip writing class java/lang/invoke/BoundMethodHandle$Species_LLLL from source (null) to classlist file So C++ can handle the NULL arg well in printf. I am not sure if all platforms handle this way, so will change to "(null)": stream->source() != NULL ? stream->source() : "(null)" ------------- PR: https://git.openjdk.java.net/jdk16u/pull/119 From minqi at openjdk.java.net Wed May 19 23:41:44 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 19 May 2021 23:41:44 GMT Subject: [jdk16u] RFR: 8267345: VM crashes during dumping classlist with -Xshare:dump option [v2] In-Reply-To: References: Message-ID: > Hi, Please review > The problem is caused by JDK-8247536: Support for pre-generated java.lang.invoke classes in CDS static archive > Usually the dump with an appointed class list file, -XX:SharedClassListFile=, the 'classlist' is collected by pre-run the application with -XX:DumpLoadedClassList, so it is rare case using -Xshare:dump and -XX:DumpLoadedClassList together, though we can do that. > It is reproducible by run > java -Xshare:dump -XX:DumpLoadedClassList= > The problem happened when regenerating lambda form invoker's holder classes, with which the re-generated class stream without a source associated (class is generated on fly). Referencing to NULL source failed. Fix checks if source is valid. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed skipping printout, changed Copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk16u/pull/119/files - new: https://git.openjdk.java.net/jdk16u/pull/119/files/aabbe535..f13049a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=119&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=119&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk16u/pull/119 From rekakovacs at microsoft.com Thu May 20 00:51:32 2021 From: rekakovacs at microsoft.com (Reka Kovacs) Date: Thu, 20 May 2021 00:51:32 +0000 Subject: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 In-Reply-To: References: Message-ID: Hi Martin, I'm responding to your comment on the backport bug, I hope you'll receive it this time. Thank you for the review, and for setting the fix-request tag for me. Could you please sponsor the change? I'm hoping to earn authorship soon, to be able to do some of the administrative steps myself. Thanks again, Reka From: Reka Kovacs Sent: Monday, May 17, 2021 4:16 PM To: jdk-updates-dev at openjdk.java.net Cc: Monica Beckwith Subject: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 Hi, I would like to backport this change as it eliminates build failures on Windows with VS2019, which is now the generally recommended version of Visual Studio. Could someone please review? Original bug: https://bugs.openjdk.java.net/browse/JDK-8241087 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c616656f7e01 Bug for backport: https://bugs.openjdk.java.net/browse/JDK-8254634 Webrev: http://cr.openjdk.java.net/~mbeckwit/8241087/webrev.00/ The original patch does not apply cleanly to jdk11u, because the copyright year in awt_DnDDT.cpp has already been changed to 2021. The updated patch does not touch that line. Monica kindly hosted the webrev for me. Tested: build and tier1 on x86_64 Windows, Linux and MacOS. Thank you, Reka From thomas.stuefe at gmail.com Thu May 20 05:21:24 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 20 May 2021 07:21:24 +0200 Subject: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: <53640CDE-B41D-4E3E-8861-96C8A54E9C32@azul.com> References: <53640CDE-B41D-4E3E-8861-96C8A54E9C32@azul.com> Message-ID: Thanks, Sergey! ..Thomas On Wed, May 19, 2021 at 8:41 PM Sergey Nazarkin wrote: > Checked on arm32: new test fails without patch and passes with the patch > > > > > > > On May 11, 2021, at 09:07, Thomas St?fe wrote: > > > > Hi, > > > > I'd like reviews for this downport, please. > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 > > Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb > > Original Review: https://git.openjdk.java.net/jdk/pull/1695 > > > > This patch does two things: > > > > 1) On Posix platforms it fixes SafeFetch to work in all threads, not only > > in JavaThreads. In non-JavaThreads before this patch it would crash. > > > > The patch is totally trivial. In the signal handler, when handling > > SafeFetch, there was a condition that Thread != NULL and be a JavaThread. > > This condition was unnecessary. All SafeFetch handling needs is a valid > > context. The Patch moves SafeFetch handling out of the is-JavaThread > > condition. > > > > 2) On Windows we did not have the problem; however there is the > > `Handle_Exception` function handling SafeFetch among other things, which > > may be called with a non-java thread, but then forcibly casts the Thread* > > to JavaThread. > > > > 11u patch: > > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads > > > > The original patch does not apply, at all. The reason for this is that we > > consolidated common functionality of the many cpu+arch signal handlers to > > one function, in os_posix.cpp. This happened in JDK16 and I do not want > to > > backport this cleanup change to 11. For this patch, it means that the > > posix-related fixes practically had to be rewritten for each and every > > signal handler. Each fix is primitive however, since it just moves > > SafeFetch handling around, but every signal handler is a tiny bit > different. > > > > I tested this patch for several weeks in our systems on Linux > > ppc/ppcle/x64/s390/aarch64, AIX, Solaris and Mac, no problems surfaced. > > > > I did not test on 32bit arm. > > > > Thanks, Thomas > > From iklam at openjdk.java.net Thu May 20 05:24:35 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 20 May 2021 05:24:35 GMT Subject: [jdk16u] RFR: 8267345: VM crashes during dumping classlist with -Xshare:dump option [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 23:41:44 GMT, Yumin Qi wrote: >> Hi, Please review >> The problem is caused by JDK-8247536: Support for pre-generated java.lang.invoke classes in CDS static archive >> Usually the dump with an appointed class list file, -XX:SharedClassListFile=, the 'classlist' is collected by pre-run the application with -XX:DumpLoadedClassList, so it is rare case using -Xshare:dump and -XX:DumpLoadedClassList together, though we can do that. >> It is reproducible by run >> java -Xshare:dump -XX:DumpLoadedClassList= >> The problem happened when regenerating lambda form invoker's holder classes, with which the re-generated class stream without a source associated (class is generated on fly). Referencing to NULL source failed. Fix checks if source is valid. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed skipping printout, changed Copyright year LGTM. I think the behavior of printing of %s with NULL is undefined, so your change is the safe way to do it. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk16u/pull/119 From ccheung at openjdk.java.net Thu May 20 05:28:51 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 20 May 2021 05:28:51 GMT Subject: [jdk16u] RFR: 8267345: VM crashes during dumping classlist with -Xshare:dump option [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 23:41:44 GMT, Yumin Qi wrote: >> Hi, Please review >> The problem is caused by JDK-8247536: Support for pre-generated java.lang.invoke classes in CDS static archive >> Usually the dump with an appointed class list file, -XX:SharedClassListFile=, the 'classlist' is collected by pre-run the application with -XX:DumpLoadedClassList, so it is rare case using -Xshare:dump and -XX:DumpLoadedClassList together, though we can do that. >> It is reproducible by run >> java -Xshare:dump -XX:DumpLoadedClassList= >> The problem happened when regenerating lambda form invoker's holder classes, with which the re-generated class stream without a source associated (class is generated on fly). Referencing to NULL source failed. Fix checks if source is valid. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed skipping printout, changed Copyright year Looks good. ------------- Marked as reviewed by ccheung (Committer). PR: https://git.openjdk.java.net/jdk16u/pull/119 From yan at openjdk.java.net Thu May 20 07:07:16 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 May 2021 07:07:16 GMT Subject: [jdk13u-dev] RFR: 8243452: JFR: Could not create chunk in repository with over 200 recordings In-Reply-To: References: Message-ID: On Wed, 19 May 2021 18:56:24 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8243452 to 13u for parity with 11u. > The patch doesn't apply cleanly due to context difference in jdk/jfr/internal/RepositoryChunk.java (JDK-8244463 is not in 13u), reapplied manually. > Tested with tier1 and jdk/jfr tests; the test attached to the issue fails without the patch, passes with it. apparently a number of changed lines didn't change so Skara decided it's clean: OK ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/221 From anleonar at redhat.com Thu May 20 08:58:26 2021 From: anleonar at redhat.com (Andrew Leonard) Date: Thu, 20 May 2021 09:58:26 +0100 Subject: sponsor: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols Message-ID: Please can I get a sponsor for this approved backport, thank you https://bugs.openjdk.java.net/browse/JDK-8266818 cheers Andrew From yan at openjdk.java.net Thu May 20 09:01:41 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 May 2021 09:01:41 GMT Subject: [jdk15u-dev] RFR: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On Wed, 19 May 2021 18:13:14 GMT, Vladimir Kempik wrote: > Please review backport of JDK-8261395 to jdk15u-dev > Two chunks of instanceKlass.cpp wasn't applyting clean, slight mod were needed. > Testcase were adapted for jdk15 in testlibrary related header. > Test case fails before patch and passes after. > Original fix - https://github.com/openjdk/jdk/commit/e828a939a8155a3b4ab26811a405bb4e4b2b99e8 Fine with me ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk15u-dev/pull/63 From sgehwolf at redhat.com Thu May 20 09:45:06 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 20 May 2021 11:45:06 +0200 Subject: [11u] RFR: 8266929: Unable to use algorithms from 3p providers In-Reply-To: References: <057751d07319ebbda5095570823147859b330545.camel@redhat.com> Message-ID: <68dbb7afc45f2baba19cb93c08502ce40588377b.camel@redhat.com> Hi, On Wed, 2021-05-19 at 21:47 +0000, Lutker, Dan wrote: > Hi Severin, > > All of the algorithms supported by jarsigner should be added, based on > the "Supported Algorithms" table on [1] we should have to add > SHA256withRSA, SHA384withRSA and SHA512withRSA. Thanks for the review! Makes sense to me: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266929/jdk11/02/webrev/ More thoughts? Thanks, Severin -Dan [1] https://docs.oracle.com/en/java/javase/11/tools/jarsigner.html? From dcherepanov at openjdk.java.net Thu May 20 09:50:56 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 20 May 2021 09:50:56 GMT Subject: [jdk13u-dev] Integrated: 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files In-Reply-To: <8jQEAB2KL6EkAAkXJ2kQL7zJluxXWYQbOO_Sr7-uQvQ=.bc492c24-d8da-4192-b6f4-a5a36e040d31@github.com> References: <8jQEAB2KL6EkAAkXJ2kQL7zJluxXWYQbOO_Sr7-uQvQ=.bc492c24-d8da-4192-b6f4-a5a36e040d31@github.com> Message-ID: On Wed, 19 May 2021 15:03:37 GMT, Dmitry Cherepanov wrote: > 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files This pull request has now been integrated. Changeset: 9fe778e2 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/9fe778e26a91cfe216c1eb37e9e6ec6dd2e65306 Stats: 1818 lines in 7 files changed: 1215 ins; 69 del; 534 mod 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Backport-of: 7d8985243d472db19dd416a5d9fe116737d3b327 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/220 From martin.doerr at sap.com Thu May 20 09:57:25 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 20 May 2021 09:57:25 +0000 Subject: AW: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 In-Reply-To: References: , Message-ID: Hi Reka, I?ve pushed it and also JDK-8251031. Several emails from jdk-updates-dev haven?t reached us but mailing to us directly works. Best regards, Martin Von: Reka Kovacs Datum: Donnerstag, 20. Mai 2021 um 02:51 An: mdoerr at openjdk.java.net Cc: jdk-updates-dev at openjdk.java.net Betreff: RE: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 Hi Martin, I'm responding to your comment on the backport bug, I hope you'll receive it this time. Thank you for the review, and for setting the fix-request tag for me. Could you please sponsor the change? I'm hoping to earn authorship soon, to be able to do some of the administrative steps myself. Thanks again, Reka From: Reka Kovacs Sent: Monday, May 17, 2021 4:16 PM To: jdk-updates-dev at openjdk.java.net Cc: Monica Beckwith Subject: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 Hi, I would like to backport this change as it eliminates build failures on Windows with VS2019, which is now the generally recommended version of Visual Studio. Could someone please review? Original bug: https://bugs.openjdk.java.net/browse/JDK-8241087 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c616656f7e01 Bug for backport: https://bugs.openjdk.java.net/browse/JDK-8254634 Webrev: http://cr.openjdk.java.net/~mbeckwit/8241087/webrev.00/ The original patch does not apply cleanly to jdk11u, because the copyright year in awt_DnDDT.cpp has already been changed to 2021. The updated patch does not touch that line. Monica kindly hosted the webrev for me. Tested: build and tier1 on x86_64 Windows, Linux and MacOS. Thank you, Reka From dcherepanov at openjdk.java.net Thu May 20 10:14:56 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 20 May 2021 10:14:56 GMT Subject: [jdk15u-dev] Integrated: 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files In-Reply-To: References: Message-ID: On Wed, 19 May 2021 14:54:22 GMT, Dmitry Cherepanov wrote: > 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files This pull request has now been integrated. Changeset: 717506c2 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk15u-dev/commit/717506c2979152177860f052c5aec883a72ed925 Stats: 1818 lines in 7 files changed: 1215 ins; 69 del; 534 mod 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Backport-of: 7d8985243d472db19dd416a5d9fe116737d3b327 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/62 From dcherepanov at openjdk.java.net Thu May 20 10:17:42 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 20 May 2021 10:17:42 GMT Subject: [jdk13u-dev] RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:40:00 GMT, Yuri Nesterenko wrote: > Applies clean with only a copyright year difference. > Full night run completed without visible issues. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/212 From yan at openjdk.java.net Thu May 20 10:32:11 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 May 2021 10:32:11 GMT Subject: [jdk13u-dev] Integrated: 8252883: AccessDeniedException caused by delayed file deletion on Windows In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:40:00 GMT, Yuri Nesterenko wrote: > Applies clean with only a copyright year difference. > Full night run completed without visible issues. This pull request has now been integrated. Changeset: 32f107ad Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/32f107ad3819d524bbaf5e20487fa2ea1f9305b4 Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod 8252883: AccessDeniedException caused by delayed file deletion on Windows Reviewed-by: dcherepanov Backport-of: ebdc80ead9b2ffd5f0d1e16ca6b8bab94b5ae6f3 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/212 From evergizova at openjdk.java.net Thu May 20 10:41:30 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 20 May 2021 10:41:30 GMT Subject: [jdk13u-dev] Integrated: 8243452: JFR: Could not create chunk in repository with over 200 recordings In-Reply-To: References: Message-ID: <2PcreNcy5cRSO_qi-vO0VWRSMlt5YHKEYBHROb31wvo=.93cfa168-40e9-462e-a3c6-143e5b8c4788@github.com> On Wed, 19 May 2021 18:56:24 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8243452 to 13u for parity with 11u. > The patch doesn't apply cleanly due to context difference in jdk/jfr/internal/RepositoryChunk.java (JDK-8244463 is not in 13u), reapplied manually. > Tested with tier1 and jdk/jfr tests; the test attached to the issue fails without the patch, passes with it. This pull request has now been integrated. Changeset: e7fc2017 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/e7fc2017b8ada53e965c32947fc3a290056d3daa Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8243452: JFR: Could not create chunk in repository with over 200 recordings Backport-of: 6dd84434934544542137f7b7567158e067e68590 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/221 From martin.doerr at sap.com Thu May 20 10:43:26 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 20 May 2021 10:43:26 +0000 Subject: AW: sponsor: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols In-Reply-To: References: Message-ID: Hi Andrew, I?ve pushed it. Best regards, Martin Von: jdk-updates-dev im Auftrag von Andrew Leonard Datum: Donnerstag, 20. Mai 2021 um 10:59 An: jdk-updates-dev at openjdk.java.net Betreff: sponsor: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols Please can I get a sponsor for this approved backport, thank you https://bugs.openjdk.java.net/browse/JDK-8266818 cheers Andrew From yan at openjdk.java.net Thu May 20 12:18:08 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 May 2021 12:18:08 GMT Subject: [jdk13u-dev] Integrated: 8216012: Infinite loop in RSA KeyPairGenerator Message-ID: I'd like to backport this fix here, too. Applies cleanly, test fails/pass without/with the fix. ------------- Commit messages: - Backport 567465c62c0f0a41b3ca8b979013e92bf368a8d3 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/222/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=222&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8216012 Stats: 99 lines in 2 files changed: 98 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/222.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/222/head:pull/222 PR: https://git.openjdk.java.net/jdk13u-dev/pull/222 From yan at openjdk.java.net Thu May 20 12:18:10 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 May 2021 12:18:10 GMT Subject: [jdk13u-dev] Integrated: 8216012: Infinite loop in RSA KeyPairGenerator In-Reply-To: References: Message-ID: <3zz_VmZgOc_o_ysh3JyqBY42mz6vs-5TKjDx0sRDlrU=.99c467c4-e35e-4433-9589-fd989d1c31d0@github.com> On Thu, 20 May 2021 12:07:44 GMT, Yuri Nesterenko wrote: > I'd like to backport this fix here, too. Applies cleanly, test fails/pass without/with the fix. This pull request has now been integrated. Changeset: 5cae7b24 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/5cae7b24ea5e237c63d6e7abd9496b69418f5634 Stats: 99 lines in 2 files changed: 98 ins; 0 del; 1 mod 8216012: Infinite loop in RSA KeyPairGenerator Check and error out on even RSA public exponents Backport-of: 567465c62c0f0a41b3ca8b979013e92bf368a8d3 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/222 From vkempik at openjdk.java.net Thu May 20 13:03:46 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 20 May 2021 13:03:46 GMT Subject: [jdk15u-dev] Integrated: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On Wed, 19 May 2021 18:13:14 GMT, Vladimir Kempik wrote: > Please review backport of JDK-8261395 to jdk15u-dev > Two chunks of instanceKlass.cpp wasn't applyting clean, slight mod were needed. > Testcase were adapted for jdk15 in testlibrary related header. > Test case fails before patch and passes after. > Original fix - https://github.com/openjdk/jdk/commit/e828a939a8155a3b4ab26811a405bb4e4b2b99e8 This pull request has now been integrated. Changeset: 0903e109 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/0903e1095717ef82c12c1640c429f72e07257daa Stats: 226 lines in 4 files changed: 167 ins; 40 del; 19 mod 8261395: C1 crash "cannot make java calls from the native compiler" Reviewed-by: yan Backport-of: e828a939a8155a3b4ab26811a405bb4e4b2b99e8 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/63 From yan at openjdk.java.net Thu May 20 13:11:57 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 May 2021 13:11:57 GMT Subject: [jdk13u-dev] Integrated: 8229396: jdeps ignores multi-release when generate-module-info used on command line Message-ID: should be fixed here, too, together with 8225773. jdeps tests run OK. ------------- Commit messages: - Backport b7e74ef62f4797d30a6edc5c7963f309b11b067d Changes: https://git.openjdk.java.net/jdk13u-dev/pull/223/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=223&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8229396 Stats: 355 lines in 11 files changed: 323 ins; 12 del; 20 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/223.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/223/head:pull/223 PR: https://git.openjdk.java.net/jdk13u-dev/pull/223 From yan at openjdk.java.net Thu May 20 13:11:58 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 May 2021 13:11:58 GMT Subject: [jdk13u-dev] Integrated: 8229396: jdeps ignores multi-release when generate-module-info used on command line In-Reply-To: References: Message-ID: On Thu, 20 May 2021 13:02:21 GMT, Yuri Nesterenko wrote: > should be fixed here, too, together with 8225773. jdeps tests run OK. This pull request has now been integrated. Changeset: d103e2ef Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/d103e2ef4aacd9ff802c156d3ffff05b30184ca1 Stats: 355 lines in 11 files changed: 323 ins; 12 del; 20 mod 8229396: jdeps ignores multi-release when generate-module-info used on command line Backport-of: b7e74ef62f4797d30a6edc5c7963f309b11b067d ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/223 From yan at openjdk.java.net Thu May 20 13:45:43 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 May 2021 13:45:43 GMT Subject: [jdk13u-dev] RFR: 8225773: jdeps --check produces NPE if there is any missing module dependence Message-ID: should backport this very useful change to 13u, too. All jdeps tests pass OK. ------------- Commit messages: - Backport fe8e1aacd16e4a0d3638550f7a28c4a9ff116e04 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/224/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=224&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225773 Stats: 73 lines in 4 files changed: 46 ins; 8 del; 19 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/224.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/224/head:pull/224 PR: https://git.openjdk.java.net/jdk13u-dev/pull/224 From martin.doerr at sap.com Thu May 20 13:47:40 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 20 May 2021 13:47:40 +0000 Subject: AW: [11u] RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: <5F4FAC88-87B4-411E-A4FF-266FAED4013F@azul.com> References: <5F4FAC88-87B4-411E-A4FF-266FAED4013F@azul.com> Message-ID: Hi Alexey, looks good. Thanks for backporting. Best regards, Martin Von: jdk-updates-dev im Auftrag von Alexey Bakhtin Datum: Donnerstag, 13. Mai 2021 um 21:36 An: jdk-updates-dev at openjdk.java.net Betreff: [11u] RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Hello, Could you please review the jdk11 backport of JDK-8242148: JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 Webrev 11u: http://cr.openjdk.java.net/~abakhtin/8241248_11u/webrev.v0/ Original patch: https://github.com/openjdk/jdk/commit/1603ca23422b03157afb2bd1050524465474b60e.patch The patch is not applied clean for PreSharedKeyExtension.java and ServerHello.java files because of JDK-8211018 ?Session Resumption without Server-Side State? [1] is not backported to JDK11 The merge is trivial. Test from the bug report is passed sun/security/ssl and javax/net/ssl jtreg tests passed [1] https://bugs.openjdk.java.net/browse/JDK-8211018 Regards Alexey From yan at openjdk.java.net Thu May 20 13:58:40 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 May 2021 13:58:40 GMT Subject: [jdk13u-dev] Integrated: 8225773: jdeps --check produces NPE if there is any missing module dependence In-Reply-To: References: Message-ID: On Thu, 20 May 2021 13:34:31 GMT, Yuri Nesterenko wrote: > should backport this very useful change to 13u, too. All jdeps tests pass OK. This pull request has now been integrated. Changeset: ebb6843d Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/ebb6843d23a41f65e1d9dea39a47e9a9e73b69b0 Stats: 73 lines in 4 files changed: 46 ins; 8 del; 19 mod 8225773: jdeps --check produces NPE if there is any missing module dependence Backport-of: fe8e1aacd16e4a0d3638550f7a28c4a9ff116e04 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/224 From ilarion at azul.com Thu May 20 14:14:28 2021 From: ilarion at azul.com (Ilarion Nakonechnyy) Date: Thu, 20 May 2021 14:14:28 +0000 Subject: [11u] RFR: JDK-8227080 backport: (fs) Files.newInputStream(...).skip(n) is slow Message-ID: <53DB81AE-DD36-4A0E-8F7B-EC401B21D13A@azul.com> Dear Sirs, I?d like to backport JDK-8227080 to JDK11. The patch applied unclear, a small correction in comment was done. Build successfully and run tier-1 on mac x86_64. Could you please review the changes? webrev: http://cr.openjdk.java.net/~yan/8227080_wr/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8227080 Thanks. From christoph.langer at sap.com Thu May 20 15:31:43 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 May 2021 15:31:43 +0000 Subject: [11u] RFR: JDK-8227080 backport: (fs) Files.newInputStream(...).skip(n) is slow In-Reply-To: <53DB81AE-DD36-4A0E-8F7B-EC401B21D13A@azul.com> References: <53DB81AE-DD36-4A0E-8F7B-EC401B21D13A@azul.com> Message-ID: Hi Ilarion, looks good to me ?? Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ilarion Nakonechnyy > Sent: Donnerstag, 20. Mai 2021 16:14 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: JDK-8227080 backport: (fs) > Files.newInputStream(...).skip(n) is slow > > Dear Sirs, I?d like to backport JDK-8227080 to JDK11. > > The patch applied unclear, a small correction in comment was done. Build > successfully and run tier-1 on mac x86_64. > Could you please review the changes? > webrev: http://cr.openjdk.java.net/~yan/8227080_wr/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8227080 > > Thanks. From minqi at openjdk.java.net Thu May 20 15:32:00 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 20 May 2021 15:32:00 GMT Subject: [jdk16u] RFR: 8267345: VM crashes during dumping classlist with -Xshare:dump option [v2] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 05:21:27 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed skipping printout, changed Copyright year > > LGTM. > I think the behavior of printing of %s with NULL is undefined, so your change is the safe way to do it. @iklam @calvinccheung Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk16u/pull/119 From minqi at openjdk.java.net Thu May 20 15:32:01 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 20 May 2021 15:32:01 GMT Subject: [jdk16u] Integrated: 8267345: VM crashes during dumping classlist with -Xshare:dump option In-Reply-To: References: Message-ID: On Wed, 19 May 2021 19:46:58 GMT, Yumin Qi wrote: > Hi, Please review > The problem is caused by JDK-8247536: Support for pre-generated java.lang.invoke classes in CDS static archive > Usually the dump with an appointed class list file, -XX:SharedClassListFile=, the 'classlist' is collected by pre-run the application with -XX:DumpLoadedClassList, so it is rare case using -Xshare:dump and -XX:DumpLoadedClassList together, though we can do that. > It is reproducible by run > java -Xshare:dump -XX:DumpLoadedClassList= > The problem happened when regenerating lambda form invoker's holder classes, with which the re-generated class stream without a source associated (class is generated on fly). Referencing to NULL source failed. Fix checks if source is valid. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: 5311c4d4 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk16u/commit/5311c4d454bc30a357d0a066f8cb919d89792836 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8267345: VM crashes during dumping classlist with -Xshare:dump option Reviewed-by: iklam, ccheung ------------- PR: https://git.openjdk.java.net/jdk16u/pull/119 From vkempik at openjdk.java.net Thu May 20 16:03:17 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 20 May 2021 16:03:17 GMT Subject: [jdk15u-dev] RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash Message-ID: This issue affects all aarch64 platforms, but to make java crash the platform need to pac-sign LR register, on the rest of aarch64 platform it effectively NO-OP ------------- Commit messages: - Backport ca93399af103384e750dabf3abcc6e8392bcf3f4 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/64/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=64&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267235 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/64.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/64/head:pull/64 PR: https://git.openjdk.java.net/jdk15u-dev/pull/64 From lutkerd at amazon.com Thu May 20 16:22:24 2021 From: lutkerd at amazon.com (Lutker, Dan) Date: Thu, 20 May 2021 16:22:24 +0000 Subject: [11u] RFR: 8266929: Unable to use algorithms from 3p providers In-Reply-To: <68dbb7afc45f2baba19cb93c08502ce40588377b.camel@redhat.com> References: <057751d07319ebbda5095570823147859b330545.camel@redhat.com> <68dbb7afc45f2baba19cb93c08502ce40588377b.camel@redhat.com> Message-ID: LGTM! ?On 5/20/21, 2:45 AM, "Severin Gehwolf" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi, On Wed, 2021-05-19 at 21:47 +0000, Lutker, Dan wrote: > Hi Severin, > > All of the algorithms supported by jarsigner should be added, based on > the "Supported Algorithms" table on [1] we should have to add > SHA256withRSA, SHA384withRSA and SHA512withRSA. Thanks for the review! Makes sense to me: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266929/jdk11/02/webrev/ More thoughts? Thanks, Severin -Dan [1] https://docs.oracle.com/en/java/javase/11/tools/jarsigner.html From zgu at openjdk.java.net Thu May 20 16:58:06 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 20 May 2021 16:58:06 GMT Subject: [jdk16u] RFR: 8266802: Shenandoah: Round up region size to page size unconditionally Message-ID: I would like to backport this patch to 16u. Without this patch, Shenandoah may not create enough regions to cover whole heap, that results some of heap memory never used. The original patch applies cleanly to 16u and passed new test in patch. ------------- Commit messages: - Backport e5d3ee394ae940ee0111489e6e072f327ec29c3b Changes: https://git.openjdk.java.net/jdk16u/pull/120/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=120&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266802 Stats: 76 lines in 3 files changed: 71 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk16u/pull/120.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/120/head:pull/120 PR: https://git.openjdk.java.net/jdk16u/pull/120 From rekakovacs at microsoft.com Thu May 20 18:33:06 2021 From: rekakovacs at microsoft.com (Reka Kovacs) Date: Thu, 20 May 2021 18:33:06 +0000 Subject: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 In-Reply-To: References: , Message-ID: Thank you, Martin! Kind regards, Reka From: Doerr, Martin Sent: Thursday, May 20, 2021 2:57 AM To: Reka Kovacs ; mdoerr at openjdk.java.net Cc: jdk-updates-dev at openjdk.java.net Subject: [EXTERNAL] AW: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 Hi Reka, I've pushed it and also JDK-8251031. Several emails from jdk-updates-dev haven't reached us but mailing to us directly works. Best regards, Martin Von: Reka Kovacs > Datum: Donnerstag, 20. Mai 2021 um 02:51 An: mdoerr at openjdk.java.net > Cc: jdk-updates-dev at openjdk.java.net > Betreff: RE: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 Hi Martin, I'm responding to your comment on the backport bug, I hope you'll receive it this time. Thank you for the review, and for setting the fix-request tag for me. Could you please sponsor the change? I'm hoping to earn authorship soon, to be able to do some of the administrative steps myself. Thanks again, Reka From: Reka Kovacs Sent: Monday, May 17, 2021 4:16 PM To: jdk-updates-dev at openjdk.java.net Cc: Monica Beckwith > Subject: [11u] RFR 8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873 Hi, I would like to backport this change as it eliminates build failures on Windows with VS2019, which is now the generally recommended version of Visual Studio. Could someone please review? Original bug: https://bugs.openjdk.java.net/browse/JDK-8241087 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c616656f7e01 Bug for backport: https://bugs.openjdk.java.net/browse/JDK-8254634 Webrev: http://cr.openjdk.java.net/~mbeckwit/8241087/webrev.00/ The original patch does not apply cleanly to jdk11u, because the copyright year in awt_DnDDT.cpp has already been changed to 2021. The updated patch does not touch that line. Monica kindly hosted the webrev for me. Tested: build and tier1 on x86_64 Windows, Linux and MacOS. Thank you, Reka From denghui.ddh at alibaba-inc.com Fri May 21 06:23:04 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Fri, 21 May 2021 14:23:04 +0800 Subject: =?UTF-8?B?WzExdV0gUkZSIDgyNjY2NDI6IEltcHJvdmUgUmVzb2x2ZWRNZXRob2RUYWJsZSBoYXNoIGZ1?= =?UTF-8?B?bmN0aW9u?= Message-ID: <86736ba4-d650-4dd8-95de-87aa6f6a7ab4.denghui.ddh@alibaba-inc.com> Hi, May I have a review of this small backport to 11u: JBS: https://bugs.openjdk.java.net/browse/JDK-8266642 Original patch: https://git.openjdk.java.net/jdk/pull/3901.diff webrev: http://cr.openjdk.java.net/~ddong/8266642/webrev.00/ This patch is almost a clean backport except there needs a manual adjustment at 'method_hash' since the context is different. For the problem that the patch wants to solve, please refer to: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-May/048014.html testing: hotspot_tier1 jdk_tier1 Thanks, Denghui Dong From vkempik at openjdk.java.net Fri May 21 07:41:45 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 21 May 2021 07:41:45 GMT Subject: [jdk15u-dev] Integrated: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: References: Message-ID: On Thu, 20 May 2021 15:57:43 GMT, Vladimir Kempik wrote: > This issue affects all aarch64 platforms, but to make java crash the platform need to pac-sign LR register, on the rest of aarch64 platform it effectively NO-OP This pull request has now been integrated. Changeset: a0b1ba19 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/a0b1ba197bc9303dbcd808b9058ee00bd45f8b2a Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash Backport-of: ca93399af103384e750dabf3abcc6e8392bcf3f4 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/64 From anleonar at redhat.com Fri May 21 07:50:23 2021 From: anleonar at redhat.com (Andrew Leonard) Date: Fri, 21 May 2021 08:50:23 +0100 Subject: sponsor: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols In-Reply-To: References: Message-ID: Thank you Martin, much appreciated. Are you able to push jdk8u-dev as well please? https://bugs.openjdk.java.net/browse/JDK-8266558?focusedCommentId=14419854&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14419854 Thank you Andrew On Thu, May 20, 2021 at 11:43 AM Doerr, Martin wrote: > Hi Andrew, > > > > I?ve pushed it. > > > > Best regards, > > Martin > > > > > > *Von: *jdk-updates-dev im Auftrag > von Andrew Leonard > *Datum: *Donnerstag, 20. Mai 2021 um 10:59 > *An: *jdk-updates-dev at openjdk.java.net > *Betreff: *sponsor: [11u] RFR : 8266818: Enable AIX build platform to > make external debug symbols > > Please can I get a sponsor for this approved backport, thank you > https://bugs.openjdk.java.net/browse/JDK-8266818 > cheers > Andrew > From vkempik at openjdk.java.net Fri May 21 08:13:58 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 21 May 2021 08:13:58 GMT Subject: [jdk13u-dev] RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash Message-ID: This issue affects all aarch64 platforms, but to make java crash the platform need to pac-sign LR register, on the rest of aarch64 platform it effectively NO-OP Applies clean ------------- Commit messages: - Backport ca93399af103384e750dabf3abcc6e8392bcf3f4 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/226/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=226&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267235 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/226.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/226/head:pull/226 PR: https://git.openjdk.java.net/jdk13u-dev/pull/226 From sgehwolf at redhat.com Fri May 21 08:31:07 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 21 May 2021 10:31:07 +0200 Subject: [11u] RFR: 8266929: Unable to use algorithms from 3p providers In-Reply-To: References: <057751d07319ebbda5095570823147859b330545.camel@redhat.com> <68dbb7afc45f2baba19cb93c08502ce40588377b.camel@redhat.com> Message-ID: Thanks! Could I get a review from an jdk-updates project Reviewer too, please? Thanks, Severin On Thu, 2021-05-20 at 16:22 +0000, Lutker, Dan wrote: > LGTM! > > ?On 5/20/21, 2:45 AM, "Severin Gehwolf" wrote: > > ??? CAUTION: This email originated from outside of the organization. > Do not click links or open attachments unless you can confirm the > sender and know the content is safe. > > > > ??? Hi, > > ??? On Wed, 2021-05-19 at 21:47 +0000, Lutker, Dan wrote: > ??? > Hi Severin, > ??? > > ??? > All of the algorithms supported by jarsigner should be added, > based on > ??? > the "Supported Algorithms" table on [1] we should have to add > ??? > SHA256withRSA, SHA384withRSA and SHA512withRSA. > > ??? Thanks for the review! Makes sense to me: > ??? > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266929/jdk11/02/webrev/ > > ??? More thoughts? > > ??? Thanks, > ??? Severin > > ??? -Dan > > ??? [1] > https://docs.oracle.com/en/java/javase/11/tools/jarsigner.html > > From martin.doerr at sap.com Fri May 21 09:12:35 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 21 May 2021 09:12:35 +0000 Subject: AW: sponsor: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols In-Reply-To: References: , Message-ID: Somebody who has an 8u repository can do it more easily than me. I?m no longer working on 8u. Maybe you, Severin can push it? Best regards, Martin Von: Andrew Leonard Datum: Freitag, 21. Mai 2021 um 09:50 An: Doerr, Martin Cc: jdk-updates-dev at openjdk.java.net , sgehwolf Betreff: Re: sponsor: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols Thank you Martin, much appreciated. Are you able to push jdk8u-dev as well please? https://bugs.openjdk.java.net/browse/JDK-8266558?focusedCommentId=14419854&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14419854 Thank you Andrew On Thu, May 20, 2021 at 11:43 AM Doerr, Martin > wrote: Hi Andrew, I?ve pushed it. Best regards, Martin Von: jdk-updates-dev > im Auftrag von Andrew Leonard > Datum: Donnerstag, 20. Mai 2021 um 10:59 An: jdk-updates-dev at openjdk.java.net > Betreff: sponsor: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols Please can I get a sponsor for this approved backport, thank you https://bugs.openjdk.java.net/browse/JDK-8266818 cheers Andrew From sgehwolf at redhat.com Fri May 21 09:30:53 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 21 May 2021 11:30:53 +0200 Subject: AW: sponsor: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols In-Reply-To: References: , Message-ID: <966708692b69998cd18947ebed7c82ca21ce7d0f.camel@redhat.com> On Fri, 2021-05-21 at 09:12 +0000, Doerr, Martin wrote: > Maybe you, Severin can push it? Sure. I'll take care of it. Thanks, Severin From anleonar at redhat.com Fri May 21 09:56:45 2021 From: anleonar at redhat.com (Andrew Leonard) Date: Fri, 21 May 2021 10:56:45 +0100 Subject: AW: sponsor: [11u] RFR : 8266818: Enable AIX build platform to make external debug symbols In-Reply-To: <966708692b69998cd18947ebed7c82ca21ce7d0f.camel@redhat.com> References: <966708692b69998cd18947ebed7c82ca21ce7d0f.camel@redhat.com> Message-ID: Thank you Severin On Fri, May 21, 2021 at 10:31 AM Severin Gehwolf wrote: > On Fri, 2021-05-21 at 09:12 +0000, Doerr, Martin wrote: > > Maybe you, Severin can push it? > > Sure. I'll take care of it. > > Thanks, > Severin > > > From github.com+4146708+a74nh at openjdk.java.net Fri May 21 11:46:53 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Fri, 21 May 2021 11:46:53 GMT Subject: [jdk13u-dev] RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: References: Message-ID: On Fri, 21 May 2021 08:06:28 GMT, Vladimir Kempik wrote: > This issue affects all aarch64 platforms, but to make java crash the platform need to pac-sign LR register, on the rest of aarch64 platform it effectively NO-OP > Applies clean How is this bug being produced? Are you building for the arm64e target? As I understood it, jdk is only built for the arm64 target. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 703: > 701: // if it was tail-call optimized by compiler, since lr is not callee-saved > 702: // reload it with proper value > 703: adr(lr, l); 1. Instead of adr, using xpaclri would be better logically, and potentially faster. Plus on non-pac hardware it's just a NOP, so even better. The AArch64 assembler does not yet have any pac instructions .... but I have already written that code. I'm happy to give you that patch, either for this PR or I can add a new PR (I hadn't done this yet because nothing would then use those instructions). 2. I'm unsure as to why the LR could be signed here. If the LR is signed, then how did the code jump back here without unsigning first? If a throw_pending_exception has been tail call optimised then it doesn't create a stack frame, and therefore shouldn't have signed the LR. Blindly stripping the value in the caller feels very wrong from a PAC standpoint - the callee should be doing both signing and unsigning. ------------- Changes requested by a74nh at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk13u-dev/pull/226 From ilarion at azul.com Fri May 21 14:06:58 2021 From: ilarion at azul.com (Ilarion Nakonechnyy) Date: Fri, 21 May 2021 14:06:58 +0000 Subject: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size Message-ID: <419A5CC6-EF74-4423-B0F6-74D5832E3E6F@azul.com> Hi, I?d like to backport JDK-8227609 to JDK11. The patch applied unclear, a small correction in comment was done. Build successfully and run tier-1 on mac x86_64. Could you please review the changes? webrev: http://cr.openjdk.java.net/~yan/8227609_wr/webrew.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8227609 Thanks. From vkempik at openjdk.java.net Fri May 21 14:12:05 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 21 May 2021 14:12:05 GMT Subject: [jdk13u-dev] RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: References: Message-ID: <2OjM8EecsvUyJQ-wusgXVGhF9qqdfGt0YBkPCIjRITc=.3c30d4cb-6cdc-40bc-b26b-6b376888584e@github.com> On Fri, 21 May 2021 11:42:08 GMT, Alan Hayward wrote: >> This issue affects all aarch64 platforms, but to make java crash the platform need to pac-sign LR register, on the rest of aarch64 platform it effectively NO-OP >> Applies clean > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 703: > >> 701: // if it was tail-call optimized by compiler, since lr is not callee-saved >> 702: // reload it with proper value >> 703: adr(lr, l); > > 1. Instead of adr, using xpaclri would be better logically, and potentially faster. Plus on non-pac hardware it's just a NOP, so even better. > The AArch64 assembler does not yet have any pac instructions .... but I have already written that code. I'm happy to give you that patch, either for this PR or I can add a new PR (I hadn't done this yet because nothing would then use those instructions). > > 2. I'm unsure as to why the LR could be signed here. If the LR is signed, then how did the code jump back here without unsigning first? If a throw_pending_exception has been tail call optimised then it doesn't create a stack frame, and therefore shouldn't have signed the LR. Blindly stripping the value in the caller feels very wrong from a PAC standpoint - the callee should be doing both signing and unsigning. Hello, the final callee which does return is pthread_jit_write_protect_np it does pacibsp at the beginning and i was told it's intentional: >pthread_jit_write_protect_np now needs to push a frame in 11.4, so it PACs lr before spilling it and authenticates it before returning. >the shared cache in arm64 processes is arm64e and the B keys are enabled, allowing non-ABI-visible ptrauth in first-party libraries including libpthread. This fix is more about saving LR before call and restoring it after call, as LR is not callee-saved. So I think it's better to restore LR to proper state than stripping PAC signature in it. it's not even ARM64E process here so I'm unsure if we should use some PAC-related asm code. BTW, if I stop these clang optimisations with attributes and throw_pending_exception returns on it's own then it restores LR from the stack and everything runs just fine. What you said is better be done as part of http://openjdk.java.net/jeps/8264131 in future. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/226 From github.com+4146708+a74nh at openjdk.java.net Fri May 21 14:12:12 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Fri, 21 May 2021 14:12:12 GMT Subject: [jdk13u-dev] RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: <2OjM8EecsvUyJQ-wusgXVGhF9qqdfGt0YBkPCIjRITc=.3c30d4cb-6cdc-40bc-b26b-6b376888584e@github.com> References: <2OjM8EecsvUyJQ-wusgXVGhF9qqdfGt0YBkPCIjRITc=.3c30d4cb-6cdc-40bc-b26b-6b376888584e@github.com> Message-ID: On Fri, 21 May 2021 12:57:06 GMT, Vladimir Kempik wrote: >and authenticates it before returning Which means the pac signature will have been removed. So there is something more subtle going on. But that's probably irrelevant, because.... >LR is not callee-saved Agreed. Which means we can't rely on it. In practice it always is restored.... except in this one case :) So, yes, adr is the correct thing to do here. Ok, I'm happy with this change. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/226 From vkempik at openjdk.java.net Fri May 21 14:12:16 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 21 May 2021 14:12:16 GMT Subject: [jdk13u-dev] Integrated: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: References: Message-ID: On Fri, 21 May 2021 08:06:28 GMT, Vladimir Kempik wrote: > This issue affects all aarch64 platforms, but to make java crash the platform need to pac-sign LR register, on the rest of aarch64 platform it effectively NO-OP > Applies clean This pull request has now been integrated. Changeset: dd8262db Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/dd8262db59ab1632f664ae026cb538879a9010a9 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash Backport-of: ca93399af103384e750dabf3abcc6e8392bcf3f4 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/226 From omikhaltcova at openjdk.java.net Fri May 21 14:15:15 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 21 May 2021 14:15:15 GMT Subject: [jdk13u-dev] RFR: 8251456: [TESTBUG] compiler/vectorization/TestVectorsNotSavedAtSafepoint.java failed OutOfMemoryError Message-ID: I'd like to backport JDK-8251456 to jdk13u for parity with jdk11u. The original patch applied cleanly. Slight changes is made to the test: added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179, - due to tier1 on win32 failed with "Unrecognized VM option 'UseCountedLoopSafepoints' ". All regular tests passed. ------------- Commit messages: - Added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179 - Backport 51b3bd2c2e39fc379918d4fba325f26b2c6cd4ec Changes: https://git.openjdk.java.net/jdk13u-dev/pull/225/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=225&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251456 Stats: 16 lines in 1 file changed: 3 ins; 3 del; 10 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/225.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/225/head:pull/225 PR: https://git.openjdk.java.net/jdk13u-dev/pull/225 From omikhaltcova at openjdk.java.net Fri May 21 14:27:26 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 21 May 2021 14:27:26 GMT Subject: [jdk15u-dev] RFR: 8251456: [TESTBUG] compiler/vectorization/TestVectorsNotSavedAtSafepoint.java failed OutOfMemoryError Message-ID: I'd like to backport JDK-8251456 to jdk15u for parity with jdk11u. The original patch applied cleanly. Slight changes is made to the test: added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179, - due to tier1 on win32 failed with "Unrecognized VM option 'UseCountedLoopSafepoints' ". All regular tests passed. ------------- Commit messages: - Added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179 - Backport 51b3bd2c2e39fc379918d4fba325f26b2c6cd4ec Changes: https://git.openjdk.java.net/jdk15u-dev/pull/65/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=65&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251456 Stats: 16 lines in 1 file changed: 3 ins; 3 del; 10 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/65.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/65/head:pull/65 PR: https://git.openjdk.java.net/jdk15u-dev/pull/65 From yan at openjdk.java.net Fri May 21 14:56:58 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 21 May 2021 14:56:58 GMT Subject: [jdk13u-dev] RFR: 8251456: [TESTBUG] compiler/vectorization/TestVectorsNotSavedAtSafepoint.java failed OutOfMemoryError In-Reply-To: References: Message-ID: On Thu, 20 May 2021 15:25:46 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8251456 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > > Slight changes is made to the test: added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179, - due to tier1 on win32 failed with "Unrecognized VM option 'UseCountedLoopSafepoints' ". > > All regular tests passed. Adding this single flag to a test to prevent its failure seems natural and sound, especially having in mind that there is no e.g. another separate fix for that exact issue . ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/225 From yan at openjdk.java.net Fri May 21 15:04:10 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 21 May 2021 15:04:10 GMT Subject: [jdk15u-dev] RFR: 8251456: [TESTBUG] compiler/vectorization/TestVectorsNotSavedAtSafepoint.java failed OutOfMemoryError In-Reply-To: References: Message-ID: <7qvkP5KUFweU9ifOZoqxffCByT3crC812Flrub_rQf0=.ed7d30e8-cf33-42e1-95db-cab5482ee543@github.com> On Thu, 20 May 2021 16:16:10 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8251456 to jdk15u for parity with jdk11u. > The original patch applied cleanly. > > Slight changes is made to the test: added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179, - due to tier1 on win32 failed with "Unrecognized VM option 'UseCountedLoopSafepoints' ". > > All regular tests passed. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/65 From omikhaltcova at openjdk.java.net Fri May 21 15:05:09 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 21 May 2021 15:05:09 GMT Subject: [jdk13u-dev] Integrated: 8251456: [TESTBUG] compiler/vectorization/TestVectorsNotSavedAtSafepoint.java failed OutOfMemoryError In-Reply-To: References: Message-ID: <6ArJ5smwhCr5Jr7bkBD1jONoEjtdEmHLBR3nl305qS0=.96956688-ff80-49b0-82d3-74534a800186@github.com> On Thu, 20 May 2021 15:25:46 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8251456 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > > Slight changes is made to the test: added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179, - due to tier1 on win32 failed with "Unrecognized VM option 'UseCountedLoopSafepoints' ". > > All regular tests passed. This pull request has now been integrated. Changeset: 7368c4be Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/7368c4be0bba7403f2f52bc4089a76e85b2ccd2d Stats: 16 lines in 1 file changed: 3 ins; 3 del; 10 mod 8251456: [TESTBUG] compiler/vectorization/TestVectorsNotSavedAtSafepoint.java failed OutOfMemoryError Removed allocation of large arrays to avoid OOME. Reviewed-by: yan Backport-of: 51b3bd2c2e39fc379918d4fba325f26b2c6cd4ec ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/225 From github.com+4146708+a74nh at openjdk.java.net Fri May 21 15:30:01 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Fri, 21 May 2021 15:30:01 GMT Subject: [jdk13u-dev] RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: References: <2OjM8EecsvUyJQ-wusgXVGhF9qqdfGt0YBkPCIjRITc=.3c30d4cb-6cdc-40bc-b26b-6b376888584e@github.com> Message-ID: On Fri, 21 May 2021 13:25:48 GMT, Alan Hayward wrote: >> Hello, the final callee which does return is pthread_jit_write_protect_np >> it does pacibsp at the beginning and i was told it's intentional: >>>pthread_jit_write_protect_np now needs to push a frame in 11.4, so it PACs lr before spilling it and authenticates it before returning. >>>the shared cache in arm64 processes is arm64e and the B keys are enabled, allowing non-ABI-visible ptrauth in first-party libraries including libpthread. >> >> This fix is more about saving LR before call and restoring it after call, as LR is not callee-saved. >> So I think it's better to restore LR to proper state than stripping PAC signature in it. it's not even ARM64E process here so I'm unsure if we should use some PAC-related asm code. >> BTW, if I stop these clang optimisations with attributes and throw_pending_exception returns on it's own then it restores LR from the stack and everything runs just fine. >> >> What you said is better be done as part of http://openjdk.java.net/jeps/8264131 in future. > >>and authenticates it before returning > > Which means the pac signature will have been removed. So there is something more subtle going on. But that's probably irrelevant, because.... > >>LR is not callee-saved > > Agreed. Which means we can't rely on it. In practice it always is restored.... except in this one case :) So, yes, adr is the correct thing to do here. > > Ok, I'm happy with this change. [ This review was meant for the mainline patch, not jdk13 - I clicked on the wrong link. Either way, mainline one had been pushed anyway ] ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/226 From omikhaltcova at openjdk.java.net Fri May 21 15:44:02 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 21 May 2021 15:44:02 GMT Subject: [jdk15u-dev] Integrated: 8251456: [TESTBUG] compiler/vectorization/TestVectorsNotSavedAtSafepoint.java failed OutOfMemoryError In-Reply-To: References: Message-ID: On Thu, 20 May 2021 16:16:10 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8251456 to jdk15u for parity with jdk11u. > The original patch applied cleanly. > > Slight changes is made to the test: added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179, - due to tier1 on win32 failed with "Unrecognized VM option 'UseCountedLoopSafepoints' ". > > All regular tests passed. This pull request has now been integrated. Changeset: 0f9e11c9 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/0f9e11c99ab640141e137a012a25a6de2d7ecc4b Stats: 16 lines in 1 file changed: 3 ins; 3 del; 10 mod 8251456: [TESTBUG] compiler/vectorization/TestVectorsNotSavedAtSafepoint.java failed OutOfMemoryError Removed allocation of large arrays to avoid OOME. Reviewed-by: yan Backport-of: 51b3bd2c2e39fc379918d4fba325f26b2c6cd4ec ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/65 From hohensee at amazon.com Fri May 21 17:20:27 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 21 May 2021 17:20:27 +0000 Subject: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size Message-ID: <3D03C0F5-96F0-4479-94F3-A3857443B1F3@amazon.com> Looks like you're referencing the the bug number list in Misc.java. Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Ilarion Nakonechnyy Date: Friday, May 21, 2021 at 7:08 AM To: "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size Hi, I?d like to backport JDK-8227609 to JDK11. The patch applied unclear, a small correction in comment was done. Build successfully and run tier-1 on mac x86_64. Could you please review the changes? webrev: http://cr.openjdk.java.net/~yan/8227609_wr/webrew.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8227609 Thanks. From hohensee at amazon.com Fri May 21 21:21:12 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 21 May 2021 21:21:12 +0000 Subject: [11u] RFR: 8266929: Unable to use algorithms from 3p providers Message-ID: <705E3DB3-2D0B-458D-AAE1-360B47E93C15@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Severin Gehwolf Date: Friday, May 21, 2021 at 1:32 AM To: "Lutker, Dan" , jdk-updates-dev Cc: Andrew Hughes , Martin Balao Subject: Re: [11u] RFR: 8266929: Unable to use algorithms from 3p providers Thanks! Could I get a review from an jdk-updates project Reviewer too, please? Thanks, Severin On Thu, 2021-05-20 at 16:22 +0000, Lutker, Dan wrote: > LGTM! > > On 5/20/21, 2:45 AM, "Severin Gehwolf" wrote: > > CAUTION: This email originated from outside of the organization. > Do not click links or open attachments unless you can confirm the > sender and know the content is safe. > > > > Hi, > > On Wed, 2021-05-19 at 21:47 +0000, Lutker, Dan wrote: > > Hi Severin, > > > > All of the algorithms supported by jarsigner should be added, > based on > > the "Supported Algorithms" table on [1] we should have to add > > SHA256withRSA, SHA384withRSA and SHA512withRSA. > > Thanks for the review! Makes sense to me: > > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8266929/jdk11/02/webrev/ > > More thoughts? > > Thanks, > Severin > > -Dan > > [1] > https://docs.oracle.com/en/java/javase/11/tools/jarsigner.html > > From zgu at openjdk.java.net Fri May 21 21:22:37 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 21 May 2021 21:22:37 GMT Subject: [jdk16u] Integrated: 8266802: Shenandoah: Round up region size to page size unconditionally In-Reply-To: References: Message-ID: <--jVWK177ls-CpoD4tyfwhyQ8bOLf_jsXVPMYy38yao=.100a9c61-62ae-458c-93b4-5dfa307f87b0@github.com> On Thu, 20 May 2021 16:50:33 GMT, Zhengyu Gu wrote: > I would like to backport this patch to 16u. > > Without this patch, Shenandoah may not create enough regions to cover whole heap, that results some of heap memory never used. > > The original patch applies cleanly to 16u and passed new test in patch. This pull request has now been integrated. Changeset: e0060a32 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk16u/commit/e0060a32ba7aa87678aebc707178fda6a49fb6a3 Stats: 76 lines in 3 files changed: 71 ins; 0 del; 5 mod 8266802: Shenandoah: Round up region size to page size unconditionally Backport-of: e5d3ee394ae940ee0111489e6e072f327ec29c3b ------------- PR: https://git.openjdk.java.net/jdk16u/pull/120 From zgu at redhat.com Sat May 22 23:20:54 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Sat, 22 May 2021 19:20:54 -0400 Subject: [11u] RFR 8267561: Shenandoah: Reference processing not properly setup for outside of cycle degenerated GC Message-ID: <7ef26b6b-fd30-9e48-6543-3c3fb1c472e9@redhat.com> Alibaba reported that Shenandoah outside-of-cycle degenerated GC slowly leak, please see CR for details. The cause is that reference processing not setup properly during outside-of-cycle degenerated GC. Webrev: http://cr.openjdk.java.net/~zgu/JDK-8267561/webrev.00/ Test: hotspot_gc_shenandoah specJVM Debery with configuration reported in CR. Thanks, -Zhengyu From vkempik at openjdk.java.net Sun May 23 18:05:06 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Sun, 23 May 2021 18:05:06 GMT Subject: [jdk16u] RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash Message-ID: Backporting the fix for LR saving issue to jdk16u ------------- Commit messages: - Backport ca93399af103384e750dabf3abcc6e8392bcf3f4 Changes: https://git.openjdk.java.net/jdk16u/pull/121/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=121&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267235 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/121.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/121/head:pull/121 PR: https://git.openjdk.java.net/jdk16u/pull/121 From clanger at openjdk.java.net Sun May 23 18:28:16 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Sun, 23 May 2021 18:28:16 GMT Subject: [jdk16u] RFR: 8261354: SIGSEGV at MethodIteratorHost Message-ID: 8261354: SIGSEGV at MethodIteratorHost ------------- Commit messages: - Backport 24623167ffbf8e192ef539fd0a969412719f850c Changes: https://git.openjdk.java.net/jdk16u/pull/123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=123&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261354 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16u/pull/123 From buddyliao at tencent.com Mon May 24 08:35:30 2021 From: buddyliao at tencent.com (=?utf-8?B?YnVkZHlsaWFvKOW7luW9rCk=?=) Date: Mon, 24 May 2021 08:35:30 +0000 Subject: =?utf-8?B?WzExdV0gUkZSIDgyNjYzNTI6IEFkZCBwYXJhbGxlbCBoZWFwIGl0ZXJhdGlv?= =?utf-8?B?biBmb3Igam1hcCDigJNoaXN0bw==?= Message-ID: <3754DBF2-F18F-4ACD-A1BF-AE2AA153369B@tencent.com> Hi all, Would you help me to review the following backport from jdk-master? The following three patches should be backport together for the reason of bugfix. Original bug: https://bugs.openjdk.java.net/browse/JDK-8215624 http://hg.openjdk.java.net/jdk/jdk/rev/b1afb7c82d59 https://bugs.openjdk.java.net/browse/JDK-8251570 https://hg.openjdk.java.net/jdk/jdk/rev/dd827a012e43 https://bugs.openjdk.java.net/browse/JDK-8253763 https://git.openjdk.java.net/jdk/commit/6d19fe65 Original patch does not apply cleanly to 11u, because jmap command parameter is different between each other, and the code structure has little changed. Notably, I had to change the src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java to make it matches 11u-dev Thank you for Matin?s suggestion, I combined all above three patches together and backport it. 11u webrev: https://cr.openjdk.java.net/~lzang/BuddyLiao/8266352/webrev02/ Testing: x86_64 build, affected tests, tier1 Thanks, -Buddy From clanger at openjdk.java.net Mon May 24 09:36:51 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 24 May 2021 09:36:51 GMT Subject: [jdk16u] RFR: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched Message-ID: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched ------------- Commit messages: - Backport 020236cb9825bf4fa91a495a179623e3fcdc0149 Changes: https://git.openjdk.java.net/jdk16u/pull/122/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=122&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264786 Stats: 24 lines in 4 files changed: 9 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk16u/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/122/head:pull/122 PR: https://git.openjdk.java.net/jdk16u/pull/122 From vkempik at openjdk.java.net Mon May 24 10:20:08 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 24 May 2021 10:20:08 GMT Subject: [jdk16u] Integrated: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: References: Message-ID: <8zG0sEgM45y3VdfHduanzWaiQP1uwvq6Vch_DX5V9-s=.dbacddb2-69b2-4b04-86a6-7e35fc611e92@github.com> On Sun, 23 May 2021 16:02:46 GMT, Vladimir Kempik wrote: > Backporting the fix for LR saving issue to jdk16u This pull request has now been integrated. Changeset: 410f742b Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk16u/commit/410f742b9861a3008edd030e8e9609441cbbd6e4 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash Backport-of: ca93399af103384e750dabf3abcc6e8392bcf3f4 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/121 From zgu at redhat.com Mon May 24 13:57:09 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 24 May 2021 09:57:09 -0400 Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 Message-ID: <2d1a7850-cfa5-f303-1fc1-1994e1dca3dc@redhat.com> I would like to backport this patch to 11u for parity with Oracle 11.0.13. The original bug: https://bugs.openjdk.java.net/browse/JDK-8265231 The original patch: https://github.com/openjdk/jdk/commit/d1b28e7a The original patch does not apply cleanly, due to JDK-8262465 11u backport diverged from original patch, and preserved isDirectIOSupportedByFS check. 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8265231-11u/webrev.00/ Test: DirectIOTest.java passed on Linux x86_64 Thanks, -Zhengyu From dmitry.chuyko at bell-sw.com Mon May 24 18:55:25 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Mon, 24 May 2021 21:55:25 +0300 Subject: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size In-Reply-To: <3D03C0F5-96F0-4479-94F3-A3857443B1F3@amazon.com> References: <3D03C0F5-96F0-4479-94F3-A3857443B1F3@amazon.com> Message-ID: Hi, It looks like the push was not clean: jdk11u-dev/src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java:130: error: ';' expected ??????????????????? newPos = size;8227609 https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/dce73d35ee28/src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java#l130 -Dmitry On 5/21/21 8:20 PM, Hohensee, Paul wrote: > Looks like you're referencing the the bug number list in Misc.java. Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Ilarion Nakonechnyy > Date: Friday, May 21, 2021 at 7:08 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: Re: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size > > Hi, I?d like to backport JDK-8227609 to JDK11. > > The patch applied unclear, a small correction in comment was done. Build successfully and run tier-1 on mac x86_64. > Could you please review the changes? > webrev: http://cr.openjdk.java.net/~yan/8227609_wr/webrew.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8227609 > > Thanks. > From hohensee at amazon.com Mon May 24 20:17:42 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 24 May 2021 20:17:42 +0000 Subject: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size Message-ID: <3B1C50A9-4966-46DE-8E95-BB6608982013@amazon.com> "8227609" was't in the webrev. http://cr.openjdk.java.net/~yan/8227609_wr/webrew.00/src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java.udiff.html Looks like a transcription error on the push. Yan? ?-----Original Message----- From: Dmitry Chuyko Date: Monday, May 24, 2021 at 11:55 AM To: "Hohensee, Paul" , Ilarion Nakonechnyy , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size Hi, It looks like the push was not clean: jdk11u-dev/src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java:130: error: ';' expected newPos = size;8227609 https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/dce73d35ee28/src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java#l130 -Dmitry On 5/21/21 8:20 PM, Hohensee, Paul wrote: > Looks like you're referencing the the bug number list in Misc.java. Lgtm. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of Ilarion Nakonechnyy > Date: Friday, May 21, 2021 at 7:08 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: Re: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size > > Hi, I?d like to backport JDK-8227609 to JDK11. > > The patch applied unclear, a small correction in comment was done. Build successfully and run tier-1 on mac x86_64. > Could you please review the changes? > webrev: http://cr.openjdk.java.net/~yan/8227609_wr/webrew.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8227609 > > Thanks. > From hohensee at amazon.com Mon May 24 20:45:58 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 24 May 2021 20:45:58 +0000 Subject: [11u] RFR: 8267641: [11u] 8227609 backport typo Message-ID: <94A2465D-7F5E-4942-B659-748F06DAAF79@amazon.com> Please review this tiny patch to fix a backport typo. See https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-May/006350.html JBS: https://bugs.openjdk.java.net/browse/JDK-8267641 Webrev: https://cr.openjdk.java.net/~phh/8267641/webrev.11u.00/ Thanks, Paul From hohensee at amazon.com Mon May 24 20:46:25 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 24 May 2021 20:46:25 +0000 Subject: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size In-Reply-To: <3B1C50A9-4966-46DE-8E95-BB6608982013@amazon.com> References: <3B1C50A9-4966-46DE-8E95-BB6608982013@amazon.com> Message-ID: <46368811-AEDA-4EB2-A80A-F8425C03431A@amazon.com> I filed https://bugs.openjdk.java.net/browse/JDK-8267641: [11u] 8227609 backport typo to fix it. Pls review the patch (separate email). Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Monday, May 24, 2021 at 1:18 PM To: Dmitry Chuyko , Ilarion Nakonechnyy , "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size "8227609" was't in the webrev. http://cr.openjdk.java.net/~yan/8227609_wr/webrew.00/src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java.udiff.html Looks like a transcription error on the push. Yan? -----Original Message----- From: Dmitry Chuyko Date: Monday, May 24, 2021 at 11:55 AM To: "Hohensee, Paul" , Ilarion Nakonechnyy , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size Hi, It looks like the push was not clean: jdk11u-dev/src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java:130: error: ';' expected newPos = size;8227609 https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/dce73d35ee28/src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java#l130 -Dmitry On 5/21/21 8:20 PM, Hohensee, Paul wrote: > Looks like you're referencing the the bug number list in Misc.java. Lgtm. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of Ilarion Nakonechnyy > Date: Friday, May 21, 2021 at 7:08 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: Re: [11u] RFR: JDK-8227609 backport: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size > > Hi, I?d like to backport JDK-8227609 to JDK11. > > The patch applied unclear, a small correction in comment was done. Build successfully and run tier-1 on mac x86_64. > Could you please review the changes? > webrev: http://cr.openjdk.java.net/~yan/8227609_wr/webrew.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8227609 > > Thanks. > From yan at openjdk.java.net Tue May 25 06:09:56 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 25 May 2021 06:09:56 GMT Subject: [jdk15u-dev] RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows Message-ID: <8Ro7hT2deLyVJ_I4PA-WV5qCnM77Vd79mdwYBDXHEAI=.ec9259d3-2aa2-4b31-a4f6-91c364dd84be@github.com> For consistency, backport the fix here, too. Nightly test run OK. ------------- Commit messages: - Backport ebdc80ead9b2ffd5f0d1e16ca6b8bab94b5ae6f3 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/66/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=66&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252883 Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/66.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/66/head:pull/66 PR: https://git.openjdk.java.net/jdk15u-dev/pull/66 From yan at azul.com Tue May 25 08:52:16 2021 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 25 May 2021 11:52:16 +0300 Subject: [11u] RFR: 8267641: [11u] 8227609 backport typo In-Reply-To: <94A2465D-7F5E-4942-B659-748F06DAAF79@amazon.com> References: <94A2465D-7F5E-4942-B659-748F06DAAF79@amazon.com> Message-ID: <5391653e-6437-aae5-f304-64c1a316037e@azul.com> Ouch! Yes, Paul, that's my fault. Apparently that was pasted after a control build just before the push when I fixed jcheck issues in the patch. --yan On 24.05.2021 23:45, Hohensee, Paul wrote: > Please review this tiny patch to fix a backport typo. See > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-May/006350.html > > JBS: https://bugs.openjdk.java.net/browse/JDK-8267641 > Webrev: https://cr.openjdk.java.net/~phh/8267641/webrev.11u.00/ > > Thanks, > Paul > From yan at azul.com Tue May 25 08:56:35 2021 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 25 May 2021 11:56:35 +0300 Subject: [11u] RFR: 8267641: [11u] 8227609 backport typo In-Reply-To: <5391653e-6437-aae5-f304-64c1a316037e@azul.com> References: <94A2465D-7F5E-4942-B659-748F06DAAF79@amazon.com> <5391653e-6437-aae5-f304-64c1a316037e@azul.com> Message-ID: And sure, add me as a reviewer to JDK-8267641 if necessary:-) --yan On 25.05.2021 11:52, Yuri Nesterenko wrote: > Ouch! Yes, Paul, that's my fault. Apparently that was pasted after a > control build just before the push when I fixed jcheck issues in the patch. > > --yan > > On 24.05.2021 23:45, Hohensee, Paul wrote: >> Please review this tiny patch to fix a backport typo. See >> >> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-May/006350.html >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8267641 >> Webrev: https://cr.openjdk.java.net/~phh/8267641/webrev.11u.00/ >> >> Thanks, >> Paul >> From dcherepanov at openjdk.java.net Tue May 25 09:15:00 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 25 May 2021 09:15:00 GMT Subject: [jdk15u-dev] RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows In-Reply-To: <8Ro7hT2deLyVJ_I4PA-WV5qCnM77Vd79mdwYBDXHEAI=.ec9259d3-2aa2-4b31-a4f6-91c364dd84be@github.com> References: <8Ro7hT2deLyVJ_I4PA-WV5qCnM77Vd79mdwYBDXHEAI=.ec9259d3-2aa2-4b31-a4f6-91c364dd84be@github.com> Message-ID: On Tue, 25 May 2021 06:03:15 GMT, Yuri Nesterenko wrote: > For consistency, backport the fix here, too. Nightly test run OK. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/66 From rkennke at redhat.com Tue May 25 10:46:11 2021 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 25 May 2021 12:46:11 +0200 Subject: [11u] RFR 8267561: Shenandoah: Reference processing not properly setup for outside of cycle degenerated GC In-Reply-To: <7ef26b6b-fd30-9e48-6543-3c3fb1c472e9@redhat.com> References: <7ef26b6b-fd30-9e48-6543-3c3fb1c472e9@redhat.com> Message-ID: Hi Zhengyu, The fix looks good. Is sh/jdk8 affected by this? If so, please mark the bug accordingly (and handle the backport if you can). Thanks, Roman > Alibaba reported that Shenandoah outside-of-cycle degenerated GC slowly > leak, please see CR for details. > > The cause is that reference processing not setup properly during > outside-of-cycle degenerated GC. > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8267561/webrev.00/ > > Test: > ?hotspot_gc_shenandoah > ?specJVM Debery with configuration reported in CR. > > Thanks, > > -Zhengyu > From martin.doerr at sap.com Tue May 25 11:45:52 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 25 May 2021 11:45:52 +0000 Subject: AW: [11u] RFR: 8267641: [11u] 8227609 backport typo In-Reply-To: References: <94A2465D-7F5E-4942-B659-748F06DAAF79@amazon.com> <5391653e-6437-aae5-f304-64c1a316037e@azul.com>, Message-ID: Hi Paul, thanks for fixing it. Looks good. Please push ASAP. Best regards, Martin Von: jdk-updates-dev im Auftrag von Yuri Nesterenko Datum: Dienstag, 25. Mai 2021 um 10:57 An: jdk-updates-dev at openjdk.java.net Betreff: Re: [11u] RFR: 8267641: [11u] 8227609 backport typo And sure, add me as a reviewer to JDK-8267641 if necessary:-) --yan On 25.05.2021 11:52, Yuri Nesterenko wrote: > Ouch! Yes, Paul, that's my fault. Apparently that was pasted after a > control build just before the push when I fixed jcheck issues in the patch. > > --yan > > On 24.05.2021 23:45, Hohensee, Paul wrote: >> Please review this tiny patch to fix a backport typo. See >> >> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-May/006350.html >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8267641 >> Webrev: https://cr.openjdk.java.net/~phh/8267641/webrev.11u.00/ >> >> Thanks, >> Paul >> From yan at openjdk.java.net Tue May 25 11:52:56 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 25 May 2021 11:52:56 GMT Subject: [jdk15u-dev] Integrated: 8252883: AccessDeniedException caused by delayed file deletion on Windows In-Reply-To: <8Ro7hT2deLyVJ_I4PA-WV5qCnM77Vd79mdwYBDXHEAI=.ec9259d3-2aa2-4b31-a4f6-91c364dd84be@github.com> References: <8Ro7hT2deLyVJ_I4PA-WV5qCnM77Vd79mdwYBDXHEAI=.ec9259d3-2aa2-4b31-a4f6-91c364dd84be@github.com> Message-ID: On Tue, 25 May 2021 06:03:15 GMT, Yuri Nesterenko wrote: > For consistency, backport the fix here, too. Nightly test run OK. This pull request has now been integrated. Changeset: e266324a Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/e266324a30c5694e1b5b000be4c0b72f64317ca6 Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod 8252883: AccessDeniedException caused by delayed file deletion on Windows Reviewed-by: dcherepanov Backport-of: ebdc80ead9b2ffd5f0d1e16ca6b8bab94b5ae6f3 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/66 From martin.doerr at sap.com Tue May 25 12:06:43 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 25 May 2021 12:06:43 +0000 Subject: =?big5?B?QVc6IFsxMXVdIFJGUiA4MjY2MzUyOiBBZGQgcGFyYWxsZWwgaGVhcCBpdGVyYXRp?= =?big5?B?b24gZm9yIGptYXAgoVZoaXN0bw==?= In-Reply-To: <3754DBF2-F18F-4ACD-A1BF-AE2AA153369B@tencent.com> References: <3754DBF2-F18F-4ACD-A1BF-AE2AA153369B@tencent.com> Message-ID: Hi Buddy, Let me make this clearer: I only suggested to push them at once. But we still need 3 individual commits to keep the history and JBS sane. Please make sure they don?t get merged into one commit. Can you upload your 3 patches, too, please? Best regards, Martin Von: buddyliao(??) Datum: Montag, 24. Mai 2021 um 10:36 An: jdk-updates-dev at openjdk.java.net Cc: Doerr, Martin Betreff: [11u] RFR 8266352: Add parallel heap iteration for jmap ?histo Hi all, Would you help me to review the following backport from jdk-master? The following three patches should be backport together for the reason of bugfix. Original bug: https://bugs.openjdk.java.net/browse/JDK-8215624 http://hg.openjdk.java.net/jdk/jdk/rev/b1afb7c82d59 https://bugs.openjdk.java.net/browse/JDK-8251570 https://hg.openjdk.java.net/jdk/jdk/rev/dd827a012e43 https://bugs.openjdk.java.net/browse/JDK-8253763 https://git.openjdk.java.net/jdk/commit/6d19fe65 Original patch does not apply cleanly to 11u, because jmap command parameter is different between each other, and the code structure has little changed. Notably, I had to change the src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java to make it matches 11u-dev Thank you for Matin?s suggestion, I combined all above three patches together and backport it. 11u webrev: https://cr.openjdk.java.net/~lzang/BuddyLiao/8266352/webrev02/ Testing: x86_64 build, affected tests, tier1 Thanks, -Buddy From florian.david at datadoghq.com Tue May 25 12:43:27 2021 From: florian.david at datadoghq.com (Florian David) Date: Tue, 25 May 2021 14:43:27 +0200 Subject: [test] [11u] RFR: 8258414: OldObjectSample events too expensive Message-ID: Hi, I'm resending this as a standalone email since some people do not seem to receive it through the original mail thread. ------------- Hi all, Please find an update to the backport. Comments related to https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005880.html where the previous patch has broken the 11u build have been taken into account: - check_java_thread_in_native is replaced by check_java_thread_in_vm in ObjectSampleCheckpoint::on_rotation - ThreadInVMfromNative transition(thread) is removed. That check is part of the original PR for JDK17 but since some code in JFR was moved from JNI (in 11) to native in 16, this check is not valid here. Build and Tests: - Linux release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". - Windows release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". The run-test-tier1 test suite did not complete entirely because of some issues with paths being too long and "vswhere.exe" not able to be run by the test on my machine. I would feel more confident (especially Windows was broken by the previous backport) if a maintainer could run the test suite on Windows. The "jtreg:jdk/jfr/" test suite ran successfully. Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ Original PR: https://github.com/openjdk/jdk/pull/2780 Thanks, Florian DAVID From hohensee at amazon.com Tue May 25 13:44:33 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 25 May 2021 13:44:33 +0000 Subject: AW: [11u] RFR: 8267641: [11u] 8227609 backport typo Message-ID: <8A6304A0-4C7B-4927-A4FC-78607338B90B@amazon.com> Pushed. Thanks for reviewing, Martin, Yan, and Severin, and thanks, Severin, for tagging. Paul From: "Doerr, Martin" Date: Tuesday, May 25, 2021 at 4:46 AM To: Yuri Nesterenko , "jdk-updates-dev at openjdk.java.net" , "Hohensee, Paul" Subject: AW: [11u] RFR: 8267641: [11u] 8227609 backport typo Hi Paul, thanks for fixing it. Looks good. Please push ASAP. Best regards, Martin Von: jdk-updates-dev im Auftrag von Yuri Nesterenko Datum: Dienstag, 25. Mai 2021 um 10:57 An: jdk-updates-dev at openjdk.java.net Betreff: Re: [11u] RFR: 8267641: [11u] 8227609 backport typo And sure, add me as a reviewer to JDK-8267641 if necessary:-) --yan On 25.05.2021 11:52, Yuri Nesterenko wrote: > Ouch! Yes, Paul, that's my fault. Apparently that was pasted after a > control build just before the push when I fixed jcheck issues in the patch. > > --yan > > On 24.05.2021 23:45, Hohensee, Paul wrote: >> Please review this tiny patch to fix a backport typo. See >> >> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-May/006350.html >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8267641 >> Webrev: https://cr.openjdk.java.net/~phh/8267641/webrev.11u.00/ >> >> Thanks, >> Paul >> From goetz.lindenmaier at sap.com Tue May 25 14:06:35 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 May 2021 14:06:35 +0000 Subject: [11u reminder]: jdk 11.0.12 rampdown starts Tuesday, June 1st, 18:00 CET. Message-ID: Hi, I would like to remind everybody who is working on jdk 11 updates that rampdown of 11.0.12 starts next Tuesday, June 1st, at 18:00 CEST. At that point in time the last merge from jdk11u-dev to jdk11u will take place. Please push all changes you want to get to 11.0.12 before that date. After that, changes for 11.0.12 must be requested with jdk11u-critical-request tags, and they need to be pushed directly to jdk11u. Please also remember that 11.0.13 development will be in the git repository https://github.com/openjdk/jdk11u-dev. Kindly allow a bit of additional time for pushing the 11.0.13+0 tag and the version update change 8267695. Critical changes for 11.0.12 still must be pushed to the well-known mercurial repo. Best regards, Goetz See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From dcherepanov at openjdk.java.net Tue May 25 14:24:05 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 25 May 2021 14:24:05 GMT Subject: [jdk13u-dev] RFR: 8235368: Update BCEL to Version 6.4.1 Message-ID: 8235368: Update BCEL to Version 6.4.1 Applies cleanly except @LastModified timestamps in two files below (due to JDK-8248348 with newer timestamps is already included in 13u) src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/BranchInstruction.java src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/Instruction.java ------------- Commit messages: - Backport e8f8eef9087c2be14bb1726cf9892517581067cd Changes: https://git.openjdk.java.net/jdk13u-dev/pull/227/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=227&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8235368 Stats: 3402 lines in 318 files changed: 2175 ins; 527 del; 700 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/227.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/227/head:pull/227 PR: https://git.openjdk.java.net/jdk13u-dev/pull/227 From yan at openjdk.java.net Wed May 26 07:30:14 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 26 May 2021 07:30:14 GMT Subject: [jdk13u-dev] RFR: 8235368: Update BCEL to Version 6.4.1 In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:15:23 GMT, Dmitry Cherepanov wrote: > 8235368: Update BCEL to Version 6.4.1 > > Applies cleanly except @LastModified timestamps in two files below (due to JDK-8248348 with newer timestamps is already included in 13u) > > src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/BranchInstruction.java > src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/Instruction.java fine with me! ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/227 From dcherepanov at openjdk.java.net Wed May 26 10:20:19 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 26 May 2021 10:20:19 GMT Subject: [jdk13u-dev] Integrated: 8235368: Update BCEL to Version 6.4.1 In-Reply-To: References: Message-ID: <88V5C9IIRcld2SdFLdrQwAChdlDa08JjWy8Np0IpskI=.b8ddb6ab-ad78-4bbf-b6cc-5d16eaace36e@github.com> On Tue, 25 May 2021 14:15:23 GMT, Dmitry Cherepanov wrote: > 8235368: Update BCEL to Version 6.4.1 > > Applies cleanly except @LastModified timestamps in two files below (due to JDK-8248348 with newer timestamps is already included in 13u) > > src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/BranchInstruction.java > src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/Instruction.java This pull request has now been integrated. Changeset: cea44d62 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/cea44d62bee4d24fa6c66152468f0f0e7ec5fd78 Stats: 3402 lines in 318 files changed: 2175 ins; 527 del; 700 mod 8235368: Update BCEL to Version 6.4.1 Reviewed-by: yan Backport-of: e8f8eef9087c2be14bb1726cf9892517581067cd ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/227 From vkempik at openjdk.java.net Wed May 26 11:43:16 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Wed, 26 May 2021 11:43:16 GMT Subject: [jdk15u-dev] RFR: 8263361: Incorrect arraycopy stub selected by C2 for SATB collectors In-Reply-To: References: Message-ID: On Wed, 12 May 2021 18:31:37 GMT, Sergey Nazarkin wrote: > Hi! > I'd like to backport this patch that fixes hotspot debug builds crash. The patch doesn't apply cleanly due to miss of 8252848. The manual fix is required for **macroArrayCopy.cpp:553**: rename **dest_uninitialized** to **acopy_to_uninitialized** > > Pass tier(1,2} Marked as reviewed by vkempik (Committer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/52 From yan at openjdk.java.net Wed May 26 11:50:30 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 26 May 2021 11:50:30 GMT Subject: [jdk15u-dev] RFR: 8263361: Incorrect arraycopy stub selected by C2 for SATB collectors In-Reply-To: References: Message-ID: <_f8QBF7NF9Ko8K70ie5Qe7euvvrU4R99gS_Dd4keplU=.36b65d92-c049-4c3f-8991-a7f1e7336aa9@github.com> On Wed, 12 May 2021 18:31:37 GMT, Sergey Nazarkin wrote: > Hi! > I'd like to backport this patch that fixes hotspot debug builds crash. The patch doesn't apply cleanly due to miss of 8252848. The manual fix is required for **macroArrayCopy.cpp:553**: rename **dest_uninitialized** to **acopy_to_uninitialized** > > Pass tier(1,2} Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/52 From martin.doerr at sap.com Wed May 26 12:42:23 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 26 May 2021 12:42:23 +0000 Subject: AW: AW: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager In-Reply-To: References: <7b7428f8-ae8f-c27a-9330-28f267d98ebe@azul.com> <984828bd-b989-580a-d91b-3dbb17172368@azul.com> , <016f6b5e-7c1f-b125-1925-b548b4b07f8b@azul.com>, Message-ID: Hi Andrew, I?m just checking the changes for 11.0.12. Do we need these 2 fixes for that release? Is anybody already working on an 8255790 backport? It looks a bit tricky. Doesn?t apply well. Best regards, Martin Von: Doerr, Martin Datum: Freitag, 7. Mai 2021 um 18:37 An: Andrew Brygin , jdk-updates-dev at openjdk.java.net Betreff: AW: AW: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager Excellent! Thanks a lot! Best regards, Martin Von: Andrew Brygin Datum: Freitag, 7. Mai 2021 um 18:36 An: Doerr, Martin , jdk-updates-dev at openjdk.java.net Betreff: Re: AW: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager Hi Martin, thanks for review. I agree that 8251367 and 8255790 should be pushed together. I will put the fix request comment into 8251367, just as reference to this review thread, but postpone the fix request label until 8255790 will be ready for 11u. Is it OK? Thanks, Andrew On 07/05/2021 19:29, Doerr, Martin wrote: > Hi Andrew, > > > > thanks for checking. You can consider your 8251367 backport as reviewed, > but I think it should get pushed together with 8255790 if possible. Do > you agree? > > > > Best regards, > > Martin > > > > > > *Von: *Andrew Brygin > *Datum: *Freitag, 7. Mai 2021 um 18:25 > *An: *Doerr, Martin , > jdk-updates-dev at openjdk.java.net > *Betreff: *Re: AW: [11u] RFR (S): 8251367: [windows] harfbuzz.dll not > found causes failure to load sun.font.SunFontManager > > Hi Martin, > > yes, I think we have to backport JDK-8255790 as well: it actually > reverts the harfbuzz separation (JDK-8249821) for windows, so the > problem with exe4j apps will be resolved without modification of > FontManagerNativeLibrary.java. > > Thanks, > Andrew > > On 07/05/2021 18:55, Doerr, Martin wrote: >> Hi Andrew, >> >> >> >> looks like correctly backported. >> >> However, the code added to FontManagerNativeLibrary.java was removed > again: >> >> > https://github.com/openjdk/jdk/commit/05fe06a6bafc089c6466ccbdea335e5dbfdaf335 > >> >> Are you planning to backport that one, too? >> >> >> >> Best regards, >> >> Martin >> >> >> >> >> >> *Von: *jdk-updates-dev im >> Auftrag von Andrew Brygin >> *Datum: *Freitag, 7. Mai 2021 um 11:07 >> *An: *jdk-updates-dev at openjdk.java.net >> *Betreff: *[11u] RFR (S): 8251367: [windows] harfbuzz.dll not found >> causes failure to load sun.font.SunFontManager >> >> Hello, >> >> I would like to propose a backport of 8251367 for 11u: >> >> The fix for 8249821: Separate libharfbuzz from libfontmanager is >> already backported into 11u, so fontmanager.dll now has two >> dependencies: freetype.dl and harfbuzz.dll which should be handled in >> the same manner. >> >> The absence of explicit loading of harfbuzz.dll affects some >> exe4j/install4j deployments which do not use standard java/javaw > launchers. >> >> Original issue: https://bugs.openjdk.java.net/browse/JDK-8251367 > >> > >> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/21c664a5b7e2 > >> > >> Webrev: http://cr.openjdk.java.net/~bae/11u/8251367/webrev.00/ > >> > >> >> The patch for Awt2dLibraries.gmk required some adjustments due to the >> file rename (make/modules/java.desktop/lib/Awt2dLibraries.gmk -> >> make/lib/Awt2dLibraries.gmk) and context differences. >> >> Thanks, >> Andrew >> > From hohensee at amazon.com Wed May 26 18:17:10 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 26 May 2021 18:17:10 +0000 Subject: [11u]: RFR (XS): 8249875: GCC 10 warnings -Wtype-limits with JFR code Message-ID: <98A9D759-DB6A-494D-9E53-CF2A7A2B4E4E@amazon.com> Please review this simple backport to 11u. The only conflicts were copyright dates. Original JBS: https://bugs.openjdk.java.net/browse/JDK-8249875 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/942b669a4ae3 11u webrev: https://cr.openjdk.java.net/~phh/8249875/webrev.11u.00/ Thanks, Paul From abakhtin at openjdk.java.net Thu May 27 09:29:29 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Thu, 27 May 2021 09:29:29 GMT Subject: [jdk16u] RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Message-ID: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) ------------- Commit messages: - Backport 1603ca23422b03157afb2bd1050524465474b60e Changes: https://git.openjdk.java.net/jdk16u/pull/124/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=124&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241248 Stats: 45 lines in 4 files changed: 40 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/124.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/124/head:pull/124 PR: https://git.openjdk.java.net/jdk16u/pull/124 From markus.gronlund at oracle.com Thu May 27 11:54:19 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 27 May 2021 11:54:19 +0000 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: Hi Florian and Jaroslav, objectSampleCheckpoint.cpp: ... 26 #include "jfr/jni/jfrJavaSupport.hpp" and 297 JavaThread* const thread = JavaThread::current(); 298 DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_vm(thread);) All this can be removed, because its only used to verify the single state there is in 11, i.e. "_thread_in_vm." Only in later versions we explicitly transition between "_thread_in_native" and "_thread_in_vm". 287 ResourceMark rm; and 293 // caller needs ResourceMark With the ResourceMark introduced in 287, the comment at 293 can be removed. jfrStackTraceRepository.hpp: ... 71 const JfrStackTrace* lookup(unsigned int hash, traceid id) const; Can be removed. Otherwise looks good, don't need an updated webrev. Thank you Markus -----Original Message----- From: jdk-updates-dev On Behalf Of Florian David Sent: den 19 maj 2021 16:26 To: Jaroslav Bachor?k Cc: jdk-updates-dev ; Marcus Hirt Subject: Re: [11u] RFR: 8258414: OldObjectSample events too expensive Hi, I'm re-sending this email since Martin Doerr didn't receive it and found it with the mailing list archives, so maybe others miss it. Martin reported that he doesn't see test errors anymore with this webrev. Hi all, Please find an update to the backport. Comments related to https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005880.html where the previous patch has broken the 11u build have been taken into account: - check_java_thread_in_native is replaced by check_java_thread_in_vm in ObjectSampleCheckpoint::on_rotation - ThreadInVMfromNative transition(thread) is removed. That check is part of the original PR for JDK17 but since some code in JFR was moved from JNI (in 11) to native in 16, this check is not valid here. Build and Tests: - Linux release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". - Windows release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". The run-test-tier1 test suite did not complete entirely because of some issues with paths being too long and "vswhere.exe" not able to be run by the test on my machine. I would feel more confident (especially Windows was broken by the previous backport) if a maintainer could run the test suite on Windows. The "jtreg:jdk/jfr/" test suite ran successfully. Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ Original PR: https://github.com/openjdk/jdk/pull/2780 Thanks, Florian DAVID On Fri, May 7, 2021 at 6:34 PM Florian David wrote: > Hi all, > > Please find an update to the backport. Comments related to > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005 > 880.html > > where the previous patch has broken the 11u build have been taken into > account: > > - check_java_thread_in_native is replaced by check_java_thread_in_vm > in ObjectSampleCheckpoint::on_rotation > - ThreadInVMfromNative transition(thread) is removed. That check is > part of the original PR for JDK17 but since some code in JFR was moved > from JNI (in 11) to native in 16, this check is not valid here. > > Build and Tests: > - Linux release and fastdebug builds. Tested with make run-test-tier1 > && make run-test TEST="jtreg:jdk/jfr/". > - Windows release and fastdebug builds. Tested with make > run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". The > run-test-tier1 test suite did not complete entirely because of some > issues with paths being too long and "vswhere.exe" not able to be run > by the test on my machine. I would feel more confident (especially > Windows was broken by the previous backport) if a maintainer could run > the test suite on Windows. The "jtreg:jdk/jfr/" test suite ran > successfully. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ > Original PR: https://github.com/openjdk/jdk/pull/2780 > > Thanks, > Florian DAVID > > On Mon, Apr 12, 2021 at 10:38 AM Jaroslav Bachor?k < > jaroslav.bachorik at datadoghq.com> wrote: > >> 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 hohensee at amazon.com Thu May 27 15:39:31 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 27 May 2021 15:39:31 +0000 Subject: [11u] RFR (S) 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller Message-ID: <4E58FB80-3B4F-4EAB-BBB0-8BF6FCF7842D@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Tuesday, May 18, 2021 at 7:49 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (S) 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8253048 Preconditions are met in 11u: stub genertor logic is to "save the bottom 64 bits of each value stored in v8-v15; it is the responsibility of the caller to preserve larger values.", add_call_kills() logic is present. Original patch does not apply cleanly (JDK-8231441 - initial SVE - is not in 11u, some other changes as well). But it was rather simply reproduced: src/hotspot/cpu/aarch64/aarch64.ad 'reg_def V<8-15>, V<8-15>_H' are made 'SOC, SOE...' instead of 'SOC, SOC...' src/hotspot/cpu/aarch64/macroAssembler_aarch64_trig.cpp Replaced v10 usages by v24. No other references of v8-v15 in macroAssembler-aarch64*. In assembler_aarch64.cpp there are still usages generated by aarch64-asmtest.py. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8253048/webrev.11u.00/ Testing: tier1, tier2. Opto assembly check for the test [1] from original review shows 'stack bang size=48' -> 'stack bang size=32' around nanoTime call. [1] http://cr.openjdk.java.net/~jzhu/8253048/Test.java -- Thanks, -Dmitry From hohensee at amazon.com Thu May 27 17:00:51 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 27 May 2021 17:00:51 +0000 Subject: [11u]: RFR (XS): 8249875: GCC 10 warnings -Wtype-limits with JFR code In-Reply-To: <98A9D759-DB6A-494D-9E53-CF2A7A2B4E4E@amazon.com> References: <98A9D759-DB6A-494D-9E53-CF2A7A2B4E4E@amazon.com> Message-ID: <3DC36098-184A-4D65-88F3-79F8DFD84FD0@amazon.com> I pushed this backport to 11u by mistake. Christoph, shall I revert it? Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Wednesday, May 26, 2021 at 11:18 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [UNVERIFIED SENDER] [11u]: RFR (XS): 8249875: GCC 10 warnings -Wtype-limits with JFR code Please review this simple backport to 11u. The only conflicts were copyright dates. Original JBS: https://bugs.openjdk.java.net/browse/JDK-8249875 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/942b669a4ae3 11u webrev: https://cr.openjdk.java.net/~phh/8249875/webrev.11u.00/ Thanks, Paul From snazarki at openjdk.java.net Thu May 27 17:34:16 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Thu, 27 May 2021 17:34:16 GMT Subject: [jdk15u-dev] Integrated: 8263361: Incorrect arraycopy stub selected by C2 for SATB collectors In-Reply-To: References: Message-ID: On Wed, 12 May 2021 18:31:37 GMT, Sergey Nazarkin wrote: > Hi! > I'd like to backport this patch that fixes hotspot debug builds crash. The patch doesn't apply cleanly due to miss of 8252848. The manual fix is required for **macroArrayCopy.cpp:553**: rename **dest_uninitialized** to **acopy_to_uninitialized** > > Pass tier(1,2} This pull request has now been integrated. Changeset: ebaf7e16 Author: Sergey Nazarkin Committer: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/ebaf7e16c59090f24ef8b43b5a47ac64ca68e432 Stats: 42 lines in 3 files changed: 10 ins; 0 del; 32 mod 8263361: Incorrect arraycopy stub selected by C2 for SATB collectors Reviewed-by: vkempik, yan Backport-of: 5d87a21991b964e1c50495dc2dc982db425830b5 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/52 From hohensee at amazon.com Fri May 28 00:27:34 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 28 May 2021 00:27:34 +0000 Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 Message-ID: <05D67513-7B96-4B2C-A0B4-DEC2F141B672@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Zhengyu Gu Date: Monday, May 24, 2021 at 6:57 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 I would like to backport this patch to 11u for parity with Oracle 11.0.13. The original bug: https://bugs.openjdk.java.net/browse/JDK-8265231 The original patch: https://github.com/openjdk/jdk/commit/d1b28e7a The original patch does not apply cleanly, due to JDK-8262465 11u backport diverged from original patch, and preserved isDirectIOSupportedByFS check. 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8265231-11u/webrev.00/ Test: DirectIOTest.java passed on Linux x86_64 Thanks, -Zhengyu From zgu at redhat.com Fri May 28 01:31:23 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 27 May 2021 21:31:23 -0400 Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 In-Reply-To: <05D67513-7B96-4B2C-A0B4-DEC2F141B672@amazon.com> References: <05D67513-7B96-4B2C-A0B4-DEC2F141B672@amazon.com> Message-ID: <26a9ccda-c766-640a-d7d2-6be8ac45eba1@redhat.com> Thanks, Paul. Tagged for approval. -Zhengyu On 5/27/21 8:27 PM, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Zhengyu Gu > Date: Monday, May 24, 2021 at 6:57 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 > > I would like to backport this patch to 11u for parity with Oracle 11.0.13. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8265231 > The original patch: https://github.com/openjdk/jdk/commit/d1b28e7a > > The original patch does not apply cleanly, due to JDK-8262465 11u > backport diverged from original patch, and preserved > isDirectIOSupportedByFS check. > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8265231-11u/webrev.00/ > > > Test: > DirectIOTest.java passed on Linux x86_64 > > Thanks, > > -Zhengyu > > From volker.simonis at gmail.com Fri May 28 08:20:04 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 May 2021 10:20:04 +0200 Subject: [11u]: RFR (XS): 8249875: GCC 10 warnings -Wtype-limits with JFR code In-Reply-To: <3DC36098-184A-4D65-88F3-79F8DFD84FD0@amazon.com> References: <98A9D759-DB6A-494D-9E53-CF2A7A2B4E4E@amazon.com> <3DC36098-184A-4D65-88F3-79F8DFD84FD0@amazon.com> Message-ID: Just in case a retroactive review helps, the downport looks good and I review it :) On Thu, May 27, 2021 at 7:04 PM Hohensee, Paul wrote: > > I pushed this backport to 11u by mistake. Christoph, shall I revert it? > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of "Hohensee, Paul" > Date: Wednesday, May 26, 2021 at 11:18 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [UNVERIFIED SENDER] [11u]: RFR (XS): 8249875: GCC 10 warnings -Wtype-limits with JFR code > > Please review this simple backport to 11u. The only conflicts were copyright dates. > > Original JBS: https://bugs.openjdk.java.net/browse/JDK-8249875 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/942b669a4ae3 > 11u webrev: https://cr.openjdk.java.net/~phh/8249875/webrev.11u.00/ > > Thanks, > Paul > > From florian.david at datadoghq.com Fri May 28 08:24:24 2021 From: florian.david at datadoghq.com (Florian David) Date: Fri, 28 May 2021 10:24:24 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: Thanks Markus for the review. Here is an updated webrev addressing previous comments. I rebuilt the webrev with new changes in fastdebug just in case. Update webrev link: Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: https://cr.openjdk.java.net/~fdavid/8258414/webrev.04 Original PR: https://github.com/openjdk/jdk/pull/2780 I'm updating the Fix request in the bug report accordingly. Thanks, Florian On Thu, May 27, 2021 at 1:54 PM Markus Gronlund wrote: > Hi Florian and Jaroslav, > > objectSampleCheckpoint.cpp: > ... > 26 #include "jfr/jni/jfrJavaSupport.hpp" > and > 297 JavaThread* const thread = JavaThread::current(); > 298 DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_vm(thread);) > > All this can be removed, because its only used to verify the single state > there is in 11, i.e. "_thread_in_vm." Only in later versions we explicitly > transition between "_thread_in_native" and "_thread_in_vm". > > 287 ResourceMark rm; > and > 293 // caller needs ResourceMark > > With the ResourceMark introduced in 287, the comment at 293 can be removed. > > jfrStackTraceRepository.hpp: > ... > 71 const JfrStackTrace* lookup(unsigned int hash, traceid id) const; > > Can be removed. > > Otherwise looks good, don't need an updated webrev. > > Thank you > Markus > > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Florian David > Sent: den 19 maj 2021 16:26 > To: Jaroslav Bachor?k > Cc: jdk-updates-dev ; Marcus Hirt < > marcus.hirt at datadoghq.com> > Subject: Re: [11u] RFR: 8258414: OldObjectSample events too expensive > > Hi, I'm re-sending this email since Martin Doerr didn't receive it and > found it with the mailing list archives, so maybe others miss it. Martin > reported that he doesn't see test errors anymore with this webrev. > > Hi all, > > Please find an update to the backport. Comments related to > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005880.html > where the previous patch has broken the 11u build have been taken into > account: > > - check_java_thread_in_native is replaced by check_java_thread_in_vm in > ObjectSampleCheckpoint::on_rotation > - ThreadInVMfromNative transition(thread) is removed. That check is part > of the original PR for JDK17 but since some code in JFR was moved from JNI > (in 11) to native in 16, this check is not valid here. > > Build and Tests: > - Linux release and fastdebug builds. Tested with make run-test-tier1 && > make run-test TEST="jtreg:jdk/jfr/". > - Windows release and fastdebug builds. Tested with make run-test-tier1 && > make run-test TEST="jtreg:jdk/jfr/". The > run-test-tier1 test suite did not complete entirely because of some issues > with paths being too long and "vswhere.exe" not able to be run by the test > on my machine. I would feel more confident (especially Windows was broken > by the previous backport) if a maintainer could run the test suite on > Windows. The "jtreg:jdk/jfr/" test suite ran successfully. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ > Original PR: https://github.com/openjdk/jdk/pull/2780 > > Thanks, > Florian DAVID > > On Fri, May 7, 2021 at 6:34 PM Florian David > wrote: > > > Hi all, > > > > Please find an update to the backport. Comments related to > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005 > > 880.html > > > > where the previous patch has broken the 11u build have been taken into > > account: > > > > - check_java_thread_in_native is replaced by check_java_thread_in_vm > > in ObjectSampleCheckpoint::on_rotation > > - ThreadInVMfromNative transition(thread) is removed. That check is > > part of the original PR for JDK17 but since some code in JFR was moved > > from JNI (in 11) to native in 16, this check is not valid here. > > > > Build and Tests: > > - Linux release and fastdebug builds. Tested with make run-test-tier1 > > && make run-test TEST="jtreg:jdk/jfr/". > > - Windows release and fastdebug builds. Tested with make > > run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". The > > run-test-tier1 test suite did not complete entirely because of some > > issues with paths being too long and "vswhere.exe" not able to be run > > by the test on my machine. I would feel more confident (especially > > Windows was broken by the previous backport) if a maintainer could run > > the test suite on Windows. The "jtreg:jdk/jfr/" test suite ran > > successfully. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ > > Original PR: https://github.com/openjdk/jdk/pull/2780 > > > > Thanks, > > Florian DAVID > > > > On Mon, Apr 12, 2021 at 10:38 AM Jaroslav Bachor?k < > > jaroslav.bachorik at datadoghq.com> wrote: > > > >> 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 snazarkin at azul.com Fri May 28 09:10:38 2021 From: snazarkin at azul.com (Sergey Nazarkin) Date: Fri, 28 May 2021 09:10:38 +0000 Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 In-Reply-To: <05D67513-7B96-4B2C-A0B4-DEC2F141B672@amazon.com> References: <05D67513-7B96-4B2C-A0B4-DEC2F141B672@amazon.com> Message-ID: Hi Paul, Pardon me for the intrusion and I?m definitely not a reviewer, but according to original bug isDirectIOSupportedByFS is required for tests running on Solaris. As I?m author of the 8264821 jdk11u backport, I?d like to clarify, for my further activity, should I care about Solaris platform when patches is taken from jdk17? Sergey > On May 28, 2021, at 03:27, Hohensee, Paul wrote: > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Zhengyu Gu > Date: Monday, May 24, 2021 at 6:57 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 > > I would like to backport this patch to 11u for parity with Oracle 11.0.13. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8265231 > The original patch: https://github.com/openjdk/jdk/commit/d1b28e7a > > The original patch does not apply cleanly, due to JDK-8262465 11u > backport diverged from original patch, and preserved > isDirectIOSupportedByFS check. > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8265231-11u/webrev.00/ > > > Test: > DirectIOTest.java passed on Linux x86_64 > > Thanks, > > -Zhengyu > > From martin.doerr at sap.com Fri May 28 12:52:18 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 28 May 2021 12:52:18 +0000 Subject: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u Message-ID: Hi, Oracle has reverted the changes from JDK-8153005 backport in 11.0.12-oracle for interoperability reasons. See: https://bugs.openjdk.java.net/browse/JDK-8267599 and CSR: https://bugs.openjdk.java.net/browse/JDK-8267701 I had to adapt the small test addition from JDK-8266293 (see "// 8266293" comment in ParamsPreferences.java): http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/ Please review. Comments? Best regards, Martin From sean.coffey at oracle.com Fri May 28 13:40:45 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 28 May 2021 14:40:45 +0100 Subject: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u In-Reply-To: References: Message-ID: Martin, you seem to be suggesting a full revert of the JDK-8153005 changes. Note that the Oracle JDK changes only relate to to the default PKCS12 macAlgorithm and macIterationCount (back to HmacPBESHA1 and 100000 respectively). While there are other interoperability concerns with the keystore.pkcs12.certProtectionAlgorithm and keystore.pkcs12.keyProtectionAlgorithm values [1], they relate to JDK 8u/7u where PKCS12 is not the default keystore type. regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8267837 On 28/05/2021 13:52, Doerr, Martin wrote: > Hi, > > Oracle has reverted the changes from JDK-8153005 backport in 11.0.12-oracle for interoperability reasons. See: > https://bugs.openjdk.java.net/browse/JDK-8267599 > and CSR: > https://bugs.openjdk.java.net/browse/JDK-8267701 > > I had to adapt the small test addition from JDK-8266293 (see "// 8266293" comment in ParamsPreferences.java): > http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/ > > Please review. > Comments? > > Best regards, > Martin > From martin.doerr at sap.com Fri May 28 14:02:53 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 28 May 2021 14:02:53 +0000 Subject: AW: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u In-Reply-To: References: , Message-ID: Hi Sean, thank you for your quick reply. I was already hoping to get such feedback. I had read the CSR and I had already thought that you guys didn?t revert the complete change. My problem is that I can?t see what exactly you have done. I?m concerned about making it insecure by creating a mixture of old and new behavior. How can I ensure to get the same behavior as 11.0.12-oracle? Would it be possible to publish your security file and PKCS12KeyStore.java? Otherwise, wouldn?t it be safer to stick with the old behavior until we switch to the new one in a future release? Best regards, Martin Von: Se?n Coffey Datum: Freitag, 28. Mai 2021 um 15:42 An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev , Hohensee, Paul Betreff: Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u Martin, you seem to be suggesting a full revert of the JDK-8153005 changes. Note that the Oracle JDK changes only relate to to the default PKCS12 macAlgorithm and macIterationCount (back to HmacPBESHA1 and 100000 respectively). While there are other interoperability concerns with the keystore.pkcs12.certProtectionAlgorithm and keystore.pkcs12.keyProtectionAlgorithm values [1], they relate to JDK 8u/7u where PKCS12 is not the default keystore type. regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8267837 On 28/05/2021 13:52, Doerr, Martin wrote: > Hi, > > Oracle has reverted the changes from JDK-8153005 backport in 11.0.12-oracle for interoperability reasons. See: > https://bugs.openjdk.java.net/browse/JDK-8267599 > and CSR: > https://bugs.openjdk.java.net/browse/JDK-8267701 > > I had to adapt the small test addition from JDK-8266293 (see "// 8266293" comment in ParamsPreferences.java): > http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/ > > Please review. > Comments? > > Best regards, > Martin > From sean.coffey at oracle.com Fri May 28 14:35:51 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 28 May 2021 15:35:51 +0100 Subject: [External] : AW: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u In-Reply-To: References: Message-ID: here are the main changes that we pushed for JDK 11u: > diff --git a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java > index a62452bdcd..441f2b651e 100644 > --- a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java > +++ b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java > @@ -101,10 +101,10 @@ public final class PKCS12KeyStore extends KeyStoreSpi { > = "PBEWithHmacSHA256AndAES_256"; > private static final String DEFAULT_KEY_PBE_ALGORITHM > = "PBEWithHmacSHA256AndAES_256"; > - private static final String DEFAULT_MAC_ALGORITHM = "HmacPBESHA256"; > + private static final String DEFAULT_MAC_ALGORITHM = "HmacPBESHA1"; > private static final int DEFAULT_CERT_PBE_ITERATION_COUNT = 10000; > private static final int DEFAULT_KEY_PBE_ITERATION_COUNT = 10000; > - private static final int DEFAULT_MAC_ITERATION_COUNT = 10000; > + private static final int DEFAULT_MAC_ITERATION_COUNT = 100000; > > // Legacy settings. Used when "keystore.pkcs12.legacy" is set. > private static final String LEGACY_CERT_PBE_ALGORITHM > diff --git a/src/java.base/share/conf/security/java.security b/src/java.base/share/conf/security/java.security > index b0c5beccf6..893567071c 100644 > --- a/src/java.base/share/conf/security/java.security > +++ b/src/java.base/share/conf/security/java.security > @@ -1200,12 +1200,12 @@ jceks.key.serialFilter = java.base/java.lang.Enum;java.base/java.security.KeyRep > # The algorithm used to calculate the optional MacData at the end of a PKCS12 > # file. This can be any HmacPBE algorithm defined in the Mac section of the > # Java Security Standard Algorithm Names Specification. When set to "NONE", > -# no Mac is generated. The default value is "HmacPBESHA256". > -#keystore.pkcs12.macAlgorithm = HmacPBESHA256 > +# no Mac is generated. The default value is "HmacPBESHA1". > +#keystore.pkcs12.macAlgorithm = HmacPBESHA1 > > # The iteration count used by the MacData algorithm. This value must be a > -# positive integer. The default value is 10000. > -#keystore.pkcs12.macIterationCount = 10000 > +# positive integer. The default value is 100000. > +#keystore.pkcs12.macIterationCount = 100000 > > # > # Enhanced exception message information regards, Sean. On 28/05/2021 15:02, Doerr, Martin wrote: > > Hi Sean, > > thank you for your quick reply. I was already hoping to get such feedback. > > I had read the CSR and I had already thought that you guys didn?t > revert the complete change. > > My problem is that I can?t see what exactly you have done. > > I?m concerned about making it insecure by creating a mixture of old > and new behavior. How can I ensure to get the same behavior as > 11.0.12-oracle? > > Would it be possible to publish your security file and > PKCS12KeyStore.java? > > Otherwise, wouldn?t it be safer to stick with the old behavior until > we switch to the new one in a future release? > > Best regards, > > Martin > > *Von: *Se?n Coffey > *Datum: *Freitag, 28. Mai 2021 um 15:42 > *An: *Doerr, Martin , > jdk-updates-dev at openjdk.java.net , > security-dev , Hohensee, Paul > > *Betreff: *Re: [11u] RFR: 8267599: Revert the change to the default > PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u > > Martin, > > you seem to be suggesting a full revert of the JDK-8153005 changes. Note > that the Oracle JDK changes only relate to to the default PKCS12 > macAlgorithm and macIterationCount (back to HmacPBESHA1 and 100000 > respectively). While there are other interoperability concerns with the > keystore.pkcs12.certProtectionAlgorithm and > keystore.pkcs12.keyProtectionAlgorithm values [1], they relate to JDK > 8u/7u where PKCS12 is not the default keystore type. > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8267837 > > > On 28/05/2021 13:52, Doerr, Martin wrote: > > Hi, > > > > Oracle has reverted the changes from JDK-8153005 backport in > 11.0.12-oracle for interoperability reasons. See: > > https://bugs.openjdk.java.net/browse/JDK-8267599 > > > and CSR: > > https://bugs.openjdk.java.net/browse/JDK-8267701 > > > > > I had to adapt the small test addition from JDK-8266293 (see "// > 8266293" comment in ParamsPreferences.java): > > > http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/ > > > > > Please review. > > Comments? > > > > Best regards, > > Martin > > > From martin.doerr at sap.com Fri May 28 15:03:20 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 28 May 2021 15:03:20 +0000 Subject: AW: [External] : AW: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u In-Reply-To: References: , Message-ID: Hi Sean, thank you very much! I was concerned to miss anything. But it is really that simple ?? I?ll prepare a new webrev. Best regards, Martin Von: Se?n Coffey Datum: Freitag, 28. Mai 2021 um 16:36 An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev , Hohensee, Paul Betreff: Re: [External] : AW: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u here are the main changes that we pushed for JDK 11u: diff --git a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java index a62452bdcd..441f2b651e 100644 --- a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java +++ b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java @@ -101,10 +101,10 @@ public final class PKCS12KeyStore extends KeyStoreSpi { = "PBEWithHmacSHA256AndAES_256"; private static final String DEFAULT_KEY_PBE_ALGORITHM = "PBEWithHmacSHA256AndAES_256"; - private static final String DEFAULT_MAC_ALGORITHM = "HmacPBESHA256"; + private static final String DEFAULT_MAC_ALGORITHM = "HmacPBESHA1"; private static final int DEFAULT_CERT_PBE_ITERATION_COUNT = 10000; private static final int DEFAULT_KEY_PBE_ITERATION_COUNT = 10000; - private static final int DEFAULT_MAC_ITERATION_COUNT = 10000; + private static final int DEFAULT_MAC_ITERATION_COUNT = 100000; // Legacy settings. Used when "keystore.pkcs12.legacy" is set. private static final String LEGACY_CERT_PBE_ALGORITHM diff --git a/src/java.base/share/conf/security/java.security b/src/java.base/share/conf/security/java.security index b0c5beccf6..893567071c 100644 --- a/src/java.base/share/conf/security/java.security +++ b/src/java.base/share/conf/security/java.security @@ -1200,12 +1200,12 @@ jceks.key.serialFilter = java.base/java.lang.Enum;java.base/java.security.KeyRep # The algorithm used to calculate the optional MacData at the end of a PKCS12 # file. This can be any HmacPBE algorithm defined in the Mac section of the # Java Security Standard Algorithm Names Specification. When set to "NONE", -# no Mac is generated. The default value is "HmacPBESHA256". -#keystore.pkcs12.macAlgorithm = HmacPBESHA256 +# no Mac is generated. The default value is "HmacPBESHA1". +#keystore.pkcs12.macAlgorithm = HmacPBESHA1 # The iteration count used by the MacData algorithm. This value must be a -# positive integer. The default value is 10000. -#keystore.pkcs12.macIterationCount = 10000 +# positive integer. The default value is 100000. +#keystore.pkcs12.macIterationCount = 100000 # # Enhanced exception message information regards, Sean. On 28/05/2021 15:02, Doerr, Martin wrote: Hi Sean, thank you for your quick reply. I was already hoping to get such feedback. I had read the CSR and I had already thought that you guys didn?t revert the complete change. My problem is that I can?t see what exactly you have done. I?m concerned about making it insecure by creating a mixture of old and new behavior. How can I ensure to get the same behavior as 11.0.12-oracle? Would it be possible to publish your security file and PKCS12KeyStore.java? Otherwise, wouldn?t it be safer to stick with the old behavior until we switch to the new one in a future release? Best regards, Martin Von: Se?n Coffey Datum: Freitag, 28. Mai 2021 um 15:42 An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev , Hohensee, Paul Betreff: Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u Martin, you seem to be suggesting a full revert of the JDK-8153005 changes. Note that the Oracle JDK changes only relate to to the default PKCS12 macAlgorithm and macIterationCount (back to HmacPBESHA1 and 100000 respectively). While there are other interoperability concerns with the keystore.pkcs12.certProtectionAlgorithm and keystore.pkcs12.keyProtectionAlgorithm values [1], they relate to JDK 8u/7u where PKCS12 is not the default keystore type. regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8267837 On 28/05/2021 13:52, Doerr, Martin wrote: > Hi, > > Oracle has reverted the changes from JDK-8153005 backport in 11.0.12-oracle for interoperability reasons. See: > https://bugs.openjdk.java.net/browse/JDK-8267599 > and CSR: > https://bugs.openjdk.java.net/browse/JDK-8267701 > > I had to adapt the small test addition from JDK-8266293 (see "// 8266293" comment in ParamsPreferences.java): > http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/ > > Please review. > Comments? > > Best regards, > Martin > From hohensee at amazon.com Fri May 28 16:11:44 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 28 May 2021 16:11:44 +0000 Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 Message-ID: <53155FF4-CBEC-45BB-90CC-838B5523762A@amazon.com> Hi, Sergey, Thanks for pointing this out. Looking at it again, you're correct. Only the change to DirectoIOTest.java should be retained: do you agree? If so, Zhengyu, would you please revise the patch? On the topic of Solaris support, I surveyed Adopt, Alibaba Dragonwell, Amazon Corretto, Azul Zulu, and Oracle. Only Oracle makes Solaris JDK 11 binaries available (only Solaris-Sparc64, at that). Illumos distros are available, and they may run JDK 11, but if I were an Illumos user I wouldn't be using Java, given that Solaris support has been gone since JDK 15. Given all that, it's an open question to me whether OpenJDK 11 should continue to support Solaris and/or Sparc. Paul ?-----Original Message----- From: Sergey Nazarkin Date: Friday, May 28, 2021 at 2:10 AM To: "Hohensee, Paul" Cc: Zhengyu Gu , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 Hi Paul, Pardon me for the intrusion and I?m definitely not a reviewer, but according to original bug isDirectIOSupportedByFS is required for tests running on Solaris. As I?m author of the 8264821 jdk11u backport, I?d like to clarify, for my further activity, should I care about Solaris platform when patches is taken from jdk17? Sergey > On May 28, 2021, at 03:27, Hohensee, Paul wrote: > > Lgtm. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of Zhengyu Gu > Date: Monday, May 24, 2021 at 6:57 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 > > I would like to backport this patch to 11u for parity with Oracle 11.0.13. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8265231 > The original patch: https://github.com/openjdk/jdk/commit/d1b28e7a > > The original patch does not apply cleanly, due to JDK-8262465 11u > backport diverged from original patch, and preserved > isDirectIOSupportedByFS check. > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8265231-11u/webrev.00/ > > > Test: > DirectIOTest.java passed on Linux x86_64 > > Thanks, > > -Zhengyu > > From martin.doerr at sap.com Fri May 28 16:17:33 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 28 May 2021 16:17:33 +0000 Subject: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u In-Reply-To: References: , , Message-ID: Hi, here?s my new webrev for reverting the pkcs12.macAlgorithm and macIterationCount changes from the JDK-8153005 backport: http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.01/ Oracle?s JBS issue: https://bugs.openjdk.java.net/browse/JDK-8267599 and CSR: https://bugs.openjdk.java.net/browse/JDK-8267701 Thanks to Sean for confirming that there?s nothing else to do in the security file and PKCS12KeyStore.java. So, I only had to adapt the tests. Please review. Best regards, Martin From sean.coffey at oracle.com Fri May 28 16:50:54 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 28 May 2021 17:50:54 +0100 Subject: [External] : Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u In-Reply-To: References: Message-ID: <8a62a00d-f843-5ee4-4b17-2fede01ef703@oracle.com> Looks good! regards, Sean. On 28/05/2021 17:17, Doerr, Martin wrote: > > Hi, > > here?s my new webrev for reverting the pkcs12.macAlgorithm and > macIterationCount changes from the JDK-8153005 > backport: > > http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.01/ > > > Oracle?s JBS issue: > > https://bugs.openjdk.java.net/browse/JDK-8267599 > > > and CSR: > > https://bugs.openjdk.java.net/browse/JDK-8267701 > > > Thanks to Sean for confirming that there?s nothing else to do in the > security file and PKCS12KeyStore.java. > > So, I only had to adapt the tests. > > Please review. > > Best regards, > > Martin > From martin.doerr at sap.com Fri May 28 16:52:22 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 28 May 2021 16:52:22 +0000 Subject: AW: [External] : Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u In-Reply-To: <8a62a00d-f843-5ee4-4b17-2fede01ef703@oracle.com> References: , <8a62a00d-f843-5ee4-4b17-2fede01ef703@oracle.com> Message-ID: Thank you, Sean, for your review and all your help! Best regards, Martin Von: Se?n Coffey Datum: Freitag, 28. Mai 2021 um 18:51 An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev , Hohensee, Paul Betreff: Re: [External] : Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u Looks good! regards, Sean. On 28/05/2021 17:17, Doerr, Martin wrote: Hi, here?s my new webrev for reverting the pkcs12.macAlgorithm and macIterationCount changes from the JDK-8153005 backport: http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.01/ Oracle?s JBS issue: https://bugs.openjdk.java.net/browse/JDK-8267599 and CSR: https://bugs.openjdk.java.net/browse/JDK-8267701 Thanks to Sean for confirming that there?s nothing else to do in the security file and PKCS12KeyStore.java. So, I only had to adapt the tests. Please review. Best regards, Martin From denghui.ddh at alibaba-inc.com Mon May 31 06:44:07 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 31 May 2021 14:44:07 +0800 Subject: =?UTF-8?B?UGluZz8gWzExdV0gUkZSIDgyNjY2NDI6IEltcHJvdmUgUmVzb2x2ZWRNZXRob2RUYWJsZSBo?= =?UTF-8?B?YXNoIGZ1bmN0aW9u?= Message-ID: Gentle ping? ------------------------------------------------------------------ From:???(??) Send Time:2021?5?21?(???) 14:23 To:jdk-updates-dev at openjdk.java.net Subject:[11u] RFR 8266642: Improve ResolvedMethodTable hash function Hi, May I have a review of this small backport to 11u: JBS: https://bugs.openjdk.java.net/browse/JDK-8266642 Original patch: https://git.openjdk.java.net/jdk/pull/3901.diff webrev: http://cr.openjdk.java.net/~ddong/8266642/webrev.00/ This patch is almost a clean backport except there needs a manual adjustment at 'method_hash' since the context is different. For the problem that the patch wants to solve, please refer to: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-May/048014.html testing: hotspot_tier1 jdk_tier1 Thanks, Denghui Dong From martin.doerr at sap.com Mon May 31 09:47:58 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 31 May 2021 09:47:58 +0000 Subject: AW: [DMARC FAILURE] Ping? [11u] RFR 8266642: Improve ResolvedMethodTable hash function In-Reply-To: References: Message-ID: Hi Denghui Dong, looks good to me. Best regards, Martin Von: jdk-updates-dev im Auftrag von Denghui Dong Datum: Montag, 31. Mai 2021 um 08:45 An: jdk-updates-dev at openjdk.java.net Betreff: [DMARC FAILURE] Ping? [11u] RFR 8266642: Improve ResolvedMethodTable hash function Gentle ping? ------------------------------------------------------------------ From:???(??) Send Time:2021?5?21?(???) 14:23 To:jdk-updates-dev at openjdk.java.net Subject:[11u] RFR 8266642: Improve ResolvedMethodTable hash function Hi, May I have a review of this small backport to 11u: JBS: https://bugs.openjdk.java.net/browse/JDK-8266642 Original patch: https://git.openjdk.java.net/jdk/pull/3901.diff webrev: http://cr.openjdk.java.net/~ddong/8266642/webrev.00/ This patch is almost a clean backport except there needs a manual adjustment at 'method_hash' since the context is different. For the problem that the patch wants to solve, please refer to: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-May/048014.html testing: hotspot_tier1 jdk_tier1 Thanks, Denghui Dong From snazarkin at azul.com Mon May 31 10:45:06 2021 From: snazarkin at azul.com (Sergey Nazarkin) Date: Mon, 31 May 2021 10:45:06 +0000 Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 In-Reply-To: <53155FF4-CBEC-45BB-90CC-838B5523762A@amazon.com> References: <53155FF4-CBEC-45BB-90CC-838B5523762A@amazon.com> Message-ID: <6AD96F98-0F6E-4D44-B3B3-C0478B0A80A9@azul.com> Hi Paul, DirectIOTest changes are OK but not necessary since those are just minor refactoring that doesn?t affect other tests. Sergey > On May 28, 2021, at 19:11, Hohensee, Paul wrote: > > Hi, Sergey, > > Thanks for pointing this out. Looking at it again, you're correct. Only the change to DirectoIOTest.java should be retained: do you agree? If so, Zhengyu, would you please revise the patch? > > On the topic of Solaris support, I surveyed Adopt, Alibaba Dragonwell, Amazon Corretto, Azul Zulu, and Oracle. Only Oracle makes Solaris JDK 11 binaries available (only Solaris-Sparc64, at that). Illumos distros are available, and they may run JDK 11, but if I were an Illumos user I wouldn't be using Java, given that Solaris support has been gone since JDK 15. Given all that, it's an open question to me whether OpenJDK 11 should continue to support Solaris and/or Sparc. > > Paul > > ?-----Original Message----- > From: Sergey Nazarkin > Date: Friday, May 28, 2021 at 2:10 AM > To: "Hohensee, Paul" > Cc: Zhengyu Gu , "jdk-updates-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 > > Hi Paul, > > Pardon me for the intrusion and I?m definitely not a reviewer, but according to original bug isDirectIOSupportedByFS is required for tests running on Solaris. As I?m author of the 8264821 jdk11u backport, I?d like to clarify, for my further activity, should I care about Solaris platform when patches is taken from jdk17? > > Sergey > > > > >> On May 28, 2021, at 03:27, Hohensee, Paul wrote: >> >> Lgtm. >> >> Thanks, >> Paul >> >> -----Original Message----- >> From: jdk-updates-dev on behalf of Zhengyu Gu >> Date: Monday, May 24, 2021 at 6:57 AM >> To: "jdk-updates-dev at openjdk.java.net" >> Subject: [11u] RFR 8265231: (fc) ReadDirect and WriteDirect tests fail after fix for JDK-8264821 >> >> I would like to backport this patch to 11u for parity with Oracle 11.0.13. >> >> The original bug: https://bugs.openjdk.java.net/browse/JDK-8265231 >> The original patch: https://github.com/openjdk/jdk/commit/d1b28e7a >> >> The original patch does not apply cleanly, due to JDK-8262465 11u >> backport diverged from original patch, and preserved >> isDirectIOSupportedByFS check. >> >> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8265231-11u/webrev.00/ >> >> >> Test: >> DirectIOTest.java passed on Linux x86_64 >> >> Thanks, >> >> -Zhengyu >> >> > > From markus.gronlund at oracle.com Mon May 31 11:59:47 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 31 May 2021 11:59:47 +0000 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: Hi, Looks good, I have only smoke-tested this on some available x64 platforms (Linux, Windows, Mac) ? I have no status information about other platforms / targets. Thanks Markus From: Florian David Sent: den 28 maj 2021 10:24 To: Markus Gronlund Cc: Jaroslav Bachor?k ; jdk-updates-dev ; Marcus Hirt Subject: Re: [11u] RFR: 8258414: OldObjectSample events too expensive Thanks Markus for the review. Here is an updated webrev addressing previous comments. I rebuilt the webrev with new changes in fastdebug just in case. Update webrev link: Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: https://cr.openjdk.java.net/~fdavid/8258414/webrev.04 Original PR: https://github.com/openjdk/jdk/pull/2780 I'm updating the Fix request in the bug report accordingly. Thanks, Florian On Thu, May 27, 2021 at 1:54 PM Markus Gronlund > wrote: Hi Florian and Jaroslav, objectSampleCheckpoint.cpp: ... 26 #include "jfr/jni/jfrJavaSupport.hpp" and 297 JavaThread* const thread = JavaThread::current(); 298 DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_vm(thread);) All this can be removed, because its only used to verify the single state there is in 11, i.e. "_thread_in_vm." Only in later versions we explicitly transition between "_thread_in_native" and "_thread_in_vm". 287 ResourceMark rm; and 293 // caller needs ResourceMark With the ResourceMark introduced in 287, the comment at 293 can be removed. jfrStackTraceRepository.hpp: ... 71 const JfrStackTrace* lookup(unsigned int hash, traceid id) const; Can be removed. Otherwise looks good, don't need an updated webrev. Thank you Markus -----Original Message----- From: jdk-updates-dev > On Behalf Of Florian David Sent: den 19 maj 2021 16:26 To: Jaroslav Bachor?k > Cc: jdk-updates-dev >; Marcus Hirt > Subject: Re: [11u] RFR: 8258414: OldObjectSample events too expensive Hi, I'm re-sending this email since Martin Doerr didn't receive it and found it with the mailing list archives, so maybe others miss it. Martin reported that he doesn't see test errors anymore with this webrev. Hi all, Please find an update to the backport. Comments related to https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005880.html where the previous patch has broken the 11u build have been taken into account: - check_java_thread_in_native is replaced by check_java_thread_in_vm in ObjectSampleCheckpoint::on_rotation - ThreadInVMfromNative transition(thread) is removed. That check is part of the original PR for JDK17 but since some code in JFR was moved from JNI (in 11) to native in 16, this check is not valid here. Build and Tests: - Linux release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". - Windows release and fastdebug builds. Tested with make run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". The run-test-tier1 test suite did not complete entirely because of some issues with paths being too long and "vswhere.exe" not able to be run by the test on my machine. I would feel more confident (especially Windows was broken by the previous backport) if a maintainer could run the test suite on Windows. The "jtreg:jdk/jfr/" test suite ran successfully. Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ Original PR: https://github.com/openjdk/jdk/pull/2780 Thanks, Florian DAVID On Fri, May 7, 2021 at 6:34 PM Florian David > wrote: > Hi all, > > Please find an update to the backport. Comments related to > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005 > 880.html > > where the previous patch has broken the 11u build have been taken into > account: > > - check_java_thread_in_native is replaced by check_java_thread_in_vm > in ObjectSampleCheckpoint::on_rotation > - ThreadInVMfromNative transition(thread) is removed. That check is > part of the original PR for JDK17 but since some code in JFR was moved > from JNI (in 11) to native in 16, this check is not valid here. > > Build and Tests: > - Linux release and fastdebug builds. Tested with make run-test-tier1 > && make run-test TEST="jtreg:jdk/jfr/". > - Windows release and fastdebug builds. Tested with make > run-test-tier1 && make run-test TEST="jtreg:jdk/jfr/". The > run-test-tier1 test suite did not complete entirely because of some > issues with paths being too long and "vswhere.exe" not able to be run > by the test on my machine. I would feel more confident (especially > Windows was broken by the previous backport) if a maintainer could run > the test suite on Windows. The "jtreg:jdk/jfr/" test suite ran > successfully. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.03/ > Original PR: https://github.com/openjdk/jdk/pull/2780 > > Thanks, > Florian DAVID > > On Mon, Apr 12, 2021 at 10:38 AM Jaroslav Bachor?k < > jaroslav.bachorik at datadoghq.com> wrote: > >> 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