From jpai at openjdk.org  Wed Oct  1 01:45:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 1 Oct 2025 01:45:19 GMT
Subject: RFR: 8367026: Reorder the timeout failure handler commands to have
 jstack run before the rest
In-Reply-To: <MI6hWYYYACr-gEUwxXQg04YvFbVbanAyvlY18AkaLyI=.43bdb669-8615-4bf4-8232-cb4c6165f10e@github.com>
References: <MI6hWYYYACr-gEUwxXQg04YvFbVbanAyvlY18AkaLyI=.43bdb669-8615-4bf4-8232-cb4c6165f10e@github.com>
Message-ID: <6_GILTLKull58arLWhkD5j1wr3FJgvMiOhZmOfN_uhI=.d1b9e77b-21fc-40f9-8bcd-c02ff04992db@github.com>

On Tue, 30 Sep 2025 11:37:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to a jtreg failure handler configured in the JDK?
> 
> The change proposes to generate a thread dump much sooner than previously whenever a test times out. This should thus capture a much more accurate state of the test process when the test is considered timed out.
> 
> Due to the recent changes in the default timeout factor, we have noticed some tests which timeout and the jtreg failure handler actions start execution. While those are being executed the test sometimes completes. So by the time the "jstack" failure handler action is executed (can be several seconds later), the test's state will no longer be accurate.
> 
> The change here generates a thread dump using jstack as the first action in the set of failure handler actions. It does it only once and then moves to the rest of the actions, one of which subsequent "jstack" which generates thread dumps more than once.
> 
> I have verified that this change works as expected when a test times out. The action is named "thread_dump" instead of just reusing the "jstack" name because the current HTML rendering of the processes.html runs into trouble if there are more than one action with the same name.
> 
> I wanted to reorder some of the other commands in that set, but it causes some trouble in the rendering of the HTML and would require some changes to that part. So I decided to keep this simple and have it done sooner to help investigating timeout failures in our CI.

Thank you Erik and Leonid for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27574#issuecomment-3354369661

From jpai at openjdk.org  Wed Oct  1 01:45:20 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 1 Oct 2025 01:45:20 GMT
Subject: Integrated: 8367026: Reorder the timeout failure handler commands to
 have jstack run before the rest
In-Reply-To: <MI6hWYYYACr-gEUwxXQg04YvFbVbanAyvlY18AkaLyI=.43bdb669-8615-4bf4-8232-cb4c6165f10e@github.com>
References: <MI6hWYYYACr-gEUwxXQg04YvFbVbanAyvlY18AkaLyI=.43bdb669-8615-4bf4-8232-cb4c6165f10e@github.com>
Message-ID: <6wH1y-RQejYv1DAnMtfjsqeLa2-SDehXDkKAis4Z1Zs=.91f1d14c-6074-4921-95ed-0a9048ecea9d@github.com>

On Tue, 30 Sep 2025 11:37:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to a jtreg failure handler configured in the JDK?
> 
> The change proposes to generate a thread dump much sooner than previously whenever a test times out. This should thus capture a much more accurate state of the test process when the test is considered timed out.
> 
> Due to the recent changes in the default timeout factor, we have noticed some tests which timeout and the jtreg failure handler actions start execution. While those are being executed the test sometimes completes. So by the time the "jstack" failure handler action is executed (can be several seconds later), the test's state will no longer be accurate.
> 
> The change here generates a thread dump using jstack as the first action in the set of failure handler actions. It does it only once and then moves to the rest of the actions, one of which subsequent "jstack" which generates thread dumps more than once.
> 
> I have verified that this change works as expected when a test times out. The action is named "thread_dump" instead of just reusing the "jstack" name because the current HTML rendering of the processes.html runs into trouble if there are more than one action with the same name.
> 
> I wanted to reorder some of the other commands in that set, but it causes some trouble in the rendering of the HTML and would require some changes to that part. So I decided to keep this simple and have it done sooner to help investigating timeout failures in our CI.

This pull request has now been integrated.

Changeset: 17d8fa8e
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17d8fa8e421db67027c9e7d2ddd634ff0b897cb6
Stats:     12 lines in 1 file changed: 10 ins; 0 del; 2 mod

8367026: Reorder the timeout failure handler commands to have jstack run before the rest

Reviewed-by: erikj, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/27574

From mbaesken at openjdk.org  Wed Oct  1 08:34:35 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 1 Oct 2025 08:34:35 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build
Message-ID: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>

In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.

An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .

-------------

Commit messages:
 - JDK-8368960

Changes: https://git.openjdk.org/jdk/pull/27588/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27588&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368960
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27588/head:pull/27588

PR: https://git.openjdk.org/jdk/pull/27588

From mbaesken at openjdk.org  Wed Oct  1 11:44:23 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 1 Oct 2025 11:44:23 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v2]
In-Reply-To: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
Message-ID: <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>

> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
> 
> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Remove special handling from ToolsJdk

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27588/files
  - new: https://git.openjdk.org/jdk/pull/27588/files/74351b4e..d674a86f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27588&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27588&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27588/head:pull/27588

PR: https://git.openjdk.org/jdk/pull/27588

From erikj at openjdk.org  Wed Oct  1 13:03:40 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 1 Oct 2025 13:03:40 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v2]
In-Reply-To: <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
Message-ID: <98-5Y5r7Ua9tUc2ucfy6icP58sXYtq7VasU5T-64nw4=.0762883a-f70e-49fb-8f1b-6c7604112a64@github.com>

On Wed, 1 Oct 2025 11:44:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
>> 
>> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove special handling from ToolsJdk

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27588#pullrequestreview-3289012833

From duke at openjdk.org  Wed Oct  1 14:02:51 2025
From: duke at openjdk.org (craigraw)
Date: Wed, 1 Oct 2025 14:02:51 GMT
Subject: RFR: 8345810: Custom launchers must be linked with pthread to
 avoid dynamic linker issues [v2]
In-Reply-To: <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
References: <pXf8-xw4yhb4gRzNDS4GdcQ8uVF80kA0iLZpqUYKot4=.0cdf9034-43ac-4e66-8349-bfb8157db2fd@github.com>
 <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
Message-ID: <3wmTc01gqlZgKbHbolEjymrkTN0ONFgmSLlfTjHvKfI=.9c3b4fcd-79b0-4702-8dd0-a8c7b8257bf7@github.com>

On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more investigation.
>> 
>> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to debug it to older glibc issue, which makes `dlerror` not thread-safe when pthreads are not yet loaded. This bug seems to uniquely affect custom launchers. We figured this is because custom launchers are not linked with `pthread`. JLI seems to be avoiding this issue, because it does link with `pthread`. Therefore the fix on the JDK side is to always link custom launchers with `pthread`.
>> 
>> Reproducing the issue is a bit awkward. It requires compiling with older GCC (7.3.1 in my case), so that `libsimdsort` would not expose `avx2_sort` symbol, so that compiler stub initialization sequence would get its own erroneous `dlerror`, which would conflict inside of glibc. The compilations with newer GCC (10, at very least) are not exposed to this. This is why the issue is so elusive. But now that we understand it, we know this is a ticking time bomb that can fire at any time in the future, once any concurrent thread inside of VM gets a non-zero `dlerror` for whatever reason.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `sun/management/jmxremote`, 100x, no failures
>>  - [x] Linux AArch64 server fastdebug, `tools/jpackage`, 20x, no failures
>>  - [x] Linux AArch64 server fastdebug, `jdk_all`, no failures
>
> Aleksey Shipilev 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:
> 
>  - Broader pthread linkage for all JDK jtreg executables, similar to how Hotspot jtreg executables do it
>  - Merge branch 'master' into JDK-8345810-custom-launcher-dlerror
>  - Change to LIB* variables
>  - Fix

It really feels like the bug is serious enough to warrant backporting this fix into Java 25 LTS. Currently it is not safe to create a multithreaded jpackaged app that may be run on older Linux distro releases, including Ubuntu 20.04.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26978#issuecomment-3355948391

From duke at openjdk.org  Wed Oct  1 15:03:28 2025
From: duke at openjdk.org (Sean Gilligan)
Date: Wed, 1 Oct 2025 15:03:28 GMT
Subject: RFR: 8345810: Custom launchers must be linked with pthread to
 avoid dynamic linker issues [v2]
In-Reply-To: <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
References: <pXf8-xw4yhb4gRzNDS4GdcQ8uVF80kA0iLZpqUYKot4=.0cdf9034-43ac-4e66-8349-bfb8157db2fd@github.com>
 <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
Message-ID: <fVNxDl4pW4K6CYnr_wS1BoPZ3LFL9jMY28eXvt_cFDs=.fdeb0a3c-9388-4b6c-86e0-56c5a0763bd1@github.com>

On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more investigation.
>> 
>> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to debug it to older glibc issue, which makes `dlerror` not thread-safe when pthreads are not yet loaded. This bug seems to uniquely affect custom launchers. We figured this is because custom launchers are not linked with `pthread`. JLI seems to be avoiding this issue, because it does link with `pthread`. Therefore the fix on the JDK side is to always link custom launchers with `pthread`.
>> 
>> Reproducing the issue is a bit awkward. It requires compiling with older GCC (7.3.1 in my case), so that `libsimdsort` would not expose `avx2_sort` symbol, so that compiler stub initialization sequence would get its own erroneous `dlerror`, which would conflict inside of glibc. The compilations with newer GCC (10, at very least) are not exposed to this. This is why the issue is so elusive. But now that we understand it, we know this is a ticking time bomb that can fire at any time in the future, once any concurrent thread inside of VM gets a non-zero `dlerror` for whatever reason.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `sun/management/jmxremote`, 100x, no failures
>>  - [x] Linux AArch64 server fastdebug, `tools/jpackage`, 20x, no failures
>>  - [x] Linux AArch64 server fastdebug, `jdk_all`, no failures
>
> Aleksey Shipilev 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:
> 
>  - Broader pthread linkage for all JDK jtreg executables, similar to how Hotspot jtreg executables do it
>  - Merge branch 'master' into JDK-8345810-custom-launcher-dlerror
>  - Change to LIB* variables
>  - Fix

It looks like the back port is here: https://github.com/openjdk/jdk25u/pull/257

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26978#issuecomment-3356859483

From bpb at openjdk.org  Wed Oct  1 16:43:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 1 Oct 2025 16:43:10 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v16]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <zpsaCrgZQIHZY-HAlSFxruwk13dsLxEYhgl2Aj7zTdE=.4da22ba3-8893-44ed-b61c-2f689b1e47f7@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - ... and 6 more: https://git.openjdk.org/jdk/compare/fe9dbcc4...498be60b

-------------

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=15
  Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From dholmes at openjdk.org  Wed Oct  1 21:23:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Oct 2025 21:23:04 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v2]
In-Reply-To: <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
Message-ID: <UErgDV7pYgds0myqI_Bu8jgsMCKVXKz_9YXmqLqBypU=.8c7cb533-8cd7-4118-944b-846bdecf6a3c@github.com>

On Wed, 1 Oct 2025 11:44:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
>> 
>> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove special handling from ToolsJdk

@MBaesken I thought the aim was to redirect log warnings/errors to stderr, not to disable logging completely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3358170920

From mbaesken at openjdk.org  Thu Oct  2 07:57:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Oct 2025 07:57:46 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v2]
In-Reply-To: <UErgDV7pYgds0myqI_Bu8jgsMCKVXKz_9YXmqLqBypU=.8c7cb533-8cd7-4118-944b-846bdecf6a3c@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
 <UErgDV7pYgds0myqI_Bu8jgsMCKVXKz_9YXmqLqBypU=.8c7cb533-8cd7-4118-944b-846bdecf6a3c@github.com>
Message-ID: <NUN-amPUAY0CK24XPqpIgw4a7TW4Oix9sn32eTORqz8=.7a33369b-387c-46e1-8dc1-044d1e1ae550@github.com>

On Wed, 1 Oct 2025 21:20:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I thought the aim was to redirect log warnings/errors to stderr, not to disable logging completely.

Yeah I considered this too.
But not sure about it ; bring the UL messages (warnings/errors etc.) really a benefit _in the build_  itself ?
But I am open to set some other UL command line flags keeping messages .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3359701227

From erikj at openjdk.org  Thu Oct  2 13:16:55 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 2 Oct 2025 13:16:55 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v2]
In-Reply-To: <NUN-amPUAY0CK24XPqpIgw4a7TW4Oix9sn32eTORqz8=.7a33369b-387c-46e1-8dc1-044d1e1ae550@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
 <UErgDV7pYgds0myqI_Bu8jgsMCKVXKz_9YXmqLqBypU=.8c7cb533-8cd7-4118-944b-846bdecf6a3c@github.com>
 <NUN-amPUAY0CK24XPqpIgw4a7TW4Oix9sn32eTORqz8=.7a33369b-387c-46e1-8dc1-044d1e1ae550@github.com>
Message-ID: <NZqNUqdW-gtDe-yhgVHpfmdLynXeAVdHL4rn3XHgUtI=.9f201b36-4143-49a1-b55a-e6c33db67607@github.com>

On Thu, 2 Oct 2025 07:55:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I thought the aim was to redirect log warnings/errors to stderr, not to disable logging completely.
> 
> Yeah I considered this too. But not sure about it ; bring the UL messages (warnings/errors etc.) really a benefit _in the build_ itself ? But I am open to set some other UL command line flags keeping messages .

If it's possible to redirect it to stderr, I think that would be preferred. It would make us aware of misconfigured tool command lines. 

In the case of the original warning you saw that triggered this, I think we need to actually fix our usage of CDS in the boot JDK. The current implementation was introduced back when the JDK didn't ship with a default CDS archive. Now that it does, we don't actually need to create one in configure. It would be interesting to see if there is any performance difference using the default archive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3361176686

From mbaesken at openjdk.org  Thu Oct  2 15:06:35 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Oct 2025 15:06:35 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v3]
In-Reply-To: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
Message-ID: <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>

> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
> 
> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust logging in the build instead of just disabling it

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27588/files
  - new: https://git.openjdk.org/jdk/pull/27588/files/d674a86f..498d70f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27588&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27588&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27588/head:pull/27588

PR: https://git.openjdk.org/jdk/pull/27588

From mbaesken at openjdk.org  Thu Oct  2 15:06:36 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Oct 2025 15:06:36 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v2]
In-Reply-To: <NZqNUqdW-gtDe-yhgVHpfmdLynXeAVdHL4rn3XHgUtI=.9f201b36-4143-49a1-b55a-e6c33db67607@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
 <UErgDV7pYgds0myqI_Bu8jgsMCKVXKz_9YXmqLqBypU=.8c7cb533-8cd7-4118-944b-846bdecf6a3c@github.com>
 <NUN-amPUAY0CK24XPqpIgw4a7TW4Oix9sn32eTORqz8=.7a33369b-387c-46e1-8dc1-044d1e1ae550@github.com>
 <NZqNUqdW-gtDe-yhgVHpfmdLynXeAVdHL4rn3XHgUtI=.9f201b36-4143-49a1-b55a-e6c33db67607@github.com>
Message-ID: <ltNxAn3sLBEkAAREYtzHXjwmW8rZTxcR_EIdpQa7XbI=.cf2a01ba-f63c-401f-be02-b3a08772ddf9@github.com>

On Thu, 2 Oct 2025 13:14:04 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> If it's possible to redirect it to stderr, I think that would be preferred. It would make us aware of misconfigured tool command  lines.

I adjusted the settings, please comment if this is better.

> In the case of the original warning you saw that triggered this, I think we need to actually fix our usage of CDS in the boot JDK

So do you think we can just kick out this archive dumping + `Xshare=something`  setting from configure ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3361622681
PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3361627445

From jwaters at openjdk.org  Thu Oct  2 16:29:41 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Oct 2025 16:29:41 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
Message-ID: <6c9c2AO4gs36Po0A6Z4pYOhqv8a3AoYSxxlmMWPYr2E=.939c38bb-965c-4cd2-af9f-38078c7835c7@github.com>

On Fri, 10 Jan 2025 10:42:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> Hi, the workaround 'disable lto in g1ParScanThreadState because of special inlining/flattening used there' is removed , why this works now ?
>> 
>> The issue there was the `-Wattribute-warning` warnings that were being generated.  But this change is suppressing
>> those warnings in the LTO link:
>> https://github.com/openjdk/jdk/blame/9d05cb8eff344fea3c6b9a9686b728ec53963978/make/hotspot/lib/JvmFeatures.gmk#L176C11-L176C11
>> Note that won't work with the new portable forbidding mechanism based on `deprecated` attributes.
>> 
>> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans.
>> The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.
>
>> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.
> 
> Turns out I didn't wait long enough.  It does terminate after about 40 minutes, though not successfully.  Instead the
> build crashes with a failed assert:
> 
> #  Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=4017588, tid=4017620
> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
> 
> I've not tried to debug this.  Maybe it's a consequence of one of those problems of bypassing an intentional implicit
> noinline in our code (by ensuring a function definition is in a different TU from all callers), with LTO breaking that.
> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
> by normal compilation).

After trying and failing and trying and failing countless hours and days... I admit I'm nowhere close to solving this problem. I just can't figure out what the slow paths and external methods not local to the g1ParScanThreadState.cpp source file are. Every attempt at using a tool to discern this has failed catastrophically, and the call hierarchy is enormous, meaning manually trying to do this myself is out of the question. @kimbarrett if I could ask, what are the slow paths that should not be inlined, and what are the methods that are not local to the source file in question? If I just knew what to look at, maybe I could begin to start tackling this problem properly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3362079047

From erikj at openjdk.org  Thu Oct  2 17:15:06 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 2 Oct 2025 17:15:06 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v2]
In-Reply-To: <ltNxAn3sLBEkAAREYtzHXjwmW8rZTxcR_EIdpQa7XbI=.cf2a01ba-f63c-401f-be02-b3a08772ddf9@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
 <UErgDV7pYgds0myqI_Bu8jgsMCKVXKz_9YXmqLqBypU=.8c7cb533-8cd7-4118-944b-846bdecf6a3c@github.com>
 <NUN-amPUAY0CK24XPqpIgw4a7TW4Oix9sn32eTORqz8=.7a33369b-387c-46e1-8dc1-044d1e1ae550@github.com>
 <NZqNUqdW-gtDe-yhgVHpfmdLynXeAVdHL4rn3XHgUtI=.9f201b36-4143-49a1-b55a-e6c33db67607@github.com>
 <ltNxAn3sLBEkAAREYtzHXjwmW8rZTxcR_EIdpQa7XbI=.cf2a01ba-f63c-401f-be02-b3a08772ddf9@github.com>
Message-ID: <igCVKpgOrXXRr1I0O2q-GkOQG1nZP3EO_BsCFyv2frQ=.43780407-c100-41b6-916f-c5807a82e337@github.com>

On Thu, 2 Oct 2025 15:03:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > In the case of the original warning you saw that triggered this, I think we need to actually fix our usage of CDS in the boot JDK
> 
> So do you think we can just kick out this archive dumping + `Xshare=something` setting from configure ?

Yes, I think we can, but I would like to see it verified to not cause a regression in build performance before we do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3362227200

From erikj at openjdk.org  Thu Oct  2 17:20:01 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 2 Oct 2025 17:20:01 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v3]
In-Reply-To: <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>
Message-ID: <63G3Ej-C0CaWvvb9GxTYDrcQS61dwHaDTDywmViii38=.a8f15e4e-243f-448c-9641-b893184f086d@github.com>

On Thu, 2 Oct 2025 15:06:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
>> 
>> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust logging in the build instead of just disabling it

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27588#pullrequestreview-3295633958

From pavel.rappo at gmail.com  Thu Oct  2 17:09:29 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Thu, 2 Oct 2025 18:09:29 +0100
Subject: How to pass javatest.maxOutputSize to make test?
Message-ID: <CAChcVu=Ob+3kEOmRXbi7UrnGkmOdtq-5CqPee+Z7cURdCfQ26w@mail.gmail.com>

Hello,

This has been probably asked multiple times, but I cannot quickly find
anything. I'm running a set of tests as follows:

    make test TEST="test/jdk/java/time/"

If a test fails, sometimes I get this output:

    ...
    Output overflow:
    JT Harness has limited the test output to the text
    at the beginning and the end, so that you can see how the
    test began, and how it completed.

    If you need to see more of the output from the test,
    set the system property javatest.maxOutputSize to a higher
    value. The current value is 100000
    ...

I know there's even an FAQ item [^1] addressing this property. But I
cannot easily see how to translate jtreg syntax to that of `make
test`. Whatever I tried hasn't worked. As a workaround, I added this
to the nearest TEST.properties:

    maxOutputSize=99999999

[^1]: https://openjdk.org/jtreg/faq.html#how-to-set-javatest.maxOutputSize

From djelinski1 at gmail.com  Thu Oct  2 18:40:39 2025
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Thu, 2 Oct 2025 20:40:39 +0200
Subject: How to pass javatest.maxOutputSize to make test?
In-Reply-To: <CAChcVu=Ob+3kEOmRXbi7UrnGkmOdtq-5CqPee+Z7cURdCfQ26w@mail.gmail.com>
References: <CAChcVu=Ob+3kEOmRXbi7UrnGkmOdtq-5CqPee+Z7cURdCfQ26w@mail.gmail.com>
Message-ID: <CAMrH03KWJQytzmOOeTgLQ+t3bH9+iLoKFzNvdkL8HEO=r5vkAg@mail.gmail.com>

Hi Pavel,
JTREG=MAX_OUTPUT=999999999 is what you're looking for.
Cheers,
Daniel

czw., 2 pa? 2025 o 20:37 Pavel Rappo <pavel.rappo at gmail.com> napisa?(a):
>
> Hello,
>
> This has been probably asked multiple times, but I cannot quickly find
> anything. I'm running a set of tests as follows:
>
>     make test TEST="test/jdk/java/time/"
>
> If a test fails, sometimes I get this output:
>
>     ...
>     Output overflow:
>     JT Harness has limited the test output to the text
>     at the beginning and the end, so that you can see how the
>     test began, and how it completed.
>
>     If you need to see more of the output from the test,
>     set the system property javatest.maxOutputSize to a higher
>     value. The current value is 100000
>     ...
>
> I know there's even an FAQ item [^1] addressing this property. But I
> cannot easily see how to translate jtreg syntax to that of `make
> test`. Whatever I tried hasn't worked. As a workaround, I added this
> to the nearest TEST.properties:
>
>     maxOutputSize=99999999
>
> [^1]: https://openjdk.org/jtreg/faq.html#how-to-set-javatest.maxOutputSize

From pavel.rappo at gmail.com  Thu Oct  2 19:00:21 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Thu, 2 Oct 2025 20:00:21 +0100
Subject: How to pass javatest.maxOutputSize to make test?
In-Reply-To: <CAMrH03KWJQytzmOOeTgLQ+t3bH9+iLoKFzNvdkL8HEO=r5vkAg@mail.gmail.com>
References: <CAChcVu=Ob+3kEOmRXbi7UrnGkmOdtq-5CqPee+Z7cURdCfQ26w@mail.gmail.com>
 <CAMrH03KWJQytzmOOeTgLQ+t3bH9+iLoKFzNvdkL8HEO=r5vkAg@mail.gmail.com>
Message-ID: <CAChcVum8aakWmc5rOk2Y1fX=Ci+j0G0rf0zK40nVh_i4F5y6+w@mail.gmail.com>

It works, thanks!

I found a JBS issue that mentions this:
https://bugs.openjdk.org/browse/JDK-8220639. I wonder if this
parameter can be mentioned in these documents, so it could be easily
found by the next person:

  - https://openjdk.org/groups/build/doc/testing.html
  - https://github.com/openjdk/jdk/blob/master/doc/testing.md
  - https://openjdk.org/guide/#testing-the-jdk

On Thu, Oct 2, 2025 at 7:40?PM Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>
> Hi Pavel,
> JTREG=MAX_OUTPUT=999999999 is what you're looking for.
> Cheers,
> Daniel
>
> czw., 2 pa? 2025 o 20:37 Pavel Rappo <pavel.rappo at gmail.com> napisa?(a):
> >
> > Hello,
> >
> > This has been probably asked multiple times, but I cannot quickly find
> > anything. I'm running a set of tests as follows:
> >
> >     make test TEST="test/jdk/java/time/"
> >
> > If a test fails, sometimes I get this output:
> >
> >     ...
> >     Output overflow:
> >     JT Harness has limited the test output to the text
> >     at the beginning and the end, so that you can see how the
> >     test began, and how it completed.
> >
> >     If you need to see more of the output from the test,
> >     set the system property javatest.maxOutputSize to a higher
> >     value. The current value is 100000
> >     ...
> >
> > I know there's even an FAQ item [^1] addressing this property. But I
> > cannot easily see how to translate jtreg syntax to that of `make
> > test`. Whatever I tried hasn't worked. As a workaround, I added this
> > to the nearest TEST.properties:
> >
> >     maxOutputSize=99999999
> >
> > [^1]: https://openjdk.org/jtreg/faq.html#how-to-set-javatest.maxOutputSize

From mikael at openjdk.org  Fri Oct  3 03:23:17 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 3 Oct 2025 03:23:17 GMT
Subject: RFR: 8369080: Use uname -m for devkit cpu detection
Message-ID: <tu4CHsxoR5mVLkuA_T0WLoZGAWor4VivUs3fW8zJiAI=.4d5bccbd-f157-4d03-8e8f-b01ea6c88667@github.com>

The devkit creation uses uname -p for detection the cpu architecture. uname -p is non-portable and no longer works on recent Linux/distributions (e.g. OL10). It should be changed to uname -m which is portable and works.

Testing: manual verification on ol{7,8,9,10}-{aarch64,x86_64}

-------------

Commit messages:
 - 8369080: Use uname -m for devkit cpu detection

Changes: https://git.openjdk.org/jdk/pull/27617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27617&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369080
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27617/head:pull/27617

PR: https://git.openjdk.org/jdk/pull/27617

From iris at openjdk.org  Fri Oct  3 03:38:51 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 3 Oct 2025 03:38:51 GMT
Subject: RFR: 8369080: Use uname -m for devkit cpu detection
In-Reply-To: <tu4CHsxoR5mVLkuA_T0WLoZGAWor4VivUs3fW8zJiAI=.4d5bccbd-f157-4d03-8e8f-b01ea6c88667@github.com>
References: <tu4CHsxoR5mVLkuA_T0WLoZGAWor4VivUs3fW8zJiAI=.4d5bccbd-f157-4d03-8e8f-b01ea6c88667@github.com>
Message-ID: <xNgacvtp9I_qRE-GCwBSBWdgnKAC-HP4y-QrJpvaem8=.547964be-645e-470d-8bc7-4906643583d1@github.com>

On Fri, 3 Oct 2025 03:16:32 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The devkit creation uses uname -p for detection the cpu architecture. uname -p is non-portable and no longer works on recent Linux/distributions (e.g. OL10). It should be changed to uname -m which is portable and works.
> 
> Testing: manual verification on ol{7,8,9,10}-{aarch64,x86_64}

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27617#pullrequestreview-3297285539

From alan.bateman at oracle.com  Fri Oct  3 05:55:55 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 3 Oct 2025 06:55:55 +0100
Subject: How to pass javatest.maxOutputSize to make test?
In-Reply-To: <CAChcVu=Ob+3kEOmRXbi7UrnGkmOdtq-5CqPee+Z7cURdCfQ26w@mail.gmail.com>
References: <CAChcVu=Ob+3kEOmRXbi7UrnGkmOdtq-5CqPee+Z7cURdCfQ26w@mail.gmail.com>
Message-ID: <87dd3b16-df02-413d-b3ca-d7190a6d67cb@oracle.com>



On 02/10/2025 18:09, Pavel Rappo wrote:
> Hello,
>
> This has been probably asked multiple times, but I cannot quickly find
> anything. I'm running a set of tests as follows:
>
>      make test TEST="test/jdk/java/time/"
>
> If a test fails, sometimes I get this output:
>
>      ...
>      Output overflow:
>      JT Harness has limited the test output to the text
>      at the beginning and the end, so that you can see how the
>      test began, and how it completed.
>
>      If you need to see more of the output from the test,
>      set the system property javatest.maxOutputSize to a higher
>      value. The current value is 100000
>      ...
>
At some point I think we need to think again about having maxOutputSize 
set to a very large value in the TEST.ROOT for least the test/jdk test. 
There are many parameterized tests that result in lot of output but it 
very important output for diagnosing failures, even the "STARTED" and 
"SUCCESSFUL" messages for JUnit tests as they give you the execution 
time for specific tests when trying to diagnose timeouts and slow downs. 
Right now, we have TEST.properties in some areas overriding the value of 
maxOutputSize because of this issue. So while it might mean a test run 
retains large .jtr that is truncated today, it seems a reasonable trade 
off when comparing to the frustrating of finding which test has failed.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20251003/6707a567/attachment-0001.htm>

From jaikiran.pai at oracle.com  Fri Oct  3 06:10:11 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Fri, 3 Oct 2025 11:40:11 +0530
Subject: How to pass javatest.maxOutputSize to make test?
In-Reply-To: <87dd3b16-df02-413d-b3ca-d7190a6d67cb@oracle.com>
References: <CAChcVu=Ob+3kEOmRXbi7UrnGkmOdtq-5CqPee+Z7cURdCfQ26w@mail.gmail.com>
 <87dd3b16-df02-413d-b3ca-d7190a6d67cb@oracle.com>
Message-ID: <a4945c11-8b12-4810-9877-a7d26672e50e@oracle.com>

On 03/10/25 11:25 am, Alan Bateman wrote:
>
>
> On 02/10/2025 18:09, Pavel Rappo wrote:
>> Hello,
>>
>> ...
>> If a test fails, sometimes I get this output:
>>
>>      ...
>>      Output overflow:
>>      JT Harness has limited the test output to the text
>>      at the beginning and the end, so that you can see how the
>>      test began, and how it completed.
>>
>>      If you need to see more of the output from the test,
>>      set the system property javatest.maxOutputSize to a higher
>>      value. The current value is 100000
>>      ...
>>
> At some point I think we need to think again about having 
> maxOutputSize set to a very large value in the TEST.ROOT for least the 
> test/jdk test. 

This has happened several times and it is frustrating when it happens 
for intermittently failing tests because we lose crucial details of the 
failure. I have now filed https://bugs.openjdk.org/browse/JDK-8369087 to 
increase this value in the JDK repo, after running some experiments.

-Jaikiran

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20251003/78bd2d65/attachment.htm>

From duke at openjdk.org  Fri Oct  3 06:35:58 2025
From: duke at openjdk.org (duke)
Date: Fri, 3 Oct 2025 06:35:58 GMT
Subject: Withdrawn: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once
In-Reply-To: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
Message-ID: <ZIMTwFndMXL5s95dzE_S7HrtWz3w8C12UeqcfPFdch0=.d3efea2a-f897-462a-a665-3d261ecd87ef@github.com>

On Fri, 27 Jun 2025 23:29:15 GMT, Daniel Hu <duke at openjdk.org> wrote:

> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26030

From dholmes at openjdk.org  Fri Oct  3 11:45:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Oct 2025 11:45:47 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v3]
In-Reply-To: <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>
Message-ID: <T5nLo_WZ5rUgoAYpGmiSslhVtC4PeshFwmB9PlAcB_4=.234f2680-3fde-436f-afd9-cacaf678bebf@github.com>

On Thu, 2 Oct 2025 15:06:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
>> 
>> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust logging in the build instead of just disabling it

Changes requested by dholmes (Reviewer).

make/autoconf/boot-jdk.m4 line 447:

> 445:   UTIL_ADD_JVM_ARG_IF_OK([-Duser.language=en -Duser.country=US],boot_jdk_jvmargs,[$JAVA])
> 446: 
> 447:   UTIL_ADD_JVM_ARG_IF_OK([-Xlog:all=warning:stderr],boot_jdk_jvmargs,[$JAVA])

This is not sufficient you have to disable the warnings on stdout, not just enable them on stderr.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27588#pullrequestreview-3298570936
PR Review Comment: https://git.openjdk.org/jdk/pull/27588#discussion_r2401612970

From erikj at openjdk.org  Fri Oct  3 13:03:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 3 Oct 2025 13:03:53 GMT
Subject: RFR: 8369080: Use uname -m for devkit cpu detection
In-Reply-To: <tu4CHsxoR5mVLkuA_T0WLoZGAWor4VivUs3fW8zJiAI=.4d5bccbd-f157-4d03-8e8f-b01ea6c88667@github.com>
References: <tu4CHsxoR5mVLkuA_T0WLoZGAWor4VivUs3fW8zJiAI=.4d5bccbd-f157-4d03-8e8f-b01ea6c88667@github.com>
Message-ID: <iw28BsVrGz3VwlzTVVNewcTNSvvrEO9pTuVRq36bdAw=.4e81106e-047e-4f15-b93f-721f60207eb0@github.com>

On Fri, 3 Oct 2025 03:16:32 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The devkit creation uses uname -p for detection the cpu architecture. uname -p is non-portable and no longer works on recent Linux/distributions (e.g. OL10). It should be changed to uname -m which is portable and works.
> 
> Testing: manual verification on ol{7,8,9,10}-{aarch64,x86_64}

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27617#pullrequestreview-3298862835

From mikael at openjdk.org  Fri Oct  3 17:43:56 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 3 Oct 2025 17:43:56 GMT
Subject: RFR: 8369080: Use uname -m for devkit cpu detection
In-Reply-To: <tu4CHsxoR5mVLkuA_T0WLoZGAWor4VivUs3fW8zJiAI=.4d5bccbd-f157-4d03-8e8f-b01ea6c88667@github.com>
References: <tu4CHsxoR5mVLkuA_T0WLoZGAWor4VivUs3fW8zJiAI=.4d5bccbd-f157-4d03-8e8f-b01ea6c88667@github.com>
Message-ID: <nxXRCPWISElxWpn8aHRjyMvmCMt3uv2BzOYx-qJX3-E=.9ff2f013-3fc2-4699-a958-d93bf0249f25@github.com>

On Fri, 3 Oct 2025 03:16:32 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The devkit creation uses uname -p for detection the cpu architecture. uname -p is non-portable and no longer works on recent Linux/distributions (e.g. OL10). It should be changed to uname -m which is portable and works.
> 
> Testing: manual verification on ol{7,8,9,10}-{aarch64,x86_64}

Thank you for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27617#issuecomment-3366620405

From mikael at openjdk.org  Fri Oct  3 17:43:57 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 3 Oct 2025 17:43:57 GMT
Subject: Integrated: 8369080: Use uname -m for devkit cpu detection
In-Reply-To: <tu4CHsxoR5mVLkuA_T0WLoZGAWor4VivUs3fW8zJiAI=.4d5bccbd-f157-4d03-8e8f-b01ea6c88667@github.com>
References: <tu4CHsxoR5mVLkuA_T0WLoZGAWor4VivUs3fW8zJiAI=.4d5bccbd-f157-4d03-8e8f-b01ea6c88667@github.com>
Message-ID: <wm0FwG5xT0WBcHp4Hd87qo95ZowNWN0jG4yAWFqb0b4=.327c2dea-23a1-4511-b996-7769369d9985@github.com>

On Fri, 3 Oct 2025 03:16:32 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The devkit creation uses uname -p for detection the cpu architecture. uname -p is non-portable and no longer works on recent Linux/distributions (e.g. OL10). It should be changed to uname -m which is portable and works.
> 
> Testing: manual verification on ol{7,8,9,10}-{aarch64,x86_64}

This pull request has now been integrated.

Changeset: 0935b76c
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0935b76c6bd1fbfa0a431eedb54c51f6fe4d194e
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8369080: Use uname -m for devkit cpu detection

Reviewed-by: iris, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/27617

From sherman at openjdk.org  Fri Oct  3 19:10:20 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 3 Oct 2025 19:10:20 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support
Message-ID: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>

### Summary

Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.

Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:

**String.equalsIgnoreCase(String)**

- Unicode-aware, locale-independent.
- Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
- Limited: does not support 1:M mapping defined in Unicode case folding.

**Character.toLowerCase(int) / Character.toUpperCase(int)**

- Locale-independent, single code point only.
- No support for 1:M mappings.

**String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**

- Based on Unicode SpecialCasing.txt, supports 1:M mappings.
- Intended primarily for presentation/display, not structural case-insensitive matching.
- Requires full string conversion before comparison, which is less efficient and not intended for structural matching.

**1:M mapping example, U+00DF (?)**

- String.toUpperCase(Locale.ROOT, "?") ? "SS"
- Case folding produces "ss", matching Unicode caseless comparison rules.


jshell> "\u00df".equalsIgnoreCase("ss")
$22 ==> false

jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
$24 ==> true


### Motivation & Direction

Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.

- Unicode-compliant **full** case folding.
- Simpler, stable and more efficient case-less matching without workarounds.
- Brings Java's string comparison handling in line with other programming languages/libraries.

This PR proposes to introduce the following comparison methods in `String` class

- boolean equalsFoldCase(String anotherString)
- int compareToFoldCase(String anotherString)
- Comparator<String> UNICODE_CASEFOLD_ORDER

These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.

*Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.

### The New API


   /**
     * Compares this {@code String} to another {@code String} for equality,
     * using <em>Unicode case folding</em>. Two strings are considered equal
     * by this method if their case-folded forms are identical.
     * <p>
     * Case folding is defined by the Unicode Standard in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")}
     * returns {@code true}, since the character {@code U+00DF} (sharp s) folds
     * to {@code "ss"}.
     * <p>
     * Case folding is locale-independent and language-neutral, unlike
     * locale-sensitive transformations such as {@link #toLowerCase()} or
     * {@link #toUpperCase()}. It is intended for caseless matching,
     * searching, and indexing.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #equalsIgnoreCase(String)}. It implements full case folding as
     * defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code equalsIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }</pre>
     *
     * @param  anotherString
     *         The {@code String} to compare this {@code String} against
     *
     * @return  {@code true} if the given object is not {@code null} and represents
     *          the same sequence of characters as this string under Unicode case
     *          folding; {@code false} otherwise.
     *
     * @see     #compareToFoldCase(String)
     * @see     #equalsIgnoreCase(String)
     * @since   26
     */
    public boolean equalsFoldCase(String anotherString)

    /**
     * Compares two strings lexicographically using <em>Unicode case folding</em>.
     * This method returns an integer whose sign is that of calling {@code compareTo}
     * on the Unicode case folded version of the strings. Unicode Case folding
     * eliminates differences in case according to the Unicode Standard, using the
     * mappings defined in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}.
     * <p>
     * Case folding is a locale-independent, language-neutral form of case mapping,
     * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)},
     * which applies a simpler locale-insensitive uppercase mapping. This method
     * follows the Unicode <em>full</em> case folding, providing stable and
     * consistent results across all environments.
     * <p>
     * Note that this method does <em>not</em> take locale into account, and may
     * produce results that differ from locale-sensitive ordering. Use
     * {@link java.text.Collator} for locale-sensitive comparison.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #compareToIgnoreCase(String)}. It implements the <em>full</em> case folding
     * as defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code compareToIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }</pre>
     *
     * @param   str   the {@code String} to be compared.
     * @return  a negative integer, zero, or a positive integer as the specified
     *          String is greater than, equal to, or less than this String,
     *          ignoring case considerations by case folding.
     * @see     #equalsFoldCase(String)
     * @see     #compareToIgnoreCase(String)
     * @see     java.text.Collator
     * @since   26
     */
    public int compareToFoldCase(String str) 

    /**
     * A Comparator that orders {@code String} objects as by
     * {@link #compareToFoldCase(String) compareToFoldCase()}.
     *
     * @see     #compareToFoldCase(String)
     * @since   26
     */
    public static final Comparator<String> UNICODE_CASEFOLD_ORDER;



### Usage Examples

Sharp s (U+00DF) case-folds to "ss"


    "stra?e".equalsIgnoreCase("strasse");             // false
    "stra?e".compareToIgnoreCase("strasse");          // != 0
    "stra?e".equalsFoldCase("strasse");               // true



### Performance

The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing  compareToIgnoreCase().


Benchmark                                         Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.asciiGreekLower         avgt   15  20.195 ? 0.300  ns/op
StringCompareToIgnoreCase.asciiGreekLowerCF       avgt   15  11.051 ? 0.254  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLower    avgt   15   6.035 ? 0.047  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLowerCF  avgt   15  14.786 ? 0.382  ns/op
StringCompareToIgnoreCase.asciiLower              avgt   15  17.688 ? 1.396  ns/op
StringCompareToIgnoreCase.asciiLowerCF            avgt   15  44.552 ? 0.155  ns/op
StringCompareToIgnoreCase.asciiUpperLower         avgt   15  13.069 ? 0.487  ns/op
StringCompareToIgnoreCase.asciiUpperLowerCF       avgt   15  58.684 ? 0.274  ns/op
StringCompareToIgnoreCase.greekLower              avgt   15  20.642 ? 0.082  ns/op
StringCompareToIgnoreCase.greekLowerCF            avgt   15   7.255 ? 0.271  ns/op
StringCompareToIgnoreCase.greekUpperLower         avgt   15   5.737 ? 0.013  ns/op
StringCompareToIgnoreCase.greekUpperLowerCF       avgt   15  11.100 ? 1.147  ns/op
StringCompareToIgnoreCase.lower                   avgt   15  20.192 ? 0.044  ns/op
StringCompareToIgnoreCase.lowerrCF                avgt   15  11.257 ? 0.259  ns/op
StringCompareToIgnoreCase.supLower                avgt   15  54.801 ? 0.415  ns/op
StringCompareToIgnoreCase.supLowerCF              avgt   15  15.207 ? 0.418  ns/op
StringCompareToIgnoreCase.supUpperLower           avgt   15  14.431 ? 0.188  ns/op
StringCompareToIgnoreCase.supUpperLowerCF         avgt   15  19.149 ? 0.985  ns/op
StringCompareToIgnoreCase.upperLower              avgt   15   5.650 ? 0.051  ns/op
StringCompareToIgnoreCase.upperLowerCF            avgt   15  14.338 ? 0.352  ns/op
StringCompareToIgnoreCase.utf16SubLower           avgt   15  14.774 ? 0.200  ns/op
StringCompareToIgnoreCase.utf16SubLowerCF         avgt   15   2.669 ? 0.041  ns/op
StringCompareToIgnoreCase.utf16SupUpperLower      avgt   15  16.250 ? 0.099  ns/op
StringCompareToIgnoreCase.utf16SupUpperLowerCF    avgt   15  11.524 ? 0.327  ns/op



### Refs

[Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790)
[Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping)
[Unicode Technical Standard #18:  Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches)
[Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt)
[Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt)

### Other Languages

**Python string.casefold()**

The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons.

**Perl?s fc()**

Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings.
Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case.
Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. 

**ICU4J UCharacter.foldCase (Java)** 

Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF).
Method Signature (String based): public static String foldCase(String str, int options)
Method Signature (CharSequence & Appendable based): public static <A extends Appendable> A foldCase(CharSequence src, A dest, int options, Edits edits)
Key Features:
Case Folding: Converts a string to its case-folded equivalent.
Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings.
Context Insensitive: The mapping of a character is not affected by surrounding characters.
Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text.
Result Length: The resulting string can be longer or shorter than the original.
Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes.

**u_strFoldCase (C/C++)**

A lower-level C API function for case folding a string.
Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior.
Availability: Found in the ustring.h and unistr.h headers in the ICU4C library.

-------------

Commit messages:
 - 8365675: Add String Unicode Case-Folding Support

Changes: https://git.openjdk.org/jdk/pull/26892/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365675
  Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892

PR: https://git.openjdk.org/jdk/pull/26892

From sherman at openjdk.org  Fri Oct  3 19:41:20 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 3 Oct 2025 19:41:20 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
References: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
Message-ID: <XmrPXxWubXK0V4sLHruFfklfLmOWQcfYo_65VZH7WZY=.c9abec92-cae1-4927-b74a-928b9ecd5807@github.com>

> ### Summary
> 
> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
> 
> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
> 
> **String.equalsIgnoreCase(String)**
> 
> - Unicode-aware, locale-independent.
> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
> - Limited: does not support 1:M mapping defined in Unicode case folding.
> 
> **Character.toLowerCase(int) / Character.toUpperCase(int)**
> 
> - Locale-independent, single code point only.
> - No support for 1:M mappings.
> 
> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
> 
> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
> - Intended primarily for presentation/display, not structural case-insensitive matching.
> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
> 
> **1:M mapping example, U+00DF (?)**
> 
> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
> - Case folding produces "ss", matching Unicode caseless comparison rules.
> 
> 
> jshell> "\u00df".equalsIgnoreCase("ss")
> $22 ==> false
> 
> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
> $24 ==> true
> 
> 
> ### Motivation & Direction
> 
> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
> 
> - Unicode-compliant **full** case folding.
> - Simpler, stable and more efficient case-less matching without workarounds.
> - Brings Java's string comparison handling in line with other programming languages/libraries.
> 
> This PR proposes to introduce the following comparison methods in `String` class
> 
> - boolean equalsFoldCase(String anotherString)
> - int compareToFoldCase(String anotherString)
> - Comparator<String> UNICODE_CASEFOLD_ORDER
> 
> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
> 
> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.
> 
> ### The New API
> 
> 
>    /**
>      * Compares thi...

Xueming Shen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8365675
 - 8365675: Add String Unicode Case-Folding Support
   
   to update api

-------------

Changes: https://git.openjdk.org/jdk/pull/26892/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=01
  Stats: 1282 lines in 12 files changed: 1119 ins; 137 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892

PR: https://git.openjdk.org/jdk/pull/26892

From rriggs at openjdk.org  Fri Oct  3 19:54:22 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 Oct 2025 19:54:22 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <XmrPXxWubXK0V4sLHruFfklfLmOWQcfYo_65VZH7WZY=.c9abec92-cae1-4927-b74a-928b9ecd5807@github.com>
References: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
 <XmrPXxWubXK0V4sLHruFfklfLmOWQcfYo_65VZH7WZY=.c9abec92-cae1-4927-b74a-928b9ecd5807@github.com>
Message-ID: <QsU_oaagatZATmQKQDWE7gOvX7P-BFrwf8y5VV5Ccmw=.6785e1a0-c6bd-49eb-a808-ce5155c3d82e@github.com>

On Fri, 3 Oct 2025 19:41:20 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8365675
>  - 8365675: Add String Unicode Case-Folding Support
>    
>    to update api

src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 1:

> 1: /*

We're going to need to find a more compact format for the data, individual 1 or 2 entry char arrays have a large overhead. Plus the map entries take a lot of space for the data and indexing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26892#discussion_r2403194785

From sherman at openjdk.org  Fri Oct  3 19:54:23 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 3 Oct 2025 19:54:23 GMT
Subject: Withdrawn: 8365675: Add String Unicode Case-Folding Support
In-Reply-To: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
References: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
Message-ID: <j2PytCsaYuRiL0kiYcq0yxgMfJHH0NjNUGVm-3vIm-k=.f1add041-3639-4f59-ae67-a7a1570bd40f@github.com>

On Fri, 22 Aug 2025 03:50:03 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> ### Summary
> 
> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
> 
> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
> 
> **String.equalsIgnoreCase(String)**
> 
> - Unicode-aware, locale-independent.
> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
> - Limited: does not support 1:M mapping defined in Unicode case folding.
> 
> **Character.toLowerCase(int) / Character.toUpperCase(int)**
> 
> - Locale-independent, single code point only.
> - No support for 1:M mappings.
> 
> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
> 
> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
> - Intended primarily for presentation/display, not structural case-insensitive matching.
> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
> 
> **1:M mapping example, U+00DF (?)**
> 
> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
> - Case folding produces "ss", matching Unicode caseless comparison rules.
> 
> 
> jshell> "\u00df".equalsIgnoreCase("ss")
> $22 ==> false
> 
> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
> $24 ==> true
> 
> 
> ### Motivation & Direction
> 
> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
> 
> - Unicode-compliant **full** case folding.
> - Simpler, stable and more efficient case-less matching without workarounds.
> - Brings Java's string comparison handling in line with other programming languages/libraries.
> 
> This PR proposes to introduce the following comparison methods in `String` class
> 
> - boolean equalsFoldCase(String anotherString)
> - int compareToFoldCase(String anotherString)
> - Comparator<String> UNICODE_CASEFOLD_ORDER
> 
> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
> 
> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.
> 
> ### The New API
> 
> 
>    /**
>      * Compares thi...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26892

From sherman at openjdk.org  Fri Oct  3 20:09:21 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 3 Oct 2025 20:09:21 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support
Message-ID: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>

### Summary

Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.

Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:

**String.equalsIgnoreCase(String)**

- Unicode-aware, locale-independent.
- Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
- Limited: does not support 1:M mapping defined in Unicode case folding.

**Character.toLowerCase(int) / Character.toUpperCase(int)**

- Locale-independent, single code point only.
- No support for 1:M mappings.

**String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**

- Based on Unicode SpecialCasing.txt, supports 1:M mappings.
- Intended primarily for presentation/display, not structural case-insensitive matching.
- Requires full string conversion before comparison, which is less efficient and not intended for structural matching.

**1:M mapping example, U+00DF (?)**

- String.toUpperCase(Locale.ROOT, "?") ? "SS"
- Case folding produces "ss", matching Unicode caseless comparison rules.


jshell> "\u00df".equalsIgnoreCase("ss")
$22 ==> false

jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
$24 ==> true


### Motivation & Direction

Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.

- Unicode-compliant **full** case folding.
- Simpler, stable and more efficient case-less matching without workarounds.
- Brings Java's string comparison handling in line with other programming languages/libraries.

This PR proposes to introduce the following comparison methods in `String` class

- boolean equalsFoldCase(String anotherString)
- int compareToFoldCase(String anotherString)
- Comparator<String> UNICODE_CASEFOLD_ORDER

These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.

*Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.

### The New API


   /**
     * Compares this {@code String} to another {@code String} for equality,
     * using <em>Unicode case folding</em>. Two strings are considered equal
     * by this method if their case-folded forms are identical.
     * <p>
     * Case folding is defined by the Unicode Standard in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")}
     * returns {@code true}, since the character {@code U+00DF} (sharp s) folds
     * to {@code "ss"}.
     * <p>
     * Case folding is locale-independent and language-neutral, unlike
     * locale-sensitive transformations such as {@link #toLowerCase()} or
     * {@link #toUpperCase()}. It is intended for caseless matching,
     * searching, and indexing.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #equalsIgnoreCase(String)}. It implements full case folding as
     * defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code equalsIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }</pre>
     *
     * @param  anotherString
     *         The {@code String} to compare this {@code String} against
     *
     * @return  {@code true} if the given object is not {@code null} and represents
     *          the same sequence of characters as this string under Unicode case
     *          folding; {@code false} otherwise.
     *
     * @see     #compareToFoldCase(String)
     * @see     #equalsIgnoreCase(String)
     * @since   26
     */
    public boolean equalsFoldCase(String anotherString)

    /**
     * Compares two strings lexicographically using <em>Unicode case folding</em>.
     * This method returns an integer whose sign is that of calling {@code compareTo}
     * on the Unicode case folded version of the strings. Unicode Case folding
     * eliminates differences in case according to the Unicode Standard, using the
     * mappings defined in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}.
     * <p>
     * Case folding is a locale-independent, language-neutral form of case mapping,
     * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)},
     * which applies a simpler locale-insensitive uppercase mapping. This method
     * follows the Unicode <em>full</em> case folding, providing stable and
     * consistent results across all environments.
     * <p>
     * Note that this method does <em>not</em> take locale into account, and may
     * produce results that differ from locale-sensitive ordering. Use
     * {@link java.text.Collator} for locale-sensitive comparison.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #compareToIgnoreCase(String)}. It implements the <em>full</em> case folding
     * as defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code compareToIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }</pre>
     *
     * @param   str   the {@code String} to be compared.
     * @return  a negative integer, zero, or a positive integer as the specified
     *          String is greater than, equal to, or less than this String,
     *          ignoring case considerations by case folding.
     * @see     #equalsFoldCase(String)
     * @see     #compareToIgnoreCase(String)
     * @see     java.text.Collator
     * @since   26
     */
    public int compareToFoldCase(String str) 

    /**
     * A Comparator that orders {@code String} objects as by
     * {@link #compareToFoldCase(String) compareToFoldCase()}.
     *
     * @see     #compareToFoldCase(String)
     * @since   26
     */
    public static final Comparator<String> UNICODE_CASEFOLD_ORDER;



### Usage Examples

Sharp s (U+00DF) case-folds to "ss"


    "stra?e".equalsIgnoreCase("strasse");             // false
    "stra?e".compareToIgnoreCase("strasse");          // != 0
    "stra?e".equalsFoldCase("strasse");               // true



### Performance

The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing  compareToIgnoreCase().


Benchmark                                         Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.asciiGreekLower         avgt   15  20.195 ? 0.300  ns/op
StringCompareToIgnoreCase.asciiGreekLowerCF       avgt   15  11.051 ? 0.254  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLower    avgt   15   6.035 ? 0.047  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLowerCF  avgt   15  14.786 ? 0.382  ns/op
StringCompareToIgnoreCase.asciiLower              avgt   15  17.688 ? 1.396  ns/op
StringCompareToIgnoreCase.asciiLowerCF            avgt   15  44.552 ? 0.155  ns/op
StringCompareToIgnoreCase.asciiUpperLower         avgt   15  13.069 ? 0.487  ns/op
StringCompareToIgnoreCase.asciiUpperLowerCF       avgt   15  58.684 ? 0.274  ns/op
StringCompareToIgnoreCase.greekLower              avgt   15  20.642 ? 0.082  ns/op
StringCompareToIgnoreCase.greekLowerCF            avgt   15   7.255 ? 0.271  ns/op
StringCompareToIgnoreCase.greekUpperLower         avgt   15   5.737 ? 0.013  ns/op
StringCompareToIgnoreCase.greekUpperLowerCF       avgt   15  11.100 ? 1.147  ns/op
StringCompareToIgnoreCase.lower                   avgt   15  20.192 ? 0.044  ns/op
StringCompareToIgnoreCase.lowerrCF                avgt   15  11.257 ? 0.259  ns/op
StringCompareToIgnoreCase.supLower                avgt   15  54.801 ? 0.415  ns/op
StringCompareToIgnoreCase.supLowerCF              avgt   15  15.207 ? 0.418  ns/op
StringCompareToIgnoreCase.supUpperLower           avgt   15  14.431 ? 0.188  ns/op
StringCompareToIgnoreCase.supUpperLowerCF         avgt   15  19.149 ? 0.985  ns/op
StringCompareToIgnoreCase.upperLower              avgt   15   5.650 ? 0.051  ns/op
StringCompareToIgnoreCase.upperLowerCF            avgt   15  14.338 ? 0.352  ns/op
StringCompareToIgnoreCase.utf16SubLower           avgt   15  14.774 ? 0.200  ns/op
StringCompareToIgnoreCase.utf16SubLowerCF         avgt   15   2.669 ? 0.041  ns/op
StringCompareToIgnoreCase.utf16SupUpperLower      avgt   15  16.250 ? 0.099  ns/op
StringCompareToIgnoreCase.utf16SupUpperLowerCF    avgt   15  11.524 ? 0.327  ns/op



### Refs

[Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790)
[Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping)
[Unicode Technical Standard #18:  Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches)
[Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt)
[Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt)

### Other Languages

**Python string.casefold()**

The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons.

**Perl?s fc()**

Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings.
Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case.
Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. 

**ICU4J UCharacter.foldCase (Java)** 

Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF).
Method Signature (String based): public static String foldCase(String str, int options)
Method Signature (CharSequence & Appendable based): public static <A extends Appendable> A foldCase(CharSequence src, A dest, int options, Edits edits)
Key Features:
Case Folding: Converts a string to its case-folded equivalent.
Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings.
Context Insensitive: The mapping of a character is not affected by surrounding characters.
Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text.
Result Length: The resulting string can be longer or shorter than the original.
Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes.

**u_strFoldCase (C/C++)**

A lower-level C API function for case folding a string.
Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior.
Availability: Found in the ustring.h and unistr.h headers in the ICU4C library.

-------------

Commit messages:
 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8365675
 - 8365675: Add String Unicode Case-Folding Support

Changes: https://git.openjdk.org/jdk/pull/27628/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365675
  Stats: 1282 lines in 12 files changed: 1119 ins; 137 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/27628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628

PR: https://git.openjdk.org/jdk/pull/27628

From mbaesken at openjdk.org  Sat Oct  4 11:49:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sat, 4 Oct 2025 11:49:46 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v2]
In-Reply-To: <igCVKpgOrXXRr1I0O2q-GkOQG1nZP3EO_BsCFyv2frQ=.43780407-c100-41b6-916f-c5807a82e337@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
 <UErgDV7pYgds0myqI_Bu8jgsMCKVXKz_9YXmqLqBypU=.8c7cb533-8cd7-4118-944b-846bdecf6a3c@github.com>
 <NUN-amPUAY0CK24XPqpIgw4a7TW4Oix9sn32eTORqz8=.7a33369b-387c-46e1-8dc1-044d1e1ae550@github.com>
 <NZqNUqdW-gtDe-yhgVHpfmdLynXeAVdHL4rn3XHgUtI=.9f201b36-4143-49a1-b55a-e6c33db67607@github.com>
 <ltNxAn3sLBEkAAREYtzHXjwmW8rZTxcR_EIdpQa7XbI=.cf2a01ba-f63c-401f-be02-b3a08772ddf9@github.com>
 <igCVKpgOrXXRr1I0O2q-GkOQG1nZP3EO_BsCFyv2frQ=.43780407-c100-41b6-916f-c5807a82e337@github.com>
Message-ID: <VtW9HI70GBcLWrYrxVN1ouQ1-hsjE5-b5ELTTvWr9Cg=.b29fb627-44f9-472c-8cab-2fac7c66ef0b@github.com>

On Thu, 2 Oct 2025 17:12:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Yes, I think we can, but I would like to see it verified to not cause a regression in build performance before we do.

Sure, we should not do this here in this PR. Probably better handled in another issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3368155868

From mbaesken at openjdk.org  Sat Oct  4 11:49:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sat, 4 Oct 2025 11:49:49 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v3]
In-Reply-To: <T5nLo_WZ5rUgoAYpGmiSslhVtC4PeshFwmB9PlAcB_4=.234f2680-3fde-436f-afd9-cacaf678bebf@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>
 <T5nLo_WZ5rUgoAYpGmiSslhVtC4PeshFwmB9PlAcB_4=.234f2680-3fde-436f-afd9-cacaf678bebf@github.com>
Message-ID: <id4Qh_hiEZBiumWgIAFTzX7IgTl-5tALquBBMCxfMbo=.5f8c5bf5-6c30-452d-97c7-d98cba98c0d6@github.com>

On Fri, 3 Oct 2025 11:42:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust logging in the build instead of just disabling it
>
> make/autoconf/boot-jdk.m4 line 447:
> 
>> 445:   UTIL_ADD_JVM_ARG_IF_OK([-Duser.language=en -Duser.country=US],boot_jdk_jvmargs,[$JAVA])
>> 446: 
>> 447:   UTIL_ADD_JVM_ARG_IF_OK([-Xlog:all=warning:stderr],boot_jdk_jvmargs,[$JAVA])
> 
> This is not sufficient you have to disable the warnings on stdout, not just enable them on stderr.

So should I set something like `-Xlog:disable` _additionally_ to the  `-Xlog:all=warning:stderr ` ?
The whole UL sometimes is strange and a bit confusing to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27588#discussion_r2403930707

From mikael at openjdk.org  Sun Oct  5 16:59:55 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Sun, 5 Oct 2025 16:59:55 GMT
Subject: RFR: 8355752: Bump minimum boot jdk to JDK 25
Message-ID: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>

With the JDK 25 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25.

Testing: tier1-5, GHA

-------------

Commit messages:
 - 8355752: Bump minimum boot jdk to JDK 25

Changes: https://git.openjdk.org/jdk/pull/27638/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27638&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355752
  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27638/head:pull/27638

PR: https://git.openjdk.org/jdk/pull/27638

From darcy at openjdk.org  Sun Oct  5 19:30:46 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 5 Oct 2025 19:30:46 GMT
Subject: RFR: 8355752: Bump minimum boot jdk to JDK 25
In-Reply-To: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
References: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
Message-ID: <JL2YX2DIt6y1K9EYs2UiLuZo1Xtd4UG3qOmJbdFVfHQ=.73fec1ff-90a5-4a9d-9cb7-1ac68a147327@github.com>

On Sun, 5 Oct 2025 16:54:38 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> With the JDK 25 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25.
> 
> Testing: tier1-5, GHA

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27638#pullrequestreview-3302512208

From shade at openjdk.org  Mon Oct  6 09:04:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 09:04:52 GMT
Subject: RFR: 8355752: Bump minimum boot jdk to JDK 25
In-Reply-To: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
References: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
Message-ID: <aH7aIOlOSjZddMUyMqkaICndYAopKQJV8npViCiRiXA=.da82bfc1-8e78-45a2-a5cd-8fcc282d1b04@github.com>

On Sun, 5 Oct 2025 16:54:38 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> With the JDK 25 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25.
> 
> Testing: tier1-5, GHA

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27638#pullrequestreview-3303478917

From ihse at openjdk.org  Mon Oct  6 12:33:50 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 6 Oct 2025 12:33:50 GMT
Subject: RFR: 8355752: Bump minimum boot jdk to JDK 25
In-Reply-To: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
References: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
Message-ID: <g7ov7r_M5TwwwcE-8FLoVAPk6co7PsJGUI4Keh2k_2Q=.ae36659d-bcd7-4002-8de2-6d2e696a53a2@github.com>

On Sun, 5 Oct 2025 16:54:38 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> With the JDK 25 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25.
> 
> Testing: tier1-5, GHA

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27638#pullrequestreview-3304296821

From ihse at openjdk.org  Mon Oct  6 12:38:41 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 6 Oct 2025 12:38:41 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <RTcQrLKh4bKDYOI636jRuzIjoba8nceFHvierdgfGAc=.1306e78a-6b44-4653-a2fb-d46861576e3c@github.com>

On Fri, 3 Oct 2025 19:56:22 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> ### Summary
> 
> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
> 
> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
> 
> **String.equalsIgnoreCase(String)**
> 
> - Unicode-aware, locale-independent.
> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
> - Limited: does not support 1:M mapping defined in Unicode case folding.
> 
> **Character.toLowerCase(int) / Character.toUpperCase(int)**
> 
> - Locale-independent, single code point only.
> - No support for 1:M mappings.
> 
> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
> 
> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
> - Intended primarily for presentation/display, not structural case-insensitive matching.
> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
> 
> **1:M mapping example, U+00DF (?)**
> 
> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
> - Case folding produces "ss", matching Unicode caseless comparison rules.
> 
> 
> jshell> "\u00df".equalsIgnoreCase("ss")
> $22 ==> false
> 
> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
> $24 ==> true
> 
> 
> ### Motivation & Direction
> 
> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
> 
> - Unicode-compliant **full** case folding.
> - Simpler, stable and more efficient case-less matching without workarounds.
> - Brings Java's string comparison handling in line with other programming languages/libraries.
> 
> This PR proposes to introduce the following comparison methods in `String` class
> 
> - boolean equalsFoldCase(String anotherString)
> - int compareToFoldCase(String anotherString)
> - Comparator<String> UNICODE_CASEFOLD_ORDER
> 
> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
> 
> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.
> 
> ### The New API
> 
> 
>    /**
>      * Compares thi...

Build changes look fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3304307032

From ihse at openjdk.org  Mon Oct  6 12:39:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 6 Oct 2025 12:39:46 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v3]
In-Reply-To: <T5nLo_WZ5rUgoAYpGmiSslhVtC4PeshFwmB9PlAcB_4=.234f2680-3fde-436f-afd9-cacaf678bebf@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>
 <T5nLo_WZ5rUgoAYpGmiSslhVtC4PeshFwmB9PlAcB_4=.234f2680-3fde-436f-afd9-cacaf678bebf@github.com>
Message-ID: <eYls_yfl1SL8dRyXdbtqA9sadw2CCMZaijS534ZODu8=.22cc3336-6179-41f5-8ec0-5f84f0d03fae@github.com>

On Fri, 3 Oct 2025 11:42:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust logging in the build instead of just disabling it
>
> make/autoconf/boot-jdk.m4 line 447:
> 
>> 445:   UTIL_ADD_JVM_ARG_IF_OK([-Duser.language=en -Duser.country=US],boot_jdk_jvmargs,[$JAVA])
>> 446: 
>> 447:   UTIL_ADD_JVM_ARG_IF_OK([-Xlog:all=warning:stderr],boot_jdk_jvmargs,[$JAVA])
> 
> This is not sufficient you have to disable the warnings on stdout, not just enable them on stderr.

@dholmes-ora So what is a proper command line to enable warnings on stderr but disable them on stdout? That is what we're after here, isn't it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27588#discussion_r2406038950

From iris at openjdk.org  Mon Oct  6 14:55:47 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 6 Oct 2025 14:55:47 GMT
Subject: RFR: 8355752: Bump minimum boot jdk to JDK 25
In-Reply-To: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
References: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
Message-ID: <fS2kY3WILbpU2qksc2Px90hhf28GexZ1Lg4ny7e6vrw=.e0c2bfc9-89bf-415b-9719-f780fc9092a6@github.com>

On Sun, 5 Oct 2025 16:54:38 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> With the JDK 25 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25.
> 
> Testing: tier1-5, GHA

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27638#pullrequestreview-3305226601

From shade at openjdk.org  Mon Oct  6 17:41:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 17:41:09 GMT
Subject: RFR: 8369226: GHA: Switch to MacOS 15
Message-ID: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>

Current GHA workflows for MacOS are running with:
 - x86_64: macos-13, builds only
 - aarch64: macos-14, builds+tests

GitHub is deprecating MacOS 13 runner on December 4th, 2025, the brownouts are starting in a month: https://github.com/actions/runner-images/issues/13046. Additionally, GHA phases out MacOS x86_64, and MacOS 15 would be the last runner for x86_64. We have already disabled testing jobs for MacOS x86_64. GitHub recommends migrating to MacOS 15 at this time.

We can switch to MacOS 15 runner for both x86 and AArch64 to keep pipelines green in the coming months.

Additional testing:
 - [ ] GHA

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/27655/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27655&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369226
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27655/head:pull/27655

PR: https://git.openjdk.org/jdk/pull/27655

From erikj at openjdk.org  Mon Oct  6 18:39:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 6 Oct 2025 18:39:51 GMT
Subject: RFR: 8369226: GHA: Switch to MacOS 15
In-Reply-To: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
References: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
Message-ID: <-SCaXatTHdta7Sz-P6JIGc-eG4i33R5-_DTK_bRaSGQ=.0224894a-d7cc-4c80-89ce-aa7f19777bf2@github.com>

On Mon, 6 Oct 2025 17:34:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current GHA workflows for MacOS are running with:
>  - x86_64: macos-13, builds only
>  - aarch64: macos-14, builds+tests
> 
> GitHub is deprecating MacOS 13 runner on December 4th, 2025, the brownouts are starting in a month: https://github.com/actions/runner-images/issues/13046. Additionally, GHA phases out MacOS x86_64, and MacOS 15 would be the last runner for x86_64. We have already disabled testing jobs for MacOS x86_64. GitHub recommends migrating to MacOS 15 at this time.
> 
> We can switch to MacOS 15 runner for both x86 and AArch64 to keep pipelines green in the coming months.
> 
> Additional testing:
>  - [ ] GHA

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27655#pullrequestreview-3306547175

From mikael at openjdk.org  Mon Oct  6 21:52:02 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 6 Oct 2025 21:52:02 GMT
Subject: RFR: 8369242: Rename URL variables in devkit/Tools.gmk
Message-ID: <ksfDUAs4dVONJhM-FYLCJ4y6m66i4kG9MMaf-nxoCUs=.c1a0374e-4177-448b-9352-1524f6ad93a4@github.com>

Background (from JBS):

To keep us on our toes the source bundle URL variables in Tools.gmk are simply named after the corresponding dependency. For example (from Tools.gmk):


GCC := http://ftp.gnu.org/pub/gnu/gcc/$(gcc_ver)/$(gcc_ver).tar.xz


There's also a lower case variable set up for the "done" marker file for each dependency (from Tools.gmk):


# Define marker files for each source package to be compiled
$(foreach dep,$(dependencies),$(eval $(dep) = $(TARGETDIR)/$($(dep)_ver).done))


Will do something equivalent to:


gcc = target/dir/gcc-14.2.0.done


Let's rename the former variable to make it clearer that is, in fact, a URL.


Description:

The change renames the variables in question to include a `_URL` suffix and updates the uses accordingly.

Testing:

* Built devkit on linux-x64
* Verified that the JDK builds with the new devkit

-------------

Commit messages:
 - 8369242: Rename URL variables in devkit/Tools.gmk

Changes: https://git.openjdk.org/jdk/pull/27661/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369242
  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27661.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27661/head:pull/27661

PR: https://git.openjdk.org/jdk/pull/27661

From erikj at openjdk.org  Mon Oct  6 22:20:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 6 Oct 2025 22:20:45 GMT
Subject: RFR: 8369242: Rename URL variables in devkit/Tools.gmk
In-Reply-To: <ksfDUAs4dVONJhM-FYLCJ4y6m66i4kG9MMaf-nxoCUs=.c1a0374e-4177-448b-9352-1524f6ad93a4@github.com>
References: <ksfDUAs4dVONJhM-FYLCJ4y6m66i4kG9MMaf-nxoCUs=.c1a0374e-4177-448b-9352-1524f6ad93a4@github.com>
Message-ID: <eeUMGy-_HwHFwoO_QX2lJwYIiO7uCth3z1-7i1yZmv8=.a7d4801e-e465-4fff-93fd-30999fe4b003@github.com>

On Mon, 6 Oct 2025 21:44:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> To keep us on our toes the source bundle URL variables in Tools.gmk are simply named after the corresponding dependency. For example (from Tools.gmk):
> 
> 
> GCC := http://ftp.gnu.org/pub/gnu/gcc/$(gcc_ver)/$(gcc_ver).tar.xz
> 
> 
> There's also a lower case variable set up for the "done" marker file for each dependency (from Tools.gmk):
> 
> 
> # Define marker files for each source package to be compiled
> $(foreach dep,$(dependencies),$(eval $(dep) = $(TARGETDIR)/$($(dep)_ver).done))
> 
> 
> Will do something equivalent to:
> 
> 
> gcc = target/dir/gcc-14.2.0.done
> 
> 
> Let's rename the former variable to make it clearer that is, in fact, a URL.
> 
> 
> Description:
> 
> The change renames the variables in question to include a `_URL` suffix and updates the uses accordingly.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27661#pullrequestreview-3307687056

From mikael at openjdk.org  Tue Oct  7 00:55:59 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 7 Oct 2025 00:55:59 GMT
Subject: RFR: 8369242: Rename URL variables in devkit/Tools.gmk
In-Reply-To: <ksfDUAs4dVONJhM-FYLCJ4y6m66i4kG9MMaf-nxoCUs=.c1a0374e-4177-448b-9352-1524f6ad93a4@github.com>
References: <ksfDUAs4dVONJhM-FYLCJ4y6m66i4kG9MMaf-nxoCUs=.c1a0374e-4177-448b-9352-1524f6ad93a4@github.com>
Message-ID: <nawwKkxvX6JIAIVDmV081LprguUDIusjkG5mSPjC9zE=.fc492a41-f129-49a5-8a04-0e694efd182c@github.com>

On Mon, 6 Oct 2025 21:44:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> To keep us on our toes the source bundle URL variables in Tools.gmk are simply named after the corresponding dependency. For example (from Tools.gmk):
> 
> 
> GCC := http://ftp.gnu.org/pub/gnu/gcc/$(gcc_ver)/$(gcc_ver).tar.xz
> 
> 
> There's also a lower case variable set up for the "done" marker file for each dependency (from Tools.gmk):
> 
> 
> # Define marker files for each source package to be compiled
> $(foreach dep,$(dependencies),$(eval $(dep) = $(TARGETDIR)/$($(dep)_ver).done))
> 
> 
> Will do something equivalent to:
> 
> 
> gcc = target/dir/gcc-14.2.0.done
> 
> 
> Let's rename the former variable to make it clearer that is, in fact, a URL.
> 
> 
> Description:
> 
> The change renames the variables in question to include a `_URL` suffix and updates the uses accordingly.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

Thank you for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27661#issuecomment-3374760427

From mikael at openjdk.org  Tue Oct  7 00:56:00 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 7 Oct 2025 00:56:00 GMT
Subject: Integrated: 8369242: Rename URL variables in devkit/Tools.gmk
In-Reply-To: <ksfDUAs4dVONJhM-FYLCJ4y6m66i4kG9MMaf-nxoCUs=.c1a0374e-4177-448b-9352-1524f6ad93a4@github.com>
References: <ksfDUAs4dVONJhM-FYLCJ4y6m66i4kG9MMaf-nxoCUs=.c1a0374e-4177-448b-9352-1524f6ad93a4@github.com>
Message-ID: <tz9syRUbff1SBJYsmQErQ5rmRwko17iR8_sVDOcsrnE=.405a2389-6341-4c44-a924-0643d6578b93@github.com>

On Mon, 6 Oct 2025 21:44:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> To keep us on our toes the source bundle URL variables in Tools.gmk are simply named after the corresponding dependency. For example (from Tools.gmk):
> 
> 
> GCC := http://ftp.gnu.org/pub/gnu/gcc/$(gcc_ver)/$(gcc_ver).tar.xz
> 
> 
> There's also a lower case variable set up for the "done" marker file for each dependency (from Tools.gmk):
> 
> 
> # Define marker files for each source package to be compiled
> $(foreach dep,$(dependencies),$(eval $(dep) = $(TARGETDIR)/$($(dep)_ver).done))
> 
> 
> Will do something equivalent to:
> 
> 
> gcc = target/dir/gcc-14.2.0.done
> 
> 
> Let's rename the former variable to make it clearer that is, in fact, a URL.
> 
> 
> Description:
> 
> The change renames the variables in question to include a `_URL` suffix and updates the uses accordingly.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

This pull request has now been integrated.

Changeset: eb34a117
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb34a117934951af075a425ce2cf8d3b1ced9700
Stats:     10 lines in 1 file changed: 0 ins; 0 del; 10 mod

8369242: Rename URL variables in devkit/Tools.gmk

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/27661

From dholmes at openjdk.org  Tue Oct  7 02:35:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 02:35:47 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v3]
In-Reply-To: <id4Qh_hiEZBiumWgIAFTzX7IgTl-5tALquBBMCxfMbo=.5f8c5bf5-6c30-452d-97c7-d98cba98c0d6@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>
 <T5nLo_WZ5rUgoAYpGmiSslhVtC4PeshFwmB9PlAcB_4=.234f2680-3fde-436f-afd9-cacaf678bebf@github.com>
 <id4Qh_hiEZBiumWgIAFTzX7IgTl-5tALquBBMCxfMbo=.5f8c5bf5-6c30-452d-97c7-d98cba98c0d6@github.com>
Message-ID: <Gc_JAqAwOLsD36h1TxQ_JQthsqHspoKybLj2XWaiudI=.32bb48bc-f925-474c-952c-f622ae4841e7@github.com>

On Sat, 4 Oct 2025 11:46:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> make/autoconf/boot-jdk.m4 line 447:
>> 
>>> 445:   UTIL_ADD_JVM_ARG_IF_OK([-Duser.language=en -Duser.country=US],boot_jdk_jvmargs,[$JAVA])
>>> 446: 
>>> 447:   UTIL_ADD_JVM_ARG_IF_OK([-Xlog:all=warning:stderr],boot_jdk_jvmargs,[$JAVA])
>> 
>> This is not sufficient you have to disable the warnings on stdout, not just enable them on stderr.
>
> So should I set something like `-Xlog:disable` _additionally_ to the  `-Xlog:all=warning:stderr ` ?
> The whole UL sometimes is strange and a bit confusing to me.

As @MBaesken wrote in JBS: `-Xlog:all=off ` should disable logging on stdout. However, I just experimented with this and seems that enabling warnings on stderr is disabling them on stdout - at least I only see the warning reported once (even though the log configuration says they are enabled on both ??) .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27588#discussion_r2409168309

From mikael at openjdk.org  Tue Oct  7 03:41:18 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 7 Oct 2025 03:41:18 GMT
Subject: RFR: 8369246: Use https in make/devkit scripts
Message-ID: <v3v-acKN33nfP89hVitLJBn8q3KxRMzexm-n821zU-E=.52f3c5e6-8ec2-41b7-b47e-47e951fb9f6b@github.com>

Let's switch to https for URLs in the make/devkit files, where possible.

That's most places, apart from - it turns out from empirical testing - the `fedora.riscv.rocks` (RISC-V) URL in Tools.gmk.

Testing:

* Built devkit on linux-x64
* Verified that the JDK builds with the new devkit

-------------

Commit messages:
 - 8369246: Use https in make/devkit scripts

Changes: https://git.openjdk.org/jdk/pull/27663/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27663&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369246
  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27663/head:pull/27663

PR: https://git.openjdk.org/jdk/pull/27663

From ayang at openjdk.org  Tue Oct  7 08:31:51 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 08:31:51 GMT
Subject: RFR: 8369246: Use https in make/devkit scripts
In-Reply-To: <v3v-acKN33nfP89hVitLJBn8q3KxRMzexm-n821zU-E=.52f3c5e6-8ec2-41b7-b47e-47e951fb9f6b@github.com>
References: <v3v-acKN33nfP89hVitLJBn8q3KxRMzexm-n821zU-E=.52f3c5e6-8ec2-41b7-b47e-47e951fb9f6b@github.com>
Message-ID: <LDZo5jnHZuINYyIm446ICEXHowgIuJXBYpWb-KLJWZU=.0b503e8c-9ac3-4f79-8e26-1740a1acb702@github.com>

On Tue, 7 Oct 2025 01:52:44 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Let's switch to https for URLs in the make/devkit files, where possible.
> 
> That's most places, apart from - it turns out from empirical testing - the `fedora.riscv.rocks` (RISC-V) URL in Tools.gmk.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27663#pullrequestreview-3309009425

From ayang at openjdk.org  Tue Oct  7 08:34:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 08:34:55 GMT
Subject: RFR: 8369226: GHA: Switch to MacOS 15
In-Reply-To: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
References: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
Message-ID: <TNg0j83xobfZDjFX2ljAJNZF5cHL3Hfckk4VcKZpnoQ=.097e61d6-834e-4fe8-a20d-863490a1623a@github.com>

On Mon, 6 Oct 2025 17:34:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current GHA workflows for MacOS are running with:
>  - x86_64: macos-13, builds only
>  - aarch64: macos-14, builds+tests
> 
> GitHub is deprecating MacOS 13 runner on December 4th, 2025, the brownouts are starting in a month: https://github.com/actions/runner-images/issues/13046. Additionally, GHA phases out MacOS x86_64, and MacOS 15 would be the last runner for x86_64. We have already disabled testing jobs for MacOS x86_64. GitHub recommends migrating to MacOS 15 at this time.
> 
> We can switch to MacOS 15 runner for both x86 and AArch64 to keep pipelines green in the coming months.
> 
> Additional testing:
>  - [x] GHA

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27655#pullrequestreview-3309019625

From mbaesken at openjdk.org  Tue Oct  7 09:17:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 7 Oct 2025 09:17:20 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v4]
In-Reply-To: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
Message-ID: <lC_r51wnvcwek4LoQq7aImCL14vK9f0cUC8Rp_7bMQk=.f81a8f19-4436-43f5-8e7a-c833f4180ce2@github.com>

> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
> 
> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust warning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27588/files
  - new: https://git.openjdk.org/jdk/pull/27588/files/498d70f3..6d1cbeea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27588&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27588&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27588/head:pull/27588

PR: https://git.openjdk.org/jdk/pull/27588

From mbaesken at openjdk.org  Tue Oct  7 09:20:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 7 Oct 2025 09:20:14 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v3]
In-Reply-To: <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <U-klzWedO56JXh4PLIhhpm5iJjg8_3t2X1mqGo55AlU=.7041291f-c340-4b67-b632-06bc007c1e98@github.com>
Message-ID: <A4bvjYdMC0dwq1CeqAIWIPO0qUVREnESh7ipSRmnHVc=.29deb9a6-2297-4802-bf3e-5b6063ca2c54@github.com>

On Thu, 2 Oct 2025 15:06:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
>> 
>> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust logging in the build instead of just disabling it

I adjusted the UL settings again, and now I see the 'bad'  output


[0.010s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
[0.010s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time
[0.010s][error][cds] Disabling optimized module handling


in the `build.log` as expected and not any more in the `blocked.certs`  file , where we don't want to see it .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3375942715

From jpai at openjdk.org  Tue Oct  7 09:23:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 7 Oct 2025 09:23:01 GMT
Subject: RFR: 8367157: Remove jrunscript tool [v2]
In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
Message-ID: <scwn2-8hzk7SIOg2-jVQFyAqF9kdIgfFmLsXwhjAPnw=.ebafb503-934d-4b9d-87d8-ac1b9c59eb51@github.com>

> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157.
> 
> `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests.
> 
> tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note.

Jaikiran Pai 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 five additional commits since the last revision:

 - merge latest from master branch
 - remove tests for jrunscript
 - remove jrunscript implementation
 - remove references from tests
 - remove man page for jrunscript

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27163/files
  - new: https://git.openjdk.org/jdk/pull/27163/files/5458698f..8279d9b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27163&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27163&range=00-01

  Stats: 184646 lines in 2418 files changed: 144820 ins; 24642 del; 15184 mod
  Patch: https://git.openjdk.org/jdk/pull/27163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27163/head:pull/27163

PR: https://git.openjdk.org/jdk/pull/27163

From alanb at openjdk.org  Tue Oct  7 09:53:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Oct 2025 09:53:52 GMT
Subject: RFR: 8367157: Remove jrunscript tool [v2]
In-Reply-To: <scwn2-8hzk7SIOg2-jVQFyAqF9kdIgfFmLsXwhjAPnw=.ebafb503-934d-4b9d-87d8-ac1b9c59eb51@github.com>
References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
 <scwn2-8hzk7SIOg2-jVQFyAqF9kdIgfFmLsXwhjAPnw=.ebafb503-934d-4b9d-87d8-ac1b9c59eb51@github.com>
Message-ID: <fy7QWTDk4nZdovATiPnJdIkUkvrbKVqcBHZL2PLvNsU=.b1cafb5d-6ef8-4636-a568-a8470603f148@github.com>

On Tue, 7 Oct 2025 09:23:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157.
>> 
>> `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests.
>> 
>> tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note.
>
> Jaikiran Pai 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 five additional commits since the last revision:
> 
>  - merge latest from master branch
>  - remove tests for jrunscript
>  - remove jrunscript implementation
>  - remove references from tests
>  - remove man page for jrunscript

Looks okay, and easy to adjust course in the event that something important comes out of the wood work that depends on this tool.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27163#pullrequestreview-3309324886

From dholmes at openjdk.org  Tue Oct  7 11:02:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 11:02:49 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v4]
In-Reply-To: <lC_r51wnvcwek4LoQq7aImCL14vK9f0cUC8Rp_7bMQk=.f81a8f19-4436-43f5-8e7a-c833f4180ce2@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <lC_r51wnvcwek4LoQq7aImCL14vK9f0cUC8Rp_7bMQk=.f81a8f19-4436-43f5-8e7a-c833f4180ce2@github.com>
Message-ID: <XEAC-nDnG-UkpeM-jLIjQ0GXNuUD55iCHGyg1GFPXcg=.34ee1d7c-023b-40dc-9e1b-1f6c473ebd68@github.com>

On Tue, 7 Oct 2025 09:17:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
>> 
>> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust warning

make/autoconf/boot-jdk.m4 line 447:

> 445:   UTIL_ADD_JVM_ARG_IF_OK([-Duser.language=en -Duser.country=US],boot_jdk_jvmargs,[$JAVA])
> 446: 
> 447:   UTIL_ADD_JVM_ARG_IF_OK([-Xlog:all=off],boot_jdk_jvmargs,[$JAVA])

Suggestion:

  UTIL_ADD_JVM_ARG_IF_OK([-Xlog:all=off:stdout],boot_jdk_jvmargs,[$JAVA])

Just to be clear, rather than relying on the fact stdout is the default target device.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27588#discussion_r2410240350

From mbaesken at openjdk.org  Tue Oct  7 12:39:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 7 Oct 2025 12:39:15 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v5]
In-Reply-To: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
Message-ID: <2EwmY0XOQ0ZtBw6SXYrDR070TaYvl01aQ9RgMs1zLJA=.9734eb51-a8c9-444c-9113-070579639c6c@github.com>

> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
> 
> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  David suggested a change to the UL options for more clarity

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27588/files
  - new: https://git.openjdk.org/jdk/pull/27588/files/6d1cbeea..f7195129

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27588&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27588&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27588/head:pull/27588

PR: https://git.openjdk.org/jdk/pull/27588

From sgehwolf at openjdk.org  Tue Oct  7 13:16:31 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 7 Oct 2025 13:16:31 GMT
Subject: RFR: 8369226: GHA: Switch to MacOS 15
In-Reply-To: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
References: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
Message-ID: <gFYrzoZI5T77JHcaCCMyhuW2OTJWMm3ECSgnYLcmVkQ=.f764fd07-7b73-4c33-8fb7-927c67eb0ffd@github.com>

On Mon, 6 Oct 2025 17:34:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current GHA workflows for MacOS are running with:
>  - x86_64: macos-13, builds only
>  - aarch64: macos-14, builds+tests
> 
> GitHub is deprecating MacOS 13 runner on December 4th, 2025, the brownouts are starting in a month: https://github.com/actions/runner-images/issues/13046. Additionally, GHA phases out MacOS x86_64, and MacOS 15 would be the last runner for x86_64. We have already disabled testing jobs for MacOS x86_64. GitHub recommends migrating to MacOS 15 at this time.
> 
> We can switch to MacOS 15 runner for both x86 and AArch64 to keep pipelines green in the coming months.
> 
> Additional testing:
>  - [x] GHA

Marked as reviewed by sgehwolf (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27655#pullrequestreview-3310066630

From mbaesken at openjdk.org  Tue Oct  7 15:14:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 7 Oct 2025 15:14:18 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v2]
In-Reply-To: <igCVKpgOrXXRr1I0O2q-GkOQG1nZP3EO_BsCFyv2frQ=.43780407-c100-41b6-916f-c5807a82e337@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <MrDocxxwZ42l64KvnR76wGlhgXoEykzZsM9LISI5iHM=.f0ead7fe-f01e-4478-8af7-c4eceff9777c@github.com>
 <UErgDV7pYgds0myqI_Bu8jgsMCKVXKz_9YXmqLqBypU=.8c7cb533-8cd7-4118-944b-846bdecf6a3c@github.com>
 <NUN-amPUAY0CK24XPqpIgw4a7TW4Oix9sn32eTORqz8=.7a33369b-387c-46e1-8dc1-044d1e1ae550@github.com>
 <NZqNUqdW-gtDe-yhgVHpfmdLynXeAVdHL4rn3XHgUtI=.9f201b36-4143-49a1-b55a-e6c33db67607@github.com>
 <ltNxAn3sLBEkAAREYtzHXjwmW8rZTxcR_EIdpQa7XbI=.cf2a01ba-f63c-401f-be02-b3a08772ddf9@github.com>
 <igCVKpgOrXXRr1I0O2q-GkOQG1nZP3EO_BsCFyv2frQ=.43780407-c100-41b6-916f-c5807a82e337@github.com>
Message-ID: <nftyZ4mL51lwJJKnz-btgjPWedXSSZI54NghrVIo5Ks=.ee216181-6605-41c3-b2d6-5a0a6adf2212@github.com>

On Thu, 2 Oct 2025 17:12:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > > In the case of the original warning you saw that triggered this, I think we need to actually fix our usage of CDS in the boot JDK
> > 
> > 
> > So do you think we can just kick out this archive dumping + `Xshare=something` setting from configure ?
> 
> Yes, I think we can, but I would like to see it verified to not cause a regression in build performance before we do.


I created  https://bugs.openjdk.org/browse/JDK-8369305  Adjust usage of CDS in the boot JDK .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3377368497

From shade at openjdk.org  Tue Oct  7 16:57:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Oct 2025 16:57:21 GMT
Subject: RFR: 8369226: GHA: Switch to MacOS 15
In-Reply-To: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
References: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
Message-ID: <jBdVrNPFSx40naJ5SzNlfctgAiHioMU-0Dsp32ixxU4=.fa8f6072-6aa2-4a28-8a87-7522d3ff45c4@github.com>

On Mon, 6 Oct 2025 17:34:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current GHA workflows for MacOS are running with:
>  - x86_64: macos-13, builds only
>  - aarch64: macos-14, builds+tests
> 
> GitHub is deprecating MacOS 13 runner on December 4th, 2025, the brownouts are starting in a month: https://github.com/actions/runner-images/issues/13046. Additionally, GHA phases out MacOS x86_64, and MacOS 15 would be the last runner for x86_64. We have already disabled testing jobs for MacOS x86_64. GitHub recommends migrating to MacOS 15 at this time.
> 
> We can switch to MacOS 15 runner for both x86 and AArch64 to keep pipelines green in the coming months.
> 
> Additional testing:
>  - [x] GHA

Thanks for reviews, here we go. I'll let it linger in mainline before proposing backports. Hopefully, we will get backports in with time to spare before brownouts start.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27655#issuecomment-3377737846

From shade at openjdk.org  Tue Oct  7 16:57:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Oct 2025 16:57:21 GMT
Subject: Integrated: 8369226: GHA: Switch to MacOS 15
In-Reply-To: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
References: <R8nL7JgFziMfzDzXGtQmXpdCkYCbb-7GnYjWEkTJzeM=.ab5fd2d5-2aec-415e-858b-151161b776d6@github.com>
Message-ID: <pXNdCUNk8y6CtkasnDQ5f7dlYfA9vrYJU5btcZYYTYs=.6aec3236-f1c7-4bc6-932e-ac9ec26b8880@github.com>

On Mon, 6 Oct 2025 17:34:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current GHA workflows for MacOS are running with:
>  - x86_64: macos-13, builds only
>  - aarch64: macos-14, builds+tests
> 
> GitHub is deprecating MacOS 13 runner on December 4th, 2025, the brownouts are starting in a month: https://github.com/actions/runner-images/issues/13046. Additionally, GHA phases out MacOS x86_64, and MacOS 15 would be the last runner for x86_64. We have already disabled testing jobs for MacOS x86_64. GitHub recommends migrating to MacOS 15 at this time.
> 
> We can switch to MacOS 15 runner for both x86 and AArch64 to keep pipelines green in the coming months.
> 
> Additional testing:
>  - [x] GHA

This pull request has now been integrated.

Changeset: 1ea8cfa6
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ea8cfa6dc8e6f96fd87553331abaae17ec173ea
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8369226: GHA: Switch to MacOS 15

Reviewed-by: erikj, ayang, sgehwolf

-------------

PR: https://git.openjdk.org/jdk/pull/27655

From erikj at openjdk.org  Tue Oct  7 17:26:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 7 Oct 2025 17:26:57 GMT
Subject: RFR: 8369246: Use https in make/devkit scripts
In-Reply-To: <v3v-acKN33nfP89hVitLJBn8q3KxRMzexm-n821zU-E=.52f3c5e6-8ec2-41b7-b47e-47e951fb9f6b@github.com>
References: <v3v-acKN33nfP89hVitLJBn8q3KxRMzexm-n821zU-E=.52f3c5e6-8ec2-41b7-b47e-47e951fb9f6b@github.com>
Message-ID: <ZsEUUf-xyuJ_P4yWRFM2xO_OdDTL19iKSnglLs9ILF8=.19dbc53d-29d2-4f6a-b947-75b112ef9f8a@github.com>

On Tue, 7 Oct 2025 01:52:44 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Let's switch to https for URLs in the make/devkit files, where possible.
> 
> That's most places, apart from - it turns out from empirical testing - the `fedora.riscv.rocks` (RISC-V) URL in Tools.gmk.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27663#pullrequestreview-3311133783

From erikj at openjdk.org  Tue Oct  7 17:28:07 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 7 Oct 2025 17:28:07 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v5]
In-Reply-To: <2EwmY0XOQ0ZtBw6SXYrDR070TaYvl01aQ9RgMs1zLJA=.9734eb51-a8c9-444c-9113-070579639c6c@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <2EwmY0XOQ0ZtBw6SXYrDR070TaYvl01aQ9RgMs1zLJA=.9734eb51-a8c9-444c-9113-070579639c6c@github.com>
Message-ID: <yr_r9ff-JLChR27DRSfLUmzaOjeuARkJfjN6YIqED-0=.0fc310a9-3c44-42fc-b548-2fad24d1441b@github.com>

On Tue, 7 Oct 2025 12:39:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
>> 
>> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David suggested a change to the UL options for more clarity

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27588#pullrequestreview-3311142437

From mikael at openjdk.org  Tue Oct  7 17:40:20 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 7 Oct 2025 17:40:20 GMT
Subject: RFR: 8369246: Use https in make/devkit scripts
In-Reply-To: <v3v-acKN33nfP89hVitLJBn8q3KxRMzexm-n821zU-E=.52f3c5e6-8ec2-41b7-b47e-47e951fb9f6b@github.com>
References: <v3v-acKN33nfP89hVitLJBn8q3KxRMzexm-n821zU-E=.52f3c5e6-8ec2-41b7-b47e-47e951fb9f6b@github.com>
Message-ID: <ALxjgMIY70ecIfKNRATL461EqxIEMv5bcCC2XNM6JkA=.ee1b214c-c63b-463d-8a10-35df334a4a5f@github.com>

On Tue, 7 Oct 2025 01:52:44 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Let's switch to https for URLs in the make/devkit files, where possible.
> 
> That's most places, apart from - it turns out from empirical testing - the `fedora.riscv.rocks` (RISC-V) URL in Tools.gmk.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

Thank you for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27663#issuecomment-3377890366

From mikael at openjdk.org  Tue Oct  7 17:40:21 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 7 Oct 2025 17:40:21 GMT
Subject: Integrated: 8369246: Use https in make/devkit scripts
In-Reply-To: <v3v-acKN33nfP89hVitLJBn8q3KxRMzexm-n821zU-E=.52f3c5e6-8ec2-41b7-b47e-47e951fb9f6b@github.com>
References: <v3v-acKN33nfP89hVitLJBn8q3KxRMzexm-n821zU-E=.52f3c5e6-8ec2-41b7-b47e-47e951fb9f6b@github.com>
Message-ID: <vqYhhocuMOR3AQxn6azYCRZoVAoq91PiDHhdlH1gfJ8=.a21eb34e-4441-4e27-a4ae-0c77cf073d6f@github.com>

On Tue, 7 Oct 2025 01:52:44 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Let's switch to https for URLs in the make/devkit files, where possible.
> 
> That's most places, apart from - it turns out from empirical testing - the `fedora.riscv.rocks` (RISC-V) URL in Tools.gmk.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

This pull request has now been integrated.

Changeset: 7f070d35
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f070d356c479ae30fe84fcf4d322c0b693fa15a
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8369246: Use https in make/devkit scripts

Reviewed-by: ayang, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/27663

From naoto at openjdk.org  Tue Oct  7 18:41:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 Oct 2025 18:41:09 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <3joVVX55ZEto_x9dhTVpYgMGzPtL8tdNNvZxiBmsuHE=.42d5f21c-64b4-4547-99e1-f2a3af104272@github.com>

On Fri, 3 Oct 2025 19:56:22 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> ### Summary
> 
> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
> 
> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
> 
> **String.equalsIgnoreCase(String)**
> 
> - Unicode-aware, locale-independent.
> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
> - Limited: does not support 1:M mapping defined in Unicode case folding.
> 
> **Character.toLowerCase(int) / Character.toUpperCase(int)**
> 
> - Locale-independent, single code point only.
> - No support for 1:M mappings.
> 
> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
> 
> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
> - Intended primarily for presentation/display, not structural case-insensitive matching.
> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
> 
> **1:M mapping example, U+00DF (?)**
> 
> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
> - Case folding produces "ss", matching Unicode caseless comparison rules.
> 
> 
> jshell> "\u00df".equalsIgnoreCase("ss")
> $22 ==> false
> 
> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
> $24 ==> true
> 
> 
> ### Motivation & Direction
> 
> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
> 
> - Unicode-compliant **full** case folding.
> - Simpler, stable and more efficient case-less matching without workarounds.
> - Brings Java's string comparison handling in line with other programming languages/libraries.
> 
> This PR proposes to introduce the following comparison methods in `String` class
> 
> - boolean equalsFoldCase(String anotherString)
> - int compareToFoldCase(String anotherString)
> - Comparator<String> UNICODE_CASEFOLD_ORDER
> 
> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
> 
> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.
> 
> ### The New API
> 
> 
>    /**
>      * Compares thi...

While working on Unicode 17 upgrade, I noticed that they changed the example from "MASSE"/"Ma?e" to "FUSS"/"Fu?" (https://www.unicode.org/L2/L2025/25085.htm#183-A59), so you might want to switch them as well

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3378153999

From acobbs at openjdk.org  Tue Oct  7 19:40:35 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 7 Oct 2025 19:40:35 GMT
Subject: RFR: 5038439: Warning message for literal shift amounts outside the
 canonical domain
Message-ID: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>

When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored.

This can create a trap for the unwary, as in this example:

public long readLongBigEndian(byte[] buf, int offset) {
    return ((buf[offset + 0] & 0xff) << 56)   // BUG HERE
         | ((buf[offset + 1] & 0xff) << 48)   // BUG HERE
         | ((buf[offset + 2] & 0xff) << 40)   // BUG HERE
         | ((buf[offset + 3] & 0xff) << 32)   // BUG HERE
         | ((buf[offset + 4] & 0xff) << 24)
         | ((buf[offset + 5] & 0xff) << 16)
         | ((buf[offset + 6] & 0xff) << 8)
         | ((buf[offset + 7] & 0xff);
}

This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`.

-------------

Commit messages:
 - Merge branch 'master' into JDK-5038439 to fix conflict.
 - Add "long" as a supported message parameter type.
 - Use "bit(s)" instead of "bits" where value could be 1.
 - Merge branch 'master' into JDK-5038439
 - Sprinkle more variety into the regression test.
 - Minor diff cleanup.
 - Update "lossy-conversions" description in compiler module Javadoc.
 - Warn for bit shifts using an out-of-range shift amount.

Changes: https://git.openjdk.org/jdk/pull/27102/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-5038439
  Stats: 194 lines in 14 files changed: 184 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27102.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27102/head:pull/27102

PR: https://git.openjdk.org/jdk/pull/27102

From acobbs at openjdk.org  Tue Oct  7 20:03:25 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 7 Oct 2025 20:03:25 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v3]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <q_qI6DzbAbTICLbaW4FZkcey6WViuN-VizouO5n9oV0=.fb9b55bf-7717-4f77-b4de-de0473829edd@github.com>

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 132 commits:

 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Add clarifying comment.
 - Merge branch 'master' into JDK-8344159
 - Change inner class name to avoid shadowing superclass name.
 - Add a couple of code clarification comments.
 - Refactor test to avoid requiring changes to TestRunner.
 - Remove unnecessary -Xlint:-suppression flags.
 - Minor cleanups.
 - Add OPTIONS, PATH, and SUPPRESSION to the regression test.
 - ... and 122 more: https://git.openjdk.org/jdk/compare/910bb68e...3542625c

-------------

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=02
  Stats: 1659 lines in 34 files changed: 1486 ins; 49 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

PR: https://git.openjdk.org/jdk/pull/25167

From rriggs at openjdk.org  Tue Oct  7 22:25:08 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 7 Oct 2025 22:25:08 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <AQ7QGe_xYZhLcpWR24Uy2T5wP12Rcm2e0tD5o2nXC8M=.dfd99955-ca35-443d-b968-8fb98f52d786@github.com>

On Fri, 3 Oct 2025 19:56:22 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> ### Summary
> 
> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
> 
> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
> 
> **String.equalsIgnoreCase(String)**
> 
> - Unicode-aware, locale-independent.
> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
> - Limited: does not support 1:M mapping defined in Unicode case folding.
> 
> **Character.toLowerCase(int) / Character.toUpperCase(int)**
> 
> - Locale-independent, single code point only.
> - No support for 1:M mappings.
> 
> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
> 
> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
> - Intended primarily for presentation/display, not structural case-insensitive matching.
> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
> 
> **1:M mapping example, U+00DF (?)**
> 
> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
> - Case folding produces "ss", matching Unicode caseless comparison rules.
> 
> 
> jshell> "\u00df".equalsIgnoreCase("ss")
> $22 ==> false
> 
> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
> $24 ==> true
> 
> 
> ### Motivation & Direction
> 
> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
> 
> - Unicode-compliant **full** case folding.
> - Simpler, stable and more efficient case-less matching without workarounds.
> - Brings Java's string comparison handling in line with other programming languages/libraries.
> 
> This PR proposes to introduce the following comparison methods in `String` class
> 
> - boolean equalsFoldCase(String anotherString)
> - int compareToFoldCase(String anotherString)
> - Comparator<String> UNICODE_CASEFOLD_ORDER
> 
> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
> 
> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.
> 
> ### The New API
> 
> 
>    /**
>      * Compares thi...

The API looks good.

Is the performance comparable to equalsIgnoreCase?

src/java.base/share/classes/java/lang/StringLatin1.java line 194:

> 192:         char[] folded2 = null;
> 193:         int k1 = 0, k2 = 0, fk1 = 0, fk2 = 0;
> 194:         while ((k1 < len1 || folded1 != null && fk1 < folded1.length) &&

Many suggestions come to mind here on the algorithm, to optimize performance.
For example, many strings will have identical prefixes. Using Arrays.mismatch could quickly skip over the identical prefix.
Consider using code points (or a long, packing 4 chars) for the folded replacements, to avoid having to step through chars in char arrays.  CaseFolding.foldIfDefined could return the full expansion as a long.
It may be profitable to use Arrays.mismatch again after expanded characters are determined to be equal.

Take another look at the data structure storing and doing the lookup of foldIfDefined both to increase the lookup performance.

src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 230:

> 228:      private static class CaseFoldingEntry {
> 229:         final int cp;
> 230:         final char[] folding;

Consider storing the folding as a int or long directly to avoid the overhead of small char arrays.
Arrange to be able to compare the whole replacement with another codePoint, etc.

src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 280:

> 278:         }
> 279: 
> 280:         private void add(CaseFoldingEntry entry) {

CDS can map whole objects/data structures into the heap; consider how to make this data structure so it can be mapped and not re-computed each startup.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3312084027
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2412043131
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2412060747
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2412062604

From mikael at openjdk.org  Tue Oct  7 22:30:31 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 7 Oct 2025 22:30:31 GMT
Subject: RFR: 8369328: Use uppercase variable names in the devkit makefiles
Message-ID: <2uB9s8gGTJiRfwxRTFfbbTwYPx__emlpCeQaUU2xDIA=.b35049d3-2c01-4bdd-b03c-3fb0e938def2@github.com>

Bring the devkit makefiles closer to the naming convention used in the JDK build system by using uppercase variable names.

Testing:

* Built devkit on linux-x64
* Verified that the JDK builds with the new devkit

-------------

Commit messages:
 - 8369328: Use uppercase variable names in the devkit makefiles

Changes: https://git.openjdk.org/jdk/pull/27679/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369328
  Stats: 98 lines in 2 files changed: 0 ins; 0 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/27679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27679/head:pull/27679

PR: https://git.openjdk.org/jdk/pull/27679

From erikj at openjdk.org  Tue Oct  7 22:46:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 7 Oct 2025 22:46:51 GMT
Subject: RFR: 8369328: Use uppercase variable names in the devkit makefiles
In-Reply-To: <2uB9s8gGTJiRfwxRTFfbbTwYPx__emlpCeQaUU2xDIA=.b35049d3-2c01-4bdd-b03c-3fb0e938def2@github.com>
References: <2uB9s8gGTJiRfwxRTFfbbTwYPx__emlpCeQaUU2xDIA=.b35049d3-2c01-4bdd-b03c-3fb0e938def2@github.com>
Message-ID: <oTg82RSuH9lzQDtPJDXTlYK6qTr9lP9dCwyIhQwNQSU=.d3dccb52-76c8-41a3-9720-31da35dc0335@github.com>

On Tue, 7 Oct 2025 22:04:56 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Bring the devkit makefiles closer to the naming convention used in the JDK build system by using uppercase variable names.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27679#pullrequestreview-3312155332

From sherman at openjdk.org  Wed Oct  8 00:33:20 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 8 Oct 2025 00:33:20 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>

> ### Summary
> 
> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
> 
> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
> 
> **String.equalsIgnoreCase(String)**
> 
> - Unicode-aware, locale-independent.
> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
> - Limited: does not support 1:M mapping defined in Unicode case folding.
> 
> **Character.toLowerCase(int) / Character.toUpperCase(int)**
> 
> - Locale-independent, single code point only.
> - No support for 1:M mappings.
> 
> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
> 
> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
> - Intended primarily for presentation/display, not structural case-insensitive matching.
> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
> 
> **1:M mapping example, U+00DF (?)**
> 
> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
> - Case folding produces "ss", matching Unicode caseless comparison rules.
> 
> 
> jshell> "\u00df".equalsIgnoreCase("ss")
> $22 ==> false
> 
> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
> $24 ==> true
> 
> 
> ### Motivation & Direction
> 
> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
> 
> - Unicode-compliant **full** case folding.
> - Simpler, stable and more efficient case-less matching without workarounds.
> - Brings Java's string comparison handling in line with other programming languages/libraries.
> 
> This PR proposes to introduce the following comparison methods in `String` class
> 
> - boolean equalsFoldCase(String anotherString)
> - int compareToFoldCase(String anotherString)
> - Comparator<String> UNICODE_CASEFOLD_ORDER
> 
> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
> 
> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.
> 
> ### The New API
> 
> See CSR https://bugs.openjd...

Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:

  minor api doc updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/1abb0228..9d9997dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=00-01

  Stats: 18 lines in 1 file changed: 5 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628

PR: https://git.openjdk.org/jdk/pull/27628

From mikael at openjdk.org  Wed Oct  8 02:08:10 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 8 Oct 2025 02:08:10 GMT
Subject: RFR: 8369328: Use uppercase variable names in the devkit makefiles
In-Reply-To: <2uB9s8gGTJiRfwxRTFfbbTwYPx__emlpCeQaUU2xDIA=.b35049d3-2c01-4bdd-b03c-3fb0e938def2@github.com>
References: <2uB9s8gGTJiRfwxRTFfbbTwYPx__emlpCeQaUU2xDIA=.b35049d3-2c01-4bdd-b03c-3fb0e938def2@github.com>
Message-ID: <hOkBB0wH_B-HjxRRivHymagroP5-UOqkay4e6t7hiYs=.a4056b35-a8fc-4d9d-84f7-7695438516ac@github.com>

On Tue, 7 Oct 2025 22:04:56 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Bring the devkit makefiles closer to the naming convention used in the JDK build system by using uppercase variable names.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

Thank you for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27679#issuecomment-3379309146

From mikael at openjdk.org  Wed Oct  8 02:08:11 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 8 Oct 2025 02:08:11 GMT
Subject: Integrated: 8369328: Use uppercase variable names in the devkit
 makefiles
In-Reply-To: <2uB9s8gGTJiRfwxRTFfbbTwYPx__emlpCeQaUU2xDIA=.b35049d3-2c01-4bdd-b03c-3fb0e938def2@github.com>
References: <2uB9s8gGTJiRfwxRTFfbbTwYPx__emlpCeQaUU2xDIA=.b35049d3-2c01-4bdd-b03c-3fb0e938def2@github.com>
Message-ID: <RxzkXD2XBXW5l4ps35FxtSv_ZFC9IP1NrAdhIlcjKks=.ef46d2ca-64c2-42c0-8f0f-2ee189f013f1@github.com>

On Tue, 7 Oct 2025 22:04:56 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Bring the devkit makefiles closer to the naming convention used in the JDK build system by using uppercase variable names.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Verified that the JDK builds with the new devkit

This pull request has now been integrated.

Changeset: 4ee6079b
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ee6079b11034e7de8be72cd2832fb717c2f140d
Stats:     98 lines in 2 files changed: 0 ins; 0 del; 98 mod

8369328: Use uppercase variable names in the devkit makefiles

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/27679

From dholmes at openjdk.org  Wed Oct  8 05:07:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Oct 2025 05:07:03 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v5]
In-Reply-To: <2EwmY0XOQ0ZtBw6SXYrDR070TaYvl01aQ9RgMs1zLJA=.9734eb51-a8c9-444c-9113-070579639c6c@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <2EwmY0XOQ0ZtBw6SXYrDR070TaYvl01aQ9RgMs1zLJA=.9734eb51-a8c9-444c-9113-070579639c6c@github.com>
Message-ID: <W9mv5VD4_Z-MJFN8o7VnZ-SOlMihBhSfJ8skc-VxKvg=.0d4e3b84-7d53-405a-a7fc-21de07f09b5a@github.com>

On Tue, 7 Oct 2025 12:39:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
>> 
>> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David suggested a change to the UL options for more clarity

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27588#pullrequestreview-3312835797

From mbaesken at openjdk.org  Wed Oct  8 07:05:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 8 Oct 2025 07:05:20 GMT
Subject: RFR: 8368960: Adjust java UL logging in the build [v5]
In-Reply-To: <2EwmY0XOQ0ZtBw6SXYrDR070TaYvl01aQ9RgMs1zLJA=.9734eb51-a8c9-444c-9113-070579639c6c@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
 <2EwmY0XOQ0ZtBw6SXYrDR070TaYvl01aQ9RgMs1zLJA=.9734eb51-a8c9-444c-9113-070579639c6c@github.com>
Message-ID: <uiY3f2qw7UYC1ZawKkz69k1rhDciixCf8S5z6HX_tvw=.cc1dc4c3-6b93-4ca6-ba25-39a2ea542f29@github.com>

On Tue, 7 Oct 2025 12:39:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
>> 
>> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David suggested a change to the UL options for more clarity

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27588#issuecomment-3380025273

From mbaesken at openjdk.org  Wed Oct  8 07:05:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 8 Oct 2025 07:05:22 GMT
Subject: Integrated: 8368960: Adjust java UL logging in the build
In-Reply-To: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
References: <0qaG30dpDqdFndbPZ2fTB8rqlZdcjNaHZrn4ZbjVPTk=.b06c519a-ccc3-4aa4-80ad-a45b05531ecc@github.com>
Message-ID: <4DO_28WsgNTbBruZWKRi2D72IWUYISeu3rAE0oeu3Ho=.83ccba7e-626a-442d-8baa-d660011f4161@github.com>

On Wed, 1 Oct 2025 08:26:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.
> 
> An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .

This pull request has now been integrated.

Changeset: bd25db1f
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd25db1fb8573fc908f7a8a96bca417b1d44689a
Stats:     4 lines in 2 files changed: 3 ins; 0 del; 1 mod

8368960: Adjust java UL logging in the build

Reviewed-by: erikj, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/27588

From jwaters at openjdk.org  Wed Oct  8 12:06:45 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Oct 2025 12:06:45 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <WWuvmG4xgHdPyGLGc9qevYrVkZ6PBb3qYPsThvyFMNg=.726dd880-32d9-43be-b517-3b1649060bd0@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters 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 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/3b8c255b...9d05cb8e

Paging with the mailing list bridge to restart discussion, which I need in order to be able to continue working on this

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3381196846

From rriggs at openjdk.org  Wed Oct  8 13:24:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 13:24:48 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <AQ7QGe_xYZhLcpWR24Uy2T5wP12Rcm2e0tD5o2nXC8M=.dfd99955-ca35-443d-b968-8fb98f52d786@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <AQ7QGe_xYZhLcpWR24Uy2T5wP12Rcm2e0tD5o2nXC8M=.dfd99955-ca35-443d-b968-8fb98f52d786@github.com>
Message-ID: <BX1VT_qqL_5gxzxWeBahFUV9t_I8IPi7y6Ssq4bOZ1M=.ea2332b2-8320-4a4d-97f7-6de4d636dfa8@github.com>

On Tue, 7 Oct 2025 22:18:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor api doc updates
>
> src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 230:
> 
>> 228:      private static class CaseFoldingEntry {
>> 229:         final int cp;
>> 230:         final char[] folding;
> 
> Consider storing the folding as a int or long directly to avoid the overhead of small char arrays.
> Arrange to be able to compare the whole replacement with another codePoint, etc.

I misunderstood the algorithm when comparing folded characters against non-folded sequences.
I still think a fast path for single character replacements will lower memory costs and improve performance.
The case of single-codepoint to single-codepoint dominates the case folding mappings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2413846987

From liach at openjdk.org  Wed Oct  8 14:14:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 8 Oct 2025 14:14:26 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
Message-ID: <pOoCwagMP8MLGmeYS7JxWaLNQnHgFSQgaS3lABGbF2U=.56cbe932-c1a8-4925-ba3f-74a4f78ed0ff@github.com>

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

Given this patch obviously has so many performance optimization opportunities, I recommend handling those in subsequent RFEs so that we can review this purely from a specification point of view.

make/modules/java.base/gensrc/GensrcCharacterData.gmk line 76:

> 74: 
> 75: 
> 76: GENSRC_STRINGCASEFOLDING := $(SUPPORT_OUTPUTDIR)/gensrc/java.base/jdk/internal/java/lang/CaseFolding.java

Can we target the package `jdk.internal.lang` instead of `jdk.internal.java.lang`? I think the previous one is the convention set forth by stable values.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3314954963
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2413957017

From rriggs at openjdk.org  Wed Oct  8 14:38:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 14:38:26 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <pOoCwagMP8MLGmeYS7JxWaLNQnHgFSQgaS3lABGbF2U=.56cbe932-c1a8-4925-ba3f-74a4f78ed0ff@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
 <pOoCwagMP8MLGmeYS7JxWaLNQnHgFSQgaS3lABGbF2U=.56cbe932-c1a8-4925-ba3f-74a4f78ed0ff@github.com>
Message-ID: <g6-8IzDioM9Hj7bH8dQXiAvdbm4ciaBV0LWJo3DWjss=.496126aa-7876-4e89-9216-8bd337615c56@github.com>

On Wed, 8 Oct 2025 14:11:28 GMT, Chen Liang <liach at openjdk.org> wrote:

> Given this patch obviously has so many performance optimization opportunities, I recommend handling those in subsequent RFEs so that we can review this purely from a specification point of view.

There is adequate time before RPD1 (Dec 4, 25) to improve performance, but the feature should not be included in JDK 26 unless the performance is comparable to the existing `compareToIgnoreCase` and `equalsIgnoreCase`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3381857251

From duke at openjdk.org  Wed Oct  8 16:35:05 2025
From: duke at openjdk.org (Bernd)
Date: Wed, 8 Oct 2025 16:35:05 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
Message-ID: <9c13AiS1RTrKhWGiVifePZ4CZa7Iws-AirXB-YMR4NQ=.cc24d342-334f-4be1-b886-7efd2c0a8898@github.com>

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

Great progress thanks. Did you also consider a startsWith/containsCaseFold, I missed the case ignoring variants of those already. Or maybe provide an API to implement them on the cases folded intermediate buffers? If the API footprint gets too big on String as CaseFoldString.contains() helper maybe?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3382351349

From liach at openjdk.org  Wed Oct  8 18:23:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 8 Oct 2025 18:23:26 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <9c13AiS1RTrKhWGiVifePZ4CZa7Iws-AirXB-YMR4NQ=.cc24d342-334f-4be1-b886-7efd2c0a8898@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
 <9c13AiS1RTrKhWGiVifePZ4CZa7Iws-AirXB-YMR4NQ=.cc24d342-334f-4be1-b886-7efd2c0a8898@github.com>
Message-ID: <MELcLMbtvaqO7C2mbpPqTZDLFxVz5zztFt6idL1c99A=.878ecff4-2254-47aa-add4-493a41b29a98@github.com>

On Wed, 8 Oct 2025 16:31:53 GMT, Bernd <duke at openjdk.org> wrote:

> Did you also consider a startsWith/containsCaseFold, I missed the case ignoring variants of those already.

I think for this purpose, we should rather introduce an API to case fold a string - we can use these operations on the case-fold-normalized strings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3382715644

From rriggs at openjdk.org  Wed Oct  8 18:40:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 18:40:58 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
Message-ID: <mJRHKY2O06KOHh5eDOu7wk7dkdCVp6gvkiBgxwY1w20=.2cdb4812-6108-48bc-b3b6-7ef5b0418f56@github.com>

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

The new APIs mentioned would be more effective, leveraging the underlying implementation without needing to create new Strings.  Earlier discussions of the support for folding, raised a concern about tempting developers to a more ambiguous situation in which folded and unfolded strings exist and can be confused.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3382766309

From liach at openjdk.org  Wed Oct  8 18:58:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 8 Oct 2025 18:58:30 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
Message-ID: <n-hC7QcR_hipyppkl-LGFERel-C5nKQqX7AddlVqLE8=.b3dd1171-51f7-4700-8f10-6ae5c61b2ac6@github.com>

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

I don't think it's a good idea to have an explosion of case-folding variants of string operations if we are adding a case-folding overload for every operation. In that case, the confusion of case folding applicability would be less of a problem compared to the API bloat.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3382818647

From mikael at openjdk.org  Wed Oct  8 22:52:42 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 8 Oct 2025 22:52:42 GMT
Subject: RFR: 8369454: Verify checksums of downloaded source bundles when
 creating devkit
Message-ID: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>

Let's verify that the downloaded source bundles (tar balls) are sound by computing a checksum and verifying against the baked in one.

This change also introduces a way to provide alternative mirrors for the source bundles, e.g. by setting `GCC_BASE_URL` or `GNU_BASE_URL`.

Testing:

* Built devkit on linux-x64
* Tested that overriding `GNU_BASE_URL` works as expected
* Verified that the JDK builds with the new devkit

-------------

Commit messages:
 - Verify download checksums

Changes: https://git.openjdk.org/jdk/pull/27708/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27708&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369454
  Stats: 45 lines in 1 file changed: 31 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/27708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27708/head:pull/27708

PR: https://git.openjdk.org/jdk/pull/27708

From vpetko at openjdk.org  Wed Oct  8 23:24:14 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Wed, 8 Oct 2025 23:24:14 GMT
Subject: RFR: 8369450: [Ubuntu 25.10] openjdk fails to build due to
 rust-coreutils date
Message-ID: <yIYjLMgItqCEDKdG8185_U-rAkj-96ze2wV89pGl-Y4=.030e8b3f-24cf-419b-aa73-f45c530659a3@github.com>

This PR adds `uutils` as a GNU-compatible date provider.

Testing:
Configure

$ sh configure
...
checking if date is a GNU compatible version... yes
...


[configure.log](https://github.com/user-attachments/files/22785819/configure.log)

Build:

$ make images
....
Finished building target 'images' in configuration 'linux-x86_64-server-release'

-------------

Commit messages:
 - 8369450: [Ubuntu 25.10] openjdk fails to build due to rust-coreutils date

Changes: https://git.openjdk.org/jdk/pull/27705/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27705&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369450
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27705/head:pull/27705

PR: https://git.openjdk.org/jdk/pull/27705

From stefank at openjdk.org  Thu Oct  9 10:08:43 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 9 Oct 2025 10:08:43 GMT
Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
Message-ID: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>

[JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.

It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.

Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.

The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.

I will run this through Oracle's tier1-tier8 testing.

-------------

Commit messages:
 - 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4

Changes: https://git.openjdk.org/jdk/pull/27721/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27721&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369491
  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27721.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27721/head:pull/27721

PR: https://git.openjdk.org/jdk/pull/27721

From lkorinth at openjdk.org  Thu Oct  9 10:26:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 9 Oct 2025 10:26:19 GMT
Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
In-Reply-To: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
References: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
Message-ID: <gM8x3zgJI8j-DIE5MbQE-QPUWU_vxH88ew92n9QjXpc=.00c39dcb-cdc3-482b-8110-cd8542c07f29@github.com>

On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.
> 
> It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.
> 
> Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.
> 
> The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.
> 
> I will run this through Oracle's tier1-tier8 testing.

Looks good to me.

-------------

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3318245874

From cstein at openjdk.org  Thu Oct  9 10:32:13 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 9 Oct 2025 10:32:13 GMT
Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
In-Reply-To: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
References: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
Message-ID: <POtRGSpact3ARJO8dnZg_ATFT_BvdQ2QhmqL1NVeq8w=.968211e7-8055-4e54-bcf9-bc074c9dc516@github.com>

On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.
> 
> It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.
> 
> Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.
> 
> The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.
> 
> I will run this through Oracle's tier1-tier8 testing.

Marked as reviewed by cstein (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3318280220

From jpai at openjdk.org  Thu Oct  9 12:25:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 9 Oct 2025 12:25:28 GMT
Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
In-Reply-To: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
References: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
Message-ID: <SBzlfEnEQ2ELxsalDORy405Qxcv8hVLArlc4QXDL53w=.7eb16582-e097-431a-ac23-34f70e7224f3@github.com>

On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.
> 
> It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.
> 
> Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.
> 
> The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.
> 
> I will run this through Oracle's tier1-tier8 testing.

This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3318710232

From cstein at openjdk.org  Thu Oct  9 14:22:44 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 9 Oct 2025 14:22:44 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
Message-ID: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>

Please review the change to update to using jtreg `8.1`.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

-------------

Commit messages:
 - 8369488: Update to use jtreg 8.1

Changes: https://git.openjdk.org/jdk/pull/27719/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27719&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369488
  Stats: 11 lines in 9 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27719/head:pull/27719

PR: https://git.openjdk.org/jdk/pull/27719

From syan at openjdk.org  Thu Oct  9 14:26:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 Oct 2025 14:26:58 GMT
Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
In-Reply-To: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
References: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
Message-ID: <caGPNSY6Mpv7PvxCT_ycci75UtJBoh_NnCTu3CGH08c=.04381d2c-39ea-4ba1-ab82-e748c4442d13@github.com>

On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.
> 
> It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.
> 
> Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.
> 
> The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.
> 
> I will run this through Oracle's tier1-tier8 testing.

Glad to see this proposed change.

-------------

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3319264878

From 2840772674 at qq.com  Thu Oct  9 13:29:12 2025
From: 2840772674 at qq.com (2840772674 at qq.com)
Date: Thu, 9 Oct 2025 13:29:12 +0000
Subject: [OpenJDK 8] Doc issue: FreeType minimum version should be 2.4.11 for
 Windows builds
Message-ID: <tencent_A9DC1D8F360F73FCDFD70141167029AE1C06@qq.com>

Dear OpenJDK Build Team,
I am writing to report an issue with the build documentation for OpenJDK 8. The current documentation in doc/build.html states that FreeType 2.3.0 is the minimum requirement for Windows builds. However, during my attempts to build OpenJDK 8 (update 362-ga) on Windows XP (x86) and Windows Server 2003 x64 Enterprise Edition, I encountered linker errors for the symbols _FT_Property_Set and _FT_Library_SetLcdFilter when using FreeType 2.3.0.
After investigating the source code, I found that these functions are used in jdk/src/share/native/sun/font/freetypeScaler.c at line 283. According to the FreeType documentation, the symbol _FT_Property_Set was introduced in version 2.4.11. Therefore, the minimum FreeType requirement for Windows builds should be updated to 2.4.11.
I have confirmed that the build succeeds with FreeType 2.4.11 on the same operating systems. Below are the environment details for verification:
Failed Environment (FreeType 2.3.0):

  *   x86: Windows XP SP3, JDK 7u7, Visual Studio 2010, FreeType 2.3.0, Cygwin 1.7.16 (make 3.82.90-1, m4 1.4.16-1, binutils 2.22.51-2, zip 3.0-11, unzip 6.0-10, gawk 4.0.1-1, cpio 2.11-2, procps 3.2.7-1, file 5.11-1)
  *   x64: Windows Server 2003 x64 Enterprise, JDK 7u7, Visual Studio 2010, FreeType 2.3.0, Cygwin 1.7.16 (same components as above)

Successful Environment (FreeType 2.4.11):

  *   x86: Windows XP SP3, JDK 7u7, Visual Studio 2010, FreeType 2.4.11, Cygwin 1.7.16 (same components as above)
  *   x64: Windows Server 2003 x64 Enterprise Edition, JDK 7u7, Visual Studio 2010, FreeType 2.4.11, Cygwin 1.7.16 (same components as above)

Additionally, I note that Windows XP and Server 2003 are outdated systems. Even when the build succeeds with FreeType 2.4.11, jtreg cannot perform full tests on these platforms due to compatibility limitations and socket connection errors (even with the firewall disabled on these operating systems). For a more reliable build and testing workflow, it may be advisable to raise the minimum Windows OS requirements for OpenJDK 8 builds.
I kindly request that the documentation in doc/build.html be updated to reflect the correct minimum FreeType version (2.4.11) for Windows builds. This change will prevent similar issues for other contributors.
Thank you for your time and consideration. I am happy to provide further details if needed.
Best regards,

Neville.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20251009/da95c254/attachment.htm>

From eosterlund at openjdk.org  Thu Oct  9 15:45:21 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 9 Oct 2025 15:45:21 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching
 with Any GC
Message-ID: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>

This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.

The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.

This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.

The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.

The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.

Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in the archive. I call this iterative materialization, as opposed to traversing materialization used by the application threads if necessary.

Background materialization is performed in batches. Each batch has N roots and the background thread will ensure when processing a batch, that these roots are transitively materialized. In order to help with this, there is a table that for each root index knows the max DFS index transitively reachable. This allows each batch being processed by the background thread to define a range of objects currently being materialized: the first object and the last object of the batch.

This allows cheaper synchronization across threads. Each batch is claimed under a lock, but the actual processing of the batch may be performed without the lock, allowing the application thread(s) to perform traversals concurrently, without stepping on each others toes. When an application thread traverses through a root, for each visited object it can easily determine if this has already been transitively materialized by the background thread (before the current batch range), implying no further traversal is needed, or if the object is ahead of the current batch implying traversal is needed, or if the batch range currently being materialized contains the object, implying we should wait for it to finish. Intersections are rare, and for the most part, they can run independently.

Unlike the mapping solution, the new solution does not dump the entire string table. Instead, interned strings in the archive are marked as interned strings, and the loader knows when unpacking them that the string should be interned. An application thread might call intern before or after, but it does not matter; in both cases all links will be linked to the interned string, whichever one that is.

In order to speed up materialization, before GC is allowed to run, the materialization code maps object indices to objects using raw oops. It also copies archived object payload to the heap object (including object indices in the reference slots), and then fixes up the references in-place. This is only okay before GC is allowed to run. After that point in the bootstrapping, if materialization has not yet completed, a more careful strategy is used where primitive ranges are copied in bulk, but object references are copied one by one, so that the heap object never has its reference fields intermittently containing garbage object indices that can trip up a concurrent GC.

It is not currently intended to remove the previous heap archiving mechanism. Heuristically, we will pick the new mechanism when compressed oops is off. The JDK caches without compressed oops will hence use this new object streaming mechanism, while the other caches will use the old mapping mechanism. The HeapShared class has been used as a common interface between the two heap archive writers and loaders.

A lot of testing has been done with all combinations of GCs, AOTClassLinking, COH, COOPs, streaming/mapping, etc. Existing AOT/CDS tests have been adapted to manage with both heap archiving solutions.

-------------

Commit messages:
 - whitespace fixes
 - 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC

Changes: https://git.openjdk.org/jdk/pull/27732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365932
  Stats: 8639 lines in 109 files changed: 5870 ins; 2312 del; 457 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From iris at openjdk.org  Thu Oct  9 15:54:33 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 9 Oct 2025 15:54:33 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <ceuIjydNidvKfTEkuljdRLyqX9HRl6AnO6W3P1u7AzI=.7f5521a0-7a2a-480e-a585-01d5987396fe@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3319601046

From duke at openjdk.org  Thu Oct  9 16:11:02 2025
From: duke at openjdk.org (Bernd)
Date: Thu, 9 Oct 2025 16:11:02 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
Message-ID: <7FNQkL6cersUolPLQ1NViK0811Mx3AkaNzid3tQktbI=.2eaa33d4-8051-486a-b305-a5d4000948de@github.com>

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 36:

> 34: 
> 35: /**
> 36:  * Utility class for {@code String.toCaseFold()} that handles Unicode case folding

Maybe make it clear this is a planned api (or not refer to it?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2417269101

From erikj at openjdk.org  Thu Oct  9 17:17:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Oct 2025 17:17:45 GMT
Subject: RFR: 8369454: Verify checksums of downloaded source bundles when
 creating devkit
In-Reply-To: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>
References: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>
Message-ID: <PAMR-xW2UsQAsmH5SErBaMhbNWKfNdByoRPwySzPQPM=.8e8d6057-fe5b-42b1-8407-f4490c1e6bd5@github.com>

On Wed, 8 Oct 2025 22:45:42 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Let's verify that the downloaded source bundles (tar balls) are sound by computing a checksum and verifying against the baked in one.
> 
> This change also introduces a way to provide alternative mirrors for the source bundles, e.g. by setting `GCC_BASE_URL` or `GNU_BASE_URL`.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Tested that overriding `GNU_BASE_URL` works as expected
> * Verified that the JDK builds with the new devkit

make/devkit/Tools.gmk line 224:

> 222: 
> 223: # Generate downloading + unpacking of sources.
> 224: define DownloadVerifyUnpack

It's not actually unpacking is it?
Suggestion:

define DownloadVerify

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27708#discussion_r2417429155

From erikj at openjdk.org  Thu Oct  9 17:19:44 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Oct 2025 17:19:44 GMT
Subject: RFR: 8369450: [Ubuntu 25.10] openjdk fails to build due to
 rust-coreutils date
In-Reply-To: <yIYjLMgItqCEDKdG8185_U-rAkj-96ze2wV89pGl-Y4=.030e8b3f-24cf-419b-aa73-f45c530659a3@github.com>
References: <yIYjLMgItqCEDKdG8185_U-rAkj-96ze2wV89pGl-Y4=.030e8b3f-24cf-419b-aa73-f45c530659a3@github.com>
Message-ID: <cifgeyWhGwnyj_7g3rjZovys9lrXY_9BCjrzlaoqjMc=.b95c6337-84e9-45d6-847f-253bbf4924a5@github.com>

On Wed, 8 Oct 2025 20:41:22 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR adds `uutils` as a GNU-compatible date provider.
> 
> Testing:
> Configure
> 
> $ sh configure
> ...
> checking if date is a GNU compatible version... yes
> ...
> 
> 
> [configure.log](https://github.com/user-attachments/files/22785819/configure.log)
> 
> Build:
> 
> $ make images
> ....
> Finished building target 'images' in configuration 'linux-x86_64-server-release'

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27705#pullrequestreview-3319910124

From erikj at openjdk.org  Thu Oct  9 17:30:22 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Oct 2025 17:30:22 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <O0F-Tt7MbvHPPqYhGN-lcKer75FuHmmBbCP1Ojpb1Tk=.abb8f0d1-0acb-492f-ae75-d9b6deb548a7@github.com>

On Thu, 9 Oct 2025 15:18:16 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Build changes trivially ok.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3386863791

From erikj at openjdk.org  Thu Oct  9 17:31:20 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Oct 2025 17:31:20 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <yrNV4JVv9750_c1Q8xvrDuzIP_Ps6A-rGAxbrljRdVE=.8c69f71f-b42e-4d1a-843b-0cff7681d470@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3319953574

From mikael at openjdk.org  Thu Oct  9 18:09:23 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 9 Oct 2025 18:09:23 GMT
Subject: RFR: 8369454: Verify checksums of downloaded source bundles when
 creating devkit [v2]
In-Reply-To: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>
References: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>
Message-ID: <xzzg-p3PimO2e4HTUOrqt4UoFR5NByxk9PsjMHzSPy4=.4d2e3f17-dde2-4cf0-82f7-aa3c4280b04e@github.com>

> Let's verify that the downloaded source bundles (tar balls) are sound by computing a checksum and verifying against the baked in one.
> 
> This change also introduces a way to provide alternative mirrors for the source bundles, e.g. by setting `GCC_BASE_URL` or `GNU_BASE_URL`.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Tested that overriding `GNU_BASE_URL` works as expected
> * Verified that the JDK builds with the new devkit

Mikael Vidstedt has updated the pull request incrementally with three additional commits since the last revision:

 - Update DownloadVerify comment
 - Rename DownloadVerify
 - Update make/devkit/Tools.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27708/files
  - new: https://git.openjdk.org/jdk/pull/27708/files/473bc8a0..bdc5f831

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27708&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27708&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27708/head:pull/27708

PR: https://git.openjdk.org/jdk/pull/27708

From mikael at openjdk.org  Thu Oct  9 18:09:25 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 9 Oct 2025 18:09:25 GMT
Subject: RFR: 8369454: Verify checksums of downloaded source bundles when
 creating devkit [v2]
In-Reply-To: <PAMR-xW2UsQAsmH5SErBaMhbNWKfNdByoRPwySzPQPM=.8e8d6057-fe5b-42b1-8407-f4490c1e6bd5@github.com>
References: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>
 <PAMR-xW2UsQAsmH5SErBaMhbNWKfNdByoRPwySzPQPM=.8e8d6057-fe5b-42b1-8407-f4490c1e6bd5@github.com>
Message-ID: <IVgt5k-6JTF-9du8Pnb-L8l6NMnWbPYtYeqEIz-ss9M=.29f68260-7078-4fce-9172-055d44876579@github.com>

On Thu, 9 Oct 2025 17:14:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Mikael Vidstedt has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update DownloadVerify comment
>>  - Rename DownloadVerify
>>  - Update make/devkit/Tools.gmk
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> make/devkit/Tools.gmk line 224:
> 
>> 222: 
>> 223: # Generate downloading + unpacking of sources.
>> 224: define DownloadVerifyUnpack
> 
> It's not actually unpacking is it?
> Suggestion:
> 
> define DownloadVerify

Updated the name and the comment to match the actual behavior

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27708#discussion_r2417574723

From duke at openjdk.org  Thu Oct  9 19:22:20 2025
From: duke at openjdk.org (duke)
Date: Thu, 9 Oct 2025 19:22:20 GMT
Subject: RFR: 8369450: [Ubuntu 25.10] openjdk fails to build due to
 rust-coreutils date
In-Reply-To: <yIYjLMgItqCEDKdG8185_U-rAkj-96ze2wV89pGl-Y4=.030e8b3f-24cf-419b-aa73-f45c530659a3@github.com>
References: <yIYjLMgItqCEDKdG8185_U-rAkj-96ze2wV89pGl-Y4=.030e8b3f-24cf-419b-aa73-f45c530659a3@github.com>
Message-ID: <2oz3IIezwE176ez10ujMpxT7bt5skQEfij4UyriBDEI=.756864d4-879b-44c0-9d59-2dedec5911a6@github.com>

On Wed, 8 Oct 2025 20:41:22 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR adds `uutils` as a GNU-compatible date provider.
> 
> Testing:
> Configure
> 
> $ sh configure
> ...
> checking if date is a GNU compatible version... yes
> ...
> 
> 
> [configure.log](https://github.com/user-attachments/files/22785819/configure.log)
> 
> Build:
> 
> $ make images
> ....
> Finished building target 'images' in configuration 'linux-x86_64-server-release'

@vpa1977 
Your change (at version 3ce304b654a8652c600da211848ad4789eaff965) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27705#issuecomment-3387203396

From erikj at openjdk.org  Thu Oct  9 19:39:07 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Oct 2025 19:39:07 GMT
Subject: RFR: 8369454: Verify checksums of downloaded source bundles when
 creating devkit [v2]
In-Reply-To: <xzzg-p3PimO2e4HTUOrqt4UoFR5NByxk9PsjMHzSPy4=.4d2e3f17-dde2-4cf0-82f7-aa3c4280b04e@github.com>
References: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>
 <xzzg-p3PimO2e4HTUOrqt4UoFR5NByxk9PsjMHzSPy4=.4d2e3f17-dde2-4cf0-82f7-aa3c4280b04e@github.com>
Message-ID: <Bug8zjC0xEf8TwGURTPhzItmqkftOPIs03jOpkpcKHQ=.30dd6d8e-e862-43f3-99cd-839df350b035@github.com>

On Thu, 9 Oct 2025 18:09:23 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Let's verify that the downloaded source bundles (tar balls) are sound by computing a checksum and verifying against the baked in one.
>> 
>> This change also introduces a way to provide alternative mirrors for the source bundles, e.g. by setting `GCC_BASE_URL` or `GNU_BASE_URL`.
>> 
>> Testing:
>> 
>> * Built devkit on linux-x64
>> * Tested that overriding `GNU_BASE_URL` works as expected
>> * Verified that the JDK builds with the new devkit
>
> Mikael Vidstedt has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update DownloadVerify comment
>  - Rename DownloadVerify
>  - Update make/devkit/Tools.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27708#pullrequestreview-3320383663

From vpetko at openjdk.org  Thu Oct  9 19:42:15 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Thu, 9 Oct 2025 19:42:15 GMT
Subject: Integrated: 8369450: [Ubuntu 25.10] openjdk fails to build due to
 rust-coreutils date
In-Reply-To: <yIYjLMgItqCEDKdG8185_U-rAkj-96ze2wV89pGl-Y4=.030e8b3f-24cf-419b-aa73-f45c530659a3@github.com>
References: <yIYjLMgItqCEDKdG8185_U-rAkj-96ze2wV89pGl-Y4=.030e8b3f-24cf-419b-aa73-f45c530659a3@github.com>
Message-ID: <nx7wZSdr5b4-wfJSdL2jxsshQtfDBLB9IK2Pgrkz1ao=.2d3b1c65-984e-4238-8407-8b2344666e14@github.com>

On Wed, 8 Oct 2025 20:41:22 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR adds `uutils` as a GNU-compatible date provider.
> 
> Testing:
> Configure
> 
> $ sh configure
> ...
> checking if date is a GNU compatible version... yes
> ...
> 
> 
> [configure.log](https://github.com/user-attachments/files/22785819/configure.log)
> 
> Build:
> 
> $ make images
> ....
> Finished building target 'images' in configuration 'linux-x86_64-server-release'

This pull request has now been integrated.

Changeset: b73228b5
Author:    Vladimir Petko <vpetko at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b73228b51c1b1c59c8cd8ee7b14522edc12d564a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8369450: [Ubuntu 25.10] openjdk fails to build due to rust-coreutils date

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/27705

From mikael at openjdk.org  Thu Oct  9 19:58:13 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 9 Oct 2025 19:58:13 GMT
Subject: RFR: 8369454: Verify checksums of downloaded source bundles when
 creating devkit [v2]
In-Reply-To: <xzzg-p3PimO2e4HTUOrqt4UoFR5NByxk9PsjMHzSPy4=.4d2e3f17-dde2-4cf0-82f7-aa3c4280b04e@github.com>
References: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>
 <xzzg-p3PimO2e4HTUOrqt4UoFR5NByxk9PsjMHzSPy4=.4d2e3f17-dde2-4cf0-82f7-aa3c4280b04e@github.com>
Message-ID: <_illb0xq8C8BLRUSpnX52o0QBljF7SD2R9UyVmaLfQ0=.5a64f388-3d4e-495f-8d68-210aaf2806e9@github.com>

On Thu, 9 Oct 2025 18:09:23 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Let's verify that the downloaded source bundles (tar balls) are sound by computing a checksum and verifying against the baked in one.
>> 
>> This change also introduces a way to provide alternative mirrors for the source bundles, e.g. by setting `GCC_BASE_URL` or `GNU_BASE_URL`.
>> 
>> Testing:
>> 
>> * Built devkit on linux-x64
>> * Tested that overriding `GNU_BASE_URL` works as expected
>> * Verified that the JDK builds with the new devkit
>
> Mikael Vidstedt has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update DownloadVerify comment
>  - Rename DownloadVerify
>  - Update make/devkit/Tools.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Thank you for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27708#issuecomment-3387298736

From mikael at openjdk.org  Thu Oct  9 19:58:14 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 9 Oct 2025 19:58:14 GMT
Subject: Integrated: 8369454: Verify checksums of downloaded source bundles
 when creating devkit
In-Reply-To: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>
References: <F5lhDxFiDVkZC8LnvQpTulm7lSplwgIwT2AQXFx0iFk=.3b2e4072-1d2b-4b23-8a40-0e4739b89f1b@github.com>
Message-ID: <pM_qkPx3Cvfjg9oLzLi8OEta24HhDiNz15FvtFo4SDU=.a85c40f4-a3ed-4173-a490-e2096703391a@github.com>

On Wed, 8 Oct 2025 22:45:42 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Let's verify that the downloaded source bundles (tar balls) are sound by computing a checksum and verifying against the baked in one.
> 
> This change also introduces a way to provide alternative mirrors for the source bundles, e.g. by setting `GCC_BASE_URL` or `GNU_BASE_URL`.
> 
> Testing:
> 
> * Built devkit on linux-x64
> * Tested that overriding `GNU_BASE_URL` works as expected
> * Verified that the JDK builds with the new devkit

This pull request has now been integrated.

Changeset: cd1ce588
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd1ce5883db55540379ce090244b698696e16ec3
Stats:     46 lines in 1 file changed: 31 ins; 0 del; 15 mod

8369454: Verify checksums of downloaded source bundles when creating devkit

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/27708

From serb at openjdk.org  Fri Oct 10 03:18:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 10 Oct 2025 03:18:03 GMT
Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
In-Reply-To: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
References: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
Message-ID: <CqG693G7Q1ZYP_vsr8YLQNEpiZxVJccCrbqYaGupkbs=.117cd73a-66e4-45b8-a02e-a4179479fa14@github.com>

On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.
> 
> It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.
> 
> Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.
> 
> The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.
> 
> I will run this through Oracle's tier1-tier8 testing.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3321214353

From prr at openjdk.org  Fri Oct 10 05:00:06 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 10 Oct 2025 05:00:06 GMT
Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
In-Reply-To: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
References: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
Message-ID: <MZofrSRF7Mebh7kuGL_yf89dOehp6ICM9QmVbRRyIOg=.fd165fec-d073-4f45-b540-ce2f699f734b@github.com>

On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.
> 
> It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.
> 
> Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.
> 
> The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.
> 
> I will run this through Oracle's tier1-tier8 testing.

Marked as reviewed by prr (Reviewer).

I don't have much visibility into how this affected other areas but I was surprised that a test that for me runs in a couple of seconds was apparently timing out on some systems  (not the Oracle CI but some external one).
In the PR to resolve this I suggested (https://github.com/openjdk/jdk/pull/27397#discussion_r2383687871) 
that we may be using too high a concurrency as chosen by the build as tests could be more sensitive to this.
But I also see that if you have a system with N CPUs it is a waste to only use (eg) N/2 because "some" test might time out.
A compromise may be needed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3321344090
PR Comment: https://git.openjdk.org/jdk/pull/27721#issuecomment-3388293960

From mbaesken at openjdk.org  Fri Oct 10 11:48:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Oct 2025 11:48:16 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK
Message-ID: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>

Currently we dump an archive in the configure process, this might not be needed/beneficial any more.

Building with and without the change on Linux x86_64 (product)  shows similar build times.

-------------

Commit messages:
 - JDK-8369305

Changes: https://git.openjdk.org/jdk/pull/27741/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27741&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369305
  Stats: 28 lines in 1 file changed: 0 ins; 25 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27741.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27741/head:pull/27741

PR: https://git.openjdk.org/jdk/pull/27741

From syan at openjdk.org  Fri Oct 10 11:55:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 10 Oct 2025 11:55:08 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <th0xj31xU5BouCinlYO39yensVKK5fzapO7AQ1Ce5-M=.0d8ac8e9-880e-4a88-a1f5-9ec3d08ed752@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Hi, is there a way to get the jtreg8.1 binary, except build from source.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27719#issuecomment-3389686651

From syan at openjdk.org  Fri Oct 10 12:00:06 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 10 Oct 2025 12:00:06 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <4WET954Oj6nVqTC0d9fTAAFyjWoUnu0EsGy7VM-V9do=.b4957a46-6b4e-4e74-bfde-33291622fde4@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Hi, is there a way to get the jtreg8.1 binary, except build from source.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27719#issuecomment-3389704303

From eosterlund at openjdk.org  Fri Oct 10 13:48:38 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 10 Oct 2025 13:48:38 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v2]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <xgl6rFVWMGfndCOgAeIc_7txlymPYDWRqjWRAKljGVw=.b46ec7ca-7364-4a7b-a98f-af999655abb4@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:

 - Polish printout
 - test polishing
 - more comments from stefank
 - comments from stefank

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/ae782dda..23ef68fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=00-01

  Stats: 54 lines in 10 files changed: 35 ins; 8 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From erikj at openjdk.org  Fri Oct 10 14:09:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Oct 2025 14:09:39 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK
In-Reply-To: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
Message-ID: <ll3zzmw8wgn_SiwHSZ5LcnoUtUOccDFp71ElAL59F08=.08a4edfd-c78c-445b-97f5-3752c7ee28e7@github.com>

On Fri, 10 Oct 2025 11:40:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we dump an archive in the configure process, this might not be needed/beneficial any more.
> 
> Building with and without the change on Linux x86_64 (product)  shows similar build times.

make/autoconf/boot-jdk.m4 line 431:

> 429: 
> 430:   # Otherwise optimistically use the system-wide one, if one is present
> 431:   UTIL_ADD_JVM_ARG_IF_OK([-Xshare:auto],boot_jdk_jvmargs,[$JAVA])

I don't think this is needed. The default archive should be picked up automatically without an option needed. I also tried a build with and without your patch, as well as without this line, and they were all similar enough. Also, there is an extra newline above this block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27741#discussion_r2420417152

From mbaesken at openjdk.org  Fri Oct 10 14:42:48 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Oct 2025 14:42:48 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK [v2]
In-Reply-To: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
Message-ID: <FfLxpSKLhzVdv60sR7BT1R6crILW9vb6fTFWjt66a6I=.e5980e0e-b6fb-4422-87f4-c4c4f8530cfb@github.com>

> Currently we dump an archive in the configure process, this might not be needed/beneficial any more.
> 
> Building with and without the change on Linux x86_64 (product)  shows similar build times.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Remove -Xshare settings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27741/files
  - new: https://git.openjdk.org/jdk/pull/27741/files/9c513c97..5002d9fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27741&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27741&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27741.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27741/head:pull/27741

PR: https://git.openjdk.org/jdk/pull/27741

From mbaesken at openjdk.org  Fri Oct 10 14:45:37 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Oct 2025 14:45:37 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK [v2]
In-Reply-To: <FfLxpSKLhzVdv60sR7BT1R6crILW9vb6fTFWjt66a6I=.e5980e0e-b6fb-4422-87f4-c4c4f8530cfb@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
 <FfLxpSKLhzVdv60sR7BT1R6crILW9vb6fTFWjt66a6I=.e5980e0e-b6fb-4422-87f4-c4c4f8530cfb@github.com>
Message-ID: <35KCZic3ILa0Q1Jb2wGX75oaxFynaPGWzOOi2PSqTGw=.7eb4cd96-6332-4d20-94a6-e1231f1bc7cd@github.com>

On Fri, 10 Oct 2025 14:42:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we dump an archive in the configure process, this might not be needed/beneficial any more.
>> 
>> Building with and without the change on Linux x86_64 (product)  shows similar build times.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove -Xshare settings

Should we remove this too ? 


autoconf/bootcycle-spec.gmk.template-47-# Any CDS settings generated for the bootjdk are invalid in the bootcycle build.
autoconf/bootcycle-spec.gmk.template-48-# By filtering out those JVM args, the bootcycle JVM will use its default
autoconf/bootcycle-spec.gmk.template-49-# settings for CDS.
autoconf/bootcycle-spec.gmk.template:50:JAVA_FLAGS := $(filter-out -XX:SharedArchiveFile% -Xshare%, $(JAVA_FLAGS))

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27741#issuecomment-3390546972

From cstein at openjdk.org  Fri Oct 10 15:13:56 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 10 Oct 2025 15:13:56 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <qJI-1Ab3I1HRm_e7nZ-JdpPPuWpaoJtK9GvXGYiQ-Rs=.9f9452fa-5034-4a46-b406-b22250ecb00c@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Usually @shipilev is kind and quick to provide them here: https://builds.shipilev.net/jtreg/

Mind his warning and motto, though:
> WARNING: These artifacts are not well-tested, not virus-checked, may contain horrible bugs that could lead to data corruption, engulfing machines in flames, sharing your financial data, selling your pets on eBay, etc. etc. etc. everything that applies for binaries^W code^W anything downloaded from the Internet. Be cautious. If in doubt, build from the source yourself, and/or run on staging environment that is not painful to restore.
>

> Our motto: "[builds.shipilev.net](https://builds.shipilev.net/) ? still more secure than npm install"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27719#issuecomment-3390690779

From erikj at openjdk.org  Fri Oct 10 16:37:43 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Oct 2025 16:37:43 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK [v2]
In-Reply-To: <35KCZic3ILa0Q1Jb2wGX75oaxFynaPGWzOOi2PSqTGw=.7eb4cd96-6332-4d20-94a6-e1231f1bc7cd@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
 <FfLxpSKLhzVdv60sR7BT1R6crILW9vb6fTFWjt66a6I=.e5980e0e-b6fb-4422-87f4-c4c4f8530cfb@github.com>
 <35KCZic3ILa0Q1Jb2wGX75oaxFynaPGWzOOi2PSqTGw=.7eb4cd96-6332-4d20-94a6-e1231f1bc7cd@github.com>
Message-ID: <tzHEho0p-q0tjPD2GlHb2P-tpyL9r2BmJC9PfX9uzDo=.faef8885-a8db-4445-8414-e9b45278f759@github.com>

On Fri, 10 Oct 2025 14:43:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Should we remove this too ?
> 
> ```
> autoconf/bootcycle-spec.gmk.template-47-# Any CDS settings generated for the bootjdk are invalid in the bootcycle build.
> autoconf/bootcycle-spec.gmk.template-48-# By filtering out those JVM args, the bootcycle JVM will use its default
> autoconf/bootcycle-spec.gmk.template-49-# settings for CDS.
> autoconf/bootcycle-spec.gmk.template:50:JAVA_FLAGS := $(filter-out -XX:SharedArchiveFile% -Xshare%, $(JAVA_FLAGS))
> ```

Yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27741#issuecomment-3391099158

From duke at openjdk.org  Fri Oct 10 19:52:04 2025
From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac)
Date: Fri, 10 Oct 2025 19:52:04 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
Message-ID: <cDlEVow4k_cWVUudiUd_sbiSEpebCLP580ZywK5yKao=.c33d2a31-316e-4d79-8b43-ef8429a703dc@github.com>

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

test/micro/org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java line 89:

> 87: 
> 88:     @Benchmark
> 89:     public int lowerrCF() {

Suggestion:

    public int lowerCF() {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2421934368

From kim.barrett at oracle.com  Sat Oct 11 15:41:13 2025
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 11 Oct 2025 11:41:13 -0400
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <WWuvmG4xgHdPyGLGc9qevYrVkZ6PBb3qYPsThvyFMNg=.726dd880-32d9-43be-b517-3b1649060bd0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <WWuvmG4xgHdPyGLGc9qevYrVkZ6PBb3qYPsThvyFMNg=.726dd880-32d9-43be-b517-3b1649060bd0@github.com>
Message-ID: <154ed38b-841a-4199-bbb1-0bafecdbd40f@oracle.com>

On 10/8/25 8:06 AM, Julian Waters wrote:
>> Paging with the mailing list bridge to restart discussion, which I need in order to be able to continue working on this

As I've said before, we (Oracle) think LTO support is a substantial project,
we haven't made it a priority, and nobody here has offered up time to work on
it. Someone else might have time for this; we don't seem to. That might change
in the future, but for now...

Some of the issues that make it a substantial project include:

The LTO vs flattening problem.

There are functions that assume (or even rely upon) implicit noinline via
being in a different translation unit from callers. I think that's probably a
much harder problem to resolve, since it's generally not obvious. Functions
that do things like getting the current stack pointer or frame pointer may be
relevant? Not sure what else.

Build time issues, and their impact on development time and testing resources.

Is LTO an alternative mode, different from how things are "normally" done?
That increases testing resource requirements, else it will bit rot.

There might be others that I'm not remembering or I'm completely unaware of.


From jwaters at openjdk.org  Sat Oct 11 16:28:06 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Oct 2025 16:28:06 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers
In-Reply-To: <154ed38b-841a-4199-bbb1-0bafecdbd40f@oracle.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <154ed38b-841a-4199-bbb1-0bafecdbd40f@oracle.com>
Message-ID: <HtK1pb08qwWlskTyNBhssAR80-edNEbZQ4I9AhO6P6U=.ced4fb98-a529-4902-8b1d-815316a08793@github.com>

On Sat, 11 Oct 2025 15:42:53 GMT, Kim Barrett <kim.barrett at oracle.com> wrote:

> The LTO vs flattening problem.

Currently that seems to be the biggest problem, I do have solutions for other smaller issues with LTO, but from what I witness the flattening problem has to be solved first before any more work can be done with LTO. While I fortunately do have time to spare to try working on the issue (I'm that "Someone else", more or less), I less fortunately don't have the knowledge required to fix that problem, as even though only G1 uses flattening, the call hierarchy is too massive to actually meaningfully discern which calls need to be flattened and which calls shouldn't be flattened. Not very sure if anyone knows which code paths shouldn't be inlined within g1ParScanThreadState.cpp, actually. If anyone knew, I could fast track the flattening issue on my end and have it solved pretty quickly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3393474226

From mbaesken at openjdk.org  Mon Oct 13 07:09:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 13 Oct 2025 07:09:41 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK [v3]
In-Reply-To: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
Message-ID: <Lrvl2cyTqXkqiYEMzZoZZORXmSZW7oF7Wf8HWPrE1ZY=.c7fc2d7b-1c6f-4481-9d7a-9d51b85c546c@github.com>

> Currently we dump an archive in the configure process, this might not be needed/beneficial any more.
> 
> Building with and without the change on Linux x86_64 (product)  shows similar build times.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup bootcycle-spec.gmk.template

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27741/files
  - new: https://git.openjdk.org/jdk/pull/27741/files/5002d9fe..ead36703

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27741&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27741&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27741.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27741/head:pull/27741

PR: https://git.openjdk.org/jdk/pull/27741

From mbaesken at openjdk.org  Mon Oct 13 07:09:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 13 Oct 2025 07:09:43 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK [v2]
In-Reply-To: <tzHEho0p-q0tjPD2GlHb2P-tpyL9r2BmJC9PfX9uzDo=.faef8885-a8db-4445-8414-e9b45278f759@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
 <FfLxpSKLhzVdv60sR7BT1R6crILW9vb6fTFWjt66a6I=.e5980e0e-b6fb-4422-87f4-c4c4f8530cfb@github.com>
 <35KCZic3ILa0Q1Jb2wGX75oaxFynaPGWzOOi2PSqTGw=.7eb4cd96-6332-4d20-94a6-e1231f1bc7cd@github.com>
 <tzHEho0p-q0tjPD2GlHb2P-tpyL9r2BmJC9PfX9uzDo=.faef8885-a8db-4445-8414-e9b45278f759@github.com>
Message-ID: <xbzgUa7hKxGT9om6Q_MqfJdSQy8VNp4EGTwTTUksT5U=.f9ab0199-c5d6-43c1-857e-7cecef48c273@github.com>

On Fri, 10 Oct 2025 16:35:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Should we remove this too ?
> > ```
> > autoconf/bootcycle-spec.gmk.template-47-# Any CDS settings generated for the bootjdk are invalid in the bootcycle build.
> > autoconf/bootcycle-spec.gmk.template-48-# By filtering out those JVM args, the bootcycle JVM will use its default
> > autoconf/bootcycle-spec.gmk.template-49-# settings for CDS.
> > autoconf/bootcycle-spec.gmk.template:50:JAVA_FLAGS := $(filter-out -XX:SharedArchiveFile% -Xshare%, $(JAVA_FLAGS))
> > ```
> 
> Yes.

Done!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27741#issuecomment-3396125860

From jpai at openjdk.org  Mon Oct 13 11:14:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 Oct 2025 11:14:08 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <RTx-AAwtz37KRyTmKChREbrWrQBIiW14P86H5hp1DGQ=.2edbc9f8-b68f-4333-859e-257c3d012ebd@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3331114106

From jkern at openjdk.org  Mon Oct 13 11:45:48 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 13 Oct 2025 11:45:48 GMT
Subject: RFR: 8369657: [AIX] TOC overflow in static-launcher build when
 building slowdebug after JDK-8352064
Message-ID: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>

When building 'make all' on AIX / slowdebug the build fails :

ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
ld: 0711-781 ERROR: TOC overflow. TOC size: 646240 Maximum size: 65536
.ibm-clang: error: linker command failed with exit code 12 (use -v to see invocation)
gmake[3]: *** [StaticLibs.gmk:125: /build_slowdebug/support/static-native/launcher/java] Error 12
gmake[2]: *** [make/Main.gmk:464: static-launcher] Error 2
This is because after introducing the static-launcher for AIX with [JDK-8352064](https://bugs.openjdk.org/browse/JDK-8352064) the slowdebug build was not tested. The fastdebug or release build optimizes the not needed stuff away, while the real debug build keeps it running out of TOC space.

-------------

Commit messages:
 - JDK-8369657

Changes: https://git.openjdk.org/jdk/pull/27767/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27767&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369657
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27767/head:pull/27767

PR: https://git.openjdk.org/jdk/pull/27767

From mbaesken at openjdk.org  Mon Oct 13 11:51:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 13 Oct 2025 11:51:29 GMT
Subject: RFR: 8369657: [AIX] TOC overflow in static-launcher build when
 building slowdebug after JDK-8352064
In-Reply-To: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
References: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
Message-ID: <igqnrHU6RDJ4R-cmplsQNJveEBspmqN0W-cFSTVt5_4=.09ed2476-92c1-488f-a96c-868aed39250a@github.com>

On Mon, 13 Oct 2025 11:37:29 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> When building 'make all' on AIX / slowdebug the build fails :
> 
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> ld: 0711-781 ERROR: TOC overflow. TOC size: 646240 Maximum size: 65536
> .ibm-clang: error: linker command failed with exit code 12 (use -v to see invocation)
> gmake[3]: *** [StaticLibs.gmk:125: /build_slowdebug/support/static-native/launcher/java] Error 12
> gmake[2]: *** [make/Main.gmk:464: static-launcher] Error 2
> This is because after introducing the static-launcher for AIX with [JDK-8352064](https://bugs.openjdk.org/browse/JDK-8352064) the slowdebug build was not tested. The fastdebug or release build optimizes the not needed stuff away, while the real debug build keeps it running out of TOC space.

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27767#pullrequestreview-3331278567

From erikj at openjdk.org  Mon Oct 13 13:04:43 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Oct 2025 13:04:43 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK [v3]
In-Reply-To: <Lrvl2cyTqXkqiYEMzZoZZORXmSZW7oF7Wf8HWPrE1ZY=.c7fc2d7b-1c6f-4481-9d7a-9d51b85c546c@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
 <Lrvl2cyTqXkqiYEMzZoZZORXmSZW7oF7Wf8HWPrE1ZY=.c7fc2d7b-1c6f-4481-9d7a-9d51b85c546c@github.com>
Message-ID: <l8gze_zg3rd0JBBXJXYp9qpNgZvzEw_uWmjIDfZal-8=.31072ce6-773e-4d5d-aac0-604cd8be900b@github.com>

On Mon, 13 Oct 2025 07:09:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we dump an archive in the configure process, this might not be needed/beneficial any more.
>> 
>> Building with and without the change on Linux x86_64 (product)  shows similar build times.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup bootcycle-spec.gmk.template

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27741#pullrequestreview-3331549703

From erikj at openjdk.org  Mon Oct 13 13:14:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Oct 2025 13:14:15 GMT
Subject: RFR: 8369657: [AIX] TOC overflow in static-launcher build when
 building slowdebug after JDK-8352064
In-Reply-To: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
References: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
Message-ID: <0Qs8u97G1iBQbvvHokb4dZ55klHfA3IJhUR7p_AzG6M=.c7d8c6f9-4c57-4096-be2d-baa531b057ae@github.com>

On Mon, 13 Oct 2025 11:37:29 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> When building 'make all' on AIX / slowdebug the build fails :
> 
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> ld: 0711-781 ERROR: TOC overflow. TOC size: 646240 Maximum size: 65536
> .ibm-clang: error: linker command failed with exit code 12 (use -v to see invocation)
> gmake[3]: *** [StaticLibs.gmk:125: /build_slowdebug/support/static-native/launcher/java] Error 12
> gmake[2]: *** [make/Main.gmk:464: static-launcher] Error 2
> This is because after introducing the static-launcher for AIX with [JDK-8352064](https://bugs.openjdk.org/browse/JDK-8352064) the slowdebug build was not tested. The fastdebug or release build optimizes the not needed stuff away, while the real debug build keeps it running out of TOC space.

make/StaticLibs.gmk line 121:

> 119: ifeq ($(DEBUG_LEVEL), slowdebug)
> 120:   STATIC_LIBS += -Wl,-bbigtoc
> 121: endif

Please fix indentation. It took me way too long to realize this code was actually inside the aix block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27767#discussion_r2426313943

From jkern at openjdk.org  Mon Oct 13 13:28:10 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 13 Oct 2025 13:28:10 GMT
Subject: RFR: 8369657: [AIX] TOC overflow in static-launcher build when
 building slowdebug after JDK-8352064 [v2]
In-Reply-To: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
References: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
Message-ID: <ePMPmLC4tPtONE1-9kiMBaNDYJRLMibQQdhXHA9JXy0=.010c2b58-c42f-4971-9a89-36598b830154@github.com>

> When building 'make all' on AIX / slowdebug the build fails :
> 
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> ld: 0711-781 ERROR: TOC overflow. TOC size: 646240 Maximum size: 65536
> .ibm-clang: error: linker command failed with exit code 12 (use -v to see invocation)
> gmake[3]: *** [StaticLibs.gmk:125: /build_slowdebug/support/static-native/launcher/java] Error 12
> gmake[2]: *** [make/Main.gmk:464: static-launcher] Error 2
> This is because after introducing the static-launcher for AIX with [JDK-8352064](https://bugs.openjdk.org/browse/JDK-8352064) the slowdebug build was not tested. The fastdebug or release build optimizes the not needed stuff away, while the real debug build keeps it running out of TOC space.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27767/files
  - new: https://git.openjdk.org/jdk/pull/27767/files/ecebf299..05707906

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27767&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27767&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27767/head:pull/27767

PR: https://git.openjdk.org/jdk/pull/27767

From mdoerr at openjdk.org  Mon Oct 13 13:35:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 13 Oct 2025 13:35:46 GMT
Subject: RFR: 8369657: [AIX] TOC overflow in static-launcher build when
 building slowdebug after JDK-8352064 [v2]
In-Reply-To: <ePMPmLC4tPtONE1-9kiMBaNDYJRLMibQQdhXHA9JXy0=.010c2b58-c42f-4971-9a89-36598b830154@github.com>
References: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
 <ePMPmLC4tPtONE1-9kiMBaNDYJRLMibQQdhXHA9JXy0=.010c2b58-c42f-4971-9a89-36598b830154@github.com>
Message-ID: <um7FH2Ri-ELikqVmve61H11--tJenfBlo3tOnyZfIqQ=.67ea7830-00c9-4d0c-8c84-f38655832463@github.com>

On Mon, 13 Oct 2025 13:28:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> When building 'make all' on AIX / slowdebug the build fails :
>> 
>> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
>> ld: 0711-781 ERROR: TOC overflow. TOC size: 646240 Maximum size: 65536
>> .ibm-clang: error: linker command failed with exit code 12 (use -v to see invocation)
>> gmake[3]: *** [StaticLibs.gmk:125: /build_slowdebug/support/static-native/launcher/java] Error 12
>> gmake[2]: *** [make/Main.gmk:464: static-launcher] Error 2
>> This is because after introducing the static-launcher for AIX with [JDK-8352064](https://bugs.openjdk.org/browse/JDK-8352064) the slowdebug build was not tested. The fastdebug or release build optimizes the not needed stuff away, while the real debug build keeps it running out of TOC space.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27767#pullrequestreview-3331658780

From erikj at openjdk.org  Mon Oct 13 13:35:46 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Oct 2025 13:35:46 GMT
Subject: RFR: 8369657: [AIX] TOC overflow in static-launcher build when
 building slowdebug after JDK-8352064 [v2]
In-Reply-To: <ePMPmLC4tPtONE1-9kiMBaNDYJRLMibQQdhXHA9JXy0=.010c2b58-c42f-4971-9a89-36598b830154@github.com>
References: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
 <ePMPmLC4tPtONE1-9kiMBaNDYJRLMibQQdhXHA9JXy0=.010c2b58-c42f-4971-9a89-36598b830154@github.com>
Message-ID: <_Z8MTLU7b35Kf8UIO6I2jmeBcKgnRynLChypBpXclrs=.97baf8c2-5b75-4965-abcb-7e2050672abd@github.com>

On Mon, 13 Oct 2025 13:28:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> When building 'make all' on AIX / slowdebug the build fails :
>> 
>> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
>> ld: 0711-781 ERROR: TOC overflow. TOC size: 646240 Maximum size: 65536
>> .ibm-clang: error: linker command failed with exit code 12 (use -v to see invocation)
>> gmake[3]: *** [StaticLibs.gmk:125: /build_slowdebug/support/static-native/launcher/java] Error 12
>> gmake[2]: *** [make/Main.gmk:464: static-launcher] Error 2
>> This is because after introducing the static-launcher for AIX with [JDK-8352064](https://bugs.openjdk.org/browse/JDK-8352064) the slowdebug build was not tested. The fastdebug or release build optimizes the not needed stuff away, while the real debug build keeps it running out of TOC space.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27767#pullrequestreview-3331664711

From syan at openjdk.org  Mon Oct 13 14:07:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 13 Oct 2025 14:07:56 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <yX2LuOCWrBHmNJmSLRm8yJLW_03I3QS6aTbzTpWatQw=.5e2349a9-c189-4e26-8a8d-ed38bd4c2a05@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

I have run the tests with jtreg8.1, and there is no new failure.

-------------

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3331786495

From jpai at openjdk.org  Tue Oct 14 04:12:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 14 Oct 2025 04:12:07 GMT
Subject: RFR: 8367157: Remove jrunscript tool [v2]
In-Reply-To: <scwn2-8hzk7SIOg2-jVQFyAqF9kdIgfFmLsXwhjAPnw=.ebafb503-934d-4b9d-87d8-ac1b9c59eb51@github.com>
References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
 <scwn2-8hzk7SIOg2-jVQFyAqF9kdIgfFmLsXwhjAPnw=.ebafb503-934d-4b9d-87d8-ac1b9c59eb51@github.com>
Message-ID: <DWJbufDzS999gVOpyADaF7CkIS6eSkF89lJaEvBpW2A=.bb4ef539-6ec6-4458-aa7e-7efbb91c4a15@github.com>

On Tue, 7 Oct 2025 09:23:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157.
>> 
>> `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests.
>> 
>> tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note.
>
> Jaikiran Pai 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 five additional commits since the last revision:
> 
>  - merge latest from master branch
>  - remove tests for jrunscript
>  - remove jrunscript implementation
>  - remove references from tests
>  - remove man page for jrunscript

Thank you everyone for the reviews. The CSR has been approved. I'll go ahead with the integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27163#issuecomment-3400036193

From clanger at openjdk.org  Tue Oct 14 04:14:04 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 14 Oct 2025 04:14:04 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK [v3]
In-Reply-To: <Lrvl2cyTqXkqiYEMzZoZZORXmSZW7oF7Wf8HWPrE1ZY=.c7fc2d7b-1c6f-4481-9d7a-9d51b85c546c@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
 <Lrvl2cyTqXkqiYEMzZoZZORXmSZW7oF7Wf8HWPrE1ZY=.c7fc2d7b-1c6f-4481-9d7a-9d51b85c546c@github.com>
Message-ID: <iiAdgOYeqPkoizBI34t1zONWoz4vQ9bNVszUU92hq1g=.d3d5ae06-9a05-4dd6-95ab-43fe25c93129@github.com>

On Mon, 13 Oct 2025 07:09:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we dump an archive in the configure process, this might not be needed/beneficial any more.
>> 
>> Building with and without the change on Linux x86_64 (product)  shows similar build times.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup bootcycle-spec.gmk.template

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27741#pullrequestreview-3333836852

From clanger at openjdk.org  Tue Oct 14 04:16:04 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 14 Oct 2025 04:16:04 GMT
Subject: RFR: 8369657: [AIX] TOC overflow in static-launcher build when
 building slowdebug after JDK-8352064 [v2]
In-Reply-To: <ePMPmLC4tPtONE1-9kiMBaNDYJRLMibQQdhXHA9JXy0=.010c2b58-c42f-4971-9a89-36598b830154@github.com>
References: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
 <ePMPmLC4tPtONE1-9kiMBaNDYJRLMibQQdhXHA9JXy0=.010c2b58-c42f-4971-9a89-36598b830154@github.com>
Message-ID: <vBDCmW6Z-pKj7nRFDNglYanJDREetr5v5vIsGXvG0ZQ=.c93f626c-5131-455f-a7d9-c7c2def7497b@github.com>

On Mon, 13 Oct 2025 13:28:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> When building 'make all' on AIX / slowdebug the build fails :
>> 
>> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
>> ld: 0711-781 ERROR: TOC overflow. TOC size: 646240 Maximum size: 65536
>> .ibm-clang: error: linker command failed with exit code 12 (use -v to see invocation)
>> gmake[3]: *** [StaticLibs.gmk:125: /build_slowdebug/support/static-native/launcher/java] Error 12
>> gmake[2]: *** [make/Main.gmk:464: static-launcher] Error 2
>> This is because after introducing the static-launcher for AIX with [JDK-8352064](https://bugs.openjdk.org/browse/JDK-8352064) the slowdebug build was not tested. The fastdebug or release build optimizes the not needed stuff away, while the real debug build keeps it running out of TOC space.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27767#pullrequestreview-3333839234

From jpai at openjdk.org  Tue Oct 14 06:13:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 14 Oct 2025 06:13:18 GMT
Subject: Integrated: 8367157: Remove jrunscript tool
In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
Message-ID: <44aNxQVFVat-ckzbYc-GUoxHvcERoKgB05VTf47fyWk=.9b8db04c-73d5-4b19-aa29-29d44f6d80e2@github.com>

On Tue, 9 Sep 2025 07:18:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157.
> 
> `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests.
> 
> tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note.

This pull request has now been integrated.

Changeset: 2eb0898f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2eb0898fef7b7fef7285b7ee1837b73336b9f7be
Stats:     2364 lines in 24 files changed: 0 ins; 2360 del; 4 mod

8367157: Remove jrunscript tool

Reviewed-by: erikj, ayang, ihse, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/27163

From mbaesken at openjdk.org  Tue Oct 14 07:31:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 14 Oct 2025 07:31:17 GMT
Subject: RFR: 8369305: Adjust usage of CDS in the boot JDK [v3]
In-Reply-To: <Lrvl2cyTqXkqiYEMzZoZZORXmSZW7oF7Wf8HWPrE1ZY=.c7fc2d7b-1c6f-4481-9d7a-9d51b85c546c@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
 <Lrvl2cyTqXkqiYEMzZoZZORXmSZW7oF7Wf8HWPrE1ZY=.c7fc2d7b-1c6f-4481-9d7a-9d51b85c546c@github.com>
Message-ID: <EvBz-sfUhxkwV00m4E-uUlznAINfrrq3893gQ6-aQf4=.7847f2df-7ac6-4f16-9151-b66da58db638@github.com>

On Mon, 13 Oct 2025 07:09:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we dump an archive in the configure process, this might not be needed/beneficial any more.
>> 
>> Building with and without the change on Linux x86_64 (product)  shows similar build times.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup bootcycle-spec.gmk.template

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27741#issuecomment-3400465639

From mbaesken at openjdk.org  Tue Oct 14 07:31:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 14 Oct 2025 07:31:18 GMT
Subject: Integrated: 8369305: Adjust usage of CDS in the boot JDK
In-Reply-To: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
References: <FVAGwRoPpXfDXNlNUUTADkmnbyJ1mNkoEqC8-wk52VY=.e5b258d5-5fa5-4f19-8b69-0adafdc11379@github.com>
Message-ID: <QWT2iQRMVXKxv6RWeOeh2om37anaVUBc2zdi9HBt4Jo=.7db47176-dfdd-40fe-942b-5cdb84c1576b@github.com>

On Fri, 10 Oct 2025 11:40:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we dump an archive in the configure process, this might not be needed/beneficial any more.
> 
> Building with and without the change on Linux x86_64 (product)  shows similar build times.

This pull request has now been integrated.

Changeset: a3ee821f
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3ee821f38d0d04f982465f5157170249c92cc49
Stats:     33 lines in 2 files changed: 0 ins; 33 del; 0 mod

8369305: Adjust usage of CDS in the boot JDK

Reviewed-by: erikj, clanger

-------------

PR: https://git.openjdk.org/jdk/pull/27741

From tschatzl at openjdk.org  Tue Oct 14 07:40:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 07:40:38 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
Message-ID: <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>

> Hi all,
> 
>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * remove more g1freeidset.cpp references from makefiles

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27786/files
  - new: https://git.openjdk.org/jdk/pull/27786/files/537b137b..f08118b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27786&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27786&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27786/head:pull/27786

PR: https://git.openjdk.org/jdk/pull/27786

From sjohanss at openjdk.org  Tue Oct 14 07:40:39 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 14 Oct 2025 07:40:39 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
Message-ID: <nWfIJ3Y2tHXWSFuvlZtbITEY777oeYkkh4DHMQWKIoE=.ff97a8fd-e26b-4047-a819-ebfdf2ffb498@github.com>

On Tue, 14 Oct 2025 07:37:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove more g1freeidset.cpp references from makefiles

Marked as reviewed by sjohanss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27786#pullrequestreview-3334277538

From kbarrett at openjdk.org  Tue Oct 14 08:40:18 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Oct 2025 08:40:18 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
Message-ID: <yFkSezw4eYYuPzuFF6b7S7ulsIn0zPcIrPSGvhz_09w=.2745e0eb-a2e0-49a0-9abf-d56190434d8e@github.com>

On Tue, 14 Oct 2025 07:40:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove more g1freeidset.cpp references from makefiles

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27786#pullrequestreview-3334513091

From cstein at openjdk.org  Tue Oct 14 08:57:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 14 Oct 2025 08:57:51 GMT
Subject: Integrated: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <byRybe7y0ps0If8AgyIT1AR0OspYl6T2dJrqtKvEjuI=.e2bdd8ac-d0fa-4faa-95a6-a9ce92de25e6@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

This pull request has now been integrated.

Changeset: 702179e7
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/702179e7858bae1c7c13ad6eda3c4fbffdbb15db
Stats:     11 lines in 9 files changed: 0 ins; 0 del; 11 mod

8369488: Update to use jtreg 8.1

Reviewed-by: iris, erikj, jpai, syan

-------------

PR: https://git.openjdk.org/jdk/pull/27719

From jkern at openjdk.org  Tue Oct 14 14:07:57 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 14 Oct 2025 14:07:57 GMT
Subject: Integrated: 8369657: [AIX] TOC overflow in static-launcher build when
 building slowdebug after JDK-8352064
In-Reply-To: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
References: <s_fr2x8JYho0d2Dry-dmRp434Smxw-e3fSN14Iuc-RU=.2ea45187-ba0b-4929-9312-9f53bc812e63@github.com>
Message-ID: <tjgsKRIgoV98sox0SkHYpr2vYC5eoGqJGV8hzNsvrZw=.c21a31c6-8cd9-4a1a-a45a-a35dc81f0279@github.com>

On Mon, 13 Oct 2025 11:37:29 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> When building 'make all' on AIX / slowdebug the build fails :
> 
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> ld: 0711-781 ERROR: TOC overflow. TOC size: 646240 Maximum size: 65536
> .ibm-clang: error: linker command failed with exit code 12 (use -v to see invocation)
> gmake[3]: *** [StaticLibs.gmk:125: /build_slowdebug/support/static-native/launcher/java] Error 12
> gmake[2]: *** [make/Main.gmk:464: static-launcher] Error 2
> This is because after introducing the static-launcher for AIX with [JDK-8352064](https://bugs.openjdk.org/browse/JDK-8352064) the slowdebug build was not tested. The fastdebug or release build optimizes the not needed stuff away, while the real debug build keeps it running out of TOC space.

This pull request has now been integrated.

Changeset: 4b85ba90
Author:    Joachim Kern <jkern at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b85ba90671c0ac816a772584c3eeb30ef9062ba
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8369657: [AIX] TOC overflow in static-launcher build when building slowdebug after JDK-8352064

Reviewed-by: mdoerr, erikj, clanger, mbaesken

-------------

PR: https://git.openjdk.org/jdk/pull/27767

From duke at openjdk.org  Tue Oct 14 19:59:54 2025
From: duke at openjdk.org (Daniel Hu)
Date: Tue, 14 Oct 2025 19:59:54 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once [v5]
In-Reply-To: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
Message-ID: <Q-D6eJtg-Mv_9KOYEmcWetTUkJ5Uc6CY6iM9sb8XXr8=.0a409bef-3be3-4a2d-ba88-8733f835e669@github.com>

> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.

Daniel Hu 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 11 additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8341735
 - syntax fixes
 - implement KMP
 - refactor logic
 - speedup scanBytes
 - Merge branch 'openjdk:master' into 8341735
 - redid byte matching which should fix cross chunk strings
 - style improvements
 - remove 8341024
 - remove trailing whitespace
 - ... and 1 more: https://git.openjdk.org/jdk/compare/25296754...82a4cc91

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26030/files
  - new: https://git.openjdk.org/jdk/pull/26030/files/c3d7a77b..82a4cc91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26030&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26030&range=03-04

  Stats: 323209 lines in 5120 files changed: 228779 ins; 64158 del; 30272 mod
  Patch: https://git.openjdk.org/jdk/pull/26030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26030/head:pull/26030

PR: https://git.openjdk.org/jdk/pull/26030

From duke at openjdk.org  Tue Oct 14 21:53:41 2025
From: duke at openjdk.org (Daniel Hu)
Date: Tue, 14 Oct 2025 21:53:41 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once [v6]
In-Reply-To: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
Message-ID: <pWRMqZCqEUGGBc6oqRwqGzP162gg6yt3IUHhW6cDr_U=.a078b959-058b-4a37-bd88-4a01fb503f59@github.com>

> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.

Daniel Hu has updated the pull request incrementally with two additional commits since the last revision:

 - fix incorrect use of inputstream
 - remove extraneous variables/imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26030/files
  - new: https://git.openjdk.org/jdk/pull/26030/files/82a4cc91..6a72a163

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26030&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26030&range=04-05

  Stats: 46 lines in 1 file changed: 33 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26030/head:pull/26030

PR: https://git.openjdk.org/jdk/pull/26030

From stefank at openjdk.org  Wed Oct 15 05:41:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 15 Oct 2025 05:41:02 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
Message-ID: <s_WfJqK62lIWu5l4llBjOwuDAzkb60MKzZQbMqIeVE0=.6a9b329e-5063-4396-9625-2587dc5ebd95@github.com>

On Tue, 14 Oct 2025 07:40:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove more g1freeidset.cpp references from makefiles

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27786#pullrequestreview-3338432500

From tschatzl at openjdk.org  Wed Oct 15 11:29:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 11:29:52 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <s_WfJqK62lIWu5l4llBjOwuDAzkb60MKzZQbMqIeVE0=.6a9b329e-5063-4396-9625-2587dc5ebd95@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
 <s_WfJqK62lIWu5l4llBjOwuDAzkb60MKzZQbMqIeVE0=.6a9b329e-5063-4396-9625-2587dc5ebd95@github.com>
Message-ID: <c4kOPa1OvUVBIqz4GLuhiosb76uLncq7J4XuaRQ-mFQ=.6306fb41-7ade-4bc7-9aaa-6276928d192c@github.com>

On Wed, 15 Oct 2025 05:38:22 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * remove more g1freeidset.cpp references from makefiles
>
> Marked as reviewed by stefank (Reviewer).

Thanks @stefank @kimbarrett @kstefanj for your reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27786#issuecomment-3405939890

From tschatzl at openjdk.org  Wed Oct 15 11:29:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 11:29:53 GMT
Subject: Integrated: 8369793: G1: Remove unused G1FreeIdSet
In-Reply-To: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
Message-ID: <Pke5BZm0vW3-N30atcZNVSz1rxbhj9TaKeuxSoJjAxU=.197fb223-a9ed-4636-a839-002680f0509e@github.com>

On Tue, 14 Oct 2025 06:59:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 1af37e5c
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1af37e5c3f7ca46561ef4431ac9b779524888e61
Stats:     331 lines in 4 files changed: 0 ins; 331 del; 0 mod

8369793: G1: Remove unused G1FreeIdSet

Reviewed-by: stefank, sjohanss, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/27786

From eosterlund at openjdk.org  Wed Oct 15 15:20:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 15 Oct 2025 15:20:27 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:

 - Dont print error message when there are no archived objects
 - Fix issue in new test
 - Change is_aot_thread implementation
 - update AotJdk problem lists

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/23ef68fb..d6ff880b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=01-02

  Stats: 60 lines in 10 files changed: 28 ins; 4 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From stefank at openjdk.org  Wed Oct 15 20:32:50 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 15 Oct 2025 20:32:50 GMT
Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
In-Reply-To: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
References: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
Message-ID: <r8jzB_YAVj7qciSPbJJGo2CkKeZZBZ_caVCbvwGFOwI=.2e48cc03-ef97-462a-8a17-b3d2011c7d75@github.com>

On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.
> 
> It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.
> 
> Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.
> 
> The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.
> 
> I will run this through Oracle's tier1-tier8 testing.

Tier1-8 testing passed. My intention is to get this integrated tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27721#issuecomment-3408163480

From iklam at openjdk.org  Thu Oct 16 01:36:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Oct 2025 01:36:08 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
Message-ID: <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>

On Wed, 15 Oct 2025 15:20:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Dont print error message when there are no archived objects
>  - Fix issue in new test
>  - Change is_aot_thread implementation
>  - update AotJdk problem lists

Hi Eric, looks very good overall.

I have gone through some of the code and have some comments. More to come.

src/hotspot/share/cds/cds_globals.hpp line 79:

> 77:           "the CDS archive, in the specified file")                         \
> 78:                                                                             \
> 79:   product(bool, AOTStreamableObjects, true,                                 \

The default should be `false`, as that will be the mode that the user will get with no GC options are specified.

src/hotspot/share/cds/heapShared.cpp line 355:

> 353: }
> 354: 
> 355: bool HeapShared::is_loading_mapping_mode() {

I think `is_loading_mapping_mode()` should be removed and we should use only `is_loading_streaming_mode()`. This will make it easy to find all the places that checks between mapping/streaming. Same for `is_writing_xxx_mode()`.

Also, instead of having a tri-state of `_heap_load_mode`, it's better to have two boolean states:

- _is_loading_heap
- _is_loading_heap_streaming_mode

The first boolean is the main switch, but most of the code will be checking only the second boolean.

src/hotspot/share/cds/heapShared.cpp line 410:

> 408:       FLAG_SET_ERGO(AOTStreamableObjects, true);
> 409:       _heap_write_mode = HeapArchiveMode::_streaming;
> 410:       return;

This should be changed to `if (!UseZGC) {`, as all other GCs support writing the "mapping" format.

src/hotspot/share/cds/heapShared.cpp line 418:

> 416: 
> 417:   // Select default mode
> 418:   if (UseG1GC && UseCompressedOops) {

This is different than specified in JEP 516. The condition should be `if (UseCompressedOops)`.

test/hotspot/jtreg/runtime/cds/appcds/TestSerialGCWithCDS.java line 117:

> 115:                               small2,
> 116:                               coops,
> 117:                               "-XX:-AOTStreamableObjects",

Is this change necessary?

test/hotspot/jtreg/runtime/cds/appcds/TestSerialGCWithCDS.java line 147:

> 145:             // Regardless of which GC dumped the heap, there will be an object archive, either
> 146:             // created with mapping if dumped with G1, or streaming if dumped with serial GC.
> 147:             // At exec time, try to load them into a small SerialGC heap that may be too small.

Actually the original check of `dumpWithSerial == false` was obsolete, as SerialGC can also dump heap objects.  `dumpWithSerial == false` should be removed. The first two lines of comments should also be removed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3342741298
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434315273
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434294269
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434328432
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434316323
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434295055
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434331254

From stefank at openjdk.org  Thu Oct 16 11:16:09 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 16 Oct 2025 11:16:09 GMT
Subject: RFR: 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4
In-Reply-To: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
References: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
Message-ID: <Osv0d70kJSG9FOroTtJeBgMBC4EMkA7zkIrnvPLkbN4=.48c15b2e-0e8f-4ae6-bfac-fe06712210e6@github.com>

On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.
> 
> It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.
> 
> Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.
> 
> The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.
> 
> I will run this through Oracle's tier1-tier8 testing.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27721#issuecomment-3410361774

From stefank at openjdk.org  Thu Oct 16 11:19:26 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 16 Oct 2025 11:19:26 GMT
Subject: Integrated: 8369491: Temporarily revert default TIMEOUT_FACTOR back to
 4
In-Reply-To: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
References: <Wis0fFce8d_yDPgiZOvcQJawFkDQIW5ixgdWD5mlMKM=.8c27929a-b7b2-4a37-8978-710b22cb6391@github.com>
Message-ID: <1fWKegMvrCUndpvpe4L_LWftNVcHWKgZ_MLnVTnOr1k=.3f52ec81-3baa-4081-bbce-04932ee45ee2@github.com>

On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our timeouts worked. Together with that small change, we also bumped a number of tests that relied on the previous extended timeout. The anticipation was that there would be some fallout from that change and that we for a short time after it had been integrated would have to tweak some tests that intermittently needed a larger timeout.
> 
> It turns out that the way we run tests concurrently causes the tests to sometimes run in a resource-constrained manner. This has the effect that even simple tests that usually don't take a long time to execute run the risk of hitting the default 120s timeout limit. This invalidates the earlier plan to fix the additional, few tests that now times out, because it's probably not the tests themselves that are the problem, but rather how we run the tests.
> 
> Hunting down the reasons for the new set of timeouts we are seeing is good and figuring out how to fix our testing to not over-strain our testing machines is also something that we want to do. The problem is that there's enough of these timeouts that it affects more than just a limited set of JDK devs.
> 
> The proposal is that we, for now, revert back to the default timeout factor of 4 to relive the pressure to investigate and fix these intermittent timeouts. And revert back to 1 once enough investigation and tweaks have been made to the test infrastructure.
> 
> I will run this through Oracle's tier1-tier8 testing.

This pull request has now been integrated.

Changeset: 5fc3904b
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5fc3904bfe290625ed6cf9b41773b35b52bf72b7
Stats:     4 lines in 3 files changed: 0 ins; 0 del; 4 mod

8369491: Temporarily revert default TIMEOUT_FACTOR back to 4

Reviewed-by: lkorinth, cstein, jpai, syan, serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/27721

From mikael at openjdk.org  Thu Oct 16 17:32:49 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 16 Oct 2025 17:32:49 GMT
Subject: RFR: 8355752: Bump minimum boot jdk to JDK 25 [v2]
In-Reply-To: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
References: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
Message-ID: <5tu3W_hAPrJgyb24nJyexnkdjgAYPJgJu-v2L5GaBhA=.d8c7b001-c23c-4af4-8ff5-39d1321105d5@github.com>

> With the JDK 25 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25.
> 
> Testing: tier1-5, GHA

Mikael Vidstedt 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 'master' into 8355752-bootjdk25
 - 8355752: Bump minimum boot jdk to JDK 25

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27638/files
  - new: https://git.openjdk.org/jdk/pull/27638/files/5e4860f0..5c857a63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27638&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27638&range=00-01

  Stats: 28314 lines in 675 files changed: 18511 ins; 7771 del; 2032 mod
  Patch: https://git.openjdk.org/jdk/pull/27638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27638/head:pull/27638

PR: https://git.openjdk.org/jdk/pull/27638

From mikael at openjdk.org  Thu Oct 16 19:46:34 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 16 Oct 2025 19:46:34 GMT
Subject: RFR: 8355752: Bump minimum boot jdk to JDK 25 [v2]
In-Reply-To: <5tu3W_hAPrJgyb24nJyexnkdjgAYPJgJu-v2L5GaBhA=.d8c7b001-c23c-4af4-8ff5-39d1321105d5@github.com>
References: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
 <5tu3W_hAPrJgyb24nJyexnkdjgAYPJgJu-v2L5GaBhA=.d8c7b001-c23c-4af4-8ff5-39d1321105d5@github.com>
Message-ID: <f8i0updqQLDV2QNDF6QEoMOiv0IJGoWiHvkn9jWITXo=.3b347f47-3850-45ea-a264-3f2ec08857db@github.com>

On Thu, 16 Oct 2025 17:32:49 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> With the JDK 25 GA out it's time to bump the minimum boot JDK version for mainline/JDK 26.
>> 
>> Testing: tier1-5, GHA
>
> Mikael Vidstedt 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 'master' into 8355752-bootjdk25
>  - 8355752: Bump minimum boot jdk to JDK 25

Thank you all for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27638#issuecomment-3412587767

From mikael at openjdk.org  Thu Oct 16 19:46:35 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 16 Oct 2025 19:46:35 GMT
Subject: Integrated: 8355752: Bump minimum boot jdk to JDK 25
In-Reply-To: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
References: <_RACuzK_LJs_b3ixdmFzLEiN7jYGBTyB_-ZkJL6aGTA=.c0ba2c60-ce5d-436e-a045-6e2848398664@github.com>
Message-ID: <F1LWPHntPoY5smkfuQ5ebDfTxSKjNvjyJeg7Ldjg-2U=.74a159fa-b85a-4c67-96e9-b9123ac2ce8a@github.com>

On Sun, 5 Oct 2025 16:54:38 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> With the JDK 25 GA out it's time to bump the minimum boot JDK version for mainline/JDK 26.
> 
> Testing: tier1-5, GHA

This pull request has now been integrated.

Changeset: 9589a29d
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9589a29d2515888b437d382204df22d01d4266ff
Stats:     13 lines in 3 files changed: 0 ins; 0 del; 13 mod

8355752: Bump minimum boot jdk to JDK 25

Reviewed-by: darcy, shade, ihse, iris

-------------

PR: https://git.openjdk.org/jdk/pull/27638

From duke at openjdk.org  Thu Oct 16 23:32:17 2025
From: duke at openjdk.org (Elliot Barlas)
Date: Thu, 16 Oct 2025 23:32:17 GMT
Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v3]
In-Reply-To: <BdBA2MySOivBwzthSF-9RFMqbrQys9uS5whp8V_LAeU=.bbd151a4-6bd6-469a-8c66-68de55e70a39@github.com>
References: <dQWh9W7ZxBAyWboPvuo0NaUoP0O4vFzlBZ-_nYuumSs=.4d988e08-2842-47b9-a89b-1e383d0af161@github.com>
 <nJwlPmJ3Gk2if4dVVQl4695Nrbvz5xnvh5k3Pd229Kk=.9899f4b1-7902-4710-9ed9-c40dc0320adf@github.com>
 <LM_mDAEF_GRb7xWkVqzaGFaTF21l54_1RzArAr1GuLQ=.7c745ca4-bbc9-4e16-a37a-797292f7a8dd@github.com>
 <BdBA2MySOivBwzthSF-9RFMqbrQys9uS5whp8V_LAeU=.bbd151a4-6bd6-469a-8c66-68de55e70a39@github.com>
Message-ID: <qZHT2OaH-scjKnyU7NfkYEyZilMkkxyIuNhm1L950Ms=.9bf65bca-f00e-4a49-9006-6a56471ac44b@github.com>

On Wed, 22 Nov 2023 17:10:06 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> I'm happy with the addition of the JDK built-in catalog, the inclusion of the DTD defined by Java SE, and the docs updates.
>
>> I'm happy with the addition of the JDK built-in catalog, the inclusion of the DTD defined by Java SE, and the docs updates.
> 
> Thanks again, Alan, I really appreciate it! Finally got all pieces together, a nice foundation for the next.

Hi @JoeWang-Java , I believe there is a thread-safety issue with this change.

The change to `XMLEntityManager` introduced a reference to the JDK catalog singleton. Multiple, independent entity managers can, therefore, concurrently access the shared JDK catalog, which is not thread-safe. This can result in invalid data states and unexpected exceptions within the JDK catalog instance.

I sent an email to `core-libs-dev` about this issue yesterday, as well: https://mail.openjdk.org/pipermail/core-libs-dev/2025-October/153319.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16719#issuecomment-3408356230

From sspitsyn at openjdk.org  Fri Oct 17 09:28:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Oct 2025 09:28:05 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
Message-ID: <y-Q3n07-dECqNWVhAJx1rbQzoBaVZzOCk_rXEWisg6g=.90e972ef-d62d-4acf-a47f-fa1442886214@github.com>

On Wed, 15 Oct 2025 15:20:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Dont print error message when there are no archived objects
>  - Fix issue in new test
>  - Change is_aot_thread implementation
>  - update AotJdk problem lists

src/hotspot/share/prims/jvmtiExport.cpp line 1476:

> 1474:     // virtual threads. When exiting it is filtered out due to being hidden.
> 1475:     return;
> 1476:   }

This has to be okay for now.
It can be done in more generic way. For instance, there is a check for `thread->is_hidden_from_external_view()` below which would be nice to have earlier. However, now there is an inconsistency with the flag `is_hidden_from_external_view()` usage we need to address in the near future. So, I'm suggesting to keep this tweak as it is now.
Most likely, we need to make sure other JVMTI events are not posted for this thread as well. I can file a separate JVMTI bug on it if it is okay with you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2439002671

From eosterlund at openjdk.org  Fri Oct 17 14:57:09 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Oct 2025 14:57:09 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v4]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <3DuECXkcrRXiQsS7DmaBxB1AZww_IJr-SbNCcY17uF4=.bc121009-9acc-46b8-8cdf-f0a34fe64e87@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:

 - Test fix
 - move exception marks outside locks
 - Cleanup testing after default change
 - Ioi comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/d6ff880b..0ddc2cc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=02-03

  Stats: 90 lines in 11 files changed: 25 ins; 49 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From eosterlund at openjdk.org  Fri Oct 17 15:03:24 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Oct 2025 15:03:24 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>
Message-ID: <tvNUchlujyuFXlPfDt758DGst7XK1V9hA5kkoFxScS4=.867819a8-fd43-417a-aebe-4186259c791b@github.com>

On Thu, 16 Oct 2025 01:16:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Dont print error message when there are no archived objects
>>  - Fix issue in new test
>>  - Change is_aot_thread implementation
>>  - update AotJdk problem lists
>
> src/hotspot/share/cds/cds_globals.hpp line 79:
> 
>> 77:           "the CDS archive, in the specified file")                         \
>> 78:                                                                             \
>> 79:   product(bool, AOTStreamableObjects, true,                                 \
> 
> The default should be `false`, as that will be the mode that the user will get with no GC options are specified.

Makes sense. Fixed.

> src/hotspot/share/cds/heapShared.cpp line 355:
> 
>> 353: }
>> 354: 
>> 355: bool HeapShared::is_loading_mapping_mode() {
> 
> I think `is_loading_mapping_mode()` should be removed and we should use only `is_loading_streaming_mode()`. This will make it easy to find all the places that checks between mapping/streaming. Same for `is_writing_xxx_mode()`.
> 
> Also, instead of having a tri-state of `_heap_load_mode`, it's better to have two boolean states:
> 
> - _is_loading_heap
> - _is_loading_heap_streaming_mode
> 
> The first boolean is the main switch, but most of the code will be checking only the second boolean.

Okay. @stefank is having a look at fixing this.

> src/hotspot/share/cds/heapShared.cpp line 410:
> 
>> 408:       FLAG_SET_ERGO(AOTStreamableObjects, true);
>> 409:       _heap_write_mode = HeapArchiveMode::_streaming;
>> 410:       return;
> 
> This should be changed to `if (!UseZGC) {`, as all other GCs support writing the "mapping" format.

Fixed.

> src/hotspot/share/cds/heapShared.cpp line 418:
> 
>> 416: 
>> 417:   // Select default mode
>> 418:   if (UseG1GC && UseCompressedOops) {
> 
> This is different than specified in JEP 516. The condition should be `if (UseCompressedOops)`.

Okay, I changed it and cleaned up some comments and code suggesting dumping must be done with G1.

> test/hotspot/jtreg/runtime/cds/appcds/TestSerialGCWithCDS.java line 117:
> 
>> 115:                               small2,
>> 116:                               coops,
>> 117:                               "-XX:-AOTStreamableObjects",
> 
> Is this change necessary?

No, I removed it. Nice catch.

> test/hotspot/jtreg/runtime/cds/appcds/TestSerialGCWithCDS.java line 147:
> 
>> 145:             // Regardless of which GC dumped the heap, there will be an object archive, either
>> 146:             // created with mapping if dumped with G1, or streaming if dumped with serial GC.
>> 147:             // At exec time, try to load them into a small SerialGC heap that may be too small.
> 
> Actually the original check of `dumpWithSerial == false` was obsolete, as SerialGC can also dump heap objects.  `dumpWithSerial == false` should be removed. The first two lines of comments should also be removed.

Okay, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440306099
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440305408
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440309294
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440308642
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440303912
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440309778

From eosterlund at openjdk.org  Fri Oct 17 15:03:26 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Oct 2025 15:03:26 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <y-Q3n07-dECqNWVhAJx1rbQzoBaVZzOCk_rXEWisg6g=.90e972ef-d62d-4acf-a47f-fa1442886214@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <y-Q3n07-dECqNWVhAJx1rbQzoBaVZzOCk_rXEWisg6g=.90e972ef-d62d-4acf-a47f-fa1442886214@github.com>
Message-ID: <ioISb7v72UXZzYWUar9Jmzn0TPjgsrp4K5aEMcMXJRA=.b4b8b887-92d9-468f-af6d-bc37ec5338e6@github.com>

On Fri, 17 Oct 2025 09:25:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Dont print error message when there are no archived objects
>>  - Fix issue in new test
>>  - Change is_aot_thread implementation
>>  - update AotJdk problem lists
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1476:
> 
>> 1474:     // virtual threads. When exiting it is filtered out due to being hidden.
>> 1475:     return;
>> 1476:   }
> 
> This has to be okay for now.
> It can be done in more generic way. For instance, there is a check for `thread->is_hidden_from_external_view()` below which would be nice to have earlier. However, now there is an inconsistency with the flag `is_hidden_from_external_view()` usage we need to address in the near future. So, I'm suggesting to keep this tweak as it is now.
> Most likely, we need to make sure other JVMTI events are not posted for this thread as well. I can file a separate JVMTI bug on it if it is okay with you.

Thanks for the review Serguei! I agree with your assessment. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440313109

From serb at openjdk.org  Fri Oct 17 17:59:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Oct 2025 17:59:09 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
Message-ID: <USXKgcl7grYtjcgrt0fb6JDTFEhlUjcEL9Zov4pr12E=.02afda31-5239-410b-85f7-e7203952a83c@github.com>

On Fri, 10 Jan 2025 13:09:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.
>> 
>> Turns out I didn't wait long enough.  It does terminate after about 40 minutes, though not successfully.  Instead the
>> build crashes with a failed assert:
>> 
>> #  Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=4017588, tid=4017620
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> 
>> I've not tried to debug this.  Maybe it's a consequence of one of those problems of bypassing an intentional implicit
>> noinline in our code (by ensuring a function definition is in a different TU from all callers), with LTO breaking that.
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
>> by normal compilation).
>
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
> by normal compilation).
> 
> That seems definitely likely. With LTO the linker has a whole lot of room to try many exciting optimizations. I think it is more than likely that this can trigger some UB holes.
> 
> The question is: should we decouple "fixing LTO build" from "fixing a working LTO JVM"? I tend to think so; that the problem for the build system is to be able to build the product, and if it then crashes during use, it's the problem of the component owners instead. OTOH, this fix is relatively trivial, and if the JVM is DOA so we can't even finish the build, then maybe it makes no point to integrate it until that is fixed.

@magicus In JBS, I see a long conversation about LTO optimization for libraries aiming to cover all use cases. Maybe it's better to start with something smaller? For example, provide a way to enable it per library and per platform, so it can be incrementally adopted. Initial results for some libraries in the java.desktop look promising.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3416538676

From jwaters at openjdk.org  Fri Oct 17 18:05:09 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Oct 2025 18:05:09 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
Message-ID: <d222Kg8hLIsjIobn_l2f6mKLdTgc68Ypka7uaKBUEWg=.11c9a38a-a360-497a-8e31-0ecc326103c3@github.com>

On Fri, 10 Jan 2025 13:09:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.
>> 
>> Turns out I didn't wait long enough.  It does terminate after about 40 minutes, though not successfully.  Instead the
>> build crashes with a failed assert:
>> 
>> #  Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=4017588, tid=4017620
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> 
>> I've not tried to debug this.  Maybe it's a consequence of one of those problems of bypassing an intentional implicit
>> noinline in our code (by ensuring a function definition is in a different TU from all callers), with LTO breaking that.
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
>> by normal compilation).
>
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
> by normal compilation).
> 
> That seems definitely likely. With LTO the linker has a whole lot of room to try many exciting optimizations. I think it is more than likely that this can trigger some UB holes.
> 
> The question is: should we decouple "fixing LTO build" from "fixing a working LTO JVM"? I tend to think so; that the problem for the build system is to be able to build the product, and if it then crashes during use, it's the problem of the component owners instead. OTOH, this fix is relatively trivial, and if the JVM is DOA so we can't even finish the build, then maybe it makes no point to integrate it until that is fixed.

> @magicus In JBS, I see a long conversation about LTO optimization for libraries aiming to cover all use cases. Maybe it's better to start with something smaller? For example, provide a way to enable it per library and per platform, so it can be incrementally adopted. Initial results for some libraries in the java.desktop look promising.

Hi, at the moment this is HotSpot only; We're unfortunately facing a very severe issue in G1 that can't seem to be solved. I'm currently focusing on making it work for HotSpot before introducing this for the native libraries.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3416555982

From serb at openjdk.org  Fri Oct 17 18:46:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Oct 2025 18:46:13 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <d222Kg8hLIsjIobn_l2f6mKLdTgc68Ypka7uaKBUEWg=.11c9a38a-a360-497a-8e31-0ecc326103c3@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
 <d222Kg8hLIsjIobn_l2f6mKLdTgc68Ypka7uaKBUEWg=.11c9a38a-a360-497a-8e31-0ecc326103c3@github.com>
Message-ID: <28f-0tg_MIRW7NA2_qtYXR9MUdyjMtDNC1ayfih7kJY=.23fb213c-9834-40d9-acaf-00f2a196b4c3@github.com>

On Fri, 17 Oct 2025 18:02:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>Hi, at the moment this is HotSpot only; We're unfortunately facing a very severe issue in G1 that can't seem to be solved. I'm currently focusing on making it work for HotSpot before introducing this for the native libraries.

But as far I understand it will be much easy to implement for libs, do you know any blockers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3416689798

From sspitsyn at openjdk.org  Fri Oct 17 18:52:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Oct 2025 18:52:07 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <ioISb7v72UXZzYWUar9Jmzn0TPjgsrp4K5aEMcMXJRA=.b4b8b887-92d9-468f-af6d-bc37ec5338e6@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <y-Q3n07-dECqNWVhAJx1rbQzoBaVZzOCk_rXEWisg6g=.90e972ef-d62d-4acf-a47f-fa1442886214@github.com>
 <ioISb7v72UXZzYWUar9Jmzn0TPjgsrp4K5aEMcMXJRA=.b4b8b887-92d9-468f-af6d-bc37ec5338e6@github.com>
Message-ID: <jVyfl3kPA_-_-K9KLd0N9hKMmP92A0Su0eIL4-Vr87c=.8cec8f71-6404-4962-b753-fb7142e81c0c@github.com>

On Fri, 17 Oct 2025 15:00:02 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiExport.cpp line 1476:
>> 
>>> 1474:     // virtual threads. When exiting it is filtered out due to being hidden.
>>> 1475:     return;
>>> 1476:   }
>> 
>> This has to be okay for now.
>> It can be done in more generic way. For instance, there is a check for `thread->is_hidden_from_external_view()` below which would be nice to have earlier. However, now there is an inconsistency with the flag `is_hidden_from_external_view()` usage we need to address in the near future. So, I'm suggesting to keep this tweak as it is now.
>> Most likely, we need to make sure other JVMTI events are not posted for this thread as well. I can file a separate JVMTI bug on it if it is okay with you.
>
> Thanks for the review Serguei! I agree with your assessment. :)

Good. I've filed a JVMTI bug:
[8370128](https://bugs.openjdk.org/browse/JDK-8370128) AOT thread should not post JVMTI events

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440915774

From sherman at openjdk.org  Sat Oct 18 08:44:57 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 18 Oct 2025 08:44:57 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v3]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <nxqzsGhScv6UwRKAn533DmXvTeD7H_EpBMxKtQC0RpY=.132c69b7-462e-47a3-ae84-41c5a6d22790@github.com>

> ### Summary
> 
> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
> 
> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
> 
> **String.equalsIgnoreCase(String)**
> 
> - Unicode-aware, locale-independent.
> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
> - Limited: does not support 1:M mapping defined in Unicode case folding.
> 
> **Character.toLowerCase(int) / Character.toUpperCase(int)**
> 
> - Locale-independent, single code point only.
> - No support for 1:M mappings.
> 
> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
> 
> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
> - Intended primarily for presentation/display, not structural case-insensitive matching.
> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
> 
> **1:M mapping example, U+00DF (?)**
> 
> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
> - Case folding produces "ss", matching Unicode caseless comparison rules.
> 
> 
> jshell> "\u00df".equalsIgnoreCase("ss")
> $22 ==> false
> 
> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
> $24 ==> true
> 
> 
> ### Motivation & Direction
> 
> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
> 
> - Unicode-compliant **full** case folding.
> - Simpler, stable and more efficient case-less matching without workarounds.
> - Brings Java's string comparison handling in line with other programming languages/libraries.
> 
> This PR proposes to introduce the following comparison methods in `String` class
> 
> - boolean equalsFoldCase(String anotherString)
> - int compareToFoldCase(String anotherString)
> - Comparator<String> UNICODE_CASEFOLD_ORDER
> 
> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
> 
> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.
> 
> ### The New API
> 
> See CSR https://bugs.openjd...

Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:

  performance update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/9d9997dc..59b7a4fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=01-02

  Stats: 601 lines in 7 files changed: 285 ins; 242 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/27628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628

PR: https://git.openjdk.org/jdk/pull/27628

From sherman at openjdk.org  Sat Oct 18 08:44:59 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 18 Oct 2025 08:44:59 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <cDlEVow4k_cWVUudiUd_sbiSEpebCLP580ZywK5yKao=.c33d2a31-316e-4d79-8b43-ef8429a703dc@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <KAtz0opGeB44Rgr7drS2u9itSM6fQltNH_7f_1vuyKU=.09bba965-49f3-492a-b2a4-2cfffb9fff68@github.com>
 <cDlEVow4k_cWVUudiUd_sbiSEpebCLP580ZywK5yKao=.c33d2a31-316e-4d79-8b43-ef8429a703dc@github.com>
Message-ID: <CiCkUfeu_EZdV_w59UQ2XrTQoxaNLChvjReinb1LEzE=.a35ca471-e486-4ff7-b5b5-f4c7ff17128b@github.com>

On Fri, 10 Oct 2025 19:49:19 GMT, Jean-No?l Rouvignac <duke at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor api doc updates
>
> test/micro/org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java line 89:
> 
>> 87: 
>> 88:     @Benchmark
>> 89:     public int lowerrCF() {
> 
> Suggestion:
> 
>     public int lowerCF() {

fixed in the new test source code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2441835525

From sherman at openjdk.org  Sat Oct 18 08:54:01 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 18 Oct 2025 08:54:01 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v3]
In-Reply-To: <AQ7QGe_xYZhLcpWR24Uy2T5wP12Rcm2e0tD5o2nXC8M=.dfd99955-ca35-443d-b968-8fb98f52d786@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <AQ7QGe_xYZhLcpWR24Uy2T5wP12Rcm2e0tD5o2nXC8M=.dfd99955-ca35-443d-b968-8fb98f52d786@github.com>
Message-ID: <iLWjakdal9oPyngPnCanDTtcsF8OqCzu1yhVF8Yl4f4=.c79197ed-cdf7-49bf-bff3-71ff324d1fd1@github.com>

On Tue, 7 Oct 2025 22:10:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   performance update
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 194:
> 
>> 192:         char[] folded2 = null;
>> 193:         int k1 = 0, k2 = 0, fk1 = 0, fk2 = 0;
>> 194:         while ((k1 < len1 || folded1 != null && fk1 < folded1.length) &&
> 
> Many suggestions come to mind here on the algorithm, to optimize performance.
> For example, many strings will have identical prefixes. Using Arrays.mismatch could quickly skip over the identical prefix.
> Consider using code points (or a long, packing 4 chars) for the folded replacements, to avoid having to step through chars in char arrays.  CaseFolding.foldIfDefined could return the full expansion as a long.
> It may be profitable to use Arrays.mismatch again after expanded characters are determined to be equal.
> 
> Take another look at the data structure storing and doing the lookup of foldIfDefined both to increase the lookup performance.

With the following changes

- Use int[] / code point storage instead of char[] / char for folding data.
- Add a fast path for Latin-1 vs. Latin-1 comparisons.
- Speed up the UTF-16 path as well.

The only remaining ?slow? path is Latin-1 vs. UTF-16 for now.
Would appreciate some eagle eyes on the new fast-path implementation.  The tests suggest it?s working as expected :-)

**StringCompareToFoldCase.latin1UTF16          avgt   15  23.959 ? 2.357  ns/op
StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.455 ? 0.104  ns/op
StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  32.782 ? 0.962  ns/op
StringCompareToFoldCase.latin1UTF16FC        avgt   15  32.581 ? 0.725  ns/op**


Benchmark                                    Mode  Cnt   Score   Error  Units
StringCompareToFoldCase.asciiLower           avgt   15  17.983 ? 0.208  ns/op
StringCompareToFoldCase.asciiLowerEQ         avgt   15   9.986 ? 0.254  ns/op
StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.781 ? 0.161  ns/op
StringCompareToFoldCase.asciiLowerFC         avgt   15  10.274 ? 0.136  ns/op
StringCompareToFoldCase.asciiUpperLower      avgt   15  12.465 ? 0.409  ns/op
StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.961 ? 0.407  ns/op
StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.157 ? 0.166  ns/op
StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.228 ? 0.254  ns/op
StringCompareToFoldCase.asciiWithDFFC        avgt   15  57.603 ? 1.540  ns/op
StringCompareToFoldCase.greekLower           avgt   15  39.593 ? 0.128  ns/op
StringCompareToFoldCase.greekLowerEQ         avgt   15  39.249 ? 0.032  ns/op
StringCompareToFoldCase.greekLowerEQFC       avgt   15  13.993 ? 0.346  ns/op
StringCompareToFoldCase.greekLowerFC         avgt   15  14.030 ? 0.454  ns/op
StringCompareToFoldCase.greekUpperLower      avgt   15   7.137 ? 0.130  ns/op
StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.496 ? 0.104  ns/op
StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.203 ? 0.316  ns/op
StringCompareToFoldCase.greekUpperLowerFC    avgt   15   6.235 ? 0.256  ns/op
StringCompareToFoldCase.latin1UTF16          avgt   15  23.959 ? 2.357  ns/op
StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.455 ? 0.104  ns/op
StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  32.782 ? 0.962  ns/op
StringCompareToFoldCase.latin1UTF16FC        avgt   15  32.581 ? 0.725  ns/op
StringCompareToFoldCase.supLower             avgt   15  54.918 ? 0.809  ns/op
StringCompareToFoldCase.supLowerEQ           avgt   15  55.080 ? 0.511  ns/op
StringCompareToFoldCase.supLowerEQFC         avgt   15  14.085 ? 0.996  ns/op
StringCompareToFoldCase.supLowerFC           avgt   15  13.907 ? 0.612  ns/op
StringCompareToFoldCase.supUpperLower        avgt   15  14.479 ? 0.175  ns/op
StringCompareToFoldCase.supUpperLowerEQ      avgt   15  14.645 ? 0.059  ns/op
StringCompareToFoldCase.supUpperLowerEQFC    avgt   15   9.200 ? 0.310  ns/op
StringCompareToFoldCase.supUpperLowerFC      avgt   15   9.041 ? 0.248  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2441849469