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: <NfgnC84eaFlwIBM7_v5uVKTEBTGkqjTwi2ZfkWK1-qE=.a422360e-fdde-4b7e-9fb7-1dd8000504de@github.com>
References: <NfgnC84eaFlwIBM7_v5uVKTEBTGkqjTwi2ZfkWK1-qE=.a422360e-fdde-4b7e-9fb7-1dd8000504de@github.com>
Message-ID: <ys1NLSQbRuqM2SJjktm_U-xAGcnCw_a9B2L0RBV-B-4=.c662796e-2d88-476f-b8c8-f95ff0272804@github.com>

On Mon, 30 Jun 2025 05:00:02 GMT, Lei Zhu <duke at openjdk.org> 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: <GIM7CKfL9MXN09nGPgxz4myZkb-w5xv15WlIZkbKzjI=.26208b9d-a352-49c5-8dbb-999287ba9965@github.com>
References: <c2WFqTR5vrvW8yL1XyBI3P-HOzZ-mjiWeeObVOJphPM=.d1f02d28-f1d8-4325-898b-34749b323b2e@github.com>
 <GIM7CKfL9MXN09nGPgxz4myZkb-w5xv15WlIZkbKzjI=.26208b9d-a352-49c5-8dbb-999287ba9965@github.com>
Message-ID: <3JMpBBXOodXHQTeP3Br5LSmfHxiAM5KTN0LlCZSjrHs=.77f84b89-695e-4899-b030-b2ecea25d733@github.com>

On Tue, 3 Sep 2024 11:34:42 GMT, Dingli Zhang <dzhang at openjdk.org> 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: <aGRUzc3vx6/zPWOe@rincewind>

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: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20250701/d750c293/signature.asc>

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: <BNVg7kKEBNxEBJt6_iTJ9g1bagRhadJUTcwNHV8B2_c=.8f471fcd-0fb3-424e-a355-d071aa5817f3@github.com>

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: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20250702/6c015185/attachment.htm>

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: <BNVg7kKEBNxEBJt6_iTJ9g1bagRhadJUTcwNHV8B2_c=.8f471fcd-0fb3-424e-a355-d071aa5817f3@github.com>
References: <BNVg7kKEBNxEBJt6_iTJ9g1bagRhadJUTcwNHV8B2_c=.8f471fcd-0fb3-424e-a355-d071aa5817f3@github.com>
Message-ID: <3l7-mTJxh7RVabqb4dZioTYA2Ozbhj-AYcKFFCCIxJw=.2fc9cd61-2dd4-4e1d-96ca-db0a28003358@github.com>

On Wed, 2 Jul 2025 04:30:56 GMT, hanguanqiang <duke at openjdk.org> 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: <NfgnC84eaFlwIBM7_v5uVKTEBTGkqjTwi2ZfkWK1-qE=.a422360e-fdde-4b7e-9fb7-1dd8000504de@github.com>
References: <NfgnC84eaFlwIBM7_v5uVKTEBTGkqjTwi2ZfkWK1-qE=.a422360e-fdde-4b7e-9fb7-1dd8000504de@github.com>
Message-ID: <u-3dQkFraSYQQaw6gZKwFXETIW915v1ay9GmugO1swg=.57313653-c101-4441-ab02-8f425b099fb8@github.com>

On Mon, 30 Jun 2025 05:00:02 GMT, Lei Zhu <duke at openjdk.org> 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: <BNVg7kKEBNxEBJt6_iTJ9g1bagRhadJUTcwNHV8B2_c=.8f471fcd-0fb3-424e-a355-d071aa5817f3@github.com>
References: <BNVg7kKEBNxEBJt6_iTJ9g1bagRhadJUTcwNHV8B2_c=.8f471fcd-0fb3-424e-a355-d071aa5817f3@github.com>
Message-ID: <jNGcM2ss7kp78YJs_wVAU3moBUUrRi5QSAPl8AGfS4o=.2092ce58-68af-49f3-89b3-aa0bbcfd9828@github.com>

On Wed, 2 Jul 2025 04:30:56 GMT, hanguanqiang <duke at openjdk.org> 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: <BNVg7kKEBNxEBJt6_iTJ9g1bagRhadJUTcwNHV8B2_c=.8f471fcd-0fb3-424e-a355-d071aa5817f3@github.com>
References: <BNVg7kKEBNxEBJt6_iTJ9g1bagRhadJUTcwNHV8B2_c=.8f471fcd-0fb3-424e-a355-d071aa5817f3@github.com>
Message-ID: <Ms49zNv8kjgNUUP21GmKuXP6FRSxdVXFSqXEE_2cjIU=.1c1c23fa-19b1-4a45-9a2e-bf5c200ce721@github.com>

On Wed, 2 Jul 2025 04:30:56 GMT, hanguanqiang <duke at openjdk.org> 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: <s3qQ6VDUktxWmDaUF-83LJblhcnICja6UStqS0a39sI=.5893e03a-865d-4cc1-9f66-4b6f8798808b@github.com>
References: <s3qQ6VDUktxWmDaUF-83LJblhcnICja6UStqS0a39sI=.5893e03a-865d-4cc1-9f66-4b6f8798808b@github.com>
Message-ID: <LEbzCgMU1deSrhyegMcqQIfnPBnHUzOVEl4Oq0KmkyE=.1ad05f00-c5b0-486b-b949-3dcfcda2496a@github.com>

On Fri, 30 May 2025 13:31:05 GMT, Zhengyu Gu <zgu at openjdk.org> 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: <RVDCDddf_l7FvAlVgufpmWTctBiOFrkEp1EARpy7oUw=.ffe8e709-d170-4d3e-9b53-d2013a09e917@github.com>

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: <RVDCDddf_l7FvAlVgufpmWTctBiOFrkEp1EARpy7oUw=.ffe8e709-d170-4d3e-9b53-d2013a09e917@github.com>
References: <RVDCDddf_l7FvAlVgufpmWTctBiOFrkEp1EARpy7oUw=.ffe8e709-d170-4d3e-9b53-d2013a09e917@github.com>
Message-ID: <eMWccgDK9uL7E6E2enpqticiStSvDX_sCeaUquI0hZs=.4377ad76-ba8e-41c4-ab01-b1aaea06b501@github.com>

On Thu, 3 Jul 2025 12:53:08 GMT, Antonio Vieiro <duke at openjdk.org> 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: <Z6tY13j_hXnW74zuXEi7V4wXEhgL7O8OerF_UMbh3TQ=.a89261e7-3150-48b7-ba0c-70ca66dd9467@github.com>

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: <RVDCDddf_l7FvAlVgufpmWTctBiOFrkEp1EARpy7oUw=.ffe8e709-d170-4d3e-9b53-d2013a09e917@github.com>
References: <RVDCDddf_l7FvAlVgufpmWTctBiOFrkEp1EARpy7oUw=.ffe8e709-d170-4d3e-9b53-d2013a09e917@github.com>
Message-ID: <Oupd1UEbSb_06F0euURW41t1UcHyde8sKS2tlYEUe1Q=.591bd094-84af-4d36-a46b-dca9846ee973@github.com>

On Thu, 3 Jul 2025 12:53:08 GMT, Antonio Vieiro <duke at openjdk.org> 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: <RVDCDddf_l7FvAlVgufpmWTctBiOFrkEp1EARpy7oUw=.ffe8e709-d170-4d3e-9b53-d2013a09e917@github.com>
References: <RVDCDddf_l7FvAlVgufpmWTctBiOFrkEp1EARpy7oUw=.ffe8e709-d170-4d3e-9b53-d2013a09e917@github.com>
Message-ID: <1j-X5oezREj65nhxjyshqdo3O_Ima-PYCqocJzDjLgw=.b0d326a3-a2f2-45b7-89c1-1764bd1d3b15@github.com>

On Thu, 3 Jul 2025 12:53:08 GMT, Antonio Vieiro <duke at openjdk.org> 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: <RVDCDddf_l7FvAlVgufpmWTctBiOFrkEp1EARpy7oUw=.ffe8e709-d170-4d3e-9b53-d2013a09e917@github.com>
References: <RVDCDddf_l7FvAlVgufpmWTctBiOFrkEp1EARpy7oUw=.ffe8e709-d170-4d3e-9b53-d2013a09e917@github.com>
Message-ID: <zmig6wzXGt8NhspngkCd3QSE5kmvHAH5AsxWPviU0aI=.2f3cbb64-d600-4996-8315-a4dadd37c44c@github.com>

On Thu, 3 Jul 2025 12:53:08 GMT, Antonio Vieiro <duke at openjdk.org> 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 <avieirov at redhat.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
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