From sgehwolf at openjdk.org Tue Jul 1 09:28:48 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 1 Jul 2025 09:28:48 GMT Subject: [jdk8u-dev] RFR: 8360166: CodeSource.implies(): Wildcard host fails to imply specific host In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 05:00:02 GMT, Lei Zhu wrote: > Please review this PR which use hostname not cname to check imply. And alse add test case. > > If there are any problems please let me know and I will correct them promptly. This needs to go into later releases before a backport to JDK 8 can be evaluated. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/663#issuecomment-3022943960 From dzhang at openjdk.org Tue Jul 1 12:59:53 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 1 Jul 2025 12:59:53 GMT Subject: [jdk8u-dev] RFR: 8199138: Add RISC-V support to Zero [v2] In-Reply-To: References:

Message-ID: <3JMpBBXOodXHQTeP3Br5LSmfHxiAM5KTN0LlCZSjrHs=.77f84b89-695e-4899-b030-b2ecea25d733@github.com> On Tue, 3 Sep 2024 11:34:42 GMT, Dingli Zhang wrote: >> Hi all, >> >> I'd like to backport this patch to jdk8u. Since most linux distributions support riscv64 and provide zero version jdk8 for riscv64. However, we may need to do some workarounds each time we upgrade the version, so I think it is helpful to provide zero support for riscv64 here. >> >> `common/autoconf/build-aux/config.guess` and `hotspot/src/os/linux/vm/os_linux.cpp` do not apply cleanly due to context difference, but it is easy to resolve them manually. `common/autoconf/platform.m4` just changed file path and remove test of `x$OPENJDK_$1_CPU`. >> >> `common/autoconf/generated-configure.sh` regenerated by `bash common/autoconf/autogen.sh`. I used autoconf-2.69 and build from the [source](https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz) . But it looks a bit different from the one generated in the repo. I also tried autoconf-2.69 that comes with ubuntu 20.04 and the generated file is similar to the one in https://github.com/openjdk/jdk8u-dev/pull/413. I'm not quite sure which version of autoconf2.69 to use, if anyone has a better suggestion or is willing to help me generate a different one, I'd appreciate it! >> >> Both cross-compile build and native build on riscv64 hardware is tested. >> >> ### cross-compile on x86 >> #### boot jdk >> >> openjdk version "1.8.0_43" >> OpenJDK Runtime Environment (build 1.8.0_43-b03) >> OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode) >> >> #### run on qemu >> >> openjdk version "1.8.0_432-internal" >> OpenJDK Runtime Environment (build 1.8.0_432-internal-zhangdingli_2024_09_02_21_37-b00) >> OpenJDK 64-Bit Zero VM (build 25.432-b00, interpreted mode) >> >> ### native build on lp4a >> #### boot jdk >> >> openjdk version "1.8.0_412" >> OpenJDK Runtime Environment Bisheng (build 1.8.0_412-b08) >> OpenJDK 64-Bit Zero VM Bisheng (build 25.412-b08, interpreted mode) >> >> #### run on lp4a >> >> openjdk version "1.8.0_432-internal" >> OpenJDK Runtime Environment (build 1.8.0_432-internal-openeuler_2024_09_02_21_38-b00) >> OpenJDK 64-Bit Zero VM (build 25.432-b00, interpreted mode) >> >> >> Thanks, >> Dingli > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Put EM_RISCV after definition of EM_LOONGARCH bot, please keep it open ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/573#issuecomment-3023911165 From gnu_andrew at member.fsf.org Tue Jul 1 21:36:13 2025 From: gnu_andrew at member.fsf.org (Andrew Hughes) Date: Tue, 1 Jul 2025 22:36:13 +0100 Subject: [FREEZE] 8u462 NOW FROZEN Message-ID: The release forest: https://github.com/openjdk/jdk8u is frozen as of 2025-06-28 in preparation for release on or after 2025-07-15. The final pre-release tag is jdk8u462-b07. [0] The final release tag will thus be no lower than jdk8u462-b08. [0] https://github.com/openjdk/jdk8u/releases/tag/jdk8u462-b07 Thanks, -- Andrew :) Pronouns: he / him or they / them PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From duke at openjdk.org Wed Jul 2 04:45:36 2025 From: duke at openjdk.org (hanguanqiang) Date: Wed, 2 Jul 2025 04:45:36 GMT Subject: [jdk8u-dev] RFR: 8358568: C2 compilation hits "must have a monitor" assert with -XX:-GenerateSynchronizationCode Message-ID: This PR fixes JDK-8358568, a JVM crash triggered when running with -XX:-GenerateSynchronizationCode Problem? When synchronization code generation is disabled by -XX:-GenerateSynchronizationCode, the compiler?s do_monitor_exit() method still tries to access monitor objects without checking if any monitors exist.This causes an assertion failure and JVM crash. Root Cause? Parse::do_monitor_exit() calls shared_unlock() using monitor info unconditionally,but with GenerateSynchronizationCode disabled, no monitor info is available, leading to invalid access. Fix Add a check in do_monitor_exit() to skip monitor unlocking if GenerateSynchronizationCode is false, avoiding invalid monitor access and preventing the crash. ------------- Commit messages: - Merge pull request #1 from hgqxjj/hgqxjj-patch-1 - [JDK-8358568] Fix crash caused by -XX:-GenerateSynchronizationCode Changes: https://git.openjdk.org/jdk8u-dev/pull/664/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=664&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358568 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/664.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/664/head:pull/664 PR: https://git.openjdk.org/jdk8u-dev/pull/664 From yongheng_hgq at 126.com Wed Jul 2 14:47:56 2025 From: yongheng_hgq at 126.com (h) Date: Wed, 2 Jul 2025 22:47:56 +0800 (CST) Subject: =?GBK?Q?RFR:_8358568=A3=BAC2_compilation_hits_"must_have_a_mon?= =?GBK?Q?itor"_assert_with_-XX:-GenerateSynchronizationCode?= Message-ID: <160650f8.a4b9.197cb9bd2ff.Coremail.yongheng_hgq@126.com> Hi all, Please review this fix for JDK-8358568. It addresses a crash caused by accessing monitor info when -XX:-GenerateSynchronizationCode is set. The fix adds a guard in Parse::do_monitor_exit() to avoid the crash. Thank you in advance.Changes: https://github.com/openjdk/jdk8u-dev/pull/664/fileswebrev: https://openjdk.github.io/cr/?repo=jdk8u-dev&pr=664&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358568 Patch: https://git.openjdk.org/jdk8u-dev/pull/664.diff PR: https://github.com/openjdk/jdk8u-dev/pull/664 BR -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at openjdk.org Wed Jul 2 16:10:47 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 2 Jul 2025 16:10:47 GMT Subject: [jdk8u-dev] RFR: 8358568: C2 compilation hits "must have a monitor" assert with -XX:-GenerateSynchronizationCode In-Reply-To: References: Message-ID: <3l7-mTJxh7RVabqb4dZioTYA2Ozbhj-AYcKFFCCIxJw=.2fc9cd61-2dd4-4e1d-96ca-db0a28003358@github.com> On Wed, 2 Jul 2025 04:30:56 GMT, hanguanqiang wrote: > This PR fixes JDK-8358568, a JVM crash triggered when running with -XX:-GenerateSynchronizationCode > > Problem? > When synchronization code generation is disabled by -XX:-GenerateSynchronizationCode, the compiler?s do_monitor_exit() method still tries to access monitor objects without checking if any monitors exist.This causes an assertion failure and JVM crash. > > Root Cause? > Parse::do_monitor_exit() calls shared_unlock() using monitor info unconditionally,but with GenerateSynchronizationCode disabled, no monitor info is available, leading to invalid access. > > Fix > Add a check in do_monitor_exit() to skip monitor unlocking if GenerateSynchronizationCode is false, avoiding invalid monitor access and preventing the crash. Please fix this issue in jdk head. Repo is: https://github.com/openjdk/jdk Once a fix is in the latest JDK a backport can be proposed. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/664#issuecomment-3028437671 From duke at openjdk.org Wed Jul 2 17:12:49 2025 From: duke at openjdk.org (Lei Zhu) Date: Wed, 2 Jul 2025 17:12:49 GMT Subject: [jdk8u-dev] Withdrawn: 8360166: CodeSource.implies(): Wildcard host fails to imply specific host In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 05:00:02 GMT, Lei Zhu wrote: > Please review this PR which use hostname not cname to check imply. And alse add test case. > > If there are any problems please let me know and I will correct them promptly. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/663 From duke at openjdk.org Thu Jul 3 02:09:49 2025 From: duke at openjdk.org (hanguanqiang) Date: Thu, 3 Jul 2025 02:09:49 GMT Subject: [jdk8u-dev] RFR: 8358568: C2 compilation hits "must have a monitor" assert with -XX:-GenerateSynchronizationCode In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 04:30:56 GMT, hanguanqiang wrote: > This PR fixes JDK-8358568, a JVM crash triggered when running with -XX:-GenerateSynchronizationCode > > Problem? > When synchronization code generation is disabled by -XX:-GenerateSynchronizationCode, the compiler?s do_monitor_exit() method still tries to access monitor objects without checking if any monitors exist.This causes an assertion failure and JVM crash. > > Root Cause? > Parse::do_monitor_exit() calls shared_unlock() using monitor info unconditionally,but with GenerateSynchronizationCode disabled, no monitor info is available, leading to invalid access. > > Fix > Add a check in do_monitor_exit() to skip monitor unlocking if GenerateSynchronizationCode is false, avoiding invalid monitor access and preventing the crash. Submitting this change to mainline as requested. See new PR: https://github.com/openjdk/jdk/pull/26108 ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/664#issuecomment-3030247394 From duke at openjdk.org Thu Jul 3 02:09:49 2025 From: duke at openjdk.org (hanguanqiang) Date: Thu, 3 Jul 2025 02:09:49 GMT Subject: [jdk8u-dev] Withdrawn: 8358568: C2 compilation hits "must have a monitor" assert with -XX:-GenerateSynchronizationCode In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 04:30:56 GMT, hanguanqiang wrote: > This PR fixes JDK-8358568, a JVM crash triggered when running with -XX:-GenerateSynchronizationCode > > Problem? > When synchronization code generation is disabled by -XX:-GenerateSynchronizationCode, the compiler?s do_monitor_exit() method still tries to access monitor objects without checking if any monitors exist.This causes an assertion failure and JVM crash. > > Root Cause? > Parse::do_monitor_exit() calls shared_unlock() using monitor info unconditionally,but with GenerateSynchronizationCode disabled, no monitor info is available, leading to invalid access. > > Fix > Add a check in do_monitor_exit() to skip monitor unlocking if GenerateSynchronizationCode is false, avoiding invalid monitor access and preventing the crash. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/664 From sgehwolf at openjdk.org Thu Jul 3 09:41:45 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 3 Jul 2025 09:41:45 GMT Subject: [jdk8u-dev] RFR: 8348228: Major performance regression in GetMethodDeclaringClass and other JVMTI Method functions In-Reply-To: References: Message-ID: On Fri, 30 May 2025 13:31:05 GMT, Zhengyu Gu wrote: > Please review this patch for the parity of Oracle's [JDK-8185348](https://bugs.openjdk.org/browse/JDK-8185348). > > Oracle's patch is non-public. This patch is based on @sspitsyn's comments in JDK-8185348 and consistent with JDK9's implementation. > > Before patch, slowjvmti test case from JDK-8185348: > 16366ms > > After patch: > 3ms @zhengyu123 https://github.com/openjdk/jdk8u-dev/pull/656#issuecomment-2999799800 needs to be addressed before this can be approved. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/656#issuecomment-3031591648 From duke at openjdk.org Thu Jul 3 12:57:57 2025 From: duke at openjdk.org (Antonio Vieiro) Date: Thu, 3 Jul 2025 12:57:57 GMT Subject: [jdk8u-dev] RFR: 8358538: Update GHA Windows runner to 2025 Message-ID: Backport of [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) from JDK11 that uses the new `windows-2025` GHA runner, that is replacing the old `windows-2019` GHA runner since 2025-06-30. The backport is not clean, since the GHA configuration is completely different from JDK11. JDK8 still builds with Visual Studio 2017, so there's no need to backport [JDK-8360042](https://bugs.openjdk.org/browse/JDK-8360042), nor to change any other setting. Build should be clean, but for the `jdk_security_infra` test failures, that are well known to fail in JDK8 (as they should in JDK11), and are unrelated. ------------- Commit messages: - Backport 0927ca70e66ef27b38cbf5c0dd2851c796218067 Changes: https://git.openjdk.org/jdk8u-dev/pull/665/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=665&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358538 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/665.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/665/head:pull/665 PR: https://git.openjdk.org/jdk8u-dev/pull/665 From duke at openjdk.org Thu Jul 3 13:06:44 2025 From: duke at openjdk.org (Antonio Vieiro) Date: Thu, 3 Jul 2025 13:06:44 GMT Subject: [jdk8u-dev] RFR: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 12:53:08 GMT, Antonio Vieiro wrote: > Backport of [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) from JDK11 that uses the new `windows-2025` GHA runner, that is replacing the old `windows-2019` GHA runner since 2025-06-30. The backport is not clean, since the GHA configuration is completely different from JDK11. > > JDK8 still builds with Visual Studio 2017, so there's no need to backport [JDK-8360042](https://bugs.openjdk.org/browse/JDK-8360042), nor to change any other setting. > > Build should be clean, but for the `jdk_security_infra` test failures, that are well known to fail in JDK8 (as they should in JDK11), and are unrelated. Mmm.. there's a hotspot/tier1 on Linux (unrelated). Will be worth investigating in the future. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/665#issuecomment-3032193728 From syan at openjdk.org Mon Jul 7 13:46:23 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 7 Jul 2025 13:46:23 GMT Subject: [jdk8u-dev] RFR: 8081734: ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu. Message-ID: Hi all, This is clean backport to fix the test run time outed which the tested machine has huge cpu core number. Change has been verified locally, test-fix only, no risk. ------------- Commit messages: - Backport 6e48caf2507d4a45e1861ee699a32a5e459d70c2 Changes: https://git.openjdk.org/jdk8u-dev/pull/666/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=666&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8081734 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/666.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/666/head:pull/666 PR: https://git.openjdk.org/jdk8u-dev/pull/666 From sgehwolf at openjdk.org Mon Jul 7 14:52:50 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 7 Jul 2025 14:52:50 GMT Subject: [jdk8u-dev] RFR: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 12:53:08 GMT, Antonio Vieiro wrote: > Backport of [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) from JDK11 that uses the new `windows-2025` GHA runner, that is replacing the old `windows-2019` GHA runner since 2025-06-30. The backport is not clean, since the GHA configuration is completely different from JDK11. > > JDK8 still builds with Visual Studio 2017, so there's no need to backport [JDK-8360042](https://bugs.openjdk.org/browse/JDK-8360042), nor to change any other setting. > > Build should be clean, but for the `jdk_security_infra` test failures, that are well known to fail in JDK8 (as they should in JDK11), and are unrelated. Seems OK to me and #666 shows this in the summary so we need to get this in ASAP: Windows Server 2019 has been retired. The Windows Server 2019 image has been removed as of 2025-06-30. For more details, see https://github.com/actions/runner-images/issues/12045 ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/665#pullrequestreview-2994221113 From duke at openjdk.org Mon Jul 7 15:29:42 2025 From: duke at openjdk.org (duke) Date: Mon, 7 Jul 2025 15:29:42 GMT Subject: [jdk8u-dev] RFR: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: <1j-X5oezREj65nhxjyshqdo3O_Ima-PYCqocJzDjLgw=.b0d326a3-a2f2-45b7-89c1-1764bd1d3b15@github.com> On Thu, 3 Jul 2025 12:53:08 GMT, Antonio Vieiro wrote: > Backport of [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) from JDK11 that uses the new `windows-2025` GHA runner, that is replacing the old `windows-2019` GHA runner since 2025-06-30. The backport is not clean, since the GHA configuration is completely different from JDK11. > > JDK8 still builds with Visual Studio 2017, so there's no need to backport [JDK-8360042](https://bugs.openjdk.org/browse/JDK-8360042), nor to change any other setting. > > Build should be clean, but for the `jdk_security_infra` test failures, that are well known to fail in JDK8 (as they should in JDK11), and are unrelated. @vieiro Your change (at version bd2e71698bec5e85239f4bb6a3461cb8a3609b5f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/665#issuecomment-3045622066 From duke at openjdk.org Mon Jul 7 16:01:44 2025 From: duke at openjdk.org (Antonio Vieiro) Date: Mon, 7 Jul 2025 16:01:44 GMT Subject: [jdk8u-dev] Integrated: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 12:53:08 GMT, Antonio Vieiro wrote: > Backport of [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) from JDK11 that uses the new `windows-2025` GHA runner, that is replacing the old `windows-2019` GHA runner since 2025-06-30. The backport is not clean, since the GHA configuration is completely different from JDK11. > > JDK8 still builds with Visual Studio 2017, so there's no need to backport [JDK-8360042](https://bugs.openjdk.org/browse/JDK-8360042), nor to change any other setting. > > Build should be clean, but for the `jdk_security_infra` test failures, that are well known to fail in JDK8 (as they should in JDK11), and are unrelated. This pull request has now been integrated. Changeset: d0281bed Author: Antonio Vieiro Committer: Severin Gehwolf URL: https://git.openjdk.org/jdk8u-dev/commit/d0281bedf07a51f6b8b93ba156b615d76f561c63 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8358538: Update GHA Windows runner to 2025 Reviewed-by: sgehwolf Backport-of: 0927ca70e66ef27b38cbf5c0dd2851c796218067 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/665 From syan at openjdk.org Tue Jul 8 08:35:52 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 8 Jul 2025 08:35:52 GMT Subject: [jdk8u-dev] RFR: 8081734: ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu. In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 13:40:48 GMT, SendaoYan wrote: > Hi all, > This is clean backport to fix the test run time outed which the tested machine has huge cpu core number. Change has been verified locally, test-fix only, no risk. GHA report several failures: 1. Several security_infra jobs report fails, these fails are CA cert issue, it's unrelated to this PR. 2. Linux x86 hotspot/tier1 report gc/arguments/TestCMSHeapSizeFlags.java time outed, I think it's unralted to this PR. Thanks for the approved @jerboaa ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/666#issuecomment-3047898618 PR Comment: https://git.openjdk.org/jdk8u-dev/pull/666#issuecomment-3047900456 From duke at openjdk.org Tue Jul 8 08:35:52 2025 From: duke at openjdk.org (duke) Date: Tue, 8 Jul 2025 08:35:52 GMT Subject: [jdk8u-dev] RFR: 8081734: ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu. In-Reply-To: References: Message-ID: <266RqTfTPEabv3aKH5SAIRDoV8ST6Pmd9Pkki9_llVw=.155b61d1-caea-438c-9e4b-cd4a9dc6fe5c@github.com> On Mon, 7 Jul 2025 13:40:48 GMT, SendaoYan wrote: > Hi all, > This is clean backport to fix the test run time outed which the tested machine has huge cpu core number. Change has been verified locally, test-fix only, no risk. @sendaoYan Your change (at version e886b4b4e104e8aa46d0abb1628d64dfe7041223) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/666#issuecomment-3047903201 From syan at openjdk.org Tue Jul 8 08:39:48 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 8 Jul 2025 08:39:48 GMT Subject: [jdk8u-dev] Integrated: 8081734: ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu. In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 13:40:48 GMT, SendaoYan wrote: > Hi all, > This is clean backport to fix the test run time outed which the tested machine has huge cpu core number. Change has been verified locally, test-fix only, no risk. This pull request has now been integrated. Changeset: 35d219b4 Author: SendaoYan Committer: Severin Gehwolf URL: https://git.openjdk.org/jdk8u-dev/commit/35d219b4d4864cb05e145feaf3f5a1aeeb158c8a Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8081734: ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu. Backport-of: 6e48caf2507d4a45e1861ee699a32a5e459d70c2 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/666 From syan at openjdk.org Tue Jul 8 08:44:52 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 8 Jul 2025 08:44:52 GMT Subject: [jdk8u-dev] RFR: 8081734: ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu. In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 13:40:48 GMT, SendaoYan wrote: > Hi all, > This is clean backport to fix the test run time outed which the tested machine has huge cpu core number. Change has been verified locally, test-fix only, no risk. > /sponsor Thanks. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/666#issuecomment-3047934465 From tkurashige at openjdk.org Tue Jul 8 12:56:50 2025 From: tkurashige at openjdk.org (Taizo Kurashige) Date: Tue, 8 Jul 2025 12:56:50 GMT Subject: [jdk8u-dev] RFR: 8160767: [TEST_BUG] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java [v2] In-Reply-To: References:

Message-ID: On Mon, 24 Mar 2025 08:34:18 GMT, Taizo Kurashige wrote: >> Hi all, >> >> This is a backport of JDK-8160767: [TEST_BUG] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java >> >> Original patch doesn't apply cleanly to 8u because [JDK-8056911](https://bugs.openjdk.org/browse/JDK-8056911) isn't backported to 8u. >> >> Backporting JDK-8056911 involves changing the behavior of a public method so it is risky. In addition to that, it does not lead to significant bug fix. For these reasons, I do not think it is appropriate to apply JDK-8056911 as a dependent fix. >> So I made a slightly different fix from the original patch. Specifically, I modified to use an ExtendedRobot instead of Robot. >> >> Testing: java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java on RHEL9.2 >> >> Thanks. > > Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Fix to use ExtendedRobot > - Merge branch 'openjdk:master' into fix_MaximizedToIconified > - Merge branch 'openjdk:master' into fix_MaximizedToIconified > - Backport b46b19cb58d8b43e57cd81a0588d4e18ad6afa9a Could anyone review this PR? ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/637#issuecomment-3048845390 From andrew at openjdk.org Wed Jul 9 17:56:48 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 9 Jul 2025 17:56:48 GMT Subject: [jdk8u-dev] RFR: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 12:53:08 GMT, Antonio Vieiro wrote: > Backport of [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) from JDK11 that uses the new `windows-2025` GHA runner, that is replacing the old `windows-2019` GHA runner since 2025-06-30. The backport is not clean, since the GHA configuration is completely different from JDK11. > > JDK8 still builds with Visual Studio 2017, so there's no need to backport [JDK-8360042](https://bugs.openjdk.org/browse/JDK-8360042), nor to change any other setting. > > Build should be clean, but for the `jdk_security_infra` test failures, that are well known to fail in JDK8 (as they should in JDK11), and are unrelated. 8u also uses [VS2010](https://github.com/vieiro/jdk8u-dev/actions/runs/16048533653/job/45285519303) as well so I'm surprised and relieved this worked so easily out of the box. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/665#issuecomment-3053524817 From syan at openjdk.org Thu Jul 10 07:53:53 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 10 Jul 2025 07:53:53 GMT Subject: [jdk8u-dev] RFR: 8303770: Remove Baltimore root certificate expiring in May 2025 [v3] In-Reply-To: References:

Message-ID: On Mon, 12 May 2025 15:06:44 GMT, Antonio Vieiro wrote: >> Backport of [JDK-8303770](https://bugs.openjdk.org/browse/JDK-8303770) from 11. Mostly clean (certfile location differs from 11). >> >> Test `jdk/test/sun/security/lib/cacerts/VerifyCACerts.java` passes on `RHEL8, x86_64, gcc8.5.0`. > > Antonio Vieiro has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > Backport c0e7aa6c122e88e0d749ac3e8edf2cda9c5f53da This backport seems backport to jdk8u, but I think jdk8u-dev also need to backported? ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/650#issuecomment-3056137290 From sgehwolf at openjdk.org Thu Jul 10 08:26:50 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 10 Jul 2025 08:26:50 GMT Subject: [jdk8u-dev] RFR: 8303770: Remove Baltimore root certificate expiring in May 2025 [v3] In-Reply-To: References:

Message-ID: On Thu, 10 Jul 2025 07:50:37 GMT, SendaoYan wrote: > This backport seems backport to jdk8u, but I think jdk8u-dev also need to backported? This will get there in time when a merge from jdk8u to jdk8u-dev happens. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/650#issuecomment-3056282754 From syan at openjdk.org Tue Jul 15 06:51:57 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 15 Jul 2025 06:51:57 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer Message-ID: Hi all, When running hotspot/test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java on a CPU with more than 200 physical threads, the jvm will crashes. The reason is that the testcase turn on the gc log, which prints the statistics of each gc thread. If the machine has more cores, more gc threads will be turned on (143 gc threads on a machine with 224 physical threads). In the G1GCParPhasePrinter::print_time_values function (hotspot/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp), the relevant statistics of all gc threads are concatenated into one line, and the string concatenation content is saved in the array defined by g1GCPhaseTimes.cpp::LineBuffer::_buffer. Therefore, on machines with a large number of physical threads, it is easy for the GC log output line length to exceed the predefined buffer size. When the buffer size is exceeded, an error occurs when calling the os::vsnprintf function. In JDK9, JDK-8150068 refactors the relevant GC log output, so buffer overflow will no longer occur. However, JDK-8150068 is a new feature, and JDK-8150068 cannot be directly backported to jdk8u. In addition, the amount of JDK-8150068 code is large, and the risk of backporting to jdk8u is also very high. Therefore, this PR changes the buffer length to 1024*3 to ensure that there will be no problems with GC log output in some scenarios, and leave a certain margin. In addition, this PR adds a guarantee statement to ensure that an error is reported before calling os::vsnprintf when the buffer overflows, which is conducive to the rapid location of the problem Change has been verified locally, risk is low. Additional testing: - [ ] jtreg tests include tier1/2/3 etc.. on linux-x64 with release build ------------- Commit messages: - 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer Changes: https://git.openjdk.org/jdk8u-dev/pull/668/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=668&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362208 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/668.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/668/head:pull/668 PR: https://git.openjdk.org/jdk8u-dev/pull/668 From syan at openjdk.org Tue Jul 15 09:41:01 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 15 Jul 2025 09:41:01 GMT Subject: [jdk8u-dev] RFR: 8056283: @ignore tools/javac/defaultMethods/Assertions.java until JDK-8047675 is fixed Message-ID: Hi all, I want to backport [JDK-8047675](https://bugs.openjdk.org/browse/JDK-8047675) to jdk8u-dev, but I found that this PR is the prefixed PR to backport [JDK-8047675](https://bugs.openjdk.org/browse/JDK-8047675) to jdk8u-dev. This PR only add `@ignore` derictive to disable the test. Test-fix only, no risk. ------------- Commit messages: - Backport d66c4567eea47bd74037b49acbd85d71a2cf239a Changes: https://git.openjdk.org/jdk8u-dev/pull/669/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=669&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8056283 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/669.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/669/head:pull/669 PR: https://git.openjdk.org/jdk8u-dev/pull/669 From syan at openjdk.org Tue Jul 15 13:07:43 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 15 Jul 2025 13:07:43 GMT Subject: [jdk8u-dev] RFR: 8056283: @ignore tools/javac/defaultMethods/Assertions.java until JDK-8047675 is fixed In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 09:32:02 GMT, SendaoYan wrote: > Hi all, > > I want to backport [JDK-8047675](https://bugs.openjdk.org/browse/JDK-8047675) to jdk8u-dev, but I found that this PR is the prefixed PR to backport [JDK-8047675](https://bugs.openjdk.org/browse/JDK-8047675) to jdk8u-dev. > > This PR only add `@ignore` derictive to disable the test. Test-fix only, no risk. GHA report several test failures: 1. Several 'jdk/security_infra' job fails, it's known CA test issue, it's unrelated to this PR. 2. '[Linux x86 (hotspot/tier1)](https://github.com/sendaoYan/jdk8u-dev-ysd/actions/runs/16289489077/job/45996889543#logs)' job report test gc/concurrentMarkSweep/CheckAllocateAndSystemGC.java trigger jvm crash in 'CompactibleFreeListSpace::block_size(HeapWord const*)',it's known issue which recorded by [JDK-8303159](https://bugs.openjdk.org/browse/JDK-8303159), it's unrelated ti this PR. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/669#issuecomment-3073520086 From phh at openjdk.org Wed Jul 16 14:33:53 2025 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 16 Jul 2025 14:33:53 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 06:47:42 GMT, SendaoYan wrote: > Hi all, > > When running hotspot/test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java on a CPU with more than 200 physical threads, the jvm will crashes. The reason is that the testcase turn on the gc log, which prints the statistics of each gc thread. If the machine has more cores, more gc threads will be turned on (143 gc threads on a machine with 224 physical threads). In the G1GCParPhasePrinter::print_time_values function (hotspot/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp), the relevant statistics of all gc threads are concatenated into one line, and the string concatenation content is saved in the array defined by g1GCPhaseTimes.cpp::LineBuffer::_buffer. Therefore, on machines with a large number of physical threads, it is easy for the GC log output line length to exceed the predefined buffer size. When the buffer size is exceeded, an error occurs when calling the os::vsnprintf function. > In JDK9, JDK-8150068 refactors the relevant GC log output, so buffer overflow will no longer occur. However, JDK-8150068 is a new feature, and JDK-8150068 cannot be directly backported to jdk8u. In addition, the amount of JDK-8150068 code is large, and the risk of backporting to jdk8u is also very high. Therefore, this PR changes the buffer length to 1024*3 to ensure that there will be no problems with GC log output in some scenarios, and leave a certain margin. > > In addition, this PR adds a guarantee statement to ensure that an error is reported before calling os::vsnprintf when the buffer overflows, which is conducive to the rapid location of the problem > > Change has been verified locally, risk is low. > > Additional testing: > > - [ ] jtreg tests include tier1/2/3 etc.. on linux-x64 with release build Afaik a guarantee is supposed to check for JVM-ending situations, so it seems to strong to me just for losing some logging info. Even an assert is imo too strong. I'd turn the guarantee into a debug-only warning with something like "previous LineBuffer overflow, request ignored" and have it execute just once. I'd also gate the whole method on (_cur < BUFFER_LEN) so vnsprintf isn't called unnecessarily. ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/668#pullrequestreview-3025310666 From gnu.andrew at redhat.com Wed Jul 16 17:00:06 2025 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Jul 2025 18:00:06 +0100 Subject: OpenJDK 8u462 Released Message-ID: We are pleased to announce the release of OpenJDK 8u462. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u462-b08.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u462-b08.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: a521738deb7676ce65af6577f8fc95bf5228ce18fdbccd232197c8d1f3ef50ad openjdk8u462-b08.tar.xz d45bd1aecad66aaa2396e5735f8a090c00e2e297b4c0546644c2b5e6f1a886c4 openjdk8u462-b08.tar.xz.sig SHA512 checksums: 271914783adb59ae17c67d648fb497c0ada613787f2f059b4fa68f27a5a24134f3d0a98f117ebc4d1b052ab65fe6d950ea049ef4042fef9bd001e044bdc5e92b openjdk8u462-b08.tar.xz b56bbad4d5f8a031fcbafdf7a7860ea11a08b9e7d75321e7e49c1a9c85b9b8ba3493d97ff09a1fefdf394a2c1c3eb5567a7ae922b26fad2f24d00b7fe2ea51ef openjdk8u462-b08.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u462-b08.sha256 * https://openjdk-sources.osci.io/openjdk8/openjdk8u462-b08.sha512 New in release OpenJDK 8u462 (2025-07-15): =========================================== Live versions of these release notes can be found at: * https://bit.ly/openjdk8u462 * CVEs - CVE-2025-30749 - CVE-2025-30754 - CVE-2025-30761 - CVE-2025-50106 * Changes - JDK-8026976: ECParameters, Point does not match field size - JDK-8028998: [TEST_BUG] [macosx] java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java failed - JDK-8046883: com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows - JDK-8071996: split_if accesses NULL region of ConstraintCast - JDK-8159694: HiDPI, Unity, java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java - JDK-8186143: keytool -ext option doesn't accept wildcards for DNS subject alternative names - JDK-8186787: clang-4.0 SIGSEGV in Unsafe_PutByte - JDK-8248001: javadoc generates invalid HTML pages whose ftp:// links are broken - JDK-8274597: Some of the dnd tests time out and fail intermittently - JDK-8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test - JDK-8278472: Invalid value set to CANDIDATEFORM structure - JDK-8293107: GHA: Bump to Ubuntu 22.04 - JDK-8296631: NSS tests failing on OL9 linux-aarch64 hosts - JDK-8303770: Remove Baltimore root certificate expiring in May 2025 - JDK-8341946: [8u] sun/security/pkcs11/ec/ tests fail on RHEL9 - JDK-8345133: Test sun/security/tools/jarsigner/TsacertOptionTest.java failed: Warning found in stdout - JDK-8345625: Better HTTP connections - JDK-8346887: DrawFocusRect() may cause an assertion failure - JDK-8348989: Better Glyph drawing - JDK-8349111: Enhance Swing supports - JDK-8349594: Enhance TLS protocol support - JDK-8350498: Remove two Camerfirma root CA certificates - JDK-8351098: Bump update version of OpenJDK: 8u462 - JDK-8351422: Improve scripting supports - JDK-8351439: [8u] test/java/util/TimeZone/tools/share/Makefile use wrong path to tzdb - JDK-8352716: (tz) Update Timezone Data to 2025b - JDK-8356096: ISO 4217 Amendment 179 Update - JDK-8359170: Add 2 TLS and 2 CS Sectigo roots - JDK-8360147: Better Glyph drawing redux Notes on individual issues: =========================== security-libs/java.security: JDK-8303770: Remove Baltimore root certificate expiring in May 2025 =================================================================== The following root certificate from Baltimore has been removed from the `cacerts` keystore: Alias Name: baltimorecybertrustca [jdk] Distinguished Name: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8350498: Remove two Camerfirma root CA certificates ======================================================= The following expired root certificates from Camerfirma have been removed from the `cacerts` keystore: Alias name: camerfirmachamberscommerceca [jdk] CN=Chambers of Commerce Root OU=http://www.chambersign.org O=AC Camerfirma SA CIF A82743287 C=EU SHA256: 0C:25:8A:12:A5:67:4A:EF:25:F2:8B:A7:DC:FA:EC:EE:A3:48:E5:41:E6:F5:CC:4E:E6:3B:71:B3:61:60:6A:C3 Alias name: camerfirmachambersignca [jdk] CN=Global Chambersign Root - 2008 O=AC Camerfirma S.A. SERIALNUMBER=A82743287 L=Madrid (see current address at www.camerfirma.com/address) C=EU SHA256: 13:63:35:43:93:34:A7:69:80:16:A0:D3:24:DE:72:28:4E:07:9D:7B:52:20:BB:8F:BD:74:78:16:EE:BE:BA:CA JDK-8359170: Add 2 TLS and 2 CS Sectigo roots ============================================= The following root certificates have been added to the cacerts truststore: Name: Sectigo Limited Alias Name: sectigocodesignroote46 Distinguished Name: CN=Sectigo Public Code Signing Root E46, O=Sectigo Limited, C=GB Name: Sectigo Limited Alias Name: sectigocodesignrootr46 Distinguished Name: CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB Name: Sectigo Limited Alias Name: sectigotlsroote46 Distinguished Name: Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB Name: Sectigo Limited Alias Name: sectigotlsrootr46 Distinguished Name: Sectigo Public Server Authentication Root R46, O=Sectigo Limited, C=GB Happy hacking, -- Andrew :) Pronouns: he / him or they / them Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From syan at openjdk.org Thu Jul 17 06:36:35 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 17 Jul 2025 06:36:35 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer [v2] In-Reply-To: References: Message-ID: > Hi all, > > When running hotspot/test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java on a CPU with more than 200 physical threads, the jvm will crashes. The reason is that the testcase turn on the gc log, which prints the statistics of each gc thread. If the machine has more cores, more gc threads will be turned on (143 gc threads on a machine with 224 physical threads). In the G1GCParPhasePrinter::print_time_values function (hotspot/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp), the relevant statistics of all gc threads are concatenated into one line, and the string concatenation content is saved in the array defined by g1GCPhaseTimes.cpp::LineBuffer::_buffer. Therefore, on machines with a large number of physical threads, it is easy for the GC log output line length to exceed the predefined buffer size. When the buffer size is exceeded, an error occurs when calling the os::vsnprintf function. > In JDK9, JDK-8150068 refactors the relevant GC log output, so buffer overflow will no longer occur. However, JDK-8150068 is a new feature, and JDK-8150068 cannot be directly backported to jdk8u. In addition, the amount of JDK-8150068 code is large, and the risk of backporting to jdk8u is also very high. Therefore, this PR changes the buffer length to 1024*3 to ensure that there will be no problems with GC log output in some scenarios, and leave a certain margin. > > In addition, this PR adds a guarantee statement to ensure that an error is reported before calling os::vsnprintf when the buffer overflows, which is conducive to the rapid location of the problem > > Change has been verified locally, risk is low. > > Additional testing: > > - [x] jtreg tests include tier1/2/3 etc.. on linux-x64 with release build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove guarantee and add debug only warning, then return early when "previous LineBuffer overflow, request ignored" ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/668/files - new: https://git.openjdk.org/jdk8u-dev/pull/668/files/a207869a..a132e0c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=668&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=668&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/668.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/668/head:pull/668 PR: https://git.openjdk.org/jdk8u-dev/pull/668 From syan at openjdk.org Thu Jul 17 06:36:36 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 17 Jul 2025 06:36:36 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer [v2] In-Reply-To: References:

Message-ID: On Wed, 16 Jul 2025 14:30:41 GMT, Paul Hohensee wrote: > Afaik a guarantee is supposed to check for JVM-ending situations, so it seems to strong to me just for losing some logging info. Even an assert is imo too strong. I'd turn the guarantee into a debug-only warning with something like "previous LineBuffer overflow, request ignored" and have it execute just once. I'd also gate the whole method on (_cur < BUFFER_LEN) so vnsprintf isn't called unnecessarily. @phohensee Thanks for your suggestions. The guaratee has been removed, and I add a debug only warning, and then return early when `_cur < BUFFER_LEN` ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/668#issuecomment-3082752977 From syan at openjdk.org Thu Jul 17 07:30:33 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 17 Jul 2025 07:30:33 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer [v3] In-Reply-To: References: Message-ID: > Hi all, > > When running hotspot/test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java on a CPU with more than 200 physical threads, the jvm will crashes. The reason is that the testcase turn on the gc log, which prints the statistics of each gc thread. If the machine has more cores, more gc threads will be turned on (143 gc threads on a machine with 224 physical threads). In the G1GCParPhasePrinter::print_time_values function (hotspot/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp), the relevant statistics of all gc threads are concatenated into one line, and the string concatenation content is saved in the array defined by g1GCPhaseTimes.cpp::LineBuffer::_buffer. Therefore, on machines with a large number of physical threads, it is easy for the GC log output line length to exceed the predefined buffer size. When the buffer size is exceeded, an error occurs when calling the os::vsnprintf function. > In JDK9, JDK-8150068 refactors the relevant GC log output, so buffer overflow will no longer occur. However, JDK-8150068 is a new feature, and JDK-8150068 cannot be directly backported to jdk8u. In addition, the amount of JDK-8150068 code is large, and the risk of backporting to jdk8u is also very high. Therefore, this PR changes the buffer length to 1024*3 to ensure that there will be no problems with GC log output in some scenarios, and leave a certain margin. > > In addition, this PR adds a guarantee statement to ensure that an error is reported before calling os::vsnprintf when the buffer overflows, which is conducive to the rapid location of the problem > > Change has been verified locally, risk is low. > > Additional testing: > > - [x] jtreg tests include tier1/2/3 etc.. on linux-x64 with release build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: fix bugs ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/668/files - new: https://git.openjdk.org/jdk8u-dev/pull/668/files/a132e0c0..55e4fe2b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=668&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=668&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/668.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/668/head:pull/668 PR: https://git.openjdk.org/jdk8u-dev/pull/668 From tkiriyama at openjdk.org Thu Jul 17 09:20:54 2025 From: tkiriyama at openjdk.org (Takuya Kiriyama) Date: Thu, 17 Jul 2025 09:20:54 GMT Subject: [jdk8u-dev] RFR: 8345358: Some DLL Files are missing Windows Properties In-Reply-To: References:

Message-ID: On Wed, 5 Feb 2025 15:16:17 GMT, Alexey Bakhtin wrote: >> Add missing properties for the j2gss.dll and sspi_bridge.dll files > > Please review Hi, @alexeybakhtin The reported issue doesn't seem to be resolved yet. Would you please move forward with this pull request? ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/611#issuecomment-3083299875 From syan at openjdk.org Thu Jul 17 09:33:01 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 17 Jul 2025 09:33:01 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer [v3] In-Reply-To: References:

Message-ID: On Thu, 17 Jul 2025 07:30:33 GMT, SendaoYan wrote: >> Hi all, >> >> When running hotspot/test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java on a CPU with more than 200 physical threads, the jvm will crashes. The reason is that the testcase turn on the gc log, which prints the statistics of each gc thread. If the machine has more cores, more gc threads will be turned on (143 gc threads on a machine with 224 physical threads). In the G1GCParPhasePrinter::print_time_values function (hotspot/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp), the relevant statistics of all gc threads are concatenated into one line, and the string concatenation content is saved in the array defined by g1GCPhaseTimes.cpp::LineBuffer::_buffer. Therefore, on machines with a large number of physical threads, it is easy for the GC log output line length to exceed the predefined buffer size. When the buffer size is exceeded, an error occurs when calling the os::vsnprintf function. >> In JDK9, JDK-8150068 refactors the relevant GC log output, so buffer overflow will no longer occur. However, JDK-8150068 is a new feature, and JDK-8150068 cannot be directly backported to jdk8u. In addition, the amount of JDK-8150068 code is large, and the risk of backporting to jdk8u is also very high. Therefore, this PR changes the buffer length to 1024*3 to ensure that there will be no problems with GC log output in some scenarios, and leave a certain margin. >> >> In addition, this PR adds a guarantee statement to ensure that an error is reported before calling os::vsnprintf when the buffer overflows, which is conducive to the rapid location of the problem >> >> Change has been verified locally, risk is low. >> >> Additional testing: >> >> - [ ] jtreg tests include tier1/2/3 etc.. on linux-x64 with release build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > fix bugs Looks like the test on line 44 should be _cur >= BUFFER_LEN because _cur is set to BUFFER_LEN at line 52 as the sentinal. ------------- Changes requested by phh (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/668#pullrequestreview-3030196028 From phh at openjdk.org Thu Jul 17 20:28:01 2025 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 17 Jul 2025 20:28:01 GMT Subject: [jdk8u-dev] RFR: 8041924: [TESTBUG] sun/net/www/http/ChunkedOutputStream/checkError.java fails on some systems In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 13:22:10 GMT, SendaoYan wrote: > Hi all, > > We found that the jdk/test/sun/net/www/http/ChunkedOutputStream/checkError.java always fails with jvm option -Xcomp, and the test bug which cause test fails has been fixed by [JDK-8041924](https://bugs.openjdk.org/browse/JDK-8041924) in jdk9. So I want to backport [JDK-8041924](https://bugs.openjdk.org/browse/JDK-8041924) to fix this test bug. > > The problemlist do not needed to deal with. And jdk/test/sun/net/www/http/ChunkedOutputStream/checkError.java been touch by [JDK-8157499](https://bugs.openjdk.org/browse/JDK-8157499), and [JDK-8157499](https://bugs.openjdk.org/browse/JDK-8157499) can not backport to jdk8 cleanly and it's no necessary to backport jdk8. These two things make this PR can not backport from jdk9 to jdk8 cleanly. > > Change has been verified locally, test-fix only, no risk. Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/670#pullrequestreview-3030911878 From andrew at openjdk.org Fri Jul 18 00:00:01 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 18 Jul 2025 00:00:01 GMT Subject: [jdk8u-dev] RFR: Merge jdk8u:master Message-ID: <81qxIKfEzrrnA-DRyWIVpz1XVwaRZW3kXKC0XNv0AME=.30496404-333f-4677-9ecc-d460dfc87a3c@github.com> Merge `jdk8u462-ga` ------------- Commit messages: - Merge - 8360147: Better Glyph drawing redux - 8351422: Improve scripting supports - 8349594: Enhance TLS protocol support - 8349111: Enhance Swing supports - 8348989: Better Glyph drawing - 8345625: Better HTTP connections - 8359170: Add 2 TLS and 2 CS Sectigo roots - 8356096: ISO 4217 Amendment 179 Update - 8350498: Remove two Camerfirma root CA certificates - ... and 1 more: https://git.openjdk.org/jdk8u-dev/compare/35d219b4...68177093 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk8u-dev/pull/671/files Stats: 1044 lines in 35 files changed: 704 ins; 255 del; 85 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/671.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/671/head:pull/671 PR: https://git.openjdk.org/jdk8u-dev/pull/671 From syan at openjdk.org Fri Jul 18 06:07:55 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 18 Jul 2025 06:07:55 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer [v4] In-Reply-To: References: Message-ID: <2z91S7Q94O7xylUdIfLJqM05kjDo_RTMA5hzXJEfHBs=.ebffdee5-5c22-4041-a5ea-e9ed6e86fb6e@github.com> > Hi all, > > When running hotspot/test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java on a CPU with more than 200 physical threads, the jvm will crashes. The reason is that the testcase turn on the gc log, which prints the statistics of each gc thread. If the machine has more cores, more gc threads will be turned on (143 gc threads on a machine with 224 physical threads). In the G1GCParPhasePrinter::print_time_values function (hotspot/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp), the relevant statistics of all gc threads are concatenated into one line, and the string concatenation content is saved in the array defined by g1GCPhaseTimes.cpp::LineBuffer::_buffer. Therefore, on machines with a large number of physical threads, it is easy for the GC log output line length to exceed the predefined buffer size. When the buffer size is exceeded, an error occurs when calling the os::vsnprintf function. > In JDK9, JDK-8150068 refactors the relevant GC log output, so buffer overflow will no longer occur. However, JDK-8150068 is a new feature, and JDK-8150068 cannot be directly backported to jdk8u. In addition, the amount of JDK-8150068 code is large, and the risk of backporting to jdk8u is also very high. Therefore, this PR changes the buffer length to 1024*3 to ensure that there will be no problems with GC log output in some scenarios, and leave a certain margin. > > In addition, this PR adds a guarantee statement to ensure that an error is reported before calling os::vsnprintf when the buffer overflows, which is conducive to the rapid location of the problem > > Change has been verified locally, risk is low. > > Additional testing: > > - [ ] jtreg tests include tier1/2/3 etc.. on linux-x64 with release build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Should be _cur >= BUFFER_LEN ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/668/files - new: https://git.openjdk.org/jdk8u-dev/pull/668/files/55e4fe2b..811ce78a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=668&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=668&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/668.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/668/head:pull/668 PR: https://git.openjdk.org/jdk8u-dev/pull/668 From syan at openjdk.org Fri Jul 18 06:07:57 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 18 Jul 2025 06:07:57 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer [v3] In-Reply-To: References:

Message-ID: <5A5rK7NgtvNNqx4vwWlU7Z18uX4uDg7DKW7EGXdyu_U=.23af07df-b99a-4ec7-912f-b6ddfc153e16@github.com> On Thu, 17 Jul 2025 16:15:03 GMT, Paul Hohensee wrote: > Looks like the test on line 44 should be > > _cur >= BUFFER_LEN > > because _cur is set to BUFFER_LEN at line 52 as the sentinal. Thanks for your correction. PR has been updated. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/668#issuecomment-3087088025 From syan at openjdk.org Fri Jul 18 06:11:57 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 18 Jul 2025 06:11:57 GMT Subject: [jdk8u-dev] RFR: 8041924: [TESTBUG] sun/net/www/http/ChunkedOutputStream/checkError.java fails on some systems In-Reply-To: References:

Message-ID: On Thu, 17 Jul 2025 20:25:30 GMT, Paul Hohensee wrote: >> Hi all, >> >> We found that the jdk/test/sun/net/www/http/ChunkedOutputStream/checkError.java always fails with jvm option -Xcomp, and the test bug which cause test fails has been fixed by [JDK-8041924](https://bugs.openjdk.org/browse/JDK-8041924) in jdk9. So I want to backport [JDK-8041924](https://bugs.openjdk.org/browse/JDK-8041924) to fix this test bug. >> >> The problemlist do not needed to deal with. And jdk/test/sun/net/www/http/ChunkedOutputStream/checkError.java been touch by [JDK-8157499](https://bugs.openjdk.org/browse/JDK-8157499), and [JDK-8157499](https://bugs.openjdk.org/browse/JDK-8157499) can not backport to jdk8 cleanly and it's no necessary to backport jdk8. These two things make this PR can not backport from jdk9 to jdk8 cleanly. >> >> Change has been verified locally, test-fix only, no risk. > > Marked as reviewed by phh (Reviewer). Thanks for the reviews @phohensee. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/670#issuecomment-3087114628 From syan at openjdk.org Fri Jul 18 08:24:59 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 18 Jul 2025 08:24:59 GMT Subject: [jdk8u-dev] RFR: 8041924: [TESTBUG] sun/net/www/http/ChunkedOutputStream/checkError.java fails on some systems In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 13:22:10 GMT, SendaoYan wrote: > Hi all, > > We found that the jdk/test/sun/net/www/http/ChunkedOutputStream/checkError.java always fails with jvm option -Xcomp, and the test bug which cause test fails has been fixed by [JDK-8041924](https://bugs.openjdk.org/browse/JDK-8041924) in jdk9. So I want to backport [JDK-8041924](https://bugs.openjdk.org/browse/JDK-8041924) to fix this test bug. > > The problemlist do not needed to deal with. And jdk/test/sun/net/www/http/ChunkedOutputStream/checkError.java been touch by [JDK-8157499](https://bugs.openjdk.org/browse/JDK-8157499), and [JDK-8157499](https://bugs.openjdk.org/browse/JDK-8157499) can not backport to jdk8 cleanly and it's no necessary to backport jdk8. These two things make this PR can not backport from jdk9 to jdk8 cleanly. > > Change has been verified locally, test-fix only, no risk. GHA report several failures, all the failures are known CA issues, unrelated to this PR. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/670#issuecomment-3088372969 From phh at openjdk.org Fri Jul 18 17:14:54 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 18 Jul 2025 17:14:54 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer [v4] In-Reply-To: <2z91S7Q94O7xylUdIfLJqM05kjDo_RTMA5hzXJEfHBs=.ebffdee5-5c22-4041-a5ea-e9ed6e86fb6e@github.com> References: <2z91S7Q94O7xylUdIfLJqM05kjDo_RTMA5hzXJEfHBs=.ebffdee5-5c22-4041-a5ea-e9ed6e86fb6e@github.com> Message-ID: <-cnWapK8H_C31U4_zgXA04r1oxKKVxRy7klxMKtZR7c=.8d4d3e89-4b5e-4d4c-b45c-c80e80fd97a3@github.com> On Fri, 18 Jul 2025 06:07:55 GMT, SendaoYan wrote: >> Hi all, >> >> When running hotspot/test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java on a CPU with more than 200 physical threads, the jvm will crashes. The reason is that the testcase turn on the gc log, which prints the statistics of each gc thread. If the machine has more cores, more gc threads will be turned on (143 gc threads on a machine with 224 physical threads). In the G1GCParPhasePrinter::print_time_values function (hotspot/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp), the relevant statistics of all gc threads are concatenated into one line, and the string concatenation content is saved in the array defined by g1GCPhaseTimes.cpp::LineBuffer::_buffer. Therefore, on machines with a large number of physical threads, it is easy for the GC log output line length to exceed the predefined buffer size. When the buffer size is exceeded, an error occurs when calling the os::vsnprintf function. >> In JDK9, JDK-8150068 refactors the relevant GC log output, so buffer overflow will no longer occur. However, JDK-8150068 is a new feature, and JDK-8150068 cannot be directly backported to jdk8u. In addition, the amount of JDK-8150068 code is large, and the risk of backporting to jdk8u is also very high. Therefore, this PR changes the buffer length to 1024*3 to ensure that there will be no problems with GC log output in some scenarios, and leave a certain margin. >> >> In addition, this PR adds a guarantee statement to ensure that an error is reported before calling os::vsnprintf when the buffer overflows, which is conducive to the rapid location of the problem >> >> Change has been verified locally, risk is low. >> >> Additional testing: >> >> - [ ] jtreg tests include tier1/2/3 etc.. on linux-x64 with release build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Should be _cur >= BUFFER_LEN Thanks, looks good. ------------- Marked as reviewed by phh (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/668#pullrequestreview-3034203758 From andrew at openjdk.org Fri Jul 18 17:15:44 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 18 Jul 2025 17:15:44 GMT Subject: [jdk8u-dev] Integrated: Merge jdk8u:master In-Reply-To: <81qxIKfEzrrnA-DRyWIVpz1XVwaRZW3kXKC0XNv0AME=.30496404-333f-4677-9ecc-d460dfc87a3c@github.com> References: <81qxIKfEzrrnA-DRyWIVpz1XVwaRZW3kXKC0XNv0AME=.30496404-333f-4677-9ecc-d460dfc87a3c@github.com> Message-ID: On Thu, 17 Jul 2025 23:56:30 GMT, Andrew John Hughes wrote: > Merge `jdk8u462-ga` This pull request has now been integrated. Changeset: af84892a Author: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/af84892a33772b0624c44902ebb354c8debad13f Stats: 1044 lines in 35 files changed: 704 ins; 255 del; 85 mod Merge ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/671 From syan at openjdk.org Sat Jul 19 02:56:50 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 19 Jul 2025 02:56:50 GMT Subject: [jdk8u-dev] RFR: 8362208: [8u] Buffer overflow in g1GCPhaseTimes.cpp::LineBuffer::_buffer [v4] In-Reply-To: <-cnWapK8H_C31U4_zgXA04r1oxKKVxRy7klxMKtZR7c=.8d4d3e89-4b5e-4d4c-b45c-c80e80fd97a3@github.com> References: <2z91S7Q94O7xylUdIfLJqM05kjDo_RTMA5hzXJEfHBs=.ebffdee5-5c22-4041-a5ea-e9ed6e86fb6e@github.com> <-cnWapK8H_C31U4_zgXA04r1oxKKVxRy7klxMKtZR7c=.8d4d3e89-4b5e-4d4c-b45c-c80e80fd97a3@github.com> Message-ID: On Fri, 18 Jul 2025 16:54:05 GMT, Paul Hohensee wrote: > Thanks, looks good. Thanks for the reviews @phohensee ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/668#issuecomment-3091441896 From tkurashige at openjdk.org Tue Jul 22 02:43:39 2025 From: tkurashige at openjdk.org (Taizo Kurashige) Date: Tue, 22 Jul 2025 02:43:39 GMT Subject: [jdk8u-dev] RFR: 8160767: [TEST_BUG] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java [v2] In-Reply-To: <0P8n8apv72eGswpJxPhk456YXSSIkgljbKSUuLti8tU=.1cc2476c-53bb-41d6-92d7-4c1951c3c9c2@github.com> References: <0P8n8apv72eGswpJxPhk456YXSSIkgljbKSUuLti8tU=.1cc2476c-53bb-41d6-92d7-4c1951c3c9c2@github.com> Message-ID: On Thu, 13 Mar 2025 01:56:30 GMT, Sergey Bylokhov wrote: >> Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Fix to use ExtendedRobot >> - Merge branch 'openjdk:master' into fix_MaximizedToIconified >> - Merge branch 'openjdk:master' into fix_MaximizedToIconified >> - Backport b46b19cb58d8b43e57cd81a0588d4e18ad6afa9a > > jdk/test/java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java line 55: > >> 53: private static void checkState(Frame frame, int state) { >> 54: frame.setExtendedState(state); >> 55: robot.waitForIdle(); > > I'm not sure this will be enough for jdk8. https://bugs.openjdk.org/browse/JDK-8056911 was not ported to jdk8, so Robot.waitForIdle() uses a "dummy" implementation. @mrserb Just a quick follow-up on this PR when you have a moment. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/637#discussion_r2220870503 From syan at openjdk.org Tue Jul 22 12:49:49 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 22 Jul 2025 12:49:49 GMT Subject: [jdk8u-dev] RFR: 8335978: [8u] incorrect include file name in semaphore.inline.hpp [v2] In-Reply-To: References:

Message-ID: <9rnxDf8RlegoFNEMrgE2RhtElIjsrYPPvI7raImqGgw=.1b41e37f-99f6-4728-b066-e61d9ef35a97@github.com> On Tue, 24 Jun 2025 12:27:50 GMT, SendaoYan wrote: >> Hi all, >> In file [semaphore.inline.hpp](https://github.com/openjdk/jdk8u-dev/blame/master/hotspot/src/share/vm/runtime/semaphore.inline.hpp#L28), `#include "runtime/interfaceSupport.inline.hpp"` include incorrect file name, the crrect file name shoule be interfaceSupport.hpp in jdk8u repository. >> >> Additional testing: >> >> - [x] linux x64 tier1/2/3 >> - [x] linux aarch64 tier1/2/3 > > SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into jbs8335978 > - 8335978: [8u] incorrect include file name in semaphore.inline.hpp GHA report 5 job fails, all the fails are known CA issues, they are unrelated to this PR. Thanks for the review @phohensee Thanks for the approved @jerboaa ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/543#issuecomment-3102570060 From duke at openjdk.org Tue Jul 22 12:49:49 2025 From: duke at openjdk.org (duke) Date: Tue, 22 Jul 2025 12:49:49 GMT Subject: [jdk8u-dev] RFR: 8335978: [8u] incorrect include file name in semaphore.inline.hpp [v2] In-Reply-To: References:

Message-ID: <9aBCD68Zhz6GceNtz-0ltRCZp_ybhCKY5i311Z1qKWM=.9556a098-4855-43f1-8017-4067da5d895a@github.com> On Tue, 24 Jun 2025 12:27:50 GMT, SendaoYan wrote: >> Hi all, >> In file [semaphore.inline.hpp](https://github.com/openjdk/jdk8u-dev/blame/master/hotspot/src/share/vm/runtime/semaphore.inline.hpp#L28), `#include "runtime/interfaceSupport.inline.hpp"` include incorrect file name, the crrect file name shoule be interfaceSupport.hpp in jdk8u repository. >> >> Additional testing: >> >> - [x] linux x64 tier1/2/3 >> - [x] linux aarch64 tier1/2/3 > > SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into jbs8335978 > - 8335978: [8u] incorrect include file name in semaphore.inline.hpp @sendaoYan Your change (at version 8ffbe6a40fd91730f6253be9bfaf2221affbc047) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/543#issuecomment-3102573221 From syan at openjdk.org Tue Jul 22 14:18:38 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 22 Jul 2025 14:18:38 GMT Subject: [jdk8u-dev] Integrated: 8335978: [8u] incorrect include file name in semaphore.inline.hpp In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 09:35:09 GMT, SendaoYan wrote: > Hi all, > In file [semaphore.inline.hpp](https://github.com/openjdk/jdk8u-dev/blame/master/hotspot/src/share/vm/runtime/semaphore.inline.hpp#L28), `#include "runtime/interfaceSupport.inline.hpp"` include incorrect file name, the crrect file name shoule be interfaceSupport.hpp in jdk8u repository. > > Additional testing: > > - [x] linux x64 tier1/2/3 > - [x] linux aarch64 tier1/2/3 This pull request has now been integrated. Changeset: 16949879 Author: SendaoYan Committer: Severin Gehwolf URL: https://git.openjdk.org/jdk8u-dev/commit/16949879ae5d8decf8613db2765dd58fd9a140ad Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8335978: [8u] incorrect include file name in semaphore.inline.hpp Reviewed-by: phh ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/543 From syan at openjdk.org Tue Jul 22 14:24:37 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 22 Jul 2025 14:24:37 GMT Subject: [jdk8u-dev] RFR: 8335978: [8u] incorrect include file name in semaphore.inline.hpp [v2] In-Reply-To: References:

Message-ID: <7tKgx-c4kfBgMeAeoyg2SBsaS6s1VGR8Jn__miWcOLk=.cda4263d-d807-4fc0-b263-ef86a74678ca@github.com> On Wed, 5 Feb 2025 15:16:17 GMT, Alexey Bakhtin wrote: >> Add missing properties for the j2gss.dll and sspi_bridge.dll files > > Please review > Hi, @alexeybakhtin The reported issue doesn't seem to be resolved yet. Would you please move forward with this pull request? There is a request to make a test. I'm not sure how to make jtreg test for this issue. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/611#issuecomment-3105016637 From jbachorik at openjdk.org Thu Jul 24 19:45:36 2025 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 24 Jul 2025 19:45:36 GMT Subject: [jdk8u-dev] RFR: 8315380: AsyncGetCallTrace crash in frame::safe_for_sender Message-ID: <3x2UQjNPZAN1HJvOoXdShCgZfbiHwPc-S62OJfQ1lRk=.3b2855bb-c7ca-4ef7-b82f-89a74b32c89a@github.com> This change is fixing the problem in `frame_aarch64.cpp`, function `safe_for_sender`, where we have this code bool unextended_sp_safe = unextended_sp < thread->stack_base(); While this captures one possibility of not being safe, it omits the check for `unextended_sp` falling within the stack space. The proposed change then is bool unextended_sp_safe = (unextended_sp < thread->stack_base() && \ sp >= thread->stack_base() - thread->stack_size()); This is actually just making sure the behaviour is the same as in JDK 15+ (since [JDK-8238988](https://bugs.openjdk.org/browse/JDK-8238988)) where the `unextended_sp` is checked for being within the stack limits. This PR is a clean backport of https://github.com/openjdk/jdk11u-dev/pull/3003 ------------- Commit messages: - Backport d46f769e70f6c0e8effcb78310cacc391a14fd6f Changes: https://git.openjdk.org/jdk8u-dev/pull/667/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=667&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315380 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/667.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/667/head:pull/667 PR: https://git.openjdk.org/jdk8u-dev/pull/667 From phh at openjdk.org Thu Jul 24 19:58:07 2025 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 24 Jul 2025 19:58:07 GMT Subject: [jdk8u-dev] RFR: 8315380: AsyncGetCallTrace crash in frame::safe_for_sender In-Reply-To: <3x2UQjNPZAN1HJvOoXdShCgZfbiHwPc-S62OJfQ1lRk=.3b2855bb-c7ca-4ef7-b82f-89a74b32c89a@github.com> References: <3x2UQjNPZAN1HJvOoXdShCgZfbiHwPc-S62OJfQ1lRk=.3b2855bb-c7ca-4ef7-b82f-89a74b32c89a@github.com> Message-ID: On Thu, 10 Jul 2025 16:30:05 GMT, Jaroslav Bachorik wrote: > This change is fixing the problem in `frame_aarch64.cpp`, function `safe_for_sender`, where we have this code > > > bool unextended_sp_safe = unextended_sp < thread->stack_base(); > > > While this captures one possibility of not being safe, it omits the check for `unextended_sp` falling within the stack space. > > The proposed change then is > > > bool unextended_sp_safe = (unextended_sp < thread->stack_base() && \ > sp >= thread->stack_base() - thread->stack_size()); > > > This is actually just making sure the behaviour is the same as in JDK 15+ (since [JDK-8238988](https://bugs.openjdk.org/browse/JDK-8238988)) where the `unextended_sp` is checked for being within the stack limits. > > > This PR is a clean backport of https://github.com/openjdk/jdk11u-dev/pull/3003 Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/667#pullrequestreview-3053084928 From zgu at openjdk.org Thu Jul 24 20:02:00 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 24 Jul 2025 20:02:00 GMT Subject: [jdk8u-dev] RFR: 8315380: AsyncGetCallTrace crash in frame::safe_for_sender In-Reply-To: <3x2UQjNPZAN1HJvOoXdShCgZfbiHwPc-S62OJfQ1lRk=.3b2855bb-c7ca-4ef7-b82f-89a74b32c89a@github.com> References: <3x2UQjNPZAN1HJvOoXdShCgZfbiHwPc-S62OJfQ1lRk=.3b2855bb-c7ca-4ef7-b82f-89a74b32c89a@github.com> Message-ID: On Thu, 10 Jul 2025 16:30:05 GMT, Jaroslav Bachorik wrote: > This change is fixing the problem in `frame_aarch64.cpp`, function `safe_for_sender`, where we have this code > > > bool unextended_sp_safe = unextended_sp < thread->stack_base(); > > > While this captures one possibility of not being safe, it omits the check for `unextended_sp` falling within the stack space. > > The proposed change then is > > > bool unextended_sp_safe = (unextended_sp < thread->stack_base() && \ > sp >= thread->stack_base() - thread->stack_size()); > > > This is actually just making sure the behaviour is the same as in JDK 15+ (since [JDK-8238988](https://bugs.openjdk.org/browse/JDK-8238988)) where the `unextended_sp` is checked for being within the stack limits. > > > This PR is a clean backport of https://github.com/openjdk/jdk11u-dev/pull/3003 LGTM ------------- Marked as reviewed by zgu (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/667#pullrequestreview-3053096976 From jbachorik at openjdk.org Thu Jul 24 20:20:22 2025 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 24 Jul 2025 20:20:22 GMT Subject: [jdk8u-dev] RFR: 8315380: AsyncGetCallTrace crash in frame::safe_for_sender In-Reply-To: <3x2UQjNPZAN1HJvOoXdShCgZfbiHwPc-S62OJfQ1lRk=.3b2855bb-c7ca-4ef7-b82f-89a74b32c89a@github.com> References: <3x2UQjNPZAN1HJvOoXdShCgZfbiHwPc-S62OJfQ1lRk=.3b2855bb-c7ca-4ef7-b82f-89a74b32c89a@github.com> Message-ID: On Thu, 10 Jul 2025 16:30:05 GMT, Jaroslav Bachorik wrote: > This change is fixing the problem in `frame_aarch64.cpp`, function `safe_for_sender`, where we have this code > > > bool unextended_sp_safe = unextended_sp < thread->stack_base(); > > > While this captures one possibility of not being safe, it omits the check for `unextended_sp` falling within the stack space. > > The proposed change then is > > > bool unextended_sp_safe = (unextended_sp < thread->stack_base() && \ > sp >= thread->stack_base() - thread->stack_size()); > > > This is actually just making sure the behaviour is the same as in JDK 15+ (since [JDK-8238988](https://bugs.openjdk.org/browse/JDK-8238988)) where the `unextended_sp` is checked for being within the stack limits. > > > This PR is a clean backport of https://github.com/openjdk/jdk11u-dev/pull/3003 Turns out the aarch64 specific change escaped the pre-submit tests and the backport is using a function that is not available in JDK 8. Thanks @zhengyu123 for pointing that out. I will close this auto-generated backport PR and create a proper one with the necessary changes manually. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/667#issuecomment-3114799997 From jbachorik at openjdk.org Thu Jul 24 20:20:22 2025 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 24 Jul 2025 20:20:22 GMT Subject: [jdk8u-dev] Withdrawn: 8315380: AsyncGetCallTrace crash in frame::safe_for_sender In-Reply-To: <3x2UQjNPZAN1HJvOoXdShCgZfbiHwPc-S62OJfQ1lRk=.3b2855bb-c7ca-4ef7-b82f-89a74b32c89a@github.com> References: <3x2UQjNPZAN1HJvOoXdShCgZfbiHwPc-S62OJfQ1lRk=.3b2855bb-c7ca-4ef7-b82f-89a74b32c89a@github.com> Message-ID: On Thu, 10 Jul 2025 16:30:05 GMT, Jaroslav Bachorik wrote: > This change is fixing the problem in `frame_aarch64.cpp`, function `safe_for_sender`, where we have this code > > > bool unextended_sp_safe = unextended_sp < thread->stack_base(); > > > While this captures one possibility of not being safe, it omits the check for `unextended_sp` falling within the stack space. > > The proposed change then is > > > bool unextended_sp_safe = (unextended_sp < thread->stack_base() && \ > sp >= thread->stack_base() - thread->stack_size()); > > > This is actually just making sure the behaviour is the same as in JDK 15+ (since [JDK-8238988](https://bugs.openjdk.org/browse/JDK-8238988)) where the `unextended_sp` is checked for being within the stack limits. > > > This PR is a clean backport of https://github.com/openjdk/jdk11u-dev/pull/3003 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/667 From ktakakuri at openjdk.org Mon Jul 28 09:25:07 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Mon, 28 Jul 2025 09:25:07 GMT Subject: [jdk8u-dev] RFR: 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. [v3] In-Reply-To: References:

Message-ID: On Fri, 6 Sep 2024 09:05:54 GMT, Andrew Haley wrote: >> Unlike jdk10, this backport does not add any interfaces. >> Is it still necessary for the CSR to be approved? > >> Unlike jdk10, this backport does not add any interfaces. Is it still necessary for the CSR to be approved? > > I don't think so. But there are some complex issues with the jdk 8 backport described in the comments to https://bugs.openjdk.org/browse/JDK-8154043 , which I think is why the 8 bakport was denied in 2016. What I do not understand is why, when the backport was denied 8 years ago, it should be allowed today. If someone can explain that, we can have a meningful discussion. @theRealAph It was under review by @gnu-andrew , but he has not commented since June 6. Would you be possible to take over the review of this pull request as a maintainer? I'm hoping to get this merged in time for the October release. I have addressed all the comments and suggestions he provided so far. I'm happy to address any new comments and suggestions. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/285#issuecomment-3126333820 From dzhang at openjdk.org Wed Jul 30 07:39:05 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Wed, 30 Jul 2025 07:39:05 GMT Subject: [jdk8u-dev] RFR: 8199138: Add RISC-V support to Zero [v2] In-Reply-To: References:

Message-ID: On Tue, 3 Sep 2024 11:34:42 GMT, Dingli Zhang wrote: >> Hi all, >> >> I'd like to backport this patch to jdk8u. Since most linux distributions support riscv64 and provide zero version jdk8 for riscv64. However, we may need to do some workarounds each time we upgrade the version, so I think it is helpful to provide zero support for riscv64 here. >> >> `common/autoconf/build-aux/config.guess` and `hotspot/src/os/linux/vm/os_linux.cpp` do not apply cleanly due to context difference, but it is easy to resolve them manually. `common/autoconf/platform.m4` just changed file path and remove test of `x$OPENJDK_$1_CPU`. >> >> `common/autoconf/generated-configure.sh` regenerated by `bash common/autoconf/autogen.sh`. I used autoconf-2.69 and build from the [source](https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz) . But it looks a bit different from the one generated in the repo. I also tried autoconf-2.69 that comes with ubuntu 20.04 and the generated file is similar to the one in https://github.com/openjdk/jdk8u-dev/pull/413. I'm not quite sure which version of autoconf2.69 to use, if anyone has a better suggestion or is willing to help me generate a different one, I'd appreciate it! >> >> Both cross-compile build and native build on riscv64 hardware is tested. >> >> ### cross-compile on x86 >> #### boot jdk >> >> openjdk version "1.8.0_43" >> OpenJDK Runtime Environment (build 1.8.0_43-b03) >> OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode) >> >> #### run on qemu >> >> openjdk version "1.8.0_432-internal" >> OpenJDK Runtime Environment (build 1.8.0_432-internal-zhangdingli_2024_09_02_21_37-b00) >> OpenJDK 64-Bit Zero VM (build 25.432-b00, interpreted mode) >> >> ### native build on lp4a >> #### boot jdk >> >> openjdk version "1.8.0_412" >> OpenJDK Runtime Environment Bisheng (build 1.8.0_412-b08) >> OpenJDK 64-Bit Zero VM Bisheng (build 25.412-b08, interpreted mode) >> >> #### run on lp4a >> >> openjdk version "1.8.0_432-internal" >> OpenJDK Runtime Environment (build 1.8.0_432-internal-openeuler_2024_09_02_21_38-b00) >> OpenJDK 64-Bit Zero VM (build 25.432-b00, interpreted mode) >> >> >> Thanks, >> Dingli > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Put EM_RISCV after definition of EM_LOONGARCH bot, please keep it open ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/573#issuecomment-3135184621 From andrew at openjdk.org Wed Jul 30 13:25:11 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 30 Jul 2025 13:25:11 GMT Subject: [jdk8u-dev] RFR: 8335978: [8u] incorrect include file name in semaphore.inline.hpp [v2] In-Reply-To: References:

Message-ID: On Tue, 24 Jun 2025 12:27:50 GMT, SendaoYan wrote: >> Hi all, >> In file [semaphore.inline.hpp](https://github.com/openjdk/jdk8u-dev/blame/master/hotspot/src/share/vm/runtime/semaphore.inline.hpp#L28), `#include "runtime/interfaceSupport.inline.hpp"` include incorrect file name, the crrect file name shoule be interfaceSupport.hpp in jdk8u repository. >> >> Additional testing: >> >> - [x] linux x64 tier1/2/3 >> - [x] linux aarch64 tier1/2/3 > > SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into jbs8335978 > - 8335978: [8u] incorrect include file name in semaphore.inline.hpp Good catch. It looks like this was introduced by the [JFR backport](https://github.com/openjdk/jdk8u/commit/6ca492afe7c59b014c6ce0628eb88d7da34020b5). It surprises me that there have been no warnings or errors produced for the missing include file or `ThreadBlockInVM` which it defines. A `gcc -E` from the command line does show it: ~~~ $ gcc -I hotspot/src/share/vm -E hotspot/src/share/vm/runtime/semaphore.inline.hpp # 1 "hotspot/src/share/vm/runtime/semaphore.inline.hpp" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "hotspot/src/share/vm/runtime/semaphore.inline.hpp" hotspot/src/share/vm/runtime/semaphore.inline.hpp:28:10: fatal error: runtime/interfaceSupport.inline.hpp: No such file or directory #include "runtime/interfaceSupport.inline.hpp" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. ~~~ ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/543#issuecomment-3136337567