From almatvee at openjdk.org  Sat Nov  1 01:08:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 1 Nov 2025 01:08:05 GMT
Subject: RFR: 8371076: jpackage will wrongly overwrite the plist file in
 the embedded runtime when executed with the "--app-image" option [v2]
In-Reply-To: <FPWItEGg0y8Z-B1h7_aEVJGW_N_Kbw5pNfGSRQOMOBc=.8f318865-6963-4b0a-8caa-f7ca98638006@github.com>
References: <Lx5VUtDGjT1L-WZVxVJ1y_4do1aPHjcSs9gE2_b9zmQ=.89bcf7c4-26e0-4f72-bf70-28e2f975e0ad@github.com>
 <FPWItEGg0y8Z-B1h7_aEVJGW_N_Kbw5pNfGSRQOMOBc=.8f318865-6963-4b0a-8caa-f7ca98638006@github.com>
Message-ID: <oHXr3CGUdLTZoI1vXTS1GW_h296mFCZDGrZ0-iGMgyA=.82b0ee5a-4399-47cd-944f-7535353c5c18@github.com>

On Fri, 31 Oct 2025 21:55:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Fix MacPackagingPipeline.
>> - Fix AppImageSigner: this is the follow-up for MacPackagingPipeline fix. Without fixing AppImageSigner AppImagePackageTest.testEmpty test fails. It happened that the test passed because jpackage wrongly created the plist file for the embedded runtime in the case of the predefined app image. The test passed because of the bug in jpackage fixed in this PR.
>> - Add test cases for predefined app image packaging to the CustomInfoPListTest test. They had been failing before MacPackagingPipeline was fixed.
>> 
>> Supplementary changes:
>>  - Get rid of duplicated `createInputRuntimeImage()` and `createRuntimeBundle()` functions.
>>  - Improve `MacHelper.writeFaPListFragment()` to work with a predefined app image.
>>  - Add optional tracing to the packaging pipeline (turned off by default, must edit static fields to enable in custom builds).
>>  - PListReader: add find methods that return an Optional instead of throwing an exception when the requested key is not found; update unit tests.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - CustomInfoPListTest: use Slot class
>  - Add Slot utility class

src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/PListReader.java line 211:

> 209:             switch (node.getNodeName()) {
> 210:                 case "true", "false" -> {
> 211:                     return true;

Confused. Looks like this code will return `true` even if value is `false`. You can use `return Boolean.parseBoolean(node.getNodeName())`. No need for switch in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28089#discussion_r2483021792

From almatvee at openjdk.org  Sat Nov  1 01:20:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 1 Nov 2025 01:20:05 GMT
Subject: RFR: 8371076: jpackage will wrongly overwrite the plist file in
 the embedded runtime when executed with the "--app-image" option [v2]
In-Reply-To: <FPWItEGg0y8Z-B1h7_aEVJGW_N_Kbw5pNfGSRQOMOBc=.8f318865-6963-4b0a-8caa-f7ca98638006@github.com>
References: <Lx5VUtDGjT1L-WZVxVJ1y_4do1aPHjcSs9gE2_b9zmQ=.89bcf7c4-26e0-4f72-bf70-28e2f975e0ad@github.com>
 <FPWItEGg0y8Z-B1h7_aEVJGW_N_Kbw5pNfGSRQOMOBc=.8f318865-6963-4b0a-8caa-f7ca98638006@github.com>
Message-ID: <P9oNBks9NqpF9YuqxnErgslts7cJt67eTNUV386juHA=.ad6a36d4-627d-4d56-bb4e-fd407872feb6@github.com>

On Fri, 31 Oct 2025 21:55:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Fix MacPackagingPipeline.
>> - Fix AppImageSigner: this is the follow-up for MacPackagingPipeline fix. Without fixing AppImageSigner AppImagePackageTest.testEmpty test fails. It happened that the test passed because jpackage wrongly created the plist file for the embedded runtime in the case of the predefined app image. The test passed because of the bug in jpackage fixed in this PR.
>> - Add test cases for predefined app image packaging to the CustomInfoPListTest test. They had been failing before MacPackagingPipeline was fixed.
>> 
>> Supplementary changes:
>>  - Get rid of duplicated `createInputRuntimeImage()` and `createRuntimeBundle()` functions.
>>  - Improve `MacHelper.writeFaPListFragment()` to work with a predefined app image.
>>  - Add optional tracing to the packaging pipeline (turned off by default, must edit static fields to enable in custom builds).
>>  - PListReader: add find methods that return an Optional instead of throwing an exception when the requested key is not found; update unit tests.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - CustomInfoPListTest: use Slot class
>  - Add Slot utility class

Looks good with minor comments.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/Slot.java line 29:

> 27: import java.util.Objects;
> 28: 
> 29: public final class Slot<T> {

Can you add comment to explain why we need this class and how it is used?

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

PR Review: https://git.openjdk.org/jdk/pull/28089#pullrequestreview-3406683482
PR Review Comment: https://git.openjdk.org/jdk/pull/28089#discussion_r2483022681

From asemenyuk at openjdk.org  Sat Nov  1 02:05:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 1 Nov 2025 02:05:02 GMT
Subject: RFR: 8371076: jpackage will wrongly overwrite the plist file in
 the embedded runtime when executed with the "--app-image" option [v2]
In-Reply-To: <oHXr3CGUdLTZoI1vXTS1GW_h296mFCZDGrZ0-iGMgyA=.82b0ee5a-4399-47cd-944f-7535353c5c18@github.com>
References: <Lx5VUtDGjT1L-WZVxVJ1y_4do1aPHjcSs9gE2_b9zmQ=.89bcf7c4-26e0-4f72-bf70-28e2f975e0ad@github.com>
 <FPWItEGg0y8Z-B1h7_aEVJGW_N_Kbw5pNfGSRQOMOBc=.8f318865-6963-4b0a-8caa-f7ca98638006@github.com>
 <oHXr3CGUdLTZoI1vXTS1GW_h296mFCZDGrZ0-iGMgyA=.82b0ee5a-4399-47cd-944f-7535353c5c18@github.com>
Message-ID: <rtoapsvfPs8bGuLTKrMUtgSu6Xxxa9hQedUltSzDdcs=.13d6eed6-e0dc-4623-8ee3-8b52330f0ae4@github.com>

On Sat, 1 Nov 2025 01:05:39 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Looks like this code will return `true` even if value is `false`

Correct. This code filters the node by its name. If the name is `true` or `false`, it accepts it and pass further, otherwise it returns `false` and the function returns an empty Optional.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28089#discussion_r2483044693

From asemenyuk at openjdk.org  Sat Nov  1 02:51:24 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 1 Nov 2025 02:51:24 GMT
Subject: RFR: 8371076: jpackage will wrongly overwrite the plist file in
 the embedded runtime when executed with the "--app-image" option [v3]
In-Reply-To: <Lx5VUtDGjT1L-WZVxVJ1y_4do1aPHjcSs9gE2_b9zmQ=.89bcf7c4-26e0-4f72-bf70-28e2f975e0ad@github.com>
References: <Lx5VUtDGjT1L-WZVxVJ1y_4do1aPHjcSs9gE2_b9zmQ=.89bcf7c4-26e0-4f72-bf70-28e2f975e0ad@github.com>
Message-ID: <swNIT8udKRyMokvoKNvqe7Ly3WOnlKCIq43TixgK6Ls=.39901d35-2305-4228-bb8e-4522b9e2903a@github.com>

> - Fix MacPackagingPipeline.
> - Fix AppImageSigner: this is the follow-up for MacPackagingPipeline fix. Without fixing AppImageSigner AppImagePackageTest.testEmpty test fails. It happened that the test passed because jpackage wrongly created the plist file for the embedded runtime in the case of the predefined app image. The test passed because of the bug in jpackage fixed in this PR.
> - Add test cases for predefined app image packaging to the CustomInfoPListTest test. They had been failing before MacPackagingPipeline was fixed.
> 
> Supplementary changes:
>  - Get rid of duplicated `createInputRuntimeImage()` and `createRuntimeBundle()` functions.
>  - Improve `MacHelper.writeFaPListFragment()` to work with a predefined app image.
>  - Add optional tracing to the packaging pipeline (turned off by default, must edit static fields to enable in custom builds).
>  - PListReader: add find methods that return an Optional instead of throwing an exception when the requested key is not found; update unit tests.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Document Slot class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28089/files
  - new: https://git.openjdk.org/jdk/pull/28089/files/494adc56..33cf1873

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

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

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

From almatvee at openjdk.org  Sat Nov  1 03:47:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 1 Nov 2025 03:47:01 GMT
Subject: RFR: 8370969: --launcher-as-service option is ignored when used
 with --app-image option
In-Reply-To: <EVK7AmNfBeQgegGN9uI-NxC2J_pTo6wTB85NHh-Ghd4=.da0697bc-9f90-4513-bf45-f25e148ba109@github.com>
References: <EVK7AmNfBeQgegGN9uI-NxC2J_pTo6wTB85NHh-Ghd4=.da0697bc-9f90-4513-bf45-f25e148ba109@github.com>
Message-ID: <XosX5isKkIsFRPzgiX_G5GWNCDTMJr77VLXXBKFJSZw=.cf9dee77-933b-4f04-9d50-65e929ebdee8@github.com>

On Thu, 30 Oct 2025 18:47:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix jpackage to handle correctly the `--launcher-as-service` cli option when bundling a native bundle from the predefined app image.
>  - Rework `LauncherAsServiceVerifier` to make it work with `JPackageCommand` and `PackageTest`. This allows using it in tests when jpackage creates a native bundle from the predefined app image (`--app-image` option).
>  - Add relevant test cases to `ServiceTest`. The new test cases cover "launcher-as-service" feature for additional launchers.
>  - Fix `MacHelper.getPackageId()` to make it work when bundling a native bundle from the predefined app image.
> 
> Supplementary changes:
>  - Get rid of "thows IOException" from all method signatures in `CfgTest` and `TKit.traceFileContents()`. 
>  - Format `TKit.createTextFile()` and `TKit.createPropertiesFile()`.
>  - Add `JPackageCommand.mainLauncherName()`. It returns the same value as `JPackageCommand.name()`, but will fail if called in case or runtime bundling. Replace `JPackageCommand.name()` with `JPackageCommand.mainLauncherName()` where appropriate.
>  - Add the `PropertyFinder` class, which provides a declarative way to calculate the value of a property that may be sourced from one or a few cli options, a property in an additionl launcher property file, and a value in the app image file (.jpackage.xml).

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28071#pullrequestreview-3406796740

From almatvee at openjdk.org  Sat Nov  1 03:49:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 1 Nov 2025 03:49:05 GMT
Subject: RFR: 8371076: jpackage will wrongly overwrite the plist file in
 the embedded runtime when executed with the "--app-image" option [v3]
In-Reply-To: <swNIT8udKRyMokvoKNvqe7Ly3WOnlKCIq43TixgK6Ls=.39901d35-2305-4228-bb8e-4522b9e2903a@github.com>
References: <Lx5VUtDGjT1L-WZVxVJ1y_4do1aPHjcSs9gE2_b9zmQ=.89bcf7c4-26e0-4f72-bf70-28e2f975e0ad@github.com>
 <swNIT8udKRyMokvoKNvqe7Ly3WOnlKCIq43TixgK6Ls=.39901d35-2305-4228-bb8e-4522b9e2903a@github.com>
Message-ID: <BON0wtsIBIlTxEJEZ99Uq4nn-pBkngsBqYLInk0952c=.ed411bae-9e95-438e-baf9-bcc659b0f6e7@github.com>

On Sat, 1 Nov 2025 02:51:24 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Fix MacPackagingPipeline.
>> - Fix AppImageSigner: this is the follow-up for MacPackagingPipeline fix. Without fixing AppImageSigner AppImagePackageTest.testEmpty test fails. It happened that the test passed because jpackage wrongly created the plist file for the embedded runtime in the case of the predefined app image. The test passed because of the bug in jpackage fixed in this PR.
>> - Add test cases for predefined app image packaging to the CustomInfoPListTest test. They had been failing before MacPackagingPipeline was fixed.
>> 
>> Supplementary changes:
>>  - Get rid of duplicated `createInputRuntimeImage()` and `createRuntimeBundle()` functions.
>>  - Improve `MacHelper.writeFaPListFragment()` to work with a predefined app image.
>>  - Add optional tracing to the packaging pipeline (turned off by default, must edit static fields to enable in custom builds).
>>  - PListReader: add find methods that return an Optional instead of throwing an exception when the requested key is not found; update unit tests.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Document Slot class

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28089#pullrequestreview-3406797378

From jpai at openjdk.org  Sat Nov  1 07:27:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 1 Nov 2025 07:27:05 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v2]
In-Reply-To: <fstJg2ArWCTFddFGye-lNCQDggIOT1j_qrckztj3hQ4=.457f2981-a197-414f-9fc6-5ab30681dcd0@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
 <fstJg2ArWCTFddFGye-lNCQDggIOT1j_qrckztj3hQ4=.457f2981-a197-414f-9fc6-5ab30681dcd0@github.com>
Message-ID: <c4x28-Z3462tdyeqd_lHYYOgCxPfBXYQF4YfjhVTOts=.0d6923c0-8a1e-498a-91f6-751b8073e3a3@github.com>

On Fri, 31 Oct 2025 16:27:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367943: positive -> greater than zero

These changes look good to me. I only have a comment about the new test which I've added inline.

test/jdk/java/io/PipedOutputStream/WriteAfterClose.java line 45:

> 43:         }
> 44:         try {
> 45:             out.write(new byte[7], 3, 0);

Hello Brian, this test here attempts a write to the `PipedOutputStream` after the `PipedInputStream` is closed. It's slightly different that closing the `PipedOutputStream` itself. Should we add one more test which closes the `PipedOutputStream` and attempts this write?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28078#pullrequestreview-3406930286
PR Review Comment: https://git.openjdk.org/jdk/pull/28078#discussion_r2483175252

From alanb at openjdk.org  Sat Nov  1 07:38:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 1 Nov 2025 07:38:03 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v13]
In-Reply-To: <WLtVTuAmgZ8kZLoYi6RTr_i5Ib6BDZWfkfEwhVUvsNo=.a2337ed6-53ce-4667-994a-7bbac5e6af45@github.com>
References: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
 <WLtVTuAmgZ8kZLoYi6RTr_i5Ib6BDZWfkfEwhVUvsNo=.a2337ed6-53ce-4667-994a-7bbac5e6af45@github.com>
Message-ID: <CHNRyeypVOH9EVu0x3RtbA1MFymkyHCpjV_QVn7Zv6M=.e1fbcc16-eab9-4b9c-9d86-bd66cf6279e9@github.com>

On Fri, 31 Oct 2025 18:38:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355342: Clean up "const" usages

It took a lot of iterations but I think the latest is good. I assume you'll run tier1+tier2 at least before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27324#pullrequestreview-3406934406

From alanb at openjdk.org  Sat Nov  1 08:19:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 1 Nov 2025 08:19:09 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v26]
In-Reply-To: <4y_Uc6Qjvh_VmJwj8V3Q_0RiNvJUyFEXk8l_5mg-2Cw=.bbf52699-28aa-4cd0-8fd8-a5a9bc6fd601@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <4y_Uc6Qjvh_VmJwj8V3Q_0RiNvJUyFEXk8l_5mg-2Cw=.bbf52699-28aa-4cd0-8fd8-a5a9bc6fd601@github.com>
Message-ID: <xf0R6z8Pt5UpUiUARs7HEb3xODJ6MRumgz_M8s3ykVQ=.176dfb97-805d-4c48-bf57-1f114ccb64b9@github.com>

On Fri, 31 Oct 2025 14:32:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct reference to ProcessExamples.java to use the `file` tag.
>  - Miscellaneous javadoc improvements suggested by reviewers.
>    Updated the example program to be a standalone program as might be run
>    as a compact source file main program.

I think you've got this feature in a good place. It is definitely one of the difficult APIs to retrofit.

src/java.base/share/classes/java/lang/Process.java line 121:

> 119:  * or readers, or they have been closed. The Process {@linkplain Process#close close} method closes
> 120:  * all the streams and terminates the process to release the resources. Using try-with-resources to
> 121:  * {@linkplain ProcessBuilder#start() start} the process can ensure the process

I think it would be simpler if you drop the ProcessBuilder.start from this sentence, it need only say that using the try-with-resources statement will ensure the process is terminated.

src/java.base/share/classes/java/lang/Process.java line 199:

> 197:      * <p>
> 198:      * After the streams are closed this method {@linkplain #waitFor() waits for} the
> 199:      * process to terminate. If interrupted while {@linkplain #waitFor() waiting}

You can link "interrupted" to Thread.interrupt, no need for the second linking to waitFor as the first sentence establishes that the method waits and links to waitFor.

src/java.base/share/classes/java/lang/Process.java line 205:

> 203:      * any {@code IOExceptions} are thrown.
> 204:      * <p>
> 205:      * Try-with-resources example to write text to a process, read back the

`@apiNote` ?

src/java.base/share/classes/java/lang/Process.java line 216:

> 214:      * The {@code outputWriter} and {@code outputStream} to the process are closed.
> 215:      * The {@code inputReader} and {@code inputStream} from the process are closed.
> 216:      * The {@code errorReader} and {@code errorStream} from the process are closed.

I mentioned this previously but you can collapse these 3 sentences into one. If you want to specify the ordering (I don't it needs to) then it can say this, no ordering is implied now.

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

PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3406947587
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2483192427
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2483190247
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2483190680
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2483191329

From alanb at openjdk.org  Sat Nov  1 08:29:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 1 Nov 2025 08:29:05 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v2]
In-Reply-To: <fstJg2ArWCTFddFGye-lNCQDggIOT1j_qrckztj3hQ4=.457f2981-a197-414f-9fc6-5ab30681dcd0@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
 <fstJg2ArWCTFddFGye-lNCQDggIOT1j_qrckztj3hQ4=.457f2981-a197-414f-9fc6-5ab30681dcd0@github.com>
Message-ID: <KAK_Wyrz5LMaeko805o_e_MER129by0oE6Y8usPc4gU=.509dd8ab-baf8-4518-98f0-20200c3d5791@github.com>

On Fri, 31 Oct 2025 16:27:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367943: positive -> greater than zero

src/java.base/share/classes/java/io/PipedOutputStream.java line 132:

> 130:      * Writes {@code len} bytes from the specified byte array
> 131:      * starting at offset {@code off} to this piped output stream.
> 132:      * This method blocks until all the bytes are written to the output

To align the spec with long standing behavior then I think this sentence needs to be adjusted to say that if len is not zero, then it blocks until all bytes are written.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28078#discussion_r2483195548

From cushon at openjdk.org  Sat Nov  1 16:26:04 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 1 Nov 2025 16:26:04 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v2]
In-Reply-To: <9VpoTyAJ3oQwtSpHO6sCVwaWA_Jx3B91DS2oxOTTTcI=.afc95ec9-c937-44e8-9a0c-9b087dd3c4ff@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
 <9VpoTyAJ3oQwtSpHO6sCVwaWA_Jx3B91DS2oxOTTTcI=.afc95ec9-c937-44e8-9a0c-9b087dd3c4ff@github.com>
Message-ID: <YHtlduwfyfFMcdTFF5_xg6NHC6Fb784snhddwlV35Wo=.7975ff5e-5231-42b3-90e8-4503c376da54@github.com>

On Thu, 30 Oct 2025 23:13:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   .md files

make/data/cldr/common/main/tok.xml line 444:

> 442: 					<dateFormatLength type="long">
> 443: 						<dateFormat>
> 444: 							<pattern>'tenpo' 'sike' #y 'la' 'tenpo' MMMM 'la' 'tenpo' 'suno' #d</pattern>

I think `DateTimeFormatter` doesn't handle the new patterns for `tok`, I am seeing the following crash with these changes:


jshell> Instant.parse("2018-07-16T23:58:59.000000200Z").atZone(ZoneId.of("UTC")).format(DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG).withLocale(Locale.of("tok")))
|  Exception java.lang.IllegalArgumentException: Pattern includes reserved character: '#'
|        at DateTimeFormatterBuilder.parsePattern (DateTimeFormatterBuilder.java:2056)
|        at DateTimeFormatterBuilder.appendPattern (DateTimeFormatterBuilder.java:1910)
|        at DateTimeFormatterBuilder$LocalizedPrinterParser.lambda$formatter$0 (DateTimeFormatterBuilder.java:5181)
|        at ConcurrentHashMap.computeIfAbsent (ConcurrentHashMap.java:1727)
|        at DateTimeFormatterBuilder$LocalizedPrinterParser.formatter (DateTimeFormatterBuilder.java:5179)
|        at DateTimeFormatterBuilder$LocalizedPrinterParser.format (DateTimeFormatterBuilder.java:5154)
|        at DateTimeFormatterBuilder$CompositePrinterParser.format (DateTimeFormatterBuilder.java:2547)
|        at DateTimeFormatter.formatTo (DateTimeFormatter.java:1907)
|        at DateTimeFormatter.format (DateTimeFormatter.java:1881)
|        at ZonedDateTime.format (ZonedDateTime.java:2158)
|        at (#6:1)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28076#discussion_r2483784510

From rriggs at openjdk.org  Sat Nov  1 19:05:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 1 Nov 2025 19:05:25 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v27]
In-Reply-To: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
Message-ID: <rnsLm0t_MZeizVw8t9RMOtsvU1TqAXa5vx4rCWMFSME=.e0562f6a-3f87-492d-93a2-45185f1a9f92@github.com>

> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
> 
> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
> 
> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Minor revisions of javadoc for closes for brevity and clarity recommended in review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/58176c88..7843eb73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=25-26

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

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

From asemenyuk at openjdk.org  Sat Nov  1 23:33:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 1 Nov 2025 23:33:10 GMT
Subject: Integrated: 8370969: --launcher-as-service option is ignored when used
 with --app-image option
In-Reply-To: <EVK7AmNfBeQgegGN9uI-NxC2J_pTo6wTB85NHh-Ghd4=.da0697bc-9f90-4513-bf45-f25e148ba109@github.com>
References: <EVK7AmNfBeQgegGN9uI-NxC2J_pTo6wTB85NHh-Ghd4=.da0697bc-9f90-4513-bf45-f25e148ba109@github.com>
Message-ID: <lNjdRm4xwPL2s5cGIcncZlMsTED7wVFKPD7ek0Q8Yok=.b9de69cc-e965-45dd-b2dc-25294c29b8dd@github.com>

On Thu, 30 Oct 2025 18:47:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix jpackage to handle correctly the `--launcher-as-service` cli option when bundling a native bundle from the predefined app image.
>  - Rework `LauncherAsServiceVerifier` to make it work with `JPackageCommand` and `PackageTest`. This allows using it in tests when jpackage creates a native bundle from the predefined app image (`--app-image` option).
>  - Add relevant test cases to `ServiceTest`. The new test cases cover "launcher-as-service" feature for additional launchers.
>  - Fix `MacHelper.getPackageId()` to make it work when bundling a native bundle from the predefined app image.
> 
> Supplementary changes:
>  - Get rid of "thows IOException" from all method signatures in `CfgTest` and `TKit.traceFileContents()`. 
>  - Format `TKit.createTextFile()` and `TKit.createPropertiesFile()`.
>  - Add `JPackageCommand.mainLauncherName()`. It returns the same value as `JPackageCommand.name()`, but will fail if called in case or runtime bundling. Replace `JPackageCommand.name()` with `JPackageCommand.mainLauncherName()` where appropriate.
>  - Add the `PropertyFinder` class, which provides a declarative way to calculate the value of a property that may be sourced from one or a few cli options, a property in an additionl launcher property file, and a value in the app image file (.jpackage.xml).

This pull request has now been integrated.

Changeset: f7f4f903
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7f4f903cfdafecf69ff47d5d37e254adaf63141
Stats:     632 lines in 14 files changed: 480 ins; 42 del; 110 mod

8370969: --launcher-as-service option is ignored when used with --app-image option

Reviewed-by: almatvee

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

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

From asemenyuk at openjdk.org  Sun Nov  2 02:22:14 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sun, 2 Nov 2025 02:22:14 GMT
Subject: Integrated: 8371076: jpackage will wrongly overwrite the plist file in
 the embedded runtime when executed with the "--app-image" option
In-Reply-To: <Lx5VUtDGjT1L-WZVxVJ1y_4do1aPHjcSs9gE2_b9zmQ=.89bcf7c4-26e0-4f72-bf70-28e2f975e0ad@github.com>
References: <Lx5VUtDGjT1L-WZVxVJ1y_4do1aPHjcSs9gE2_b9zmQ=.89bcf7c4-26e0-4f72-bf70-28e2f975e0ad@github.com>
Message-ID: <5OnpK_lTbH4h8Gh7zC2v_749P5GO2CZoyZP11_iNruE=.416a6240-e2f1-4c9e-b173-ab04357b6d15@github.com>

On Fri, 31 Oct 2025 16:51:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix MacPackagingPipeline.
> - Fix AppImageSigner: this is the follow-up for MacPackagingPipeline fix. Without fixing AppImageSigner AppImagePackageTest.testEmpty test fails. It happened that the test passed because jpackage wrongly created the plist file for the embedded runtime in the case of the predefined app image. The test passed because of the bug in jpackage fixed in this PR.
> - Add test cases for predefined app image packaging to the CustomInfoPListTest test. They had been failing before MacPackagingPipeline was fixed.
> 
> Supplementary changes:
>  - Get rid of duplicated `createInputRuntimeImage()` and `createRuntimeBundle()` functions.
>  - Improve `MacHelper.writeFaPListFragment()` to work with a predefined app image.
>  - Add optional tracing to the packaging pipeline (turned off by default, must edit static fields to enable in custom builds).
>  - PListReader: add find methods that return an Optional instead of throwing an exception when the requested key is not found; update unit tests.

This pull request has now been integrated.

Changeset: 7c900da1
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c900da1985c9508198ea7805e4955da4a7cac42
Stats:     626 lines in 13 files changed: 378 ins; 118 del; 130 mod

8371076: jpackage will wrongly overwrite the plist file in the embedded runtime when executed with the "--app-image" option

Reviewed-by: almatvee

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

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

From alan.bateman at oracle.com  Sun Nov  2 09:07:55 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 2 Nov 2025 09:07:55 +0000
Subject: JDBC DriverManager never updated for system classloader?
In-Reply-To: <CAE-f1xTuCiv0nGOz0u_8SHEnUNops5VsSh-zBRHY_M_7CQeeDA@mail.gmail.com>
References: <CAE-f1xTuCiv0nGOz0u_8SHEnUNops5VsSh-zBRHY_M_7CQeeDA@mail.gmail.com>
Message-ID: <ad737850-ea05-4f63-b5d9-8c31aa86a1af@oracle.com>

On 27/10/2025 20:06, Charles Oliver Nutter wrote:
> Hello!
>
> I've been looking for a concrete explanation for why the JDBC 
> DriverManager can't find drivers under the following circumstances:
>
> * Driver jar loaded into child classloader of app classloader
> * Child classloader set for current thread's context classloader
>
> My long explanation of the issue is here:
>
> https://github.com/jruby/jruby/issues/8910#issuecomment-3453029437
>
> The short explanation is that when the DriverManager goes to check for 
> "allowed" drivers, it ends up using the wrong classloader.
>
> https://github.com/openjdk/jdk/blob/8151251fa683459e57430abf8e3583c444315746/src/java.sql/share/classes/java/sql/DriverManager.java#L157
>
> * Caller's class is acquired with Reflection.getCallerClass
> * Caller's classloader is acquired
> * If that classloader is null, as it would have been for classes 
> loaded on the root classpath in Java 8, it instead uses the thread 
> context classloader.
> * If that classloader is not null (Java 9+) and not the platform 
> classloader, it is used for verification; in this case it is the 
> system classloader (a "ClassLoader#AppClassLoader" instance) so the 
> child classloader's driver is disallowed.
>
> My confusion is why this code was never patched for the change to the 
> system classloader (from null to an AppClassLoader). The logic in 
> DriverManager will never use the ThreadContext classloader now, since 
> there's almost no cases where "getClassLoader" will return null.
>
> Is there a good explanation for why this code still checks for a null 
> classloader?
>

The java.sql module is mapped to the platform class loader so you are 
correct that none of the classes in that module will be visible to the 
boot class loader. None of the core modules `requires java.sql` so 
wouldn't compile anyway.

The edge case of a JNI attached thread calling DriverManager methods 
with no java frames on the stack should be the only case now where the 
caller is null.? The java.sql.rowset (requires java.sql) is also mapped 
to the platform class loader. I don't know if it uses DriverManager but 
if it did, then the caller would be a class defined by the platform 
class loader.

I don't think it's possible to engage on the question as to why 
DriverManager does a visibility check.? The discovery and and driver 
registration in this API date back to early JDK releases and have been 
very problematic to secure.? I think (need Lance to confirm) that the 
hope was that the eco system would move to DataSource but it seems there 
is still a lot of usage of DriverManager.

-Alan

From alanb at openjdk.org  Sun Nov  2 09:16:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 2 Nov 2025 09:16:09 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v27]
In-Reply-To: <rnsLm0t_MZeizVw8t9RMOtsvU1TqAXa5vx4rCWMFSME=.e0562f6a-3f87-492d-93a2-45185f1a9f92@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <rnsLm0t_MZeizVw8t9RMOtsvU1TqAXa5vx4rCWMFSME=.e0562f6a-3f87-492d-93a2-45185f1a9f92@github.com>
Message-ID: <Qjkq6PyX3001e2ZsQO0U8Sk_WP1CPXFBXPqx6CXXOQ0=.94d26016-4446-4a56-9850-7df7d6ab2182@github.com>

On Sat, 1 Nov 2025 19:05:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor revisions of javadoc for closes for brevity and clarity recommended in review.

All good.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3408288803

From duke at openjdk.org  Sun Nov  2 09:54:05 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 2 Nov 2025 09:54:05 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
Message-ID: <fzQCP48AOnM_sAvhD0dMRiT4X8uRzW4-TlNcTamgCmk=.480bdc6b-687a-4bc9-8d13-ff392d98c9d1@github.com>

On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update `@bug` in correct file
>  - Add default implementation on codePointCount in CharSequence
>  - Update `@bug` entries in test class doc comments
>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

The CSR text is not modified from the boilerplate, but I have no authority to modify it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3477670082

From swen at openjdk.org  Sun Nov  2 12:40:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 2 Nov 2025 12:40:55 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v6]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <UTcY2ZF5jsA2PqMrMURKeYn6rW_NGDeMOs33JEcnv-c=.73c98adc-c530-4d5b-aa83-cbf5a66ddafa@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  appendPair instead of append(char, char)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/d489f144..d969a235

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

  Stats: 27 lines in 4 files changed: 20 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

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

From duke at openjdk.org  Sun Nov  2 14:32:32 2025
From: duke at openjdk.org (Peyang)
Date: Sun, 2 Nov 2025 14:32:32 GMT
Subject: RFR: 8366058: Outdated comment in WinCAPISeedGenerator
Message-ID: <pqiP2995Dmqa236BSaAOT_F03W6A2Tbelw0J1LbdnSI=.268196ea-42cb-423a-a990-00a0eaaed425@github.com>

Removed comment about Windows 95 runtime linking, since Windows 95 is no longer supported:

> Some early versions of Windows 95 do not support the required functions.
> Use runtime linking to avoid problems.

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

Commit messages:
 - 8366058: Remove outdated comment in WinCAPISeedGenerator

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

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

From davidalayachew at gmail.com  Sun Nov  2 23:35:59 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 2 Nov 2025 18:35:59 -0500
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
Message-ID: <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>

Sorry to revive this thread after all this time. Missed the emails somehow.

A file extension method would be ideal. Didn't know that was on the table.

As for deprecations, I still think all 4 methods should be deprecated. This
path variants are kind of ok, but the String variants are just too
deceptively named.

I think Rob Spoor hit it on the head with this quote.

> Perhaps both can be added?
>
> Path.{start,end}sWithString would default to calling
> toString().{start,end}sWith(arg) and
> Path.{start,end}sWithPath would default to calling
> {start,end}sWith(arg). The latter could default to
> calling {start,end}sWith(getFileSystem().getPath(arg))
> but then custom implementations that do something else
> (in addition) may not work as expected.

Doing it this way, we can have (start|end)sWithPath() have both String and
Path overloads with no ambiguity.

And (start|end)sWithString() doesn't obviate the need for a file extension
method/API. It would just be a good enough stop gap in the meantime.

Out of curiosity, why was the old commit for file extension pulled out? I
only see the commit hash, I don't know how to look that up.

Thank you all again for your time and consideration.
David Alayachew

On Thu, Sep 18, 2025 at 5:12?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:

> On Thu, Sep 18, 2025 at 7:08?PM Brian Burkhalter
> <brian.burkhalter at oracle.com> wrote:
>
> <snip>
>
> > I have filed an issue to improve the specification of this method
> somehow:
> >
> > https://bugs.openjdk.org/browse/JDK-8368007
> >
>
> Personally, a better spec wouldn't have helped me avoid the trap. The
> spec is already clear. I think it's the combination of the method's
> name and the argument type that is misleading.
>
> I think I learned about this method by scrolling autocompletion
> suggestions in my IDE. The method seemed to fit my need exactly. Of
> course, I quickly learned that I was wrong, but somehow kept falling
> into the same trap. Not sure how representative my experience in this
> case is, though.
>
> Deprecation would flag the method in the IDE and help avoid the trap.
> But eventually, it would be good to also have the file extension
> functionality.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251102/1053357b/attachment-0001.htm>

From pavel.rappo at gmail.com  Mon Nov  3 00:03:26 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Mon, 3 Nov 2025 00:03:26 +0000
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
Message-ID: <CAChcVumRLx0rrMTAUFawZ8yEpktKBqcF_4LCi4K9ZWHfW5j_1g@mail.gmail.com>

On Sun, Nov 2, 2025 at 11:36?PM David Alayachew
<davidalayachew at gmail.com> wrote:
>
> <snip>
>
> I only see the commit hash, I don't know how to look that up.
>

Each commit (but a few initial) in openjdk/jdk has a commit message.
That message starts with an issue number. That number can be used to
look up the issue in JBS: https://bugs.openjdk.org/. The issue has a
summary, comments, and links to GitHub's commit and PR pages.

Here are the links for 10356e767a44632c5de142d4666bd85d4618bf71

 - https://bugs.openjdk.org/browse/JDK-8298303
 - https://github.com/openjdk/jdk/commit/10356e767a44632c5de142d4666bd85d4618bf71
 - https://github.com/openjdk/jdk/pull/11566

-Pavel

From davidalayachew at gmail.com  Mon Nov  3 00:04:51 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 2 Nov 2025 19:04:51 -0500
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <CAChcVumRLx0rrMTAUFawZ8yEpktKBqcF_4LCi4K9ZWHfW5j_1g@mail.gmail.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <CAChcVumRLx0rrMTAUFawZ8yEpktKBqcF_4LCi4K9ZWHfW5j_1g@mail.gmail.com>
Message-ID: <CAA9v-_PRFYsYcKtpUK5poAUhjpu-Pftkmc1tjwc1jZiwoAzk9w@mail.gmail.com>

??

David Alayachew reacted via Gmail
<https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>

On Sun, Nov 2, 2025 at 7:03?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:

> On Sun, Nov 2, 2025 at 11:36?PM David Alayachew
> <davidalayachew at gmail.com> wrote:
> >
> > <snip>
> >
> > I only see the commit hash, I don't know how to look that up.
> >
>
> Each commit (but a few initial) in openjdk/jdk has a commit message.
> That message starts with an issue number. That number can be used to
> look up the issue in JBS: https://bugs.openjdk.org/. The issue has a
> summary, comments, and links to GitHub's commit and PR pages.
>
> Here are the links for 10356e767a44632c5de142d4666bd85d4618bf71
>
>  - https://bugs.openjdk.org/browse/JDK-8298303
>  -
> https://github.com/openjdk/jdk/commit/10356e767a44632c5de142d4666bd85d4618bf71
>  - https://github.com/openjdk/jdk/pull/11566
>
> -Pavel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/vnd.google.email-reaction+json
Size: 39 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251102/540942e4/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251102/540942e4/attachment.htm>

From davidalayachew at gmail.com  Mon Nov  3 00:28:00 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 2 Nov 2025 19:28:00 -0500
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <CAChcVumRLx0rrMTAUFawZ8yEpktKBqcF_4LCi4K9ZWHfW5j_1g@mail.gmail.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <CAChcVumRLx0rrMTAUFawZ8yEpktKBqcF_4LCi4K9ZWHfW5j_1g@mail.gmail.com>
Message-ID: <CAA9v-_PfVndEY5KGx40RVSZE7rYLWTMND_dXyE95DekkPQV8OQ@mail.gmail.com>

Ty vm. Looks great. Hope to see that change come back soon!

If there is anything I can do to help it come out faster, please let me
know! I am perfectly happy to write the implementation. And since we have
the Bug Number, couldn't I just submit my PR under that? Lmk, I could do it
right now!

I'm excited since this is an implementation that I could actually do by
myself.

One thing that stood out to me is that, in the unit test, I saw that "." is
considered as no extension, but ".." is considered to be an empty
extension. Wouldn't that break Path's that are built out of ".." and "."?
For example, if I submit a Path as Path.of(".."), then by definition, that
is a directory, and thus, should be considered no extension.

I propose that "." and ".." be considered no extension.

On Sun, Nov 2, 2025 at 7:03?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:

> On Sun, Nov 2, 2025 at 11:36?PM David Alayachew
> <davidalayachew at gmail.com> wrote:
> >
> > <snip>
> >
> > I only see the commit hash, I don't know how to look that up.
> >
>
> Each commit (but a few initial) in openjdk/jdk has a commit message.
> That message starts with an issue number. That number can be used to
> look up the issue in JBS: https://bugs.openjdk.org/. The issue has a
> summary, comments, and links to GitHub's commit and PR pages.
>
> Here are the links for 10356e767a44632c5de142d4666bd85d4618bf71
>
>  - https://bugs.openjdk.org/browse/JDK-8298303
>  -
> https://github.com/openjdk/jdk/commit/10356e767a44632c5de142d4666bd85d4618bf71
>  - https://github.com/openjdk/jdk/pull/11566
>
> -Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251102/2dd72235/attachment-0001.htm>

From swen at openjdk.org  Mon Nov  3 06:52:01 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Nov 2025 06:52:01 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v7]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <v0c3A0o95Y5zNQPURzz0J2afzBSndz8VXXQJcqLR34E=.81a2c309-62bb-4206-9e66-0133af0a6832@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Revert "appendPair instead of append(char, char)"
  
  This reverts commit d969a235e54da4ac96b7205982624f52305cae31.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/d969a235..287fdb8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=05-06

  Stats: 27 lines in 4 files changed: 0 ins; 20 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

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

From lbourges at openjdk.org  Mon Nov  3 07:02:06 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 3 Nov 2025 07:02:06 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v7]
In-Reply-To: <v0c3A0o95Y5zNQPURzz0J2afzBSndz8VXXQJcqLR34E=.81a2c309-62bb-4206-9e66-0133af0a6832@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <v0c3A0o95Y5zNQPURzz0J2afzBSndz8VXXQJcqLR34E=.81a2c309-62bb-4206-9e66-0133af0a6832@github.com>
Message-ID: <IrqjJJ7eIKd33cb-kCllUPn46eNiBOAobLAsJT5_9_w=.2041c166-f524-4d12-8acb-783160f3d5c1@github.com>

On Mon, 3 Nov 2025 06:52:01 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "appendPair instead of append(char, char)"
>   
>   This reverts commit d969a235e54da4ac96b7205982624f52305cae31.

JMH results are amazing!
LGTM, not a reviewer sorry.

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

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3479156523

From pminborg at openjdk.org  Mon Nov  3 09:19:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 3 Nov 2025 09:19:02 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles [v2]
In-Reply-To: <qnuJ3cdLbbPQ-T0n6f3vRj4WyrnQ0O9EKTD60zgvQu8=.20badd28-dfe3-4d2b-82b3-6f215ef18708@github.com>
References: <VzazfJzfurzijFp8QMZRVxWjqPl24jt2mzkpTY5tomg=.b2ffa9d3-4a8e-49ac-817d-19b656f9bbc7@github.com>
 <qnuJ3cdLbbPQ-T0n6f3vRj4WyrnQ0O9EKTD60zgvQu8=.20badd28-dfe3-4d2b-82b3-6f215ef18708@github.com>
Message-ID: <OznoBN2nELVeZTW3LvYz0WJj7v33arm3T-q2yDh9GNw=.ccc49ecc-5bec-448b-9bbb-013c1f376378@github.com>

On Fri, 31 Oct 2025 20:59:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial draft of a partial set of methods wrapping primitive operators to get feedback on the class providing this functionality.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback, fix typos, etc.

I wonder if we could group the various primitive operations in separate inner classes? Like `Operators.Long` and so on in order to structure the class that otherwise would have over a hundred methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/28081#issuecomment-3479568790

From pminborg at openjdk.org  Mon Nov  3 09:19:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 3 Nov 2025 09:19:05 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles [v2]
In-Reply-To: <juge8I6ojSRWt0kn9bm4Dc4TQ_Bl0TKS74GjdE1v1UM=.c4862591-5153-4afc-8cd9-545d460c4c26@github.com>
References: <VzazfJzfurzijFp8QMZRVxWjqPl24jt2mzkpTY5tomg=.b2ffa9d3-4a8e-49ac-817d-19b656f9bbc7@github.com>
 <qnuJ3cdLbbPQ-T0n6f3vRj4WyrnQ0O9EKTD60zgvQu8=.20badd28-dfe3-4d2b-82b3-6f215ef18708@github.com>
 <juge8I6ojSRWt0kn9bm4Dc4TQ_Bl0TKS74GjdE1v1UM=.c4862591-5153-4afc-8cd9-545d460c4c26@github.com>
Message-ID: <pwKe8EH7GPxN4ON7mTUEaugxivWt88ekV5y0K13X8E0=.0e25f964-6c79-4dda-a834-37015900d60f@github.com>

On Fri, 31 Oct 2025 22:15:43 GMT, Chen Liang <liach at openjdk.org> wrote:

> I strongly oppose adding operators corresponding to individual instructions. They are not the best primitive operations, and using them as methods in method handles may suffer the same problem as Objects::equals performance drop due to lack of dedicated separate profile due to shared bytecode.

I imagine this problem could be solved in C2?

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

PR Comment: https://git.openjdk.org/jdk/pull/28081#issuecomment-3479580015

From pminborg at openjdk.org  Mon Nov  3 09:34:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 3 Nov 2025 09:34:08 GMT
Subject: RFR: 8370822: Improve performance for MemorySegment::fill
In-Reply-To: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
References: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
Message-ID: <-ipvW3A0ZZd0ftuLrHR8P2tZoXdqvCjIvly3SJbyf8g=.55b6d945-f145-492d-b678-71d2223f8c85@github.com>

On Wed, 29 Oct 2025 00:01:57 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> The manual byte-replication expression replaced with the multiplicative expansion trick - a more compact and efficient equivalent.

Marked as reviewed by pminborg (Reviewer).

It should be noted that there are existing tests covering these changes.

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

PR Review: https://git.openjdk.org/jdk/pull/28031#pullrequestreview-3410142385
PR Comment: https://git.openjdk.org/jdk/pull/28031#issuecomment-3479629459

From pminborg at openjdk.org  Mon Nov  3 09:34:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 3 Nov 2025 09:34:10 GMT
Subject: RFR: 8370822: Improve performance for MemorySegment::fill
In-Reply-To: <5vKlNQaNHB4KEQpjt1eWqRtSEcWOA_nyBmMSSdwFjss=.e4b9b1ba-870d-4785-8b5a-41fc8b216906@github.com>
References: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
 <5vKlNQaNHB4KEQpjt1eWqRtSEcWOA_nyBmMSSdwFjss=.e4b9b1ba-870d-4785-8b5a-41fc8b216906@github.com>
Message-ID: <jQRMmewMAKE2gx4if8LUP1hnhrqElIt1BPipz7pq-K0=.109e9143-f2ac-421f-b990-b134e2c6846d@github.com>

On Fri, 31 Oct 2025 16:10:28 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> The manual byte-replication expression replaced with the multiplicative expansion trick - a more compact and efficient equivalent.
>
> Here is syntactic example 
> 
> Before
> <img width="2413" height="902" alt="before" src="https://github.com/user-attachments/assets/3a1f83d0-be8a-48a5-a7e0-217334f01ac7" />
> 
> After
> <img width="2413" height="902" alt="after" src="https://github.com/user-attachments/assets/ea062b60-8ad1-4572-9b3b-e7ef203065ee" />

Thanks for the example @hextriclosan. I think the data you presented looks promising.

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

PR Comment: https://git.openjdk.org/jdk/pull/28031#issuecomment-3479614788

From rgiulietti at openjdk.org  Mon Nov  3 09:52:36 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Nov 2025 09:52:36 GMT
Subject: Integrated: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal
In-Reply-To: <UyMRxMDdGrHmPNpstQHpSC_1OaIYbvVbKidPH-lQwmY=.acfd4a49-3d59-4c54-bf3f-f99e6b7da85b@github.com>
References: <UyMRxMDdGrHmPNpstQHpSC_1OaIYbvVbKidPH-lQwmY=.acfd4a49-3d59-4c54-bf3f-f99e6b7da85b@github.com>
Message-ID: <hECt74AenrDUQV03ov8fYSIBzQAjHhblzmJIS9rRpb4=.3ac441c8-4f45-4c77-8a77-52200ac7c292@github.com>

On Thu, 28 Aug 2025 15:24:21 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.

This pull request has now been integrated.

Changeset: deb7edb1
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/deb7edb151fd5940fdf9fdb2a6356080ee94e222
Stats:     3011 lines in 9 files changed: 812 ins; 1422 del; 777 mod

8366017: Extend the set of inputs handled by fast paths in FloatingDecimal

Reviewed-by: darcy

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

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

From duke at openjdk.org  Mon Nov  3 10:08:34 2025
From: duke at openjdk.org (duke)
Date: Mon, 3 Nov 2025 10:08:34 GMT
Subject: RFR: 8370822: Improve performance for MemorySegment::fill
In-Reply-To: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
References: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
Message-ID: <xVza_x3OpBuLPCJt9zPE7mjbVVfDKN6CGKowA83G1UY=.dc16cb98-9688-42b7-a957-3d6d57fa0b76@github.com>

On Wed, 29 Oct 2025 00:01:57 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> The manual byte-replication expression replaced with the multiplicative expansion trick - a more compact and efficient equivalent.

@hextriclosan 
Your change (at version e3016f39766780efb6705e23b7481aeb311f220f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28031#issuecomment-3479751481

From duke at openjdk.org  Mon Nov  3 10:08:33 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Mon, 3 Nov 2025 10:08:33 GMT
Subject: RFR: 8370822: Improve performance for MemorySegment::fill
In-Reply-To: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
References: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
Message-ID: <poZ7-mclc11dCJiLv8pRhi7l-pblB39gU6WsH7QRtYg=.04613957-18c5-4986-92af-7b0c3ca8991d@github.com>

On Wed, 29 Oct 2025 00:01:57 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> The manual byte-replication expression replaced with the multiplicative expansion trick - a more compact and efficient equivalent.

Some of existing key-tests:
[TestFill.java](https://github.com/openjdk/jdk/blob/deb7edb151fd5940fdf9fdb2a6356080ee94e222/test/jdk/java/foreign/TestFill.java#L51)
[TestSegments.java](https://github.com/openjdk/jdk/blob/deb7edb151fd5940fdf9fdb2a6356080ee94e222/test/jdk/java/foreign/TestSegments.java#L288)
[SegmentBulkFill.java](https://github.com/openjdk/jdk/blob/400f51f7ab19c2dc6a4195f78f9f815d03dd4434/test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java)

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

PR Comment: https://git.openjdk.org/jdk/pull/28031#issuecomment-3479746354

From liach at openjdk.org  Mon Nov  3 13:00:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Nov 2025 13:00:17 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles [v2]
In-Reply-To: <pwKe8EH7GPxN4ON7mTUEaugxivWt88ekV5y0K13X8E0=.0e25f964-6c79-4dda-a834-37015900d60f@github.com>
References: <VzazfJzfurzijFp8QMZRVxWjqPl24jt2mzkpTY5tomg=.b2ffa9d3-4a8e-49ac-817d-19b656f9bbc7@github.com>
 <qnuJ3cdLbbPQ-T0n6f3vRj4WyrnQ0O9EKTD60zgvQu8=.20badd28-dfe3-4d2b-82b3-6f215ef18708@github.com>
 <juge8I6ojSRWt0kn9bm4Dc4TQ_Bl0TKS74GjdE1v1UM=.c4862591-5153-4afc-8cd9-545d460c4c26@github.com>
 <pwKe8EH7GPxN4ON7mTUEaugxivWt88ekV5y0K13X8E0=.0e25f964-6c79-4dda-a834-37015900d60f@github.com>
Message-ID: <pmIb60haRTqfjTH9zGIK83F_j6sKUW_YVvvrD7OU2J4=.dcfc2e80-0c4e-4fc7-8039-9f0274eecee8@github.com>

On Mon, 3 Nov 2025 09:16:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> I imagine this problem could be solved in C2?

The root cause here is C2 is generating subpar code due to it not able to obtain specialized/inlined profiling data. We must fix it by updating the profiling data structure.

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

PR Comment: https://git.openjdk.org/jdk/pull/28081#issuecomment-3480396725

From swen at openjdk.org  Mon Nov  3 13:07:09 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Nov 2025 13:07:09 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v8]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <GUo0UeaTPxG7Ruun5UEiE9fYMqWUEJV2Ri4MYYLfSJI=.b4c014b6-db29-49d0-bd1f-073d75ca30d0@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  appendPair instead of appendLatin1(char, char)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/287fdb8d..62085919

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=06-07

  Stats: 29 lines in 4 files changed: 5 ins; 12 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

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

From hgreule at openjdk.org  Mon Nov  3 13:20:57 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 3 Nov 2025 13:20:57 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles [v2]
In-Reply-To: <pmIb60haRTqfjTH9zGIK83F_j6sKUW_YVvvrD7OU2J4=.dcfc2e80-0c4e-4fc7-8039-9f0274eecee8@github.com>
References: <VzazfJzfurzijFp8QMZRVxWjqPl24jt2mzkpTY5tomg=.b2ffa9d3-4a8e-49ac-817d-19b656f9bbc7@github.com>
 <qnuJ3cdLbbPQ-T0n6f3vRj4WyrnQ0O9EKTD60zgvQu8=.20badd28-dfe3-4d2b-82b3-6f215ef18708@github.com>
 <juge8I6ojSRWt0kn9bm4Dc4TQ_Bl0TKS74GjdE1v1UM=.c4862591-5153-4afc-8cd9-545d460c4c26@github.com>
 <pwKe8EH7GPxN4ON7mTUEaugxivWt88ekV5y0K13X8E0=.0e25f964-6c79-4dda-a834-37015900d60f@github.com>
 <pmIb60haRTqfjTH9zGIK83F_j6sKUW_YVvvrD7OU2J4=.dcfc2e80-0c4e-4fc7-8039-9f0274eecee8@github.com>
Message-ID: <RI_av5Pjg99LVyOm_72fONP8ZiT7RzZVqtYs8gGQ8fA=.a1e12abf-e503-45bb-bba4-129cc8a6a72b@github.com>

On Mon, 3 Nov 2025 12:57:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> > I imagine this problem could be solved in C2?
> 
> The root cause here is C2 is generating subpar code due to it not able to obtain specialized/inlined profiling data. We must fix it by updating the profiling data structure.

I don't think this is a problem for static methods that don't call non-static methods (that's the problem of Objects::equals etc). The only case that could be relevant is when a bytecode can result in an exception (e.g., div by zero). But without seeing any conclusive benchmarks, that really shouldn't be a blocker.

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

PR Comment: https://git.openjdk.org/jdk/pull/28081#issuecomment-3480480052

From swen at openjdk.org  Mon Nov  3 13:53:08 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Nov 2025 13:53:08 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v9]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <S_XsDL7_BNoNszaKCACYMbY_Jk_sEVSuSqenYX_w0eM=.0575f8e7-200c-40ef-a1fe-dec7f4e58320@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - appendPair instead of appendLatin1(char, char)
 - Revert "appendPair instead of append(char, char)"
   
   This reverts commit d969a235e54da4ac96b7205982624f52305cae31.
 - appendPair instead of append(char, char)
 - Update test/jdk/jdk/internal/util/DecimalDigitsTest.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
 - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding
 - Use DecimalDigits.appendPair for formatting in time classes
   
   This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values.
   
   Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies.
   
   Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>
 - Optimize year formatting in DateTimeHelper by reducing modulo operation
   
   Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>
   
   Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair.
 - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality.
   
   Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ef464d69...c480aebb

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

Changes: https://git.openjdk.org/jdk/pull/26911/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=08
  Stats: 192 lines in 10 files changed: 161 ins; 4 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

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

From duke at openjdk.org  Mon Nov  3 14:21:32 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Mon, 3 Nov 2025 14:21:32 GMT
Subject: Integrated: 8370822: Improve performance for MemorySegment::fill
In-Reply-To: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
References: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
Message-ID: <-Ho46Tr8F8GDb-3lvRlmkSc1R0EVadR_qHO0qCSzTu4=.4c8779d8-373d-4e0c-9111-073b65aef694@github.com>

On Wed, 29 Oct 2025 00:01:57 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> The manual byte-replication expression replaced with the multiplicative expansion trick - a more compact and efficient equivalent.

This pull request has now been integrated.

Changeset: 8dbefc53
Author:    Igor Rudenko <iostream64 at gmail.com>
Committer: Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8dbefc53a95c6e3f722082316157c6372737c162
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8370822: Improve performance for MemorySegment::fill

Reviewed-by: pminborg

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

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

From jlahoda at openjdk.org  Mon Nov  3 14:51:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 3 Nov 2025 14:51:36 GMT
Subject: RFR: 8359145: Implement JEP 530: Primitive Types in Patterns,
 instanceof, and switch (Fourth Preview) [v4]
In-Reply-To: <S49bQj7470tHw9Kh4pYr1CgL-iOfCT8rUnlITvg4plQ=.099676a1-b5db-4d8d-8164-dbc04d082d0b@github.com>
References: <jFMc8Al_l5YNHDNvxZvTvffEVNoyCCS9pQePV0GISDQ=.77ea3404-94f0-4431-b09f-0336c78439db@github.com>
 <S49bQj7470tHw9Kh4pYr1CgL-iOfCT8rUnlITvg4plQ=.099676a1-b5db-4d8d-8164-dbc04d082d0b@github.com>
Message-ID: <LHMFQFq6XWzuCHmXkEqz3GngipcYinnpteD1AZyMPvc=.a427580e-6555-4d63-8a92-889e559270e9@github.com>

On Thu, 30 Oct 2025 12:50:14 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> PR for Primitive Types in Patterns, instanceof, and switch (Fourth Preview).
>> 
>> spec: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix regression in Check

Looks OK to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27637#pullrequestreview-3411387946

From headius at headius.com  Mon Nov  3 15:55:33 2025
From: headius at headius.com (Charles Oliver Nutter)
Date: Mon, 3 Nov 2025 09:55:33 -0600
Subject: JDBC DriverManager never updated for system classloader?
In-Reply-To: <ad737850-ea05-4f63-b5d9-8c31aa86a1af@oracle.com>
References: <CAE-f1xTuCiv0nGOz0u_8SHEnUNops5VsSh-zBRHY_M_7CQeeDA@mail.gmail.com>
 <ad737850-ea05-4f63-b5d9-8c31aa86a1af@oracle.com>
Message-ID: <CAE-f1xQwWynLEgh+0+dO=Pto42_a6vo6rcZWz39fvhMPF7HddQ@mail.gmail.com>

On Sun, Nov 2, 2025 at 3:08?AM Alan Bateman <alan.bateman at oracle.com> wrote:

> I don't think it's possible to engage on the question as to why
> DriverManager does a visibility check.  The discovery and and driver
> registration in this API date back to early JDK releases and have been
> very problematic to secure.  I think (need Lance to confirm) that the
> hope was that the eco system would move to DataSource but it seems there
> is still a lot of usage of DriverManager.
>

I don't want to get into that quagmire either. I know this code is from the
distant past and has been troublesome to migrate forward.

However, I think the intent of the code can be restored with a simple patch:

```diff
diff --git a/src/java.sql/share/classes/java/sql/DriverManager.java
b/src/java.sql/share/classes/java/sql/DriverManager.java
index 2f51dee5e70..328d5f19946 100644
--- a/src/java.sql/share/classes/java/sql/DriverManager.java
+++ b/src/java.sql/share/classes/java/sql/DriverManager.java
@@ -588,7 +588,9 @@ private static Connection getConnection(
          * or bundled with an application, is found.
          */
         ClassLoader callerCL = caller != null ? caller.getClassLoader() :
null;
-        if (callerCL == null || callerCL ==
ClassLoader.getPlatformClassLoader()) {
+        if (callerCL == null ||
+                callerCL == ClassLoader.getSystemClassLoader() ||
+                callerCL == ClassLoader.getPlatformClassLoader()) {
             callerCL = Thread.currentThread().getContextClassLoader();
         }
 ```

I believe the original goal of the `callerCL == null` check was to allow
driver load requests from the system/boot classloader to fall back on the
thread context classloader, since such classes used to have
`getClassLoader` as null. But with the module change, that classloader is
now an instance of `ClassLoaders::AppClassLoader` and neither null nor ==
`getPlatformClassLoader`. My patch above restores the original intent by
also checking if the callerCL is the same classloader as
`getSystemClassLoader`, the default base application classloader now.

This change fixes the reported issue:

```
$ JAVA_HOME=build/macosx-aarch64-server-release/images/jdk/ jruby -r
'jdbc/sqlite3' -e 'Jdbc::SQLite3.load_driver' -e
'java.sql.DriverManager.get_connection("jdbc:sqlite:local.db")'
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by
org.sqlite.SQLiteJDBCLoader in an unnamed module
(file:/Users/headius/work/jruby/lib/ruby/gems/shared/gems/jdbc-sqlite3-3.46.1.1/lib/sqlite-jdbc-3.46.1.1.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for
callers in this module
WARNING: Restricted methods will be blocked in a future release unless
native access is enabled
```
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251103/dea89bd7/attachment-0001.htm>

From swen at openjdk.org  Mon Nov  3 15:55:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Nov 2025 15:55:45 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v10]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <AVFDMjhvz_j3cJxzKxkcPINYx0MD-Um6_3oQmXtB4Ko=.3fe3354f-f7be-40cb-b8aa-dee063161de6@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - appendPair instead of appendLatin1(char, char)
 - Revert "appendPair instead of append(char, char)"
   
   This reverts commit d969a235e54da4ac96b7205982624f52305cae31.
 - appendPair instead of append(char, char)
 - Update test/jdk/jdk/internal/util/DecimalDigitsTest.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
 - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding
 - Use DecimalDigits.appendPair for formatting in time classes
   
   This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values.
   
   Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies.
   
   Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>
 - Optimize year formatting in DateTimeHelper by reducing modulo operation
   
   Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>
   
   Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/02a72174...678e3066

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

Changes: https://git.openjdk.org/jdk/pull/26911/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=09
  Stats: 192 lines in 10 files changed: 161 ins; 4 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

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

From rriggs at openjdk.org  Mon Nov  3 16:03:07 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 3 Nov 2025 16:03:07 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v10]
In-Reply-To: <AVFDMjhvz_j3cJxzKxkcPINYx0MD-Um6_3oQmXtB4Ko=.3fe3354f-f7be-40cb-b8aa-dee063161de6@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <AVFDMjhvz_j3cJxzKxkcPINYx0MD-Um6_3oQmXtB4Ko=.3fe3354f-f7be-40cb-b8aa-dee063161de6@github.com>
Message-ID: <T4B4zl5WbyhHu2_p1SEZsNgR0sVZOe635u1zFzLlrE4=.6319c522-3500-4102-bae2-c860b1621fa3@github.com>

On Mon, 3 Nov 2025 15:55:45 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into appendPair_202508
>  - Merge remote-tracking branch 'upstream/master' into appendPair_202508
>  - appendPair instead of appendLatin1(char, char)
>  - Revert "appendPair instead of append(char, char)"
>    
>    This reverts commit d969a235e54da4ac96b7205982624f52305cae31.
>  - appendPair instead of append(char, char)
>  - Update test/jdk/jdk/internal/util/DecimalDigitsTest.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Merge remote-tracking branch 'upstream/master' into appendPair_202508
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
>  - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding
>  - Use DecimalDigits.appendPair for formatting in time classes
>    
>    This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values.
>    
>    Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies.
>    
>    Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>
>  - Optimize year formatting in DateTimeHelper by reducing modulo operation
>    
>    Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>
>    
>    Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/02a72174...678e3066

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 918:

> 916:             Unsafe unsafe = Unsafe.getUnsafe();
> 917:             unsafe.putChar(value, Unsafe.ARRAY_BYTE_BASE_OFFSET + count, c1);
> 918:             unsafe.putChar(value, Unsafe.ARRAY_BYTE_BASE_OFFSET + count + 1, c2);

Do not introduce Unsafe usage; regular array access is adequate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2487009000

From fbredberg at openjdk.org  Mon Nov  3 16:24:32 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 3 Nov 2025 16:24:32 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
Message-ID: <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>

On Thu, 30 Oct 2025 15:54:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment and assert msg

A truly useful enhancement! Just had a few questions / suggestions.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 762:

> 760:   load_const_optimized(bad, 0xbad0101babe00000);
> 761:   for (uint32_t i = 1; i < (sizeof(regs) / sizeof(Register)); i++) {
> 762:     addi(regs[i], regs[0], regs[i]->encoding());

Guess it's a question for @reinrich, but why set up `bad = regs[0]` and then still use `regs[0]` instead of `bad`? 
I think using `bad` would make the code easier to understand than using `regs[0]`.
Suggestion:

    addi(regs[i], bad, regs[i]->encoding());

src/hotspot/share/interpreter/linkResolver.cpp line 1689:

> 1687:   EXCEPTION_MARK;
> 1688:   CallInfo info;
> 1689:   resolve_static_call(info, link_info, ClassInitMode::dont_init, THREAD);

Couldn't you just do `CHECK_AND_CLEAR_NULL` and skip the following `if (HAS_PENDING_EXCEPTION)` statement?

Suggestion:

  resolve_static_call(info, link_info, ClassInitMode::dont_init, CHECK_AND_CLEAR_NULL);

I see the same in functions both above and below this one, is there any reason for this?

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

Marked as reviewed by fbredberg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3411212227
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487050754
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2486618754

From daniel.peintner at gmail.com  Mon Nov  3 16:43:38 2025
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Mon, 3 Nov 2025 17:43:38 +0100
Subject: [jpackage] JDK25 no longer takes into account --mac-package-identifier
Message-ID: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>

Hi,

I am about to switch a JavaFX project from JDK21 to JDK25 and I noticed a
problem when running jpackage.

My domain has a hyphen, like in www.my-domain.com
Hence, my Java package reads like this: com.my_domain.project
Note: hyphen becomes underscore.

Running vanilla jpackage in JDK21 complained with
Invalid Mac-Bundle-ID [com.my_domain.project]
due to the *invalid* underscore and suggests me to use
"--mac-package-identifier"

Hence, I added --mac-package-identifier com.my-domain.project (with the
hyphen again)
All good so far.

Running the same code with JDK25 with the above settings shows the error
message again
Invalid Mac-Bundle-ID [com.my_domain.project]

I can add any argument to  --mac-package-identifier
It seems it is simply not taken into account.

I am using JDK 25.0.1

Is this a known issue with JDK25 and jpackage?
Is there any other way to make jpackage work?

Thanks,

-- Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251103/92d3cf9b/attachment.htm>

From pchilanomate at openjdk.org  Mon Nov  3 16:49:12 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 16:49:12 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
Message-ID: <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>

On Thu, 30 Oct 2025 22:47:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bug number in tests
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Fix looks good to me. Only have some comments about the JVMTI agent case, thanks.

src/hotspot/share/prims/scopedMemoryAccess.cpp line 53:

> 51: #endif
> 52: 
> 53:   bool agents_loaded = JvmtiAgentList::has_agents();

I see that for dynamically loaded agents we add to the list after loading the agent. Maybe we should check `JvmtiEnvBase::environments_might_exist()`?

src/hotspot/share/prims/scopedMemoryAccess.cpp line 94:

> 92: 
> 93: static bool is_accessing_session(JavaThread* jt, oop session, bool& in_scoped) {
> 94:   if (jt->is_throwing_unsafe_access_error()) {

If we assume arbitrary Java code in JVMTI callbacks this might return true but the target could be in a different nested scoped access. I think we should check we are in the no agent case before bailing out.

src/hotspot/share/runtime/javaThread.hpp line 1364:

> 1362:   JavaThread* _thread;
> 1363: public:
> 1364:   ThrowingUnsafeAccessError(JavaThread* thread) : _thread(thread) {

If we assume arbitrary Java code in JVMTI callbacks this could be executed recursively and `_throwing_unsafe_access_error` be set to false while we are within the outer caller. Although it?s fine since we will do a full stack walk in `is_accessing_session`, we should add a comment why this recursive case is okay (or save the old value as with `UnlockFlagSaver`).

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

PR Review: https://git.openjdk.org/jdk/pull/27919#pullrequestreview-3411931601
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487147887
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487150214
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487152847

From bpb at openjdk.org  Mon Nov  3 17:20:24 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Nov 2025 17:20:24 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v13]
In-Reply-To: <CHNRyeypVOH9EVu0x3RtbA1MFymkyHCpjV_QVn7Zv6M=.e1fbcc16-eab9-4b9c-9d86-bd66cf6279e9@github.com>
References: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
 <WLtVTuAmgZ8kZLoYi6RTr_i5Ib6BDZWfkfEwhVUvsNo=.a2337ed6-53ce-4667-994a-7bbac5e6af45@github.com>
 <CHNRyeypVOH9EVu0x3RtbA1MFymkyHCpjV_QVn7Zv6M=.e1fbcc16-eab9-4b9c-9d86-bd66cf6279e9@github.com>
Message-ID: <m_zl5kc2Mp-I-qUFSA3JQLn9StA95n4hMCWx-uXyhAc=.44f7495a-5cd1-4452-9e31-e4dfbaff7a85@github.com>

On Sat, 1 Nov 2025 07:35:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you'll run tier1+tier2 at least before integrating.

Certainly. There is still a weird test failure that I am investigating to determine whether it is related to the change. Otherwise tiers 1-3 are clear.

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

PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3481648678

From swen at openjdk.org  Mon Nov  3 17:23:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Nov 2025 17:23:51 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v11]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <C_8ZsjEny0Fmq1A9caGpVrU6-kzWDhq5b12-bGxRXSg=.40a0d3f7-72c7-42ec-8b60-3428f6678694@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Fix JavaLangAccess.appendLatin1 javadoc to match method signature
  
  The previous javadoc incorrectly described the method as appending a two-digit
  integer representation, but the method actually appends two Latin-1 characters.
  Updated the documentation to accurately reflect the method's behavior.
  
  Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/678e3066..5c9255c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=09-10

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

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

From jvernee at openjdk.org  Mon Nov  3 17:27:51 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Nov 2025 17:27:51 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
 <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
Message-ID: <wc9AKkQdn5XPWl1uDJJ96_UK4txqrhUx2-tIfVqfFYU=.2c930d46-2cca-4bd7-a2df-2a830e48729e@github.com>

On Mon, 3 Nov 2025 16:40:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update bug number in tests
>>   
>>   Co-authored-by: Chen Liang <liach at openjdk.org>
>
> src/hotspot/share/prims/scopedMemoryAccess.cpp line 94:
> 
>> 92: 
>> 93: static bool is_accessing_session(JavaThread* jt, oop session, bool& in_scoped) {
>> 94:   if (jt->is_throwing_unsafe_access_error()) {
> 
> If we assume arbitrary Java code in JVMTI callbacks this might return true but the target could be in a different nested scoped access. I think we should check we are in the no agent case before bailing out.

My assumption is that once an unsafe access error is thrown, we don't expect execution to continue. I suppose it is technically possible to catch the exception, either in Java code or in the native agent code, and then try to continue execution, but the program would be in an undefined state at that point already. In other words, I don't think anyone should be continuing execution after this exception happens.

Although, it doesn't seem like a bad idea to keep walking here as a fail safe.

> src/hotspot/share/runtime/javaThread.hpp line 1364:
> 
>> 1362:   JavaThread* _thread;
>> 1363: public:
>> 1364:   ThrowingUnsafeAccessError(JavaThread* thread) : _thread(thread) {
> 
> If we assume arbitrary Java code in JVMTI callbacks this could be executed recursively and `_throwing_unsafe_access_error` be set to false while we are within the outer caller. Although it?s fine since we will do a full stack walk in `is_accessing_session`, we should add a comment why this recursive case is okay (or save the old value as with `UnlockFlagSaver`).

That's a good point. Since this is otherwise unrelated code, I'll make it safe for the re-entrant case as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487300422
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487303301

From jvernee at openjdk.org  Mon Nov  3 17:30:46 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Nov 2025 17:30:46 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
 <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
Message-ID: <Y1RX9Z66oh6zBx-R1qpxgKUWY7gnRsJearZkyGyVoDg=.b20194ab-e028-4e72-a38b-c177b315c690@github.com>

On Mon, 3 Nov 2025 16:39:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update bug number in tests
>>   
>>   Co-authored-by: Chen Liang <liach at openjdk.org>
>
> src/hotspot/share/prims/scopedMemoryAccess.cpp line 53:
> 
>> 51: #endif
>> 52: 
>> 53:   bool agents_loaded = JvmtiAgentList::has_agents();
> 
> I see that for dynamically loaded agents we add to the list after loading the agent. Maybe we should check `JvmtiEnvBase::environments_might_exist()`?

Ah, thanks for the suggestion. I thought there might have been a way to check this already, but I couldn't find it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487315255

From cushon at openjdk.org  Mon Nov  3 18:01:14 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 3 Nov 2025 18:01:14 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v3]
In-Reply-To: <4AH-S5IP_abXOC121l0tB0oZWkXp8l4SmsN2w1sGlu0=.ad194b1f-ce60-4e16-b905-8ec8ce5dfb77@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <dqiRA1Cf-B0mnv2eZPWk0yrnd4CxrAWHHTITkpkGcBI=.15e7b58d-210d-4133-bbb4-eeb175a98c77@github.com>
 <_gORgVPPc2dmXVkRgjww36Z_6B80xoFP8MSDab7scZQ=.2ea4b41e-63bc-46d8-9608-a59602a66876@github.com>
 <TvrN7fAdIhb83QbP1GNwOBIFPZYmqcgQtkggJy8I6KE=.5f426b30-7864-4120-9bc4-b3cfcf927f74@github.com>
 <r9CSW0jDsnodAXtbpS7K39oNMXFdPWZpiyuW48Paxd8=.53d4d9ac-0d9d-4d9a-b9c1-a07623e0a477@github.com>
 <4AH-S5IP_abXOC121l0tB0oZWkXp8l4SmsN2w1sGlu0=.ad194b1f-ce60-4e16-b905-8ec8ce5dfb77@github.com>
Message-ID: <WiVNwFLXGy1ICUN13QKIjzhBmH-fDZI92YUL24fNsSQ=.dca402ab-4c57-4a4a-91a5-dc45822e2279@github.com>

On Wed, 29 Oct 2025 22:46:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> A user can easily convert between one or the other length representation by multiplying/dividing by the right scalar
>> 
>> That is true of e.g. UTF-16 but not of UTF-8, since the encoding is variable width and doing the conversion from bytes to characters is more expensive there.
>> 
>>> Either way, we felt that it would be a good idea if you could send an email to panama-dev in which you describe your exact use case, before getting further into the code review. That would give others a chance to respond with their use cases as well.
>> 
>> Sounds good, thanks, I can start a thread discussing the use-case here at a higher level.
>
>> > A user can easily convert between one or the other length representation by multiplying/dividing by the right scalar
>> 
>> That is true of e.g. UTF-16 but not of UTF-8, since the encoding is variable width and doing the conversion from bytes to characters is more expensive there.
> 
> Sorry, I don't mean 'character' but 'code unit'. For instance, when reading a UTF-8 string, the unit would be one byte, for UTF-16 it would be two, for UTF-32 four. So a user would just need to divide by the unit size, at least that's the idea.

> I can start a thread discussing the use-case here at a higher level.

Done: https://mail.openjdk.org/pipermail/panama-dev/2025-November/021182.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2487389933

From bpb at openjdk.org  Mon Nov  3 18:09:31 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Nov 2025 18:09:31 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v3]
In-Reply-To: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
Message-ID: <3qJ75D8p2yA6Dm_m0QjVS-S0WlWP6XXEj7wF1CmUWcU=.73d8689f-acc5-4b9d-9a22-b2f64fb6932d@github.com>

> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8367943: Address reviewer comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28078/files
  - new: https://git.openjdk.org/jdk/pull/28078/files/06f0a11a..40d5af81

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

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

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

From bpb at openjdk.org  Mon Nov  3 18:09:33 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Nov 2025 18:09:33 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v2]
In-Reply-To: <KAK_Wyrz5LMaeko805o_e_MER129by0oE6Y8usPc4gU=.509dd8ab-baf8-4518-98f0-20200c3d5791@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
 <fstJg2ArWCTFddFGye-lNCQDggIOT1j_qrckztj3hQ4=.457f2981-a197-414f-9fc6-5ab30681dcd0@github.com>
 <KAK_Wyrz5LMaeko805o_e_MER129by0oE6Y8usPc4gU=.509dd8ab-baf8-4518-98f0-20200c3d5791@github.com>
Message-ID: <ggOSQysae1Gj_F4cIx5PajCMKSt49qwNB4quHrwO-no=.a7099bb8-8901-4795-8f94-bca7eb3009f5@github.com>

On Sat, 1 Nov 2025 08:25:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> if len is not zero, then it blocks until all bytes are written

So changed in commit 40d5af8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28078#discussion_r2487405390

From bpb at openjdk.org  Mon Nov  3 18:09:35 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Nov 2025 18:09:35 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v2]
In-Reply-To: <c4x28-Z3462tdyeqd_lHYYOgCxPfBXYQF4YfjhVTOts=.0d6923c0-8a1e-498a-91f6-751b8073e3a3@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
 <fstJg2ArWCTFddFGye-lNCQDggIOT1j_qrckztj3hQ4=.457f2981-a197-414f-9fc6-5ab30681dcd0@github.com>
 <c4x28-Z3462tdyeqd_lHYYOgCxPfBXYQF4YfjhVTOts=.0d6923c0-8a1e-498a-91f6-751b8073e3a3@github.com>
Message-ID: <A6TK3r5TOkFVARftcyG8lWkHjcGVk2rwArF7dLyVTQU=.1cd163c9-9fd5-4f9a-9af8-dcc9f4e71bfa@github.com>

On Sat, 1 Nov 2025 07:24:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Should we add one more test which closes the `PipedOutputStream` and attempts this write?

In commit 40d5af8, I changed the test to better match the revision rather than adding another test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28078#discussion_r2487404129

From jvernee at openjdk.org  Mon Nov  3 18:29:43 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Nov 2025 18:29:43 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
Message-ID: <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Review comments Patricio

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27919/files
  - new: https://git.openjdk.org/jdk/pull/27919/files/7a793468..9e7e59b8

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

  Stats: 13 lines in 3 files changed: 5 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27919/head:pull/27919

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

From alexey.semenyuk at oracle.com  Mon Nov  3 18:30:48 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 3 Nov 2025 13:30:48 -0500
Subject: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
Message-ID: <6184b277-b030-4300-a319-81764ecac698@oracle.com>

Hi Daniel,

I can not reproduce the issue you experience with jdk25.0.1:

---
$ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest 
output --type app-image --main-jar hello.jar --main-class 
com.my_domain.project.Hello --mac-package-identifier com.my-domain.project
$ echo $?
0
---

If I run the same command line without ` --mac-package-identifier` 
option it fails as expected:
---
$ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest 
output --type app-image --main-jar hello.jar --main-class 
com.my_domain.project.Hello
Bundler Mac Application Image skipped because of a configuration 
problem: invalid mac bundle identifier [com.my_domain.project].
Advice to fix: specify identifier with "--mac-package-identifier".
---

The same failure for `--mac-package-identifier com.my_domain.project` 
(with the underscore):
---
$ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest 
output --type app-image --main-jar hello.jar --main-class 
com.my_domain.project.Hello --mac-package-identifier com.my_domain.project
Bundler Mac Application Image skipped because of a configuration 
problem: invalid mac bundle identifier [com.my_domain.project].
Advice to fix: specify identifier with "--mac-package-identifier".
---

Any chance you accidentally put the string with the underscore instead 
of the hyphen as a value of the `--mac-package-identifier` option on 
your command line?

- Alexey

On 11/3/2025 11:43 AM, Daniel Peintner wrote:
> Hi,
>
> I am about to switch a JavaFX project from JDK21 to JDK25 and I 
> noticed a problem when running jpackage.
>
> My domain has a hyphen, like in www.my-domain.com 
> <http://www.my-domain.com>
> Hence, my Java package reads like this: com.my_domain.project
> Note: hyphen becomes underscore.
>
> Running vanilla jpackage in JDK21 complained with
> Invalid Mac-Bundle-ID [com.my_domain.project]
> due to the *invalid* underscore and suggests me to use 
> "--mac-package-identifier"
>
> Hence, I added --mac-package-identifier com.my-domain.project (with 
> the hyphen again)
> All good so far.
>
> Running the same code with JDK25 with the above settings shows the 
> error message again
> Invalid Mac-Bundle-ID [com.my_domain.project]
>
> I can add any argument to --mac-package-identifier
> It seems it is simply not taken into account.
>
> I am using JDK 25.0.1
>
> Is this a known issue with?JDK25 and jpackage?
> Is there any other way to make jpackage work?
>
> Thanks,
>
> -- Daniel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251103/e9aa836a/attachment.htm>

From rrich at openjdk.org  Mon Nov  3 18:33:52 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 3 Nov 2025 18:33:52 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
 <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
Message-ID: <KWU0IKs1p_d8pneJNoXJUq_btwtXVmAoHgh3SBIUYTw=.3f8c5c6f-9b22-4976-a7bb-c3819c6fac38@github.com>

On Mon, 3 Nov 2025 16:11:38 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment and assert msg
>
> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 762:
> 
>> 760:   load_const_optimized(bad, 0xbad0101babe00000);
>> 761:   for (uint32_t i = 1; i < (sizeof(regs) / sizeof(Register)); i++) {
>> 762:     addi(regs[i], regs[0], regs[i]->encoding());
> 
> Guess it's a question for @reinrich, but why set up `bad = regs[0]` and then still use `regs[0]` instead of `bad`? 
> I think using `bad` would make the code easier to understand than using `regs[0]`.
> Suggestion:
> 
>     addi(regs[i], bad, regs[i]->encoding());

Thanks for looking at the ppc part @fbredber 
Your suggestion is good. I think the loop should be reversed too. Then the addi after it can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487475002

From rrich at openjdk.org  Mon Nov  3 18:38:06 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 3 Nov 2025 18:38:06 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
Message-ID: <RvS8-qNisqNghcBV_fQ8tKBuABKyVRF49jMxsC8XogA=.5a3376df-e4dc-40ce-bedb-836c77deaf56@github.com>

On Thu, 30 Oct 2025 15:54:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment and assert msg

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 764:

> 762:     addi(regs[i], regs[0], regs[i]->encoding());
> 763:   }
> 764:   addi(regs[0], regs[0], regs[0]->encoding());

Based on @fbredber's suggestion:
Suggestion:

  load_const_optimized(bad, 0xbad0101babe00000);
  for (int i = (sizeof(regs) / sizeof(Register)) - 1; i >= 0; i--) {
    addi(regs[i], bad, regs[i]->encoding());
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487483352

From naoto at openjdk.org  Mon Nov  3 18:42:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Nov 2025 18:42:01 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v2]
In-Reply-To: <YHtlduwfyfFMcdTFF5_xg6NHC6Fb784snhddwlV35Wo=.7975ff5e-5231-42b3-90e8-4503c376da54@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
 <9VpoTyAJ3oQwtSpHO6sCVwaWA_Jx3B91DS2oxOTTTcI=.afc95ec9-c937-44e8-9a0c-9b087dd3c4ff@github.com>
 <YHtlduwfyfFMcdTFF5_xg6NHC6Fb784snhddwlV35Wo=.7975ff5e-5231-42b3-90e8-4503c376da54@github.com>
Message-ID: <NaqWRsnchf6TXPIkGGeIioqV7iLuRfIeiYzYWB4_Y_w=.a88279e9-7907-44b2-8715-5fbb4b86f2dd@github.com>

On Sat, 1 Nov 2025 16:23:18 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   .md files
>
> make/data/cldr/common/main/tok.xml line 444:
> 
>> 442: 					<dateFormatLength type="long">
>> 443: 						<dateFormat>
>> 444: 							<pattern>'tenpo' 'sike' #y 'la' 'tenpo' MMMM 'la' 'tenpo' 'suno' #d</pattern>
> 
> I think `DateTimeFormatter` doesn't handle the new patterns for `tok`, I am seeing the following crash with these changes:
> 
> 
> jshell> Instant.parse("2018-07-16T23:58:59.000000200Z").atZone(ZoneId.of("UTC")).format(DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG).withLocale(Locale.of("tok")))
> |  Exception java.lang.IllegalArgumentException: Pattern includes reserved character: '#'
> |        at DateTimeFormatterBuilder.parsePattern (DateTimeFormatterBuilder.java:2056)
> |        at DateTimeFormatterBuilder.appendPattern (DateTimeFormatterBuilder.java:1910)
> |        at DateTimeFormatterBuilder$LocalizedPrinterParser.lambda$formatter$0 (DateTimeFormatterBuilder.java:5181)
> |        at ConcurrentHashMap.computeIfAbsent (ConcurrentHashMap.java:1727)
> |        at DateTimeFormatterBuilder$LocalizedPrinterParser.formatter (DateTimeFormatterBuilder.java:5179)
> |        at DateTimeFormatterBuilder$LocalizedPrinterParser.format (DateTimeFormatterBuilder.java:5154)
> |        at DateTimeFormatterBuilder$CompositePrinterParser.format (DateTimeFormatterBuilder.java:2547)
> |        at DateTimeFormatter.formatTo (DateTimeFormatter.java:1907)
> |        at DateTimeFormatter.format (DateTimeFormatter.java:1881)
> |        at ZonedDateTime.format (ZonedDateTime.java:2158)
> |        at (#6:1)

Thanks. Will address this in the next version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28076#discussion_r2487494223

From pchilanomate at openjdk.org  Mon Nov  3 18:54:15 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 18:54:15 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
 <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
Message-ID: <-FOyxYPMnMfseoEVE0gqhuWFKT2s04ZLcKvyKF28zwE=.2c7eef23-1b9a-4339-89c6-58117a625848@github.com>

On Mon, 3 Nov 2025 16:22:13 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> A truly useful enhancement! Just had a few questions / suggestions.
>
Thanks for the review Fred!

> src/hotspot/share/interpreter/linkResolver.cpp line 1689:
> 
>> 1687:   EXCEPTION_MARK;
>> 1688:   CallInfo info;
>> 1689:   resolve_static_call(info, link_info, ClassInitMode::dont_init, THREAD);
> 
> Couldn't you just do `CHECK_AND_CLEAR_NULL` and skip the following `if (HAS_PENDING_EXCEPTION)` statement?
> 
> Suggestion:
> 
>   resolve_static_call(info, link_info, ClassInitMode::dont_init, CHECK_AND_CLEAR_NULL);
> 
> I see the same in functions both above and below this one, is there any reason for this?

Yes, I agree. I see there are a couple of instances of this pattern in this file as you point out, so if you are okay I?d prefer to file a separate bug to clean them all up together.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3482021139
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487524814

From pchilanomate at openjdk.org  Mon Nov  3 19:03:07 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 19:03:07 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v13]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Suggested fix in macroAssembler_ppc.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/ffcd92a6..4dff05a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=11-12

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

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

From pchilanomate at openjdk.org  Mon Nov  3 19:03:08 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 19:03:08 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <RvS8-qNisqNghcBV_fQ8tKBuABKyVRF49jMxsC8XogA=.5a3376df-e4dc-40ce-bedb-836c77deaf56@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
 <RvS8-qNisqNghcBV_fQ8tKBuABKyVRF49jMxsC8XogA=.5a3376df-e4dc-40ce-bedb-836c77deaf56@github.com>
Message-ID: <oqP5lvEv9ruXBE8ioohHijsgqB5ryRZgreLn6y3YJ-Y=.57206e3c-c712-48f9-bc37-fb57b549e992@github.com>

On Mon, 3 Nov 2025 18:34:59 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment and assert msg
>
> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 764:
> 
>> 762:     addi(regs[i], regs[0], regs[i]->encoding());
>> 763:   }
>> 764:   addi(regs[0], regs[0], regs[0]->encoding());
> 
> Based on @fbredber's suggestion:
> Suggestion:
> 
>   load_const_optimized(bad, 0xbad0101babe00000);
>   for (int i = (sizeof(regs) / sizeof(Register)) - 1; i >= 0; i--) {
>     addi(regs[i], bad, regs[i]->encoding());
>   }

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487538760

From rriggs at openjdk.org  Mon Nov  3 19:18:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 3 Nov 2025 19:18:03 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v3]
In-Reply-To: <3qJ75D8p2yA6Dm_m0QjVS-S0WlWP6XXEj7wF1CmUWcU=.73d8689f-acc5-4b9d-9a22-b2f64fb6932d@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
 <3qJ75D8p2yA6Dm_m0QjVS-S0WlWP6XXEj7wF1CmUWcU=.73d8689f-acc5-4b9d-9a22-b2f64fb6932d@github.com>
Message-ID: <pxjbT3dRiLtfzQwpnTclXyv-ouir15p23GAP2_MAsxk=.479b5b17-558a-408d-9da3-5f996f261cb9@github.com>

On Mon, 3 Nov 2025 18:09:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367943: Address reviewer comments

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28078#pullrequestreview-3412533873

From pchilanomate at openjdk.org  Mon Nov  3 19:46:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 19:46:11 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
Message-ID: <xefjJ4TIiyCSXHRFFlG7HnrRk1LWhWIlyiglZYHLAf8=.bcfe1a6d-2458-4c98-897e-ee0ca8ca2bf2@github.com>

On Mon, 3 Nov 2025 18:29:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments Patricio

Fix looks good to me, thanks!

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27919#pullrequestreview-3412633838

From pchilanomate at openjdk.org  Mon Nov  3 19:46:13 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 19:46:13 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: <wc9AKkQdn5XPWl1uDJJ96_UK4txqrhUx2-tIfVqfFYU=.2c930d46-2cca-4bd7-a2df-2a830e48729e@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
 <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
 <wc9AKkQdn5XPWl1uDJJ96_UK4txqrhUx2-tIfVqfFYU=.2c930d46-2cca-4bd7-a2df-2a830e48729e@github.com>
Message-ID: <LrtVJifqupZEPTTFjyyBw9uKGryGDHsAj9n8UEUwQAU=.6bc353c6-9183-4cee-b01d-ae782e1dd6f4@github.com>

On Mon, 3 Nov 2025 17:24:22 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> My assumption is that once an unsafe access error is thrown, we don't expect execution to continue. I suppose it is technically possible to catch the exception, either in Java code or in the native agent code, and then try to continue execution, but the program would be in an undefined state at that point already. In other words, I don't think anyone should be continuing execution after this exception happens.
>
Yes, makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487654019

From duke at openjdk.org  Mon Nov  3 20:52:13 2025
From: duke at openjdk.org (jengebr)
Date: Mon, 3 Nov 2025 20:52:13 GMT
Subject: RFR: 8371164 Optimizing ArrayList.addAll()
Message-ID: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>

# JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks

## Summary

This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.

## Problem Context

### ArrayList.addAll() Inefficiency
ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:

1. Call `c.toArray()` - creates intermediate array
2. Call `System.arraycopy()` to copy from intermediate array to destination
3. Discard intermediate array

When both source and destination are ArrayList instances, this can be optimized to direct array copying.

### Collections.SingletonSet toArray() Missing Implementation
Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:

1. Creates an ArrayList internally
2. Iterates through the collection (1 element)
3. Converts ArrayList to array
4. Returns the array

For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.

## Optimized Methods

### ArrayList
- **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation

### Collections.SingletonSet
- **`toArray()`**: Direct implementation returning `new Object[] {element}`
- **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract

## Performance Impact

| Class | Method | Size | Baseline | Optimized | Improvement |
|-------|--------|------|----------|-----------|-------------|
| ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
| ArrayList | addAll | 5 | 23.804 ns/op, 104 B/op | 14.170 ns/op, 64 B/op | **40% faster, 38% less allocation** |
| ArrayList | addAll | 75 | 65.440 ns/op, 664 B/op | 42.187 ns/op, 344 B/op | **36% faster, 48% less allocation** |
| LinkedList | addAll | 0 | 6.951 ns/op, 40 B/op | 7.001 ns/op, 40 B/op | **No change (control)** |
| LinkedList | addAll | 5 | 26.019 ns/op, 104 B/op | 25.401 ns/op, 104 B/op | **No change (control)** |
| LinkedList | addAll | 75 | 199.813 ns/op, 664 B/op | 204.001 ns/op, 664 B/op | **No change (control)** |
| SingletonSet | addAll (unpoisoned) | 1 | 18.593 ns/op, 72 B/op | 21.418 ns/op, 72 B/op | **15% slower** |
| SingletonSet | addAll (poisoned) | 1 | 48.798 ns/op, 96 B/op | 25.029 ns/op, 72 B/op | **49% faster, 25% less allocation** |

## Implementation Details

### ArrayList Fast Path
Directly accesses `src.elementData` to eliminate the intermediate `toArray()` allocation.

### SingletonSet Optimizations
Both methods provide direct array creation without intermediate collections, eliminating call site poisoning vulnerability.

## FAQ

**Q: Why use exact class check instead of instanceof for ArrayList?**
A: This prevents the fast path from becoming megamorphic if ArrayList subclasses are common, ensuring the optimization remains effective.

**Q: Are these optimizations safe?**
A: Yes. ArrayList-to-ArrayList copying maintains identical behavior, and SingletonSet.toArray() implementations follow the Collection contract exactly.

**Q: What about other Collection types?**
A: Profiling data shows these are the biggest opportunities. Others exist but are lower-priority.

**Q: How do these optimizations interact with existing code?**
A: These are internal implementation optimizations that maintain full API compatibility. No external code changes are required.

## Benchmarks

JMH benchmarks are included to validate the optimizations:
- `ArrayListBulkOpsBenchmark.addAllArrayList()`: Tests ArrayList-to-ArrayList fast path
- `ArrayListBulkOpsBenchmark.addAllSingletonSet()`: Tests SingletonSet.toArray() optimization
- `ArrayListBulkOpsBenchmark.addAllLinkedList()`: Control case using existing implementation

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

Commit messages:
 - 8371164 Optimizing ArrayList.addAll()

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

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

From naoto at openjdk.org  Mon Nov  3 21:27:13 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Nov 2025 21:27:13 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v3]
In-Reply-To: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
Message-ID: <SfGVmGO0gM8BP6oQdUTFxSe6B8INO7HRiADYTSh6JYo=.6c1fe3e2-2555-4cce-9c25-e08db1d79f45@github.com>

> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  `#` fix for "tok" locale

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28076/files
  - new: https://git.openjdk.org/jdk/pull/28076/files/38f86493..41fa00fb

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

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

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

From duke at openjdk.org  Mon Nov  3 21:29:34 2025
From: duke at openjdk.org (duke)
Date: Mon, 3 Nov 2025 21:29:34 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v23]
In-Reply-To: <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
Message-ID: <ZnYgi_cj4K0YzgtNBIaqqmhL8U5LJg_CDw1JKvhgElM=.3c170b56-109b-49cf-9982-c514321c4164@github.com>

On Thu, 30 Oct 2025 10:30:05 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update api note

@kieran-farrell 
Your change (at version 27613619899658cdf17c154839606b111e6cf8f0) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3482670293

From prappo at openjdk.org  Mon Nov  3 21:31:21 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 3 Nov 2025 21:31:21 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <8NMNMnCb5ojeNZOQvN-z59cIsBIJ1z4gOmytWXQTQjQ=.5354c1f2-2be4-4f89-a830-3e28be8c34df@github.com>

On Mon, 3 Nov 2025 20:45:44 GMT, jengebr <duke at openjdk.org> wrote:

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

A drive-by observation: this PR adds benchmarks, but does not seem to add tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3482677679

From duke at openjdk.org  Mon Nov  3 21:41:42 2025
From: duke at openjdk.org (jengebr)
Date: Mon, 3 Nov 2025 21:41:42 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <8NMNMnCb5ojeNZOQvN-z59cIsBIJ1z4gOmytWXQTQjQ=.5354c1f2-2be4-4f89-a830-3e28be8c34df@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <8NMNMnCb5ojeNZOQvN-z59cIsBIJ1z4gOmytWXQTQjQ=.5354c1f2-2be4-4f89-a830-3e28be8c34df@github.com>
Message-ID: <LD-ZD9gJM9xuAUUR5fm28i_m2VL7NKh38SsAEwg3oyg=.6e7e5a1f-a62b-4fda-9c13-67470d7d3f0b@github.com>

On Mon, 3 Nov 2025 21:29:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> A drive-by observation: this PR adds benchmarks, but does not seem to add tests.

Thank you - these methods are already covered by various existing tests, but for the most part that's indirect.  Are direct ones in order?

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

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3482704710

From acobbs at openjdk.org  Mon Nov  3 21:44:37 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 3 Nov 2025 21:44:37 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <fZQkatd0ySToBaGRkbeRtRnZ-Pt-Ff0fp77Nn0zQ8wg=.2e4d4eb0-3d65-4f86-bf7f-85b909441043@github.com>

On Mon, 3 Nov 2025 20:45:44 GMT, jengebr <duke at openjdk.org> wrote:

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

src/java.base/share/classes/java/util/ArrayList.java line 758:

> 756:             int numNew = src.size;
> 757:             if (numNew == 0)
> 758:                 return false;

Previously `addAll()` with an empty list would increment `modCount`, whereas now it won't. Might want to move this test down after `modCount++` to avoid the unnecessary behavioral change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2487930511

From prappo at openjdk.org  Mon Nov  3 21:54:11 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 3 Nov 2025 21:54:11 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <LD-ZD9gJM9xuAUUR5fm28i_m2VL7NKh38SsAEwg3oyg=.6e7e5a1f-a62b-4fda-9c13-67470d7d3f0b@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <8NMNMnCb5ojeNZOQvN-z59cIsBIJ1z4gOmytWXQTQjQ=.5354c1f2-2be4-4f89-a830-3e28be8c34df@github.com>
 <LD-ZD9gJM9xuAUUR5fm28i_m2VL7NKh38SsAEwg3oyg=.6e7e5a1f-a62b-4fda-9c13-67470d7d3f0b@github.com>
Message-ID: <_QKwegyXf3jupFBrPOohr11EI7L4MdaWTTkuS-IFzIw=.b39354d5-4b50-4973-9d47-d1359bdc4ed2@github.com>

On Mon, 3 Nov 2025 21:38:49 GMT, jengebr <duke at openjdk.org> wrote:

> > A drive-by observation: this PR adds benchmarks, but does not seem to add tests.
> 
> Thank you - these methods are already covered by various existing tests, but for the most part that's indirect. Are direct ones in order?

There needs to be some proof that this functionality is covered. If you could list existing tests that exercise the ArrayList.addAll(ArrayList) and Collections.singleton().toArray() methods, we could simply add this bug number to them.

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

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3482739520

From redestad at openjdk.org  Mon Nov  3 21:58:56 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 3 Nov 2025 21:58:56 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>

On Mon, 3 Nov 2025 20:45:44 GMT, jengebr <duke at openjdk.org> wrote:

> Why use exact class check instead of instanceof for ArrayList?

You might add that in general it might not be correct (or even safe) to do these sorts of optimizations on an arbitrary subclass of `ArrayList`. It's possible to create a subclass where a snapshot of `elementData` and `size` would disagree with the data returned by `toArray`, for example.

src/java.base/share/classes/java/util/ArrayList.java line 753:

> 751:      */
> 752:     public boolean addAll(Collection<? extends E> c) {
> 753:         if (c.getClass() == ArrayList.class) {

Consider simplifying this to reduce code duplication:

Object[] a;
int newNum;
if (c.getClass() == ArrayList.class) {
    ArrayList<?> src = (ArrayList<?>) c;
    a = src.elementData;
    numNew = src.size;
} else {
    a = c.toArray();
    numNew = a.length;
}
modCount++;
...

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

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28116#pullrequestreview-3413058471
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2487950683

From rriggs at openjdk.org  Mon Nov  3 22:42:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 3 Nov 2025 22:42:06 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v23]
In-Reply-To: <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
Message-ID: <iGzhHTi4k3CFuEt8o8TFiD5Jm-7YynQqm93_GPAyw00=.d2d6d68f-2e59-4e90-92a0-00506dd2b8d6@github.com>

On Thu, 30 Oct 2025 10:30:05 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update api note

I'll sponsor it when the CI run finishes.  Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3482896912

From rriggs at openjdk.org  Mon Nov  3 22:56:14 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 3 Nov 2025 22:56:14 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v28]
In-Reply-To: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
Message-ID: <0VnIUJxc2XBSfFAQI67Woy9HV2fcmFB4s8Q1ez1-zPk=.3469c884-339e-408c-bcbe-efa3d8c65705@github.com>

> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
> 
> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
> 
> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Improve example overridding close with try/catch/finally.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/7843eb73..d23a0478

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=26-27

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

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

From liach at openjdk.org  Mon Nov  3 23:00:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Nov 2025 23:00:37 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <7GRIxy6QBXeEPIzDVffgqgXTJlxaBW1jMin177vKkAQ=.e73c6b2a-5446-4778-886a-115fc5d23212@github.com>

On Mon, 3 Nov 2025 20:45:44 GMT, jengebr <duke at openjdk.org> wrote:

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

I actually wonder if the ArrayList.class path reuses `Object[] a = c.toArray();` and `int numNew = a.length;`, we are still going to see a similar improvement - I wonder if the bottleneck is the lack of polymorphic inlining alone, or if an array copy with a size trim would hamper C2 too.

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

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3482945083

From jlu at openjdk.org  Mon Nov  3 23:54:37 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 3 Nov 2025 23:54:37 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly
Message-ID: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>

This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.

Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.

> Minimum supported client: 	Windows Vista
> Minimum supported server: 	Windows Server 2008

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

Commit messages:
 - Merge branch 'master' into JDK-8370420-Windows
 - init

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

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

From bpb at openjdk.org  Tue Nov  4 00:07:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Nov 2025 00:07:03 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly
In-Reply-To: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
Message-ID: <WH_YdXi2i29b7mQneTEM-dCeMU88DJeKVSGSiRnFh_g=.ca0ee299-7c9a-45fc-8b21-7fd22518ea7e@github.com>

On Mon, 3 Nov 2025 23:48:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.
> 
> Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.
> 
>> Minimum supported client: 	Windows Vista
>> Minimum supported server: 	Windows Server 2008

Looks all right to me.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28119#pullrequestreview-3413411560

From naoto at openjdk.org  Tue Nov  4 00:11:36 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Nov 2025 00:11:36 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v4]
In-Reply-To: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
Message-ID: <Ol1NumVT400IwBNQ95zYMBG-1dJxHOdVgsqowf8PIcg=.a0672072-c512-454b-bb67-46a004b64380@github.com>

> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Unicode copyright update for the generated sources

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28076/files
  - new: https://git.openjdk.org/jdk/pull/28076/files/41fa00fb..05f5f0d9

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

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

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

From asemenyuk at openjdk.org  Tue Nov  4 00:20:14 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 00:20:14 GMT
Subject: RFR: 8371094: --mac-signing-key-user-name "CMR Technologies Limited"
 no longer works
Message-ID: <NaweUQzVw5VguKqSkneOAUnPO8FeDWKaJrXtGrp8dGo=.b1528569-6ed7-4a82-8a45-975e524ba476@github.com>

- Fix the typo where the argument for the `String.startsWith()` function is swapped with the target string.
- Add a test.

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

Commit messages:
 - 8371094: --mac-signing-key-user-name "CMR Technologies Limited" no longer works

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

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

From asemenyuk at openjdk.org  Tue Nov  4 00:24:01 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 00:24:01 GMT
Subject: RFR: 8371094: --mac-signing-key-user-name
 "CMR Technologies Limited" no longer works
In-Reply-To: <NaweUQzVw5VguKqSkneOAUnPO8FeDWKaJrXtGrp8dGo=.b1528569-6ed7-4a82-8a45-975e524ba476@github.com>
References: <NaweUQzVw5VguKqSkneOAUnPO8FeDWKaJrXtGrp8dGo=.b1528569-6ed7-4a82-8a45-975e524ba476@github.com>
Message-ID: <RNO1hJoelNJwcejx3_c4Nx8dWCHG6K69ZCwEkw7HZMI=.6ad9cf17-82a7-4e51-b92e-460badd6d041@github.com>

On Tue, 4 Nov 2025 00:14:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix the typo where the argument for the `String.startsWith()` function is swapped with the target string.
> - Add a test.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/28120#issuecomment-3483169996

From naoto at openjdk.org  Tue Nov  4 00:49:06 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Nov 2025 00:49:06 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly
In-Reply-To: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
Message-ID: <SC7QgEV4ObD2N1oUMe98ScxEYxebfXv9_nAPOWiJyxU=.fc1b52f3-833e-41b9-a541-5c9ba5def683@github.com>

On Mon, 3 Nov 2025 23:48:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.
> 
> Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.
> 
>> Minimum supported client: 	Windows Vista
>> Minimum supported server: 	Windows Server 2008

I think we can clean it further, as we don't need to call Win32 through their function pointers. Specifically,

typedef int (WINAPI *PGLIE)(const jchar *, LCTYPE, LPWSTR, int);
typedef int (WINAPI *PGCIE)(const jchar *, CALID, LPCWSTR, CALTYPE, LPWSTR, int, LPDWORD);
typedef int (WINAPI *PECIEE)(CALINFO_ENUMPROCEXEX, const jchar *, CALID, LPCWSTR, CALTYPE, LPARAM);
PGLIE pGetLocaleInfoEx;
PGCIE pGetCalendarInfoEx;
PECIEE pEnumCalendarInfoExEx;
BOOL initialized = FALSE;

and it's init code can all go away, IIUC

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

PR Comment: https://git.openjdk.org/jdk/pull/28119#issuecomment-3483228621

From asemenyuk at openjdk.org  Tue Nov  4 00:55:33 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 00:55:33 GMT
Subject: RFR: 8371184: Improve jpackage test coverage for "--app-image" option
Message-ID: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>

- Verify that when `--app-image` option is specified, files from the predefined app image are copied verbatim into the output app image (JPackageCommand: add `PREDEFINED_APP_IMAGE_COPY`, update TKit.PathSnapshot class).
 - Clean up redundancies after [8351369: [macos] Use --install-dir option with DMG packaging](https://bugs.openjdk.org/browse/JDK-8351369) fix: remove `JPackageCommand.dmgInstallDir`, simplify InstallDirTest test.
 - Add `LauncherVerifier.launcherDescription()` and use it from LiunuxHelper; extend PropertyFinder class for `LauncherVerifier.launcherDescription()`.
 - Automatically reapply verifications to launchers in the predefined app image to the command referencing the predefined app image through `--app-image` option. Other changes relate to this update.

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

Commit messages:
 - Fix compilation error
 - InstallDirTest: simplify
 - Get rid of redundant JPackageCommand.dmgInstallDir; JPackageCommand: add action to verify files from the predefined app image copied in the output bundle verbatim; MacHelper: add isVerbatimCopyFromPredefinedAppImage()
 - LauncherVerifier: fix launcherDescription()
 - Win8282351Test: some refactoring an use PackageTest.usePredefinedAppImage()
 - LinuxHelper: use LauncherVerifier.launcherDescription() to get the description of the launcher
 - LauncherVerifier: use PropertyFinder to get the description of the launcher
 - AdditionalLauncher: use cmd.addVerifyAction(createVerifierAsConsumer(), JPackageCommand.ActionRole.LAUNCHER_VERIFIER);
 - Use PackageTest.usePredefinedAppImage()
 - PropertyFinder: enhance the API
 - ... and 2 more: https://git.openjdk.org/jdk/compare/9f972008...c37d67bf

Changes: https://git.openjdk.org/jdk/pull/28118/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28118&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371184
  Stats: 462 lines in 20 files changed: 272 ins; 80 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/28118.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28118/head:pull/28118

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

From asemenyuk at openjdk.org  Tue Nov  4 00:55:34 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 00:55:34 GMT
Subject: RFR: 8371184: Improve jpackage test coverage for "--app-image"
 option
In-Reply-To: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
References: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
Message-ID: <-Tbc9m80Q7NUnOolzbCFyVrK_afUFT7qewb_QivTYfw=.51e7862b-13ed-41b1-baf4-e3805c565537@github.com>

On Mon, 3 Nov 2025 21:45:35 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Verify that when `--app-image` option is specified, files from the predefined app image are copied verbatim into the output app image (JPackageCommand: add `PREDEFINED_APP_IMAGE_COPY`, update TKit.PathSnapshot class).
>  - Clean up redundancies after [8351369: [macos] Use --install-dir option with DMG packaging](https://bugs.openjdk.org/browse/JDK-8351369) fix: remove `JPackageCommand.dmgInstallDir`, simplify InstallDirTest test.
>  - Add `LauncherVerifier.launcherDescription()` and use it from LiunuxHelper; extend PropertyFinder class for `LauncherVerifier.launcherDescription()`.
>  - Automatically reapply verifications to launchers in the predefined app image to the command referencing the predefined app image through `--app-image` option. Other changes relate to this update.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/28118#issuecomment-3483237602

From bpb at openjdk.org  Tue Nov  4 01:49:44 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Nov 2025 01:49:44 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v14]
In-Reply-To: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
References: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
Message-ID: <2RIunJzmUUCMaaqbfPrIfeXJWc6Is7cme519UWUBLNc=.7441d786-0b49-4466-a994-7800bec9acde@github.com>

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355342: Do not fail wcanonicalize if getFinalPath fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27324/files
  - new: https://git.openjdk.org/jdk/pull/27324/files/14f91a36..0918c3a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=12-13

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

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

From bpb at openjdk.org  Tue Nov  4 02:02:30 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Nov 2025 02:02:30 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v14]
In-Reply-To: <2RIunJzmUUCMaaqbfPrIfeXJWc6Is7cme519UWUBLNc=.7441d786-0b49-4466-a994-7800bec9acde@github.com>
References: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
 <2RIunJzmUUCMaaqbfPrIfeXJWc6Is7cme519UWUBLNc=.7441d786-0b49-4466-a994-7800bec9acde@github.com>
Message-ID: <dDNl9fxEjNuG4kiZXlI7rbIIAlS8AceAq3n6t97kDIY=.ceecc515-86e2-4ba0-b39b-4c7178d4e923@github.com>

On Tue, 4 Nov 2025 01:49:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355342: Do not fail wcanonicalize if getFinalPath fails

Without commit 0918c3a, `JImageExtractTest` was failing as

Invoking testExtractToDirBySymlink
jimage [extract, --dir, .\symlink, C:\tmp\jtreg\scratch.\JImageExtractTest10882108125475978945\smalljdk\lib\modules]
STDERR:
java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at JImageCliTest.runTests(JImageCliTest.java:111)
        at JImageExtractTest.main(JImageExtractTest.java:234)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.lang.RuntimeException: Error: cannot create directory C:\tmp\jtreg\scratch.\symlink\java.base\META-INF\services
: expected true, was false
        at jdk.test.lib.Asserts.fail(Asserts.java:715)
        at jdk.test.lib.Asserts.assertTrue(Asserts.java:545)
        at JImageCliTest$JImageResult.assertSuccess(JImageCliTest.java:91)

which was apparently due to `wcanonicalize()` failing when `getFinalPath()` failed for a symlink. Suppressing this failure reinstates the control flow previously defined in the Java layer. With this change, all tier1-tier3 tests pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3483385436

From asemenyuk at openjdk.org  Tue Nov  4 02:19:41 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 02:19:41 GMT
Subject: RFR: 8371184: Improve jpackage test coverage for "--app-image"
 option [v2]
In-Reply-To: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
References: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
Message-ID: <LMat5LM8fJrgs9FD0UVzWsMwHE1QbrKH2hcfQjYrlmQ=.f3052bac-28ce-47e0-9ae3-847371a66118@github.com>

> - Verify that when `--app-image` option is specified, files from the predefined app image are copied verbatim into the output app image (JPackageCommand: add `PREDEFINED_APP_IMAGE_COPY`, update TKit.PathSnapshot class).
> - Add `LauncherVerifier.launcherDescription()` and use it from LiunuxHelper; extend PropertyFinder class for `LauncherVerifier.launcherDescription()`.
>  - Automatically reapply verifications to launchers in the predefined app image to the command referencing the predefined app image through `--app-image` option. Other changes relate to this update.
> 
> Supplementary:
> - Clean up redundancies after [8351369: [macos] Use --install-dir option with DMG packaging](https://bugs.openjdk.org/browse/JDK-8351369) fix: remove `JPackageCommand.dmgInstallDir`, simplify InstallDirTest test.
>  - AppContentTest.java: fix to make test logs stable.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  AppContentTest: keep test log stable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28118/files
  - new: https://git.openjdk.org/jdk/pull/28118/files/c37d67bf..c76e49f2

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

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

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

From almatvee at openjdk.org  Tue Nov  4 03:02:06 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 4 Nov 2025 03:02:06 GMT
Subject: RFR: 8371094: --mac-signing-key-user-name
 "CMR Technologies Limited" no longer works
In-Reply-To: <NaweUQzVw5VguKqSkneOAUnPO8FeDWKaJrXtGrp8dGo=.b1528569-6ed7-4a82-8a45-975e524ba476@github.com>
References: <NaweUQzVw5VguKqSkneOAUnPO8FeDWKaJrXtGrp8dGo=.b1528569-6ed7-4a82-8a45-975e524ba476@github.com>
Message-ID: <Udy8HL26u8CszrB9vc3U_fgGCjiLgX64WEqCk7km2pw=.404284f7-5d5c-430c-948b-34ecf6b4e903@github.com>

On Tue, 4 Nov 2025 00:14:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix the typo where the argument for the `String.startsWith()` function is swapped with the target string.
> - Add a test.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28120#pullrequestreview-3413778403

From almatvee at openjdk.org  Tue Nov  4 04:33:03 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 4 Nov 2025 04:33:03 GMT
Subject: RFR: 8371184: Improve jpackage test coverage for "--app-image"
 option [v2]
In-Reply-To: <LMat5LM8fJrgs9FD0UVzWsMwHE1QbrKH2hcfQjYrlmQ=.f3052bac-28ce-47e0-9ae3-847371a66118@github.com>
References: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
 <LMat5LM8fJrgs9FD0UVzWsMwHE1QbrKH2hcfQjYrlmQ=.f3052bac-28ce-47e0-9ae3-847371a66118@github.com>
Message-ID: <3EWILhfDqD9DurSQoOUiXhJjtKov-u_QAkbvNnJDw3s=.3e3504e5-95c2-4e1a-ac69-21bccb815614@github.com>

On Tue, 4 Nov 2025 02:19:41 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Verify that when `--app-image` option is specified, files from the predefined app image are copied verbatim into the output app image (JPackageCommand: add `PREDEFINED_APP_IMAGE_COPY`, update TKit.PathSnapshot class).
>> - Add `LauncherVerifier.launcherDescription()` and use it from LiunuxHelper; extend PropertyFinder class for `LauncherVerifier.launcherDescription()`.
>>  - Automatically reapply verifications to launchers in the predefined app image to the command referencing the predefined app image through `--app-image` option. Other changes relate to this update.
>> 
>> Supplementary:
>> - Clean up redundancies after [8351369: [macos] Use --install-dir option with DMG packaging](https://bugs.openjdk.org/browse/JDK-8351369) fix: remove `JPackageCommand.dmgInstallDir`, simplify InstallDirTest test.
>>  - AppContentTest.java: fix to make test logs stable.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AppContentTest: keep test log stable

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28118#pullrequestreview-3413923166

From stuart.marks at oracle.com  Tue Nov  4 06:04:48 2025
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 3 Nov 2025 22:04:48 -0800
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlByb3Bvc2UgdG8gcmVtb3ZlIHN1cHBvcnQgZm9y?=
 =?UTF-8?Q?_CompactStrings_off?=
In-Reply-To: <d26f06b5-cc53-4ec4-97bd-69eb9944f779@oracle.com>
References: <b27a2c9d-d268-4489-8b57-920090635dca.shaojin.wensj@alibaba-inc.com>
 <f46d0109-3dbe-4764-8c52-0b3843c85195@oracle.com>
 <08d048b2-5eb1-4db1-a169-a45e9f617b62.shaojin.wensj@alibaba-inc.com>
 <d26f06b5-cc53-4ec4-97bd-69eb9944f779@oracle.com>
Message-ID: <09039475-af3e-43ed-8d6b-8e7678a2a053@oracle.com>

Hi wenshao,

I think removing Compact Strings is a great idea! As you noted in your first 
message, removing it would make String easier to maintain. Just so that everybody 
here understands the issues, every string algorithm has THREE implementations:

1. compact strings enabled, using ISO Latin 1 coder

2. compact strings enabled, using UTF-16 coder

3. compact strings disabled

In recent years I suspect our test coverage of the compact-strings disabled case is 
lacking, as some bugs have occurred in only that case. For example, see JDK-8321514 
<https://bugs.openjdk.org/browse/JDK-8321514>, JDK-8316879 
<https://bugs.openjdk.org/browse/JDK-8316879>, JDK-8360271 
<https://bugs.openjdk.org/browse/JDK-8360271>, JDK-8360255 
<https://bugs.openjdk.org/browse/JDK-8360255>, JDK-8221430 
<https://bugs.openjdk.org/browse/JDK-8221430>, etc. (Some of these have been fixed, 
but some are still open.)

As Alan noted, however, we can't simply remove this case. We also can't simply 
deprecate the command-line option; we need to deprecate the feature of running 
without Compact Strings before we can remove that feature.

Compact Strings were introduced with JEP 254 <https://openjdk.org/jeps/254>. The JEP 
doesn't mention that there is an option to disable compact strings, but the JVM 
Guide 
<https://docs.oracle.com/en/java/javase/25/vm/java-hotspot-virtual-machine-performance-enhancements.html#GUID-D2E3DC58-D18B-4A6C-8167-4A1DFB4888E4> 
describes the Compact Strings feature and also the ability to disable it using the 
-XX:-CompactStrings command line option. This section doesn't say much about when 
you might want to disable the feature, though; it merely says "This feature can be 
disabled if you observe performance regression issues in an application." Articles 
like this one from Baeldung <https://www.baeldung.com/java-9-compact-string>, and 
vendor documentation from IBM 
<https://www.ibm.com/docs/en/sdk-java-technology/8?topic=options-xx-compactstrings> 
also document this option, but they offer similarly vague advice.

Since the option is fairly well-known, it's not merely a matter of looking at the 
status of the various ports (though those are significant, of course). It could be 
that some installations out there running with option to disable compact strings, 
perhaps if they encountered a performance regression, or for other reasons. They'll 
need to be informed that the feature is going away, and the best way to do that is 
with a JEP.

There are some additional issues to consider as well.

  * As Alan noted,? the ARM32 port has compact strings disabled by default. It's not
    clear whether it even works if compact strings are enabled.
  * Compact strings increases storage requirements of CJK character data. Our
    /assumption/ has been that even CJK-heavy applications use a lot of ASCII data
    for config files, message headers, JSON, etc., and that compact strings are
    still a net win for such applications. However, that's an assumption. There's
    the possibility that some installation run those applications with compact
    strings disabled.
  * The JNI GetStringCritical call returns a direct pointer in the non compact
    strings case but makes a copy when compact strings are enabled. Some
    applications may suffer regressions because of this; see this Stack Overflow
    <https://stackoverflow.com/questions/76913323/string-compact-has-introduced-some-performance-issues-for-the-current-jni-how>
    question.

There are probably some other issues we haven't considered yet. The best way to 
flush them out is to post a JEP, and then use other channels to publicize the JEP. 
The JEP is mostly a formality about changing the official status of running in the 
compact-strings-disabled mode to "deprecated". Even though it seems like a lot of 
overhead to write a JEP for this, the fact is that many people in the tech press 
look only at the list of JEPs for each release and not much else. Any many Java 
users look only at tech publications to keep up with Java; they don't look at GitHub 
or follow the OpenJDK mailing lists. Thus, posting a JEP is the best chance we have 
to reach a broad set of Java users, some of whom might be affected by this change.

Actual changes that go along with the deprecation will probably only involve adding 
warning messages and possibly updating documentation. We don't need to resolve 
issues like the ARM32 port yet. However, that will need to be resolved before we 
actually remove the feature.

Since I'm "Dr Deprecator" I'll volunteer to draft the JEP.

s'marks


On 10/27/25 11:56 PM, Alan Bateman wrote:
> On 28/10/2025 06:32, wenshao wrote:
>>
>> Thanks to Alan for your feedback.
>>
>> Based on Chen Liang's suggestion, I submitted a new draft PR 
>> https://github.com/openjdk/jdk/pull/27995 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27995__;!!ACWV5N9M2RV99hQ!OKe3zURFdlME6esFh_Travsoq4L0s3h71P8bsjCEG5RrmA0nzVmARS7ZAmOZEL0-DWdIg9P8orcXs26SZtYD-c8ZB8h_Fg$> 
>> to add a warning message to the ComactStrings option.
>
> I think? first step has to be establish what or who might be using 
> -XX:-CompactStrings in 2025. This means looking into the status of ports. Andrew 
> Haley is going to check with folks in IBM as some of the bug reports for the 
> -CompactString code paths come from ports there.
>
> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251103/de18f264/attachment-0001.htm>

From swen at openjdk.org  Tue Nov  4 07:17:04 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Nov 2025 07:17:04 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v12]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <ql083MmlMZTW0SD4fzjjt4VEwmP9f6nZvW3gt9QBuc0=.084f8e9b-fbf1-4591-b153-36f3230892c2@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - fix assert
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - Fix JavaLangAccess.appendLatin1 javadoc to match method signature
   
   The previous javadoc incorrectly described the method as appending a two-digit
   integer representation, but the method actually appends two Latin-1 characters.
   Updated the documentation to accurately reflect the method's behavior.
   
   Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - appendPair instead of appendLatin1(char, char)
 - Revert "appendPair instead of append(char, char)"
   
   This reverts commit d969a235e54da4ac96b7205982624f52305cae31.
 - appendPair instead of append(char, char)
 - Update test/jdk/jdk/internal/util/DecimalDigitsTest.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
 - ... and 5 more: https://git.openjdk.org/jdk/compare/50bb92a3...1f16125b

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

Changes: https://git.openjdk.org/jdk/pull/26911/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=11
  Stats: 185 lines in 10 files changed: 154 ins; 4 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

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

From jpai at openjdk.org  Tue Nov  4 07:17:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Nov 2025 07:17:54 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v23]
In-Reply-To: <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
Message-ID: <-ELV6ErraS25qWhohrVkFVGn5OGufHSPTQIABXeaqmc=.df9b1152-c3a8-4fbe-8361-3ed90826229b@github.com>

On Thu, 30 Oct 2025 10:30:05 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update api note

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25303#pullrequestreview-3414355708

From eddy at linux.ibm.com  Tue Nov  4 07:49:16 2025
From: eddy at linux.ibm.com (Eduard Stefes)
Date: Tue, 04 Nov 2025 08:49:16 +0100
Subject: state of openjdk-zlib on s390x
Message-ID: <7c022649373db9fbfc4a8d2426316429d76c9d61.camel@linux.ibm.com>

Hello,

# TLDR

zlib (and zlib-ng) on s390x use hardware compression. This
hardware compression implementation has currently some problems when
used by openjdk.



# current situation

- openjdk uses zlib(or zlib-ng) for most(all?) its data compression.
   This includes also jar file creation.
- s390x has deflate implemented on hardware level(called dfltcc). This
   implementation is up to 10x faster(empirical value) compared to the
   standard software algorithm.
- The dfltcc implementation has some drawbacks vs the software
   implementation:
	- dfltcc will ALWAYS write to the output buffer, indifferent
of 	  	  the flushing parameter passed to deflate()
	- dfltcc does not generate reproducible output. This means
	  that it will always generate valid deflate data streams
	  that uncompress(inflate) to the same input. But the
	  compressed data may look different between two calls with
	  the same input data, because the hardware compressor depends
	  also on hardware variables that not visible to the external
	  api user.




# the problem

due to the differences of the hardware implementation, some tests in
the openjdk JREG tests fail(tracked here[1][2])

- java/util/zip/CloseInflaterDeflaterTest.java
     fails due to dfltcc's flushing behaviour. The test should check if
     the openjdk wrapper around the jni and native library will
     successfully detect writes to closed output streams. This was
     created because there where bugs with and race conditions in the
     write/close/flush.

- tools/jlink/JLinkReproducibleTest.java:
- tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java:
     This tests fail due to two calls to dfltcc will not generate the
     same compressed data for the same input data. I want to
     emphasize that RFC 1950 and 1951 do not guarantee the same output
     for two deflate/zlib data streams if feed the same input data.


# proposed solutions
## flushing problem

IMHO the CloseInflaterDeflaterTest.java test relays on zlib behavior
where zlib explicitly has the freedom to change its behavior[3][1].
As a quick and dirty solution i would propose to backport the
disablement[4] of this test to openjdk-17 21 and 24.

I read and traced through the test, and for me it looks like the
behavior of the openjdk and jni wrappers will be the same regardless of
the underlying zlib. Therefor it seems ok to assume that: "If its okay
on x86 it will be ok on s390x"

However I think that this test might need a redesign. It relies on
flushing behavior of zlib the the library explicitly stated can change.



## reproducible compression

I don't know how much openjdk relies on reproducible data compression.
I assume it is preferable if its possible to create the same .jar twice
and get the same binary data. The zlib dfltcc implementation could be
controlled via an env variable to disable the hardware compression[5].
Also usually dftcc will only be used for certain compression levels and
this can also be changed via env variables[6].

Unfortunately this env variables are evaluated at library load and can
not be adjusted during runtime.

Moreover ubuntu sets the default LEVEL_MASK to 0x7e[7]. This means
that the compression level is also not a reliabl method in order to
force zlib to use software instead of hardware compression.

Also zlib-ng lacks this env variables. Here the use of dfltcc cannot be
influenced at all.

This all leads me to the conclusion that there has to be a decision if
and how openjdk on s390x will be able to generate reproducible jars.
For the time being I suppose to also disable this tests and backport
the disablements down till openjdk-17.



# Finally

I hope i did not overwhelm you all with this email. As I don't have a
bugs.openjdk.org account, I thought the mailing list is the best place
to discuss this mater.

cheers Eddy



[1] https://bugs.launchpad.net/ubuntu/+source/openjdk-21/+bug/2109016
[2] https://bugs.openjdk.org/browse/JDK-8339216
[3] https://github.com/madler/zlib/blob/develop/zlib.h#L286-L288
[4]
https://github.com/openjdk/jdk/commit/537447f8816129dad9a1edd21bd30f3edf69ea60
[5]
https://github.com/iii-i/zlib/blob/dfltcc/contrib/s390/dfltcc.c#L705-L706
[6]
https://github.com/iii-i/zlib/blob/dfltcc/contrib/s390/dfltcc.c#L714-L715
[7] https://git.launchpad.net/ubuntu/+source/zlib/tree/debian/rules#n53

From mbaesken at openjdk.org  Tue Nov  4 08:17:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Nov 2025 08:17:21 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly
In-Reply-To: <SC7QgEV4ObD2N1oUMe98ScxEYxebfXv9_nAPOWiJyxU=.fc1b52f3-833e-41b9-a541-5c9ba5def683@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
 <SC7QgEV4ObD2N1oUMe98ScxEYxebfXv9_nAPOWiJyxU=.fc1b52f3-833e-41b9-a541-5c9ba5def683@github.com>
Message-ID: <OxagcrnSxD_nxZkzoQkE0TDgntCJ11kskB0D6AZHaNY=.1e6ba5e8-3f74-4905-8526-0d7e0944fc67@github.com>

On Tue, 4 Nov 2025 00:46:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think we can clean it further, as we don't need to call Win32 through their function pointers. Specifically,
> 
> ```
> typedef int (WINAPI *PGLIE)(const jchar *, LCTYPE, LPWSTR, int);
> typedef int (WINAPI *PGCIE)(const jchar *, CALID, LPCWSTR, CALTYPE, LPWSTR, int, LPDWORD);
> typedef int (WINAPI *PECIEE)(CALINFO_ENUMPROCEXEX, const jchar *, CALID, LPCWSTR, CALTYPE, LPARAM);
> PGLIE pGetLocaleInfoEx;
> PGCIE pGetCalendarInfoEx;
> PECIEE pEnumCalendarInfoExEx;
> BOOL initialized = FALSE;
> ```
> 
> and it's init code can all go away, IIUC


Yes the GetProcAddress  stuff should be removed too, see
https://github.com/openjdk/jdk/blob/c1476fca9d7a679d32b7b43956638b845d1027cc/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L189

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

PR Comment: https://git.openjdk.org/jdk/pull/28119#issuecomment-3484469810

From duke at openjdk.org  Tue Nov  4 08:34:34 2025
From: duke at openjdk.org (walkertest)
Date: Tue, 4 Nov 2025 08:34:34 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <-FOyxYPMnMfseoEVE0gqhuWFKT2s04ZLcKvyKF28zwE=.2c7eef23-1b9a-4339-89c6-58117a625848@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
 <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
 <-FOyxYPMnMfseoEVE0gqhuWFKT2s04ZLcKvyKF28zwE=.2c7eef23-1b9a-4339-89c6-58117a625848@github.com>
Message-ID: <DCiMHXzIax_cyp5HCtr1-UXOje79IpHezPDY-YwJwx4=.120c72fc-a30b-43c4-b3c4-cba79fab883c@github.com>

On Mon, 3 Nov 2025 18:51:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> > A truly useful enhancement! Just had a few questions / suggestions.
> 
> Thanks for the review Fred!

Hello, I have meet a simlar question as: [https://stackoverflow.com/questions/79808508/jdk24-tomcat-start-pinned-in-virtual-thead-env](https://stackoverflow.com/questions/79808508/jdk24-tomcat-start-pinned-in-virtual-thead-env)

I want to know if this quesiton is same as https://bugs.openjdk.org/browse/JDK-8369238 or not.
How to temporarily solve this problem?

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3484149341

From iklam at openjdk.org  Tue Nov  4 09:01:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 09:01:36 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
Message-ID: <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines.
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`.
> 
> I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case:
> 
> 
> if (forceBase >= end) {
>     throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test.");
> }

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Refactored the various "match" methods in OutputAnalyzer; added tests; reverted changes in AccessZeroNKlassHitsProtectionZone.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28077/files
  - new: https://git.openjdk.org/jdk/pull/28077/files/184bb30c..3b493855

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

  Stats: 94 lines in 3 files changed: 72 ins; 13 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28077.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28077/head:pull/28077

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

From iklam at openjdk.org  Tue Nov  4 09:13:25 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 09:13:25 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
Message-ID: <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>

On Tue, 4 Nov 2025 09:01:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
>> 
>> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
>> 
>> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
>> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
>> 
>> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
>> 
>> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
>> 
>> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactored the various "match" methods in OutputAnalyzer; added tests; reverted changes in AccessZeroNKlassHitsProtectionZone.java

Hi Stefan, thanks for looking into this.

> So, I would prefer to see the following:
> 
> 1. Fix the title to indicate that your updating the OutputAnalyzer
> 2. Fix the summary that states that MULTILINE is needed to match over newlines
> 3. Introduce the new "find" function (or rename matches)
> 4. Add tests
> 5. Preferably, use one RFE for the above enhancements and Bug for the test failure

I fixed the title, updated the summary and added test cases.

I didn't use "find", as all the existing methods in OutputAnalyzer use "match".

The bug is in OutputAnalyzer only. The test case AccessZeroNKlassHitsProtectionZone.java is correct in its current form. So I will use this PR to fix `OutputAnalyzer.matches()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3484765891

From duke at openjdk.org  Tue Nov  4 09:30:57 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Tue, 4 Nov 2025 09:30:57 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments
Message-ID: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>

Add more precise message for IndexOutOfBoundsException in MemorySegment

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

Commit messages:
 - JDK-8346657: Improve out of bounds exception messages for MemorySegments

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

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

From mcimadamore at openjdk.org  Tue Nov  4 09:38:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 4 Nov 2025 09:38:28 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <IRN2eQoZzT1hVSvzh5JeDAO80x2f4ckPz8UW4dJLwZQ=.5098ac80-d667-4bc3-b43d-a1425882ce33@github.com>

On Tue, 4 Nov 2025 09:17:27 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> Add more precise message for IndexOutOfBoundsException in MemorySegment

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 433:

> 431: 
> 432:     private IndexOutOfBoundsException outOfBoundException(long offset, long length) {
> 433:         return new IndexOutOfBoundsException(String.format("Out of bound access on segment %s; " +

The new message looks ok, but note that this message is also reused by the `asSlice` methods. If we want to clarify the messages, perhaps we should think about rearranging the code a bit?

Related note: this is also why the routine that check OOB access needs to worry about `length` being zero -- because that's a valid value for `asSlice` (but not for access).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2489522721

From stefank at openjdk.org  Tue Nov  4 10:08:46 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 4 Nov 2025 10:08:46 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
 <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
Message-ID: <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>

On Tue, 4 Nov 2025 09:10:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I didn't use "find", as all the existing methods in OutputAnalyzer use "match".

My point is that you can't have a function called "matches" that performs a "find" instead of a "matches":

    private boolean matchesHelper(String s, Pattern pattern) {
        return s != null && pattern.matcher(s).find();
    }


That's too confusing.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3485047638

From ogillespie at openjdk.org  Tue Nov  4 10:17:20 2025
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 4 Nov 2025 10:17:20 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <BFFifJZZgD9cxcRbwSnhW_lQ3Ixt2OWqDi5ZlefQEk4=.7a41d647-3583-4315-93d8-2769971d9868@github.com>

On Mon, 3 Nov 2025 20:45:44 GMT, jengebr <duke at openjdk.org> wrote:

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

src/java.base/share/classes/java/util/Collections.java line 5260:

> 5258:         }
> 5259:         @SuppressWarnings("unchecked")
> 5260:         public <T> T[] toArray(T[] a) {

Should these have `@Override`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2489724142

From jpai at openjdk.org  Tue Nov  4 10:31:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Nov 2025 10:31:02 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v3]
In-Reply-To: <3qJ75D8p2yA6Dm_m0QjVS-S0WlWP6XXEj7wF1CmUWcU=.73d8689f-acc5-4b9d-9a22-b2f64fb6932d@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
 <3qJ75D8p2yA6Dm_m0QjVS-S0WlWP6XXEj7wF1CmUWcU=.73d8689f-acc5-4b9d-9a22-b2f64fb6932d@github.com>
Message-ID: <7TfJIxtE7zvpC-qH-dYN3uddzA6X4vHakEBbvdIl4JA=.4a39b01e-31f2-4d5b-9b4b-298edbde9f85@github.com>

On Mon, 3 Nov 2025 18:09:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367943: Address reviewer comments

Thank you for the updates, Brian. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28078#pullrequestreview-3415506711

From prappo at openjdk.org  Tue Nov  4 10:33:03 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Nov 2025 10:33:03 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <BFFifJZZgD9cxcRbwSnhW_lQ3Ixt2OWqDi5ZlefQEk4=.7a41d647-3583-4315-93d8-2769971d9868@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <BFFifJZZgD9cxcRbwSnhW_lQ3Ixt2OWqDi5ZlefQEk4=.7a41d647-3583-4315-93d8-2769971d9868@github.com>
Message-ID: <xY2pMgKqhmbWnKJ4EkADktEjsGBVdIaH6DlZTOn8KKM=.d73eca5d-7eb3-4143-bf59-fe29e56948ca@github.com>

On Tue, 4 Nov 2025 10:15:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> src/java.base/share/classes/java/util/Collections.java line 5260:
> 
>> 5258:         }
>> 5259:         @SuppressWarnings("unchecked")
>> 5260:         public <T> T[] toArray(T[] a) {
> 
> Should these have `@Override`?

All overriding methods should, yes. Also, there is slight a mismatch between the title and the contents of the PR: it's not only about `ArrayList`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2489817930

From jpai at openjdk.org  Tue Nov  4 10:42:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Nov 2025 10:42:29 GMT
Subject: RFR: 8365699: Remove jdk.internal.javac.PreviewFeature.Feature enum
 values for features finalized in Java 25 or earlier
Message-ID: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>

Can I please get a review of this change which cleans up the outdated enum constants in the internal `jdk.internal.javac.PreviewFeature$Feature` enum?

This addresses https://bugs.openjdk.org/browse/JDK-8365699. As noted in that issue, this enum has accumulated some outdated preview feature constants which are no longer needed. The changes in this PR removes those enum constants whose preview features have been finalized in Java 25 or earlier (the current mainline bootstrap JDK is Java 25). A code comment explaining the lifetime of these enum constants has also been added.

No new tests have been introduced and tier1, tier2, tier3 testing is currently in progress in the CI.

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

Commit messages:
 - 8365699: Remove jdk.internal.javac.PreviewFeature.Feature enum values for features finalized in Java 25 or earlier

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

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

From ogillespie at openjdk.org  Tue Nov  4 10:51:38 2025
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 4 Nov 2025 10:51:38 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <_ZuLLDZkfRh3dbvSyHdasiFsqBpna5pS5szkmughWOM=.bcc69cdc-af55-40e1-b7ec-5a88bdc651d2@github.com>

On Mon, 3 Nov 2025 20:45:44 GMT, jengebr <duke at openjdk.org> wrote:

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 120:

> 118:         ArrayList<String> result = new ArrayList<>(75);
> 119:         result.addAll(linkedListSource75);
> 120:         bh.consume(result);

No need for blackholes, just return the result, it has the same effect I believe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2489936317

From ogillespie at openjdk.org  Tue Nov  4 10:54:51 2025
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 4 Nov 2025 10:54:51 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <Yo7f5a6vZYHEIPLGyiWDrq_B_MCgYxGfoYeicKx1f8I=.86703dd8-ad50-4eed-af0e-bcc3e794ad93@github.com>

On Mon, 3 Nov 2025 20:45:44 GMT, jengebr <duke at openjdk.org> wrote:

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 60:

> 58: @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> 59: @Fork(value = 1, jvmArgs = { "-XX:+UseParallelGC", "-Xmx3g" })
> 60: public class ArrayListBulkOpsBenchmark {

You might find a layout like this a bit neater:


@State(Scope.Benchmark)
public class ArrayListBulkOpsBench {
    @Param({"0", "1", "5", "75"})
    int size;

    @Param({"ArrayList", "LinkedList"})
    String type;

    @Param({ "false", "true" })
    private boolean poison;

    List<String> source;

    @Setup(Level.Trial)
    public void setup() {
        switch (type) {
            case "ArrayList" -> source = new ArrayList<>(size);
            case "LinkedList" -> source = new LinkedList<>();
        }
        for (int i = 0; i < size; i++) source.add("key" + i);
        if (poison) poisonCallSites();
    }

    @Benchmark
    public ArrayList<String> addAll() {
        ArrayList<String> result = new ArrayList<>(size);
        result.addAll(source);
        return result;
    }

    static void poisonCallSites() {
        HashMap<String, String> hashMapSource = new HashMap<>();
        TreeSet<String> treeSetSource = new TreeSet<>();
        WeakHashMap<String, String> weakHashMapSource = new WeakHashMap<>();
        for (int i = 0; i < 75; i++) {
            hashMapSource.put("key" + i, "value" + i);
            treeSetSource.add("key" + i);
            weakHashMapSource.put("key" + i, "value" + i);
        }
        // Poison ArrayList.addAll() with different Collection types
        for (int i = 0; i < 40_000; i++) {
            ArrayList<Object> temp = new ArrayList<>();
            temp.addAll(hashMapSource.entrySet());
            temp.addAll(treeSetSource);
            temp.addAll(weakHashMapSource.keySet());
        }
    }

    @State(Scope.Benchmark)
    public static class SingletonSet {
        Set<String> singletonSetSource = Collections.singleton("key");

        @Param({ "false", "true" })
        private boolean poison;

        @Setup(Level.Trial)
        public void setup() {
            if (poison) poisonCallSites();
        }

        @Benchmark
        public ArrayList<String> addAllSingletonSet() {
            ArrayList<String> result = new ArrayList<>(1);
            result.addAll(singletonSetSource);
            return result;
        }
    }
}


addAll will be run against all permutations of size/type/poison. addAllSingletonSet will just be run against false/true poison.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2489955314

From iklam at openjdk.org  Tue Nov  4 11:52:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 11:52:10 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v3]
In-Reply-To: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
Message-ID: <0shDJhw9EZOwTC8r9telIA99KVqSDjNJR44azwaunNU=.1d171e95-323b-42aa-8f39-9c0768a76283@github.com>

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
> 
> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
> 
> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
> 
> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
> 
> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Renamed matchesHelper() to findPattern()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28077/files
  - new: https://git.openjdk.org/jdk/pull/28077/files/3b493855..b3feafc5

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

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

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

From iklam at openjdk.org  Tue Nov  4 11:56:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 11:56:52 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v4]
In-Reply-To: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
Message-ID: <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
> 
> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
> 
> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
> 
> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
> 
> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Use String... as suggested by @stefank

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28077/files
  - new: https://git.openjdk.org/jdk/pull/28077/files/b3feafc5..c0f37497

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

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

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

From iklam at openjdk.org  Tue Nov  4 11:56:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 11:56:53 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
 <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
 <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>
Message-ID: <4uF7j8nhnIoLoEwu-FH8OESbXR6bprJgxdZZME-Kbik=.e76d884b-3519-465c-aed6-16d457026d2d@github.com>

On Tue, 4 Nov 2025 10:05:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > I didn't use "find", as all the existing methods in OutputAnalyzer use "match".
> 
> My point is that you can't have a function called "matches" that performs a "find" instead of a "matches":
> 
> ```
>     private boolean matchesHelper(String s, Pattern pattern) {
>         return s != null && pattern.matcher(s).find();
>     }
> ```
> 
> That's too confusing.

Thanks for the clarification. I've updated the code using your suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3485603985

From ogillespie at openjdk.org  Tue Nov  4 12:07:41 2025
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 4 Nov 2025 12:07:41 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <_ZuLLDZkfRh3dbvSyHdasiFsqBpna5pS5szkmughWOM=.bcc69cdc-af55-40e1-b7ec-5a88bdc651d2@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <_ZuLLDZkfRh3dbvSyHdasiFsqBpna5pS5szkmughWOM=.bcc69cdc-af55-40e1-b7ec-5a88bdc651d2@github.com>
Message-ID: <asE4O_QuHDehfWzYf_zMg-IHfD2Tjo4s1hPkY_mJoC4=.b9ec9aff-4676-4df6-a839-2c6c528c62e7@github.com>

On Tue, 4 Nov 2025 10:48:43 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 120:
> 
>> 118:         ArrayList<String> result = new ArrayList<>(75);
>> 119:         result.addAll(linkedListSource75);
>> 120:         bh.consume(result);
> 
> No need for blackholes, just return the result, it has the same effect I believe.

(see https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/#_pure_java_blackholes)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2490252260

From nbenalla at openjdk.org  Tue Nov  4 12:27:43 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Nov 2025 12:27:43 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27
Message-ID: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>

Get JDK 27 underway.

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

Commit messages:
 - initial commit start-of-JDK-27

Changes: https://git.openjdk.org/jdk/pull/28130/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370890
  Stats: 90 lines in 34 files changed: 46 ins; 0 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

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

From nbenalla at openjdk.org  Tue Nov  4 12:27:43 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Nov 2025 12:27:43 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <NnnWCE48NkQHktGkNdTcFspWTLOZlYbDT6TY5mzHTe4=.04053336-5ed9-47c9-8184-f29816203350@github.com>

On Tue, 4 Nov 2025 11:45:04 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 27 underway.

This initial version of the PR intentionally excludes the creation of the new symbol files so that the fundamental code aspects of the update are easier to see.

The GA release date is accurate.
The URL of the JVMLS will be updated in the next commit to be accurate.

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

PR Comment: https://git.openjdk.org/jdk/pull/28130#issuecomment-3485695380

From duke at openjdk.org  Tue Nov  4 12:53:53 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 4 Nov 2025 12:53:53 GMT
Subject: RFR: 8371130: Remove String template leftovers
Message-ID: <RklzdWeDiedA_l4aq9YDGEbmZAeqDzeE4xVJ-Wj5tHs=.8d70b329-b756-46f1-924c-a38eed1c8f49@github.com>

Hi all,

This is a trivial removal of methods that is no longer needed due since the String template function is now removed [JDK-8329948](https://bugs.openjdk.org/browse/JDK-8329948).

Testing: tier1-2.

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

Commit messages:
 - Remove leftovers

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

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

From cushon at openjdk.org  Tue Nov  4 12:59:30 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 4 Nov 2025 12:59:30 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v4]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <yFb2gl4exejHO5J4pCdbeu9GrsOepFN5BbBcAWlvS8c=.f01c72a8-933e-49d9-abdd-8397b5d5a440@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> ---
> 
> 
> Benchmark                                 (size)  Mode  Cnt   Score   Error  Units
> ToJavaStringTest.panama_copyLength             5  avgt   30   7.244 ? 0.057  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30   7.499 ? 0.140  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30  11.997 ? 0.148  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30  16.260 ? 0.141  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30  26.184 ? 0.184  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30   5.969 ? 0.055  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30   7.750 ? 0.066  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30  14.094 ? 0.181  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30  18.094 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30  36.052 ? 0.143  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30   4.622 ? 0.076  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30   4.703 ? 0.087  ns/op
> ToJavaStringTest.panama_readStringLength     100  avgt   30   8.117 ? 0.204  ns/op
> ToJavaStringTest.panama_readStringLength     200  avgt   30  10.568 ? 0.231  ns/op
> ToJavaStringTest.panama_readStringLength     451  avgt   30  16.273 ? 0.149  ns/op
> 
> 
> 
> Benchmark                                                  (size)  Mode  Cnt   Score   Error  Units
> FromJavaStringTest.panama_copyStringWithoutNullTerminator       5  avgt   30   4.582 ? 0.028  ns/op
> FromJavaStringTest.panama_copyStringWithoutNullTerminator      20  avgt   30   4.973 ? 0.013  ns/op
> FromJavaStringTest.panama_copyStringWithoutNullTerminator     100  avgt   30   9.229 ? 0.077  ns/op
> FromJavaStringTest.panama_copyStringWithoutNullTerminator     200  avgt  ...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add benchmarks, and demo setStringWithoutNullTerminator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/43a719eb..53b064f2

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

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

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

From redestad at openjdk.org  Tue Nov  4 13:08:44 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 4 Nov 2025 13:08:44 GMT
Subject: RFR: 8371130: Remove String template leftovers
In-Reply-To: <RklzdWeDiedA_l4aq9YDGEbmZAeqDzeE4xVJ-Wj5tHs=.8d70b329-b756-46f1-924c-a38eed1c8f49@github.com>
References: <RklzdWeDiedA_l4aq9YDGEbmZAeqDzeE4xVJ-Wj5tHs=.8d70b329-b756-46f1-924c-a38eed1c8f49@github.com>
Message-ID: <HC6DFxpgs5QUedVofQibabYOxzoGRBjaLvdXX4b6_sI=.56f9f1f2-d95b-46ae-a05b-05539b62380a@github.com>

On Tue, 4 Nov 2025 09:22:27 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This is a trivial removal of methods that is no longer needed due since the String template function is now removed [JDK-8329948](https://bugs.openjdk.org/browse/JDK-8329948).
> 
> Testing: tier1-2.

LGTM

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28125#pullrequestreview-3416381276

From swen at openjdk.org  Tue Nov  4 13:21:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Nov 2025 13:21:06 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v13]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <0ImrQ-C7KG5hEJS0sm4dlL0DEuEg_yVrdWBFTzNLCB4=.789c6046-a2bc-4554-8329-1e1463956e2a@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendPair(int i)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access
>    - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove assert & newCapacity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/1f16125b..271b1572

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=11-12

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

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

From stefank at openjdk.org  Tue Nov  4 13:47:11 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 4 Nov 2025 13:47:11 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <4uF7j8nhnIoLoEwu-FH8OESbXR6bprJgxdZZME-Kbik=.e76d884b-3519-465c-aed6-16d457026d2d@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
 <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
 <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>
 <4uF7j8nhnIoLoEwu-FH8OESbXR6bprJgxdZZME-Kbik=.e76d884b-3519-465c-aed6-16d457026d2d@github.com>
Message-ID: <-6jxu9IZk1e4HkuhLC7s6ukT2ZvaGyOhOmy0u6fFomk=.c72390c0-7422-4e63-80f4-0a5d0e5b09dd@github.com>

On Tue, 4 Nov 2025 11:53:05 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > > I didn't use "find", as all the existing methods in OutputAnalyzer use "match".
> > 
> > 
> > My point is that you can't have a function called "matches" that performs a "find" instead of a "matches":
> > ```
> >     private boolean matchesHelper(String s, Pattern pattern) {
> >         return s != null && pattern.matcher(s).find();
> >     }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > That's too confusing.
> 
> Thanks for the clarification. I've updated the code using your suggestion.

You need to make sure that the code has sensible throughout the library, not only the functions you introduce. There's still a function that uses "find" that has a name including "matches":

    public boolean stdoutMatches(String regexp) {
        return findPattern(regexp, getStdout());
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3486079517

From kfarrell at openjdk.org  Tue Nov  4 14:05:36 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 4 Nov 2025 14:05:36 GMT
Subject: Integrated: 8334015: Add Support for UUID Version 7 (UUIDv7) defined
 in RFC 9562
In-Reply-To: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <JIbLiVc-dobtvH6gI4qeRo0wJKKRFGgiVMwZp-ZFMQE=.74ebf572-06a5-40b1-bc1a-23eebacd617e@github.com>

On Mon, 19 May 2025 13:33:51 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
> 
> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
> 
> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
> 
> 
> - random-byte-only - 99.8%
> - higher-precision - 3.5%
> - counter-based - 0%
> 
> 
> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
> 
> - random-byte-only   143.487 ? 10.932  ns/op
> - higher-precision      149.651 ?  8.438 ns/op
> - counter-based         245.036 ?  2.943  ns/op
> 
> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

This pull request has now been integrated.

Changeset: 642ba4cf
Author:    Kieran Farrell <kfarrell at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/642ba4cfd18b7e17ff7f0ac3b2ce557bcaa93784
Stats:     121 lines in 2 files changed: 106 ins; 4 del; 11 mod

8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562

Reviewed-by: rriggs, jpai, alanb

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

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

From duke at openjdk.org  Tue Nov  4 14:08:49 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 14:08:49 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <xY2pMgKqhmbWnKJ4EkADktEjsGBVdIaH6DlZTOn8KKM=.d73eca5d-7eb3-4143-bf59-fe29e56948ca@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <BFFifJZZgD9cxcRbwSnhW_lQ3Ixt2OWqDi5ZlefQEk4=.7a41d647-3583-4315-93d8-2769971d9868@github.com>
 <xY2pMgKqhmbWnKJ4EkADktEjsGBVdIaH6DlZTOn8KKM=.d73eca5d-7eb3-4143-bf59-fe29e56948ca@github.com>
Message-ID: <yEilE9spuuj8qXcU_byBW8E-HgPnCAgcWdTwUYrKHC0=.be4e2f6d-d36c-41b1-a487-f95767b6f712@github.com>

On Tue, 4 Nov 2025 10:29:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>  Also, there is slight a mismatch between the title and the contents of the PR: it's not only about ArrayList

This is a bit of a grey area - it's not only about ArrayList, rather it's only about ArrayList.addAll().  One of the improvements is to the method itself, another is to the critical downstream method.  This is demonstrated by the benchmark, which only calls ArrayList.addAll().

I'd rather leave it as-is since it describes the purpose of the optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2490658415

From duke at openjdk.org  Tue Nov  4 14:08:51 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 14:08:51 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <asE4O_QuHDehfWzYf_zMg-IHfD2Tjo4s1hPkY_mJoC4=.b9ec9aff-4676-4df6-a839-2c6c528c62e7@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <_ZuLLDZkfRh3dbvSyHdasiFsqBpna5pS5szkmughWOM=.bcc69cdc-af55-40e1-b7ec-5a88bdc651d2@github.com>
 <asE4O_QuHDehfWzYf_zMg-IHfD2Tjo4s1hPkY_mJoC4=.b9ec9aff-4676-4df6-a839-2c6c528c62e7@github.com>
Message-ID: <t0KyqbNB6c83FmPQ-4cIUdF5FlHJEbKU2k57u5SPwd8=.03347966-af47-4af4-9425-e6a7e7f38351@github.com>

On Tue, 4 Nov 2025 12:04:40 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 120:
>> 
>>> 118:         ArrayList<String> result = new ArrayList<>(75);
>>> 119:         result.addAll(linkedListSource75);
>>> 120:         bh.consume(result);
>> 
>> No need for blackholes, just return the result, it has the same effect I believe.
>
> (see https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/#_pure_java_blackholes)

Thanks, will incorporate these changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2490662114

From rriggs at openjdk.org  Tue Nov  4 14:25:22 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Nov 2025 14:25:22 GMT
Subject: RFR: 8371130: Remove String template leftovers
In-Reply-To: <RklzdWeDiedA_l4aq9YDGEbmZAeqDzeE4xVJ-Wj5tHs=.8d70b329-b756-46f1-924c-a38eed1c8f49@github.com>
References: <RklzdWeDiedA_l4aq9YDGEbmZAeqDzeE4xVJ-Wj5tHs=.8d70b329-b756-46f1-924c-a38eed1c8f49@github.com>
Message-ID: <gNjgxRhrSlIT4bofxkqAVtgMjin0FOLMu4abScs7UZs=.db3ec053-59f7-4d5a-b2c5-8e012e5eda64@github.com>

On Tue, 4 Nov 2025 09:22:27 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This is a trivial removal of methods that is no longer needed due since the String template function is now removed [JDK-8329948](https://bugs.openjdk.org/browse/JDK-8329948).
> 
> Testing: tier1-2.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28125#pullrequestreview-3416742762

From duke at openjdk.org  Tue Nov  4 14:25:22 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Nov 2025 14:25:22 GMT
Subject: RFR: 8371130: Remove String template leftovers
In-Reply-To: <RklzdWeDiedA_l4aq9YDGEbmZAeqDzeE4xVJ-Wj5tHs=.8d70b329-b756-46f1-924c-a38eed1c8f49@github.com>
References: <RklzdWeDiedA_l4aq9YDGEbmZAeqDzeE4xVJ-Wj5tHs=.8d70b329-b756-46f1-924c-a38eed1c8f49@github.com>
Message-ID: <CKI-Y_Kt1-Ip9S33KI7H3CliCrytcRFO-kswSNYgPb8=.7c19a2ff-f1e0-431b-a6b9-d9561653e7ef@github.com>

On Tue, 4 Nov 2025 09:22:27 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This is a trivial removal of methods that is no longer needed due since the String template function is now removed [JDK-8329948](https://bugs.openjdk.org/browse/JDK-8329948).
> 
> Testing: tier1-2.

@JonasNorlinder 
Your change (at version af96666bc58ed58fa9982d822df9f4fae8118411) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28125#issuecomment-3486255316

From duke at openjdk.org  Tue Nov  4 14:30:25 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 4 Nov 2025 14:30:25 GMT
Subject: Integrated: 8371130: Remove String template leftovers
In-Reply-To: <RklzdWeDiedA_l4aq9YDGEbmZAeqDzeE4xVJ-Wj5tHs=.8d70b329-b756-46f1-924c-a38eed1c8f49@github.com>
References: <RklzdWeDiedA_l4aq9YDGEbmZAeqDzeE4xVJ-Wj5tHs=.8d70b329-b756-46f1-924c-a38eed1c8f49@github.com>
Message-ID: <l44MLvpgsIeLP0Fwl47B4KoB3lPQEOu3BxknUz_m0z8=.4f4b7f0e-5510-4218-8bdb-b6bcce49240d@github.com>

On Tue, 4 Nov 2025 09:22:27 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This is a trivial removal of methods that is no longer needed due since the String template function is now removed [JDK-8329948](https://bugs.openjdk.org/browse/JDK-8329948).
> 
> Testing: tier1-2.

This pull request has now been integrated.

Changeset: d4622b2c
Author:    Jonas Norlinder <jonas.norlinder at oracle.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4622b2ceac6b6aef2717bf427878df1290c4a38
Stats:     36 lines in 1 file changed: 0 ins; 36 del; 0 mod

8371130: Remove String template leftovers

Reviewed-by: redestad, rriggs

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

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

From duke at openjdk.org  Tue Nov  4 14:50:34 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 14:50:34 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
Message-ID: <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>

On Mon, 3 Nov 2025 21:50:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> src/java.base/share/classes/java/util/ArrayList.java line 753:
> 
>> 751:      */
>> 752:     public boolean addAll(Collection<? extends E> c) {
>> 753:         if (c.getClass() == ArrayList.class) {
> 
> Consider simplifying this to reduce code duplication:
> 
> Object[] a;
> int newNum;
> if (c.getClass() == ArrayList.class) {
>     ArrayList<?> src = (ArrayList<?>) c;
>     a = src.elementData;
>     numNew = src.size;
> } else {
>     a = c.toArray();
>     numNew = a.length;
> }
> modCount++;
> ...

Interestingly, this hurt the fast-path about 5%, but the control case about 35%.  I'm going to leave it as-is on the basis of data.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2490806925

From duke at openjdk.org  Tue Nov  4 14:50:36 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 14:50:36 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <yEilE9spuuj8qXcU_byBW8E-HgPnCAgcWdTwUYrKHC0=.be4e2f6d-d36c-41b1-a487-f95767b6f712@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <BFFifJZZgD9cxcRbwSnhW_lQ3Ixt2OWqDi5ZlefQEk4=.7a41d647-3583-4315-93d8-2769971d9868@github.com>
 <xY2pMgKqhmbWnKJ4EkADktEjsGBVdIaH6DlZTOn8KKM=.d73eca5d-7eb3-4143-bf59-fe29e56948ca@github.com>
 <yEilE9spuuj8qXcU_byBW8E-HgPnCAgcWdTwUYrKHC0=.be4e2f6d-d36c-41b1-a487-f95767b6f712@github.com>
Message-ID: <vUALRFZmhyyyYiQYUH_Ui1R71oawykvPO7zl30vBYCI=.2a2721e7-b899-45e2-be8b-5368fca7c8bd@github.com>

On Tue, 4 Nov 2025 14:05:32 GMT, jengebr <duke at openjdk.org> wrote:

>> All overriding methods should, yes. Also, there is slight a mismatch between the title and the contents of the PR: it's not only about `ArrayList`.
>
>>  Also, there is slight a mismatch between the title and the contents of the PR: it's not only about ArrayList
> 
> This is a bit of a grey area - it's not only about ArrayList, rather it's only about ArrayList.addAll().  One of the improvements is to the method itself, another is to the critical downstream method.  This is demonstrated by the benchmark, which only calls ArrayList.addAll().
> 
> I'd rather leave it as-is since it describes the purpose of the optimization.

> Should these have @Override?

Will fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2490809800

From duke at openjdk.org  Tue Nov  4 14:58:57 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 14:58:57 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <fZQkatd0ySToBaGRkbeRtRnZ-Pt-Ff0fp77Nn0zQ8wg=.2e4d4eb0-3d65-4f86-bf7f-85b909441043@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <fZQkatd0ySToBaGRkbeRtRnZ-Pt-Ff0fp77Nn0zQ8wg=.2e4d4eb0-3d65-4f86-bf7f-85b909441043@github.com>
Message-ID: <i3yuFM1S9NX7EtvqND1EcLai3q0wiUowYargx4Esol0=.349f94e5-459a-41f9-b3aa-18ef72c6e59d@github.com>

On Mon, 3 Nov 2025 21:41:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> src/java.base/share/classes/java/util/ArrayList.java line 758:
> 
>> 756:             int numNew = src.size;
>> 757:             if (numNew == 0)
>> 758:                 return false;
> 
> Previously `addAll()` with an empty list would increment `modCount`, whereas now it won't. Might want to move this test down after `modCount++` to avoid the unnecessary behavioral change.

Will definitely fix, thank you for the catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2490839459

From daniel.peintner at gmail.com  Tue Nov  4 15:01:46 2025
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Tue, 4 Nov 2025 16:01:46 +0100
Subject: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <6184b277-b030-4300-a319-81764ecac698@oracle.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
Message-ID: <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>

Hi Alexey,

Thank you for your reply.
I am using the badass runtime plugin which calls jpackage under the hood.

While trying to create an example project, I noticed that there were some
changes
'--mac-package-identifier' needs to go into imageOptions and
not installerOptions.
see
https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385

That fixed the problem with jpackage. Anyhow, it still does not work with
JDK25 and macOS signing.
Using the JDK25 seems to need additional options (compared to JDK21).

With JDK25 and --mac-sign the process no longer opens the KeyChain access
and asks for the credentials. Hence, the image itself is no longer signed
which matches with what I see on the debug console
"non signed app-image used to sign dmg"  ... freely translated into English
since I see the German version only

Therefore, apple's notary service says invalid with the logs like "The
binary is not signed with a valid Developer ID certificate".

Using the *same* gradle file, switching to JDK21 works without any issues
again.
I will try to investigate further.

Thanks,

-- Daniel




On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk <alexey.semenyuk at oracle.com>
wrote:

> Hi Daniel,
>
> I can not reproduce the issue you experience with jdk25.0.1:
>
> ---
> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output
> --type app-image --main-jar hello.jar --main-class
> com.my_domain.project.Hello --mac-package-identifier com.my-domain.project
> $ echo $?
> 0
> ---
>
> If I run the same command line without ` --mac-package-identifier` option
> it fails as expected:
> ---
> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output
> --type app-image --main-jar hello.jar --main-class
> com.my_domain.project.Hello
> Bundler Mac Application Image skipped because of a configuration problem:
> invalid mac bundle identifier [com.my_domain.project].
> Advice to fix: specify identifier with "--mac-package-identifier".
> ---
>
> The same failure for `--mac-package-identifier com.my_domain.project`
> (with the underscore):
> ---
> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output
> --type app-image --main-jar hello.jar --main-class
> com.my_domain.project.Hello --mac-package-identifier com.my_domain.project
> Bundler Mac Application Image skipped because of a configuration problem:
> invalid mac bundle identifier [com.my_domain.project].
> Advice to fix: specify identifier with "--mac-package-identifier".
> ---
>
> Any chance you accidentally put the string with the underscore instead of
> the hyphen as a value of the `--mac-package-identifier` option on your
> command line?
>
> - Alexey
>
> On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>
> Hi,
>
> I am about to switch a JavaFX project from JDK21 to JDK25 and I noticed a
> problem when running jpackage.
>
> My domain has a hyphen, like in www.my-domain.com
> Hence, my Java package reads like this: com.my_domain.project
> Note: hyphen becomes underscore.
>
> Running vanilla jpackage in JDK21 complained with
> Invalid Mac-Bundle-ID [com.my_domain.project]
> due to the *invalid* underscore and suggests me to use
> "--mac-package-identifier"
>
> Hence, I added --mac-package-identifier com.my-domain.project (with the
> hyphen again)
> All good so far.
>
> Running the same code with JDK25 with the above settings shows the error
> message again
> Invalid Mac-Bundle-ID [com.my_domain.project]
>
> I can add any argument to  --mac-package-identifier
> It seems it is simply not taken into account.
>
> I am using JDK 25.0.1
>
> Is this a known issue with JDK25 and jpackage?
> Is there any other way to make jpackage work?
>
> Thanks,
>
> -- Daniel
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251104/68ee5c77/attachment-0001.htm>

From jvernee at openjdk.org  Tue Nov  4 15:43:47 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Nov 2025 15:43:47 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
Message-ID: <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>

On Mon, 3 Nov 2025 18:29:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments Patricio

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3486638747

From jvernee at openjdk.org  Tue Nov  4 15:43:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Nov 2025 15:43:50 GMT
Subject: Integrated: 8370344: Arbitrary Java frames on stack during scoped
 access
In-Reply-To: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
Message-ID: <GNO4wS2ioX_SgkNAktGtzSaaSYJSXKPMPju2gIlHU88=.406e4e77-96eb-4342-85cd-8b479ba69eb2@github.com>

On Tue, 21 Oct 2025 16:00:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

This pull request has now been integrated.

Changeset: a51a0bf5
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a51a0bf57feaae0862fd7f3dbf305883d49781a0
Stats:     550 lines in 9 files changed: 534 ins; 5 del; 11 mod

8370344: Arbitrary Java frames on stack during scoped access

Reviewed-by: pchilanomate, dholmes, liach

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

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

From pchilanomate at openjdk.org  Tue Nov  4 15:47:31 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 15:47:31 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  fix to JvmtiHideSingleStepping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/4dff05a8..55c89ad0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=12-13

  Stats: 182 lines in 4 files changed: 164 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

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

From pchilanomate at openjdk.org  Tue Nov  4 15:47:33 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 15:47:33 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v13]
In-Reply-To: <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
Message-ID: <1m9Kbr2qq1hRl4Sc4YG39hxJ0WFS5aAx-BDmiAaZ_Xk=.d9ba0f21-f06d-46b3-8b08-cf5cc3520906@github.com>

On Mon, 3 Nov 2025 19:03:07 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggested fix in macroAssembler_ppc.cpp

> Hello, I have meet a simlar question as: https://stackoverflow.com/questions/79808508/jdk24-tomcat-start-pinned-in-virtual-thead-env
> 
> I want to know if this quesiton is same as https://bugs.openjdk.org/browse/JDK-8369238 or not. How to temporarily solve this problem?
>
In the stacktrace posted, virtual thread #157 is pinned not because of the `static synchronized` but because there are native frames in the stack due to initializing class `CoyoteOutputStream`. This PR doesn?t address that pinning case. It addresses the case of virtual threads pinned waiting for a class to be initialized by another thread. Feel free to send any related questions to the loom-dev mailing list instead, it?s the best place to discuss this. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3486642618

From pchilanomate at openjdk.org  Tue Nov  4 15:48:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 15:48:00 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v13]
In-Reply-To: <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
Message-ID: <kLlUGHdyPCrCOqL-8WVRI9GahnH5HUnLJs7orQv3rms=.a485dd8f-b0f3-4b82-ad78-d63d678fbee2@github.com>

On Mon, 3 Nov 2025 19:03:07 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggested fix in macroAssembler_ppc.cpp

I pushed a small fix to `JvmtiHideSingleStepping` for an issue found during pre-integration testing where we hit this assert: https://github.com/openjdk/jdk/blob/50bb92a33b32778a96b1823ff995889892bef890/src/hotspot/share/prims/jvmtiThreadState.hpp#L337
The problem is that for a preempting vthread, the `JvmtiThreadState` of the current `JavaThread` has already been rebinded to the state of the carrier when executing `~JvmtiHideSingleStepping`. The fix is to remember the `JvmtiThreadState` used originally in the `JvmtiHideSingleStepping` constructor. The commit includes a new test that reproduces the issue. @sspitsyn maybe you could take a look at this please?

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3486666711

From jvernee at openjdk.org  Tue Nov  4 15:50:02 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Nov 2025 15:50:02 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
 [v2]
In-Reply-To: <IZXKtP1X-lxkJrUaRk61IDTKZG4D7cJJW31XtFtDjqo=.542f242c-db52-4ac7-bf22-3cf281c7dee8@github.com>
References: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
 <IZXKtP1X-lxkJrUaRk61IDTKZG4D7cJJW31XtFtDjqo=.542f242c-db52-4ac7-bf22-3cf281c7dee8@github.com>
Message-ID: <FZq6CBx_fyQx2YEpp2MsF6f6YRpPRwoIeVx1m_7FOjw=.ba1ed9a1-c37b-442a-b8c5-b8b489adfd3d@github.com>

On Tue, 28 Oct 2025 18:31:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> java.lang.reflect.Proxy has some surprising behaviors associated with protected methods in Object, covariant/contravariant overrides in interfaces, and package-private types in method signatures. Such behaviors should have tests, so that they are not accidentally perturbed in Proxy updates.
>
> Chen Liang 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>  - Tweaks
>  - 8370839: Tests to verify peculiar Proxy dispatching behaviors

These look good, but I think it would help if you could add a short description (in a comment) for each/some test cases of what it is that you're trying to test. Especially since some of the test cases are targeting the invisible bridge methods.

test/jdk/java/lang/reflect/Proxy/BridgeMethodsTest.java line 49:

> 47:     }
> 48: 
> 49:     // Does not duplicate with Object::clone so it is not proxied

Redundant comment?

test/jdk/java/lang/reflect/Proxy/NonPublicSignaturesTest.java line 72:

> 70:         instance.call();
> 71:         // checkcast fails - proxy class cannot access the return type
> 72:         returnValue.set(Internal.INSTANCE);

Where is this 'checkcast' happening exactly?

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

PR Review: https://git.openjdk.org/jdk/pull/28023#pullrequestreview-3416891103
PR Review Comment: https://git.openjdk.org/jdk/pull/28023#discussion_r2490826618
PR Review Comment: https://git.openjdk.org/jdk/pull/28023#discussion_r2490846156

From alanb at openjdk.org  Tue Nov  4 15:54:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Nov 2025 15:54:55 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v14]
In-Reply-To: <dDNl9fxEjNuG4kiZXlI7rbIIAlS8AceAq3n6t97kDIY=.ceecc515-86e2-4ba0-b39b-4c7178d4e923@github.com>
References: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
 <2RIunJzmUUCMaaqbfPrIfeXJWc6Is7cme519UWUBLNc=.7441d786-0b49-4466-a994-7800bec9acde@github.com>
 <dDNl9fxEjNuG4kiZXlI7rbIIAlS8AceAq3n6t97kDIY=.ceecc515-86e2-4ba0-b39b-4c7178d4e923@github.com>
Message-ID: <FL6NV5CUwnzfwezOVmsq1Jv2quROjst6NG3mRwT2FSw=.9c98c6d2-9acc-4d46-b499-37edf02d213d@github.com>

On Tue, 4 Nov 2025 01:59:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> which was apparently due to `wcanonicalize()` failing when `getFinalPath()` failed for a symlink. Suppressing this failure reinstates the control flow previously defined in the Java layer. With this change, all tier1-tier3 tests pass.

File::getCanonicalFile is specified to return a result when the file doesn't exist to I think this is okay. Were you able to establish if this was a just a broken link or something else?

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

PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3486701449

From alanb at openjdk.org  Tue Nov  4 16:23:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Nov 2025 16:23:45 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v10]
In-Reply-To: <XYyXqAYXrvlOaH1eefIzrrqMokx5mIS9Q4q_aR0qYxA=.96d6f935-4b12-4bce-888d-89bff4cd1b45@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <XYyXqAYXrvlOaH1eefIzrrqMokx5mIS9Q4q_aR0qYxA=.96d6f935-4b12-4bce-888d-89bff4cd1b45@github.com>
Message-ID: <6-z7Z9kN7MYxCnzup409xtPA-i0tRqdCcyAPzNRWU74=.85889a74-ed39-4592-91f2-eaa1c9c95b95@github.com>

On Wed, 17 Sep 2025 14:49:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

I went through the two relaunchers and they look okay. (I wasn't initially supportive of doing this but it is pragmatic way to test while in this current hybrid state).

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24380#pullrequestreview-3417403333

From iklam at openjdk.org  Tue Nov  4 16:24:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 16:24:47 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <-6jxu9IZk1e4HkuhLC7s6ukT2ZvaGyOhOmy0u6fFomk=.c72390c0-7422-4e63-80f4-0a5d0e5b09dd@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
 <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
 <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>
 <4uF7j8nhnIoLoEwu-FH8OESbXR6bprJgxdZZME-Kbik=.e76d884b-3519-465c-aed6-16d457026d2d@github.com>
 <-6jxu9IZk1e4HkuhLC7s6ukT2ZvaGyOhOmy0u6fFomk=.c72390c0-7422-4e63-80f4-0a5d0e5b09dd@github.com>
Message-ID: <EyOHsmC5aW8d5de4cGo4xT7DESDjbtN6oVXc2Xa3yL8=.6ebed0ab-e862-431b-b3f3-afb6ab35f08f@github.com>

On Tue, 4 Nov 2025 13:44:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> You need to make sure that the code has sensible names throughout the library, not only the functions you introduce. There are still functions that uses "find" that have names that including the word "matches":
> 
> ```
>     public boolean stdoutMatches(String regexp) {
>         return findPattern(regexp, getStdout());
>     }
> ```

We have existing APIs like `contains()` vs `shouldContain()`. If I introduce a new API `finds()`, that will be inconsistent with `shouldMatch()`.

There are hundreds of `shouldMatch()` in existing tests, and honestly "matching a regexp" is more intuitive than "finding a substring that matches the regexp", so I don't see any reason of changing that.

So, we will inevitably have an API with the name `match` that eventually calls "...matcher().find()". It's still using a "matcher" to decides whether something "matches". I don't see a problem with doing this, especially when it's only used in the implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3486861935

From alexey.semenyuk at oracle.com  Tue Nov  4 16:30:11 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 11:30:11 -0500
Subject: [External] : Re: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
 <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
Message-ID: <980f8fe4-4a5e-4144-9de1-323aa77bbeab@oracle.com>

Hi Daniel,

On 11/4/2025 10:01 AM, Daniel Peintner wrote:
> Hi Alexey,
>
> Thank you for your reply.
> I am using the?badass runtime plugin which calls jpackage under the hood.
>
> While trying to create an example project, I noticed that there were 
> some changes
> '--mac-package-identifier' needs to go into?imageOptions and 
> not?installerOptions.
> see 
> https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385 
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385__;!!ACWV5N9M2RV99hQ!JboKeapbys_zvoKtDq8PJD1LD7_jTnfgpRoEKxXwGARA-sZKB8VR-82CozmfGafHgKQvfLrODMHA2f2-bIJXfhDZBpgo-GY$>
>
> That fixed the problem with jpackage. Anyhow, it still does not work 
> with JDK25 and macOS signing.
> Using the JDK25 seems to need additional options (compared to JDK21).
Interesting. Looks like a bug in jdk25's jpackage.

>
> With JDK25 and --mac-sign the process no longer opens the KeyChain 
> access and asks for the credentials.
Can you run jpackage with the "--verbose" option and share logs of 
running the jdk25 and jdk21 jpackage? This may help us understand why 
behavior changed.

- Alexey

> Hence, the image itself is no longer signed which matches with what I 
> see on the debug console
> "non signed app-image used to sign dmg"? ... freely translated into 
> English since I see the German version only
>
> Therefore, apple's notary service says invalid with the logs like "The 
> binary is not signed with a valid Developer ID certificate".
>
> Using the *same* gradle file, switching to JDK21 works without any 
> issues again.
> I will try to investigate further.
>
> Thanks,
>
> -- Daniel
>
>
>
>
> On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk 
> <alexey.semenyuk at oracle.com> wrote:
>
>     Hi Daniel,
>
>     I can not reproduce the issue you experience with jdk25.0.1:
>
>     ---
>     $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest
>     output --type app-image --main-jar hello.jar --main-class
>     com.my_domain.project.Hello --mac-package-identifier
>     com.my-domain.project
>     $ echo $?
>     0
>     ---
>
>     If I run the same command line without ` --mac-package-identifier`
>     option it fails as expected:
>     ---
>     $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest
>     output --type app-image --main-jar hello.jar --main-class
>     com.my_domain.project.Hello
>     Bundler Mac Application Image skipped because of a configuration
>     problem: invalid mac bundle identifier [com.my_domain.project].
>     Advice to fix: specify identifier with "--mac-package-identifier".
>     ---
>
>     The same failure for `--mac-package-identifier
>     com.my_domain.project` (with the underscore):
>     ---
>     $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest
>     output --type app-image --main-jar hello.jar --main-class
>     com.my_domain.project.Hello --mac-package-identifier
>     com.my_domain.project
>     Bundler Mac Application Image skipped because of a configuration
>     problem: invalid mac bundle identifier [com.my_domain.project].
>     Advice to fix: specify identifier with "--mac-package-identifier".
>     ---
>
>     Any chance you accidentally put the string with the underscore
>     instead of the hyphen as a value of the `--mac-package-identifier`
>     option on your command line?
>
>     - Alexey
>
>     On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>     Hi,
>>
>>     I am about to switch a JavaFX project from JDK21 to JDK25 and I
>>     noticed a problem when running jpackage.
>>
>>     My domain has a hyphen, like in www.my-domain.com
>>     <https://urldefense.com/v3/__http://www.my-domain.com__;!!ACWV5N9M2RV99hQ!JboKeapbys_zvoKtDq8PJD1LD7_jTnfgpRoEKxXwGARA-sZKB8VR-82CozmfGafHgKQvfLrODMHA2f2-bIJXfhDZ7KlfIEw$>
>>     Hence, my Java package reads like this: com.my_domain.project
>>     Note: hyphen becomes underscore.
>>
>>     Running vanilla jpackage in JDK21 complained with
>>     Invalid Mac-Bundle-ID [com.my_domain.project]
>>     due to the *invalid* underscore and suggests me to use
>>     "--mac-package-identifier"
>>
>>     Hence, I added --mac-package-identifier com.my-domain.project
>>     (with the hyphen again)
>>     All good so far.
>>
>>     Running the same code with JDK25 with the above settings shows
>>     the error message again
>>     Invalid Mac-Bundle-ID [com.my_domain.project]
>>
>>     I can add any argument to --mac-package-identifier
>>     It seems it is simply not taken into account.
>>
>>     I am using JDK 25.0.1
>>
>>     Is this a known issue with?JDK25 and jpackage?
>>     Is there any other way to make jpackage work?
>>
>>     Thanks,
>>
>>     -- Daniel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251104/bbe16f41/attachment-0001.htm>

From bpb at openjdk.org  Tue Nov  4 16:55:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Nov 2025 16:55:17 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v14]
In-Reply-To: <FL6NV5CUwnzfwezOVmsq1Jv2quROjst6NG3mRwT2FSw=.9c98c6d2-9acc-4d46-b499-37edf02d213d@github.com>
References: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
 <2RIunJzmUUCMaaqbfPrIfeXJWc6Is7cme519UWUBLNc=.7441d786-0b49-4466-a994-7800bec9acde@github.com>
 <dDNl9fxEjNuG4kiZXlI7rbIIAlS8AceAq3n6t97kDIY=.ceecc515-86e2-4ba0-b39b-4c7178d4e923@github.com>
 <FL6NV5CUwnzfwezOVmsq1Jv2quROjst6NG3mRwT2FSw=.9c98c6d2-9acc-4d46-b499-37edf02d213d@github.com>
Message-ID: <_JFRaQ0UqNC-030AkAhPfmKRV7MOwEs1N9OZzibLMxU=.3c55410e-8314-4869-ba49-d9498aeaee7b@github.com>

On Tue, 4 Nov 2025 15:51:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Were you able to establish if this was a just a broken link or something else?

Not definitively, but I think if could be. The Windows system error code was `ERROR_PATH_NOT_FOUND` (3).

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

PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3487012347

From daniel.peintner at gmail.com  Tue Nov  4 17:32:23 2025
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Tue, 4 Nov 2025 18:32:23 +0100
Subject: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
 <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
Message-ID: <CAAoP7T7XG_zWj0GSM37oMMvPq=NJ300Aac9skq8erXjYzqvmqw@mail.gmail.com>

 Hi Alexey, all,

I nailed down the problem to the following, which seems to differ between
JDK25 and JDK21.
Maybe this helps to reproduce the issue.

jpackage is called 3 times in my process

   1. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
   --type app-image --input
   /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib
   --main-jar myPROJECT-25.11.03.jar --main-class
   eu.my_company.myproject.Launcher --dest
   /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT
   --app-version 25.11.03 --runtime-image
   /Users/daniel/Documents/GitHub/myPROJECT/build/jre --java-options
   --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED
   --java-options --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED
   --java-options
   --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED
   --java-options
   --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED
   --java-options
   --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED
   --java-options --add-exports=java.management/javax.management=ALL-UNNAMED
   --java-options
   --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED
   --java-options --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED
   --icon src/main/deploy/package/macosx/myPROJECT.icns
   --mac-package-identifier eu.my-company.myproject --mac-sign

   2. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
   --type pkg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
   --name myPROJECT --app-version 25.11.03 --app-image
   /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
   --file-associations src/main/resources/associations.properties
   --app-version 25.11.03 --vendor "My Company" --copyright "My Company"
   --mac-sign

   3. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
   --type dmg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
   --name myPROJECT --app-version 25.11.03 --app-image
   /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
   --file-associations src/main/resources/associations.properties
   --app-version 25.11.03 --vendor "My Company" --copyright "My Company"
   --mac-sign


First it creates the app-image and afterwards it creates pkg and dmg and
signs it.

As you can see in the 3 commands, it uses JDK21.
Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after step 2 already
with the following message in German

Warnung: Nicht signiertes app-image wird zum Erstellen von signiertem pkg
verwendet.

It translates to something like: it tries to sign pkg and complains that
the app-image is not signed.
Hence, somehow step 1 failed already but does not show any error/warning.

Please let me know whether the above helps to reproduce the issue.

Thanks,

-- Daniel



On Tue, Nov 4, 2025 at 4:01?PM Daniel Peintner <daniel.peintner at gmail.com>
wrote:

> Hi Alexey,
>
> Thank you for your reply.
> I am using the badass runtime plugin which calls jpackage under the hood.
>
> While trying to create an example project, I noticed that there were some
> changes
> '--mac-package-identifier' needs to go into imageOptions and
> not installerOptions.
> see
> https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385
>
> That fixed the problem with jpackage. Anyhow, it still does not work with
> JDK25 and macOS signing.
> Using the JDK25 seems to need additional options (compared to JDK21).
>
> With JDK25 and --mac-sign the process no longer opens the KeyChain access
> and asks for the credentials. Hence, the image itself is no longer signed
> which matches with what I see on the debug console
> "non signed app-image used to sign dmg"  ... freely translated into
> English since I see the German version only
>
> Therefore, apple's notary service says invalid with the logs like "The
> binary is not signed with a valid Developer ID certificate".
>
> Using the *same* gradle file, switching to JDK21 works without any issues
> again.
> I will try to investigate further.
>
> Thanks,
>
> -- Daniel
>
>
>
>
> On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk <alexey.semenyuk at oracle.com>
> wrote:
>
>> Hi Daniel,
>>
>> I can not reproduce the issue you experience with jdk25.0.1:
>>
>> ---
>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output
>> --type app-image --main-jar hello.jar --main-class
>> com.my_domain.project.Hello --mac-package-identifier com.my-domain.project
>> $ echo $?
>> 0
>> ---
>>
>> If I run the same command line without ` --mac-package-identifier` option
>> it fails as expected:
>> ---
>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output
>> --type app-image --main-jar hello.jar --main-class
>> com.my_domain.project.Hello
>> Bundler Mac Application Image skipped because of a configuration problem:
>> invalid mac bundle identifier [com.my_domain.project].
>> Advice to fix: specify identifier with "--mac-package-identifier".
>> ---
>>
>> The same failure for `--mac-package-identifier com.my_domain.project`
>> (with the underscore):
>> ---
>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output
>> --type app-image --main-jar hello.jar --main-class
>> com.my_domain.project.Hello --mac-package-identifier com.my_domain.project
>> Bundler Mac Application Image skipped because of a configuration problem:
>> invalid mac bundle identifier [com.my_domain.project].
>> Advice to fix: specify identifier with "--mac-package-identifier".
>> ---
>>
>> Any chance you accidentally put the string with the underscore instead of
>> the hyphen as a value of the `--mac-package-identifier` option on your
>> command line?
>>
>> - Alexey
>>
>> On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>
>> Hi,
>>
>> I am about to switch a JavaFX project from JDK21 to JDK25 and I noticed a
>> problem when running jpackage.
>>
>> My domain has a hyphen, like in www.my-domain.com
>> Hence, my Java package reads like this: com.my_domain.project
>> Note: hyphen becomes underscore.
>>
>> Running vanilla jpackage in JDK21 complained with
>> Invalid Mac-Bundle-ID [com.my_domain.project]
>> due to the *invalid* underscore and suggests me to use
>> "--mac-package-identifier"
>>
>> Hence, I added --mac-package-identifier com.my-domain.project (with the
>> hyphen again)
>> All good so far.
>>
>> Running the same code with JDK25 with the above settings shows the error
>> message again
>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>
>> I can add any argument to  --mac-package-identifier
>> It seems it is simply not taken into account.
>>
>> I am using JDK 25.0.1
>>
>> Is this a known issue with JDK25 and jpackage?
>> Is there any other way to make jpackage work?
>>
>> Thanks,
>>
>> -- Daniel
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251104/d811b821/attachment-0001.htm>

From alexey.semenyuk at oracle.com  Tue Nov  4 17:53:13 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 12:53:13 -0500
Subject: [External] : Re: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <CAAoP7T7XG_zWj0GSM37oMMvPq=NJ300Aac9skq8erXjYzqvmqw@mail.gmail.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
 <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
 <CAAoP7T7XG_zWj0GSM37oMMvPq=NJ300Aac9skq8erXjYzqvmqw@mail.gmail.com>
Message-ID: <98fc3c7c-d485-487b-9ab5-f4257c40cacf@oracle.com>

Hi Daniel,

Does the warning message resembles the one at [1]?

I think your evaluation that the step 1 failed is correct. I'd suggest 
adding "--verbose" option to the step 1 command line to get more details.

[1] 
https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties#L85

- Alexey

On 11/4/2025 12:32 PM, Daniel Peintner wrote:
> Hi Alexey, all,
>
> I nailed down the problem to the following, which seems to differ 
> between JDK25 and JDK21.
> Maybe this helps to reproduce the issue.
>
> jpackage is called 3 times in my process
>
>  1. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>     --type app-image --input
>     /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib
>     --main-jar myPROJECT-25.11.03.jar --main-class
>     eu.my_company.myproject.Launcher --dest
>     /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name
>     myPROJECT --app-version 25.11.03 --runtime-image
>     /Users/daniel/Documents/GitHub/myPROJECT/build/jre --java-options
>     --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED
>     --java-options
>     --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED
>     --java-options
>     --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED
>     --java-options
>     --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED
>     --java-options
>     --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED
>     --java-options
>     --add-exports=java.management/javax.management=ALL-UNNAMED
>     --java-options
>     --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED
>     --java-options
>     --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED --icon
>     src/main/deploy/package/macosx/myPROJECT.icns
>     --mac-package-identifier eu.my-company.myproject --mac-sign
>
>  2. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>     --type pkg --dest
>     /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name
>     myPROJECT --app-version 25.11.03 --app-image
>     /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>     --file-associations src/main/resources/associations.properties
>     --app-version 25.11.03 --vendor "My Company" --copyright "My
>     Company" --mac-sign
>
>  3. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>     --type dmg --dest
>     /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name
>     myPROJECT --app-version 25.11.03 --app-image
>     /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>     --file-associations src/main/resources/associations.properties
>     --app-version 25.11.03 --vendor "My Company" --copyright "My
>     Company" --mac-sign
>
>
> First it creates the app-image and afterwards it creates pkg and dmg 
> and signs it.
>
> As you can see in the 3 commands, it uses JDK21.
> Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after step 2 
> already with the following message in German
>
> Warnung: Nicht signiertes app-image wird zum Erstellen von signiertem 
> pkg verwendet.
>
> It translates to something?like: it tries to sign pkg and complains 
> that the app-image is not signed.
> Hence, somehow step 1 failed already but does not show any error/warning.
>
> Please let me know whether the above helps to reproduce the issue.
>
> Thanks,
>
> -- Daniel
>
>
>
> On Tue, Nov 4, 2025 at 4:01?PM Daniel Peintner 
> <daniel.peintner at gmail.com> wrote:
>
>     Hi Alexey,
>
>     Thank you for your reply.
>     I am using the?badass runtime plugin which calls jpackage under
>     the hood.
>
>     While trying to create an example project, I noticed that there
>     were some changes
>     '--mac-package-identifier' needs to go into?imageOptions and
>     not?installerOptions.
>     see
>     https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385
>     <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-K4xefEo$>
>
>     That fixed the problem with jpackage. Anyhow, it still does not
>     work with JDK25 and macOS signing.
>     Using the JDK25 seems to need additional options (compared to JDK21).
>
>     With JDK25 and --mac-sign the process no longer opens the KeyChain
>     access and asks for the credentials. Hence, the image itself is no
>     longer signed which matches with what I see on the debug console
>     "non signed app-image used to sign dmg"? ... freely translated
>     into English since I see the German version only
>
>     Therefore, apple's notary service says invalid with the logs like
>     "The binary is not signed with a valid Developer ID certificate".
>
>     Using the *same* gradle file, switching to JDK21 works without any
>     issues again.
>     I will try to investigate further.
>
>     Thanks,
>
>     -- Daniel
>
>
>
>
>     On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk
>     <alexey.semenyuk at oracle.com> wrote:
>
>         Hi Daniel,
>
>         I can not reproduce the issue you experience with jdk25.0.1:
>
>         ---
>         $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input
>         --dest output --type app-image --main-jar hello.jar
>         --main-class com.my_domain.project.Hello
>         --mac-package-identifier com.my-domain.project
>         $ echo $?
>         0
>         ---
>
>         If I run the same command line without `
>         --mac-package-identifier` option it fails as expected:
>         ---
>         $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input
>         --dest output --type app-image --main-jar hello.jar
>         --main-class com.my_domain.project.Hello
>         Bundler Mac Application Image skipped because of a
>         configuration problem: invalid mac bundle identifier
>         [com.my_domain.project].
>         Advice to fix: specify identifier with "--mac-package-identifier".
>         ---
>
>         The same failure for `--mac-package-identifier
>         com.my_domain.project` (with the underscore):
>         ---
>         $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input
>         --dest output --type app-image --main-jar hello.jar
>         --main-class com.my_domain.project.Hello
>         --mac-package-identifier com.my_domain.project
>         Bundler Mac Application Image skipped because of a
>         configuration problem: invalid mac bundle identifier
>         [com.my_domain.project].
>         Advice to fix: specify identifier with "--mac-package-identifier".
>         ---
>
>         Any chance you accidentally put the string with the underscore
>         instead of the hyphen as a value of the
>         `--mac-package-identifier` option on your command line?
>
>         - Alexey
>
>         On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>         Hi,
>>
>>         I am about to switch a JavaFX project from JDK21 to JDK25 and
>>         I noticed a problem when running jpackage.
>>
>>         My domain has a hyphen, like in www.my-domain.com
>>         <https://urldefense.com/v3/__http://www.my-domain.com__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-KS5-g-8$>
>>         Hence, my Java package reads like this: com.my_domain.project
>>         Note: hyphen becomes underscore.
>>
>>         Running vanilla jpackage in JDK21 complained with
>>         Invalid Mac-Bundle-ID [com.my_domain.project]
>>         due to the *invalid* underscore and suggests me to use
>>         "--mac-package-identifier"
>>
>>         Hence, I added --mac-package-identifier com.my-domain.project
>>         (with the hyphen again)
>>         All good so far.
>>
>>         Running the same code with JDK25 with the above settings
>>         shows the error message again
>>         Invalid Mac-Bundle-ID [com.my_domain.project]
>>
>>         I can add any argument to --mac-package-identifier
>>         It seems it is simply not taken into account.
>>
>>         I am using JDK 25.0.1
>>
>>         Is this a known issue with?JDK25 and jpackage?
>>         Is there any other way to make jpackage work?
>>
>>         Thanks,
>>
>>         -- Daniel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251104/0368d34e/attachment-0001.htm>

From naoto at openjdk.org  Tue Nov  4 17:53:36 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Nov 2025 17:53:36 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v5]
In-Reply-To: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
Message-ID: <uQzj0iMIvdDIFMxz6ZpI8x_pFbMh2sh5okn-uBp0Qoc=.97175766-315c-414f-a129-e2e15c5fac0e@github.com>

> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Minor header fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28076/files
  - new: https://git.openjdk.org/jdk/pull/28076/files/05f5f0d9..b0bfd789

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

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

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

From redestad at openjdk.org  Tue Nov  4 18:13:26 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 4 Nov 2025 18:13:26 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
Message-ID: <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>

On Tue, 4 Nov 2025 14:47:01 GMT, jengebr <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ArrayList.java line 753:
>> 
>>> 751:      */
>>> 752:     public boolean addAll(Collection<? extends E> c) {
>>> 753:         if (c.getClass() == ArrayList.class) {
>> 
>> Consider simplifying this to reduce code duplication:
>> 
>> Object[] a;
>> int newNum;
>> if (c.getClass() == ArrayList.class) {
>>     ArrayList<?> src = (ArrayList<?>) c;
>>     a = src.elementData;
>>     numNew = src.size;
>> } else {
>>     a = c.toArray();
>>     numNew = a.length;
>> }
>> modCount++;
>> ...
>
> Interestingly, this hurt the fast-path about 5%, but the control case about 35%.  I'm going to leave it as-is on the basis of data.

Ok, if the split helps the JIT peel and optimize better some amount of code duplication can be fine, but maybe then split out the two implementations to separate methods (to help inlining) and comment that the code duplication is intentional and should be handled with care.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491610407

From duke at openjdk.org  Tue Nov  4 18:35:23 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 18:35:23 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <RsQ5PECszF1LnGTUHUnli8g0GWjU492cbsSThnkzBJ8=.46b8d5f1-4964-4824-b926-abd17f9deee3@github.com>

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

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

  Adding direct unit tests, minor revisions to optimizations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28116/files
  - new: https://git.openjdk.org/jdk/pull/28116/files/dbb5b6cf..626dabbe

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

  Stats: 383 lines in 5 files changed: 281 ins; 80 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/28116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28116/head:pull/28116

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

From duke at openjdk.org  Tue Nov  4 18:35:24 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 18:35:24 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <_QKwegyXf3jupFBrPOohr11EI7L4MdaWTTkuS-IFzIw=.b39354d5-4b50-4973-9d47-d1359bdc4ed2@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <8NMNMnCb5ojeNZOQvN-z59cIsBIJ1z4gOmytWXQTQjQ=.5354c1f2-2be4-4f89-a830-3e28be8c34df@github.com>
 <LD-ZD9gJM9xuAUUR5fm28i_m2VL7NKh38SsAEwg3oyg=.6e7e5a1f-a62b-4fda-9c13-67470d7d3f0b@github.com>
 <_QKwegyXf3jupFBrPOohr11EI7L4MdaWTTkuS-IFzIw=.b39354d5-4b50-4973-9d47-d1359bdc4ed2@github.com>
Message-ID: <-V8DCjfXV2OFsF45OZnGiiGlcjo4QWp2ghkNn_gMrUo=.1d805c24-0de9-4343-83f4-919a92b955ec@github.com>

On Mon, 3 Nov 2025 21:51:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> There needs to be some proof that this functionality is covered. If you could list existing tests that exercise the ArrayList.addAll(ArrayList) and Collections.singleton().toArray() methods, we could simply add this bug number to them.

I added two new unit tests that thoroughly cover this.  Full set of tier-1 tests passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3487487062

From duke at openjdk.org  Tue Nov  4 18:35:25 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 18:35:25 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
Message-ID: <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>

On Tue, 4 Nov 2025 18:10:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Interestingly, this hurt the fast-path about 5%, but the control case about 35%.  I'm going to leave it as-is on the basis of data.
>
> Ok, if the split helps the JIT peel and optimize better some amount of code duplication can be fine, but maybe then split out the two implementations to separate methods (to help inlining) and comment that the code duplication is intentional and should be handled with care.

The comment is a good idea, but splitting out the duplication may make maintenance even worse by separating the duplicate sections.  What do you think?

Also, I'll benchmark with the split to get the impact data.  Not sure I can meaningfully validate an impact to inlining.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491667225

From duke at openjdk.org  Tue Nov  4 18:35:26 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 18:35:26 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <Yo7f5a6vZYHEIPLGyiWDrq_B_MCgYxGfoYeicKx1f8I=.86703dd8-ad50-4eed-af0e-bcc3e794ad93@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <Yo7f5a6vZYHEIPLGyiWDrq_B_MCgYxGfoYeicKx1f8I=.86703dd8-ad50-4eed-af0e-bcc3e794ad93@github.com>
Message-ID: <HHzoZXF82oNA1DjQaLvf7k6M3zuQA95aV--bfB6Apvg=.ef7a0904-cc9d-4b92-b8ae-5daf8ddfa714@github.com>

On Tue, 4 Nov 2025 10:51:58 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> jengebr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding direct unit tests, minor revisions to optimizations
>
> test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 60:
> 
>> 58: @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> 59: @Fork(value = 1, jvmArgs = { "-XX:+UseParallelGC", "-Xmx3g" })
>> 60: public class ArrayListBulkOpsBenchmark {
> 
> You might find a layout like this a bit neater:
> 
> 
> @State(Scope.Benchmark)
> public class ArrayListBulkOpsBench {
>     @Param({"0", "1", "5", "75"})
>     int size;
> 
>     @Param({"ArrayList", "LinkedList"})
>     String type;
> 
>     @Param({ "false", "true" })
>     private boolean poison;
> 
>     List<String> source;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         switch (type) {
>             case "ArrayList" -> source = new ArrayList<>(size);
>             case "LinkedList" -> source = new LinkedList<>();
>         }
>         for (int i = 0; i < size; i++) source.add("key" + i);
>         if (poison) poisonCallSites();
>     }
> 
>     @Benchmark
>     public ArrayList<String> addAll() {
>         ArrayList<String> result = new ArrayList<>(size);
>         result.addAll(source);
>         return result;
>     }
> 
>     static void poisonCallSites() {
>         HashMap<String, String> hashMapSource = new HashMap<>();
>         TreeSet<String> treeSetSource = new TreeSet<>();
>         WeakHashMap<String, String> weakHashMapSource = new WeakHashMap<>();
>         for (int i = 0; i < 75; i++) {
>             hashMapSource.put("key" + i, "value" + i);
>             treeSetSource.add("key" + i);
>             weakHashMapSource.put("key" + i, "value" + i);
>         }
>         // Poison ArrayList.addAll() with different Collection types
>         for (int i = 0; i < 40_000; i++) {
>             ArrayList<Object> temp = new ArrayList<>();
>             temp.addAll(hashMapSource.entrySet());
>             temp.addAll(treeSetSource);
>             temp.addAll(weakHashMapSource.keySet());
>         }
>     }
> 
>     @State(Scope.Benchmark)
>     public static class SingletonSet {
>         Set<String> singletonSetSource = Collections.singleton("key");
> 
>         @Param({ "false", "true" })
>         private boolean poison;
> 
>         @Setup(Level.Trial)
>         public void setup() {
>             if (poison) poisonCallSites();
>         }
> 
>         @Benchmark
>         public ArrayList<String> addAllSingletonSet() {
>             ArrayList<String> result = new ArrayList<>(1);
>             result.addAll(singletonSetSource);
>             return result;
>         }
>     }
> }
> 
> 
> addAll will be run against all permutations of size/type/poison. addAllSingletonSet will just be run against false/...

I find it much neater, thank you - adopted in the latest revision.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491658900

From duke at openjdk.org  Tue Nov  4 18:41:37 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 18:41:37 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <7GRIxy6QBXeEPIzDVffgqgXTJlxaBW1jMin177vKkAQ=.e73c6b2a-5446-4778-886a-115fc5d23212@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <7GRIxy6QBXeEPIzDVffgqgXTJlxaBW1jMin177vKkAQ=.e73c6b2a-5446-4778-886a-115fc5d23212@github.com>
Message-ID: <VWnOCrfM7LvO1y-ceDCNqoGRXwB_fKtZ8HVawYuBzHU=.f25fe944-d568-45d4-84ac-bfaca0b666b3@github.com>

On Mon, 3 Nov 2025 22:58:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> I actually wonder if the ArrayList.class path reuses `Object[] a = c.toArray();` and `int numNew = a.length;`, we are still going to see a similar improvement - I wonder if the bottleneck is the lack of polymorphic inlining alone, or if an array copy with a size trim would hamper C2 too.

One bottleneck being addressed is the intermediate array creation - gc profiling confirms that exists and is a significant impact.  I don't have data showing the presence or absence of other bottlenecks, although the performance of the de-duplicated code suggests that change introduced a side effect.  The memory savings were still present so I speculate the change introduced a new bottleneck.

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

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3487518767

From redestad at openjdk.org  Tue Nov  4 18:45:54 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 4 Nov 2025 18:45:54 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
 <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
Message-ID: <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>

On Tue, 4 Nov 2025 18:32:26 GMT, jengebr <duke at openjdk.org> wrote:

>> Ok, if the split helps the JIT peel and optimize better some amount of code duplication can be fine, but maybe then split out the two implementations to separate methods (to help inlining) and comment that the code duplication is intentional and should be handled with care.
>
> The comment is a good idea, but splitting out the duplication may make maintenance even worse by separating the duplicate sections.  What do you think?
> 
> Also, I'll benchmark with the split to get the impact data.  Not sure I can meaningfully validate an impact to inlining.

I think peeling off and outlining distinct paths in a larger method to separate, simpler methods usually reduces distracting noise and improves readability, but I guess that's subjective territory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491695436

From darcy at openjdk.org  Tue Nov  4 18:47:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Nov 2025 18:47:51 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <4YP2knvpGm61PssS9EtEX4W35vd90XLOjgkevNqaBF0=.e5a34d1c-4f3d-407e-b53d-789a97682a0d@github.com>

On Tue, 4 Nov 2025 11:45:04 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 27 underway.

Looks fine so far.

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

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3418178547

From duke at openjdk.org  Tue Nov  4 19:04:10 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 4 Nov 2025 19:04:10 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <i3yuFM1S9NX7EtvqND1EcLai3q0wiUowYargx4Esol0=.349f94e5-459a-41f9-b3aa-18ef72c6e59d@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <fZQkatd0ySToBaGRkbeRtRnZ-Pt-Ff0fp77Nn0zQ8wg=.2e4d4eb0-3d65-4f86-bf7f-85b909441043@github.com>
 <i3yuFM1S9NX7EtvqND1EcLai3q0wiUowYargx4Esol0=.349f94e5-459a-41f9-b3aa-18ef72c6e59d@github.com>
Message-ID: <Kbm6fWlKqrZ1j8YfwP2Na5PBLKLUHven0nM25NJzmWM=.3b43713f-4670-4a7d-a6ca-f10bb713cbb2@github.com>

On Tue, 4 Nov 2025 14:56:08 GMT, jengebr <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ArrayList.java line 758:
>> 
>>> 756:             int numNew = src.size;
>>> 757:             if (numNew == 0)
>>> 758:                 return false;
>> 
>> Previously `addAll()` with an empty list would increment `modCount`, whereas now it won't. Might want to move this test down after `modCount++` to avoid the unnecessary behavioral change.
>
> Will definitely fix, thank you for the catch!

> Previously addAll() with an empty list would increment modCount, 

which is unfortunate, since the list wasn't modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491735796

From jlu at openjdk.org  Tue Nov  4 19:06:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Nov 2025 19:06:31 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly [v2]
In-Reply-To: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
Message-ID: <xAWa8o65tL6Syy71GCH_3gvOoeWsF3ah0OVY2snF9n4=.bb997a2c-7595-4580-abc4-43ef1c25150a@github.com>

> This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.
> 
> Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.
> 
>> Minimum supported client: 	Windows Vista
>> Minimum supported server: 	Windows Server 2008

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove dynamic loading and call directly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28119/files
  - new: https://git.openjdk.org/jdk/pull/28119/files/0ccf212a..e18a5744

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

  Stats: 62 lines in 2 files changed: 5 ins; 44 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28119/head:pull/28119

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

From naoto at openjdk.org  Tue Nov  4 19:43:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Nov 2025 19:43:54 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly [v2]
In-Reply-To: <xAWa8o65tL6Syy71GCH_3gvOoeWsF3ah0OVY2snF9n4=.bb997a2c-7595-4580-abc4-43ef1c25150a@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
 <xAWa8o65tL6Syy71GCH_3gvOoeWsF3ah0OVY2snF9n4=.bb997a2c-7595-4580-abc4-43ef1c25150a@github.com>
Message-ID: <sJv59TfcEMySyav9bXBkVLLeNlzG3K02a2znYXC2tB4=.d4156f19-3f06-4eb4-be55-072d50b153b7@github.com>

On Tue, 4 Nov 2025 19:06:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.
>> 
>> Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.
>> 
>>> Minimum supported client: 	Windows Vista
>>> Minimum supported server: 	Windows Server 2008
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove dynamic loading and call directly

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28119#pullrequestreview-3418379991

From duke at openjdk.org  Tue Nov  4 19:46:43 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 4 Nov 2025 19:46:43 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
 <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
 <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>
Message-ID: <vYoyMY4WZV3N3DMkeve_kwSaYO20yigtkg7-k5NSFOg=.6828c6ab-7203-4dca-8f41-105fcd505467@github.com>

On Tue, 4 Nov 2025 18:43:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The comment is a good idea, but splitting out the duplication may make maintenance even worse by separating the duplicate sections.  What do you think?
>> 
>> Also, I'll benchmark with the split to get the impact data.  Not sure I can meaningfully validate an impact to inlining.
>
> I think peeling off and outlining distinct paths in a larger method to separate, simpler methods usually reduces distracting noise and improves readability, but I guess that's subjective territory.

> cl4es: Consider simplifying this to reduce code duplication:

or even simpler?


Object[] a = c.getClass() == ArrayList.class ? ((ArrayList<?>)c).elementData : a.toArray();
int newNum = a.length;
...



> jengebr: Interestingly, this hurt the fast-path about 5%, but the control case about 35%.

what is the control case, LinkedList.addAll() ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491853221

From asemenyuk at openjdk.org  Tue Nov  4 19:46:51 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 19:46:51 GMT
Subject: Integrated: 8371094: --mac-signing-key-user-name no longer works
In-Reply-To: <NaweUQzVw5VguKqSkneOAUnPO8FeDWKaJrXtGrp8dGo=.b1528569-6ed7-4a82-8a45-975e524ba476@github.com>
References: <NaweUQzVw5VguKqSkneOAUnPO8FeDWKaJrXtGrp8dGo=.b1528569-6ed7-4a82-8a45-975e524ba476@github.com>
Message-ID: <RlCE_dN1LoJ6FMhMX6Sor4JqnYP1FPRkMQYekuxLOD4=.9b6e820f-a448-403b-8394-b13736629012@github.com>

On Tue, 4 Nov 2025 00:14:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix the typo where the argument for the `String.startsWith()` function is swapped with the target string.
> - Add a test.

This pull request has now been integrated.

Changeset: 0555f622
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0555f6228c59c6739b8b824d64eb6c1545a5520a
Stats:     13 lines in 3 files changed: 11 ins; 0 del; 2 mod

8371094: --mac-signing-key-user-name no longer works

Reviewed-by: almatvee

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

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

From rriggs at openjdk.org  Tue Nov  4 19:51:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Nov 2025 19:51:35 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v28]
In-Reply-To: <0VnIUJxc2XBSfFAQI67Woy9HV2fcmFB4s8Q1ez1-zPk=.3469c884-339e-408c-bcbe-efa3d8c65705@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <0VnIUJxc2XBSfFAQI67Woy9HV2fcmFB4s8Q1ez1-zPk=.3469c884-339e-408c-bcbe-efa3d8c65705@github.com>
Message-ID: <DF8NOhMrnznuJN84X1C1Kohh4kzqRor_z3h5RT8ko9Q=.824acaa5-fef3-415d-8b66-1079c9978b95@github.com>

On Mon, 3 Nov 2025 22:56:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve example overridding close with try/catch/finally.

The CSR is approved; thanks to all the reviewers for improvements. 
A couple of approvals are needed to be able to integrate.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26649#issuecomment-3487769069

From darcy at openjdk.org  Tue Nov  4 19:58:20 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Nov 2025 19:58:20 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v28]
In-Reply-To: <0VnIUJxc2XBSfFAQI67Woy9HV2fcmFB4s8Q1ez1-zPk=.3469c884-339e-408c-bcbe-efa3d8c65705@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <0VnIUJxc2XBSfFAQI67Woy9HV2fcmFB4s8Q1ez1-zPk=.3469c884-339e-408c-bcbe-efa3d8c65705@github.com>
Message-ID: <vJ0MtTQ_HTHDDgTD2xQNeFpURFPrnTkJXRPgjl9RV1M=.b1a3e2ec-8921-425e-8df4-28de78593932@github.com>

On Mon, 3 Nov 2025 22:56:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve example overridding close with try/catch/finally.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3418420457

From lancea at openjdk.org  Tue Nov  4 19:58:21 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Nov 2025 19:58:21 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v28]
In-Reply-To: <0VnIUJxc2XBSfFAQI67Woy9HV2fcmFB4s8Q1ez1-zPk=.3469c884-339e-408c-bcbe-efa3d8c65705@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <0VnIUJxc2XBSfFAQI67Woy9HV2fcmFB4s8Q1ez1-zPk=.3469c884-339e-408c-bcbe-efa3d8c65705@github.com>
Message-ID: <B7It-JVgC1mT8nOEBEtJo7hAQludhBh7JiDzzDvCz-M=.f4752644-9ad2-406c-a07c-670b2b8a7274@github.com>

On Mon, 3 Nov 2025 22:56:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve example overridding close with try/catch/finally.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3418427570

From mdoerr at openjdk.org  Tue Nov  4 19:59:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 4 Nov 2025 19:59:30 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
 <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
Message-ID: <OgWp3USgtgltJFR7hidR1GZoyO1CtOKrn1BiE4nedAw=.d96d0251-e67a-4320-ac58-c9022b950120@github.com>

On Tue, 4 Nov 2025 15:39:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments Patricio
>
> Thanks for the reviews!

@JornVernee: The new test has failed on AIX:

[fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
[fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
[fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
[fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
[fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
[fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
[fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
[fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
[fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)

Should I file a new issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3487797511

From duke at openjdk.org  Tue Nov  4 20:06:12 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 20:06:12 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <vYoyMY4WZV3N3DMkeve_kwSaYO20yigtkg7-k5NSFOg=.6828c6ab-7203-4dca-8f41-105fcd505467@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
 <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
 <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>
 <vYoyMY4WZV3N3DMkeve_kwSaYO20yigtkg7-k5NSFOg=.6828c6ab-7203-4dca-8f41-105fcd505467@github.com>
Message-ID: <9hnYaiLpY43dWCDAiG8W_tDI2cg2teqSGzECu3ocLps=.43395add-6304-4f9f-9667-669c082082e4@github.com>

On Tue, 4 Nov 2025 19:44:01 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> I think peeling off and outlining distinct paths in a larger method to separate, simpler methods usually reduces distracting noise and improves readability, but I guess that's subjective territory.
>
>> cl4es: Consider simplifying this to reduce code duplication:
> 
> or even simpler?
> 
> 
> Object[] a = c.getClass() == ArrayList.class ? ((ArrayList<?>)c).elementData : a.toArray();
> int newNum = a.length;
> ...
> 
> 
> 
>> jengebr: Interestingly, this hurt the fast-path about 5%, but the control case about 35%.
> 
> what is the control case, LinkedList.addAll() ?

No, ArrayList.addAll(LinkedList).  This is the slow path that ideally will perform the same as before this change - and the initial change achieves that.  Rewriting to reduce duplication increased runtime of both the optimized and control.

I'll benchmark your suggestion as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491902162

From jlu at openjdk.org  Tue Nov  4 20:07:18 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Nov 2025 20:07:18 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v5]
In-Reply-To: <uQzj0iMIvdDIFMxz6ZpI8x_pFbMh2sh5okn-uBp0Qoc=.97175766-315c-414f-a129-e2e15c5fac0e@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
 <uQzj0iMIvdDIFMxz6ZpI8x_pFbMh2sh5okn-uBp0Qoc=.97175766-315c-414f-a129-e2e15c5fac0e@github.com>
Message-ID: <Xqr1K8y32oOFAvtBNvzJHig31D6LpR7qmTQ1F4L1-4U=.e0b8c48c-bf9e-42dc-bc3c-fea415850f08@github.com>

On Tue, 4 Nov 2025 17:53:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor header fix

Took a look at all the changes besides the XML data itself. LGTM.

make/data/cldr/LICENSE line 1:

> 1: ?UNICODE LICENSE V3

I guess a line ending change on their end?

make/jdk/src/classes/build/tools/cldrconverter/Bundle.java line 852:

> 850: 
> 851:     /**
> 852:      * Escape reserved pattern characters, '#', '{', and '}' in the pattern

Even though they may not be offending now, should  '[' and ']' be included since they are also non CLDR date time patterns (not A-Z), but are recognized in DateTimeFormatter patterns?

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28076#pullrequestreview-3412376711
PR Review Comment: https://git.openjdk.org/jdk/pull/28076#discussion_r2491900624
PR Review Comment: https://git.openjdk.org/jdk/pull/28076#discussion_r2491874764

From jlu at openjdk.org  Tue Nov  4 20:07:21 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Nov 2025 20:07:21 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v2]
In-Reply-To: <9VpoTyAJ3oQwtSpHO6sCVwaWA_Jx3B91DS2oxOTTTcI=.afc95ec9-c937-44e8-9a0c-9b087dd3c4ff@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
 <9VpoTyAJ3oQwtSpHO6sCVwaWA_Jx3B91DS2oxOTTTcI=.afc95ec9-c937-44e8-9a0c-9b087dd3c4ff@github.com>
Message-ID: <_OeoX0nyVU3EogxGV3pXv1knDQQmDs7axRKf2QOM4wg=.b500b7df-f03b-4605-af83-8b5394a81fe6@github.com>

On Thu, 30 Oct 2025 23:13:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   .md files

test/jdk/java/text/Format/CompactNumberFormat/TestCompactNumber.java line 1:

> 1: /*

Bug id update needed?

test/jdk/sun/util/resources/cldr/TimeZoneNamesTest.java line 1:

> 1: /*

Bug id update needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28076#discussion_r2487475839
PR Review Comment: https://git.openjdk.org/jdk/pull/28076#discussion_r2487488844

From nbenalla at openjdk.org  Tue Nov  4 20:11:23 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Nov 2025 20:11:23 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v2]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <3cZuldBvytdN_Hu0qlLhUkrCsH5EUlZJ5SEjnF8SLEU=.e76693bd-f6e1-4f8a-9dd5-699c9e4306bf@github.com>

> Get JDK 27 underway.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  add missing enum

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/cc1a968e..647904b3

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

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

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

From redestad at openjdk.org  Tue Nov  4 20:20:56 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 4 Nov 2025 20:20:56 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <9hnYaiLpY43dWCDAiG8W_tDI2cg2teqSGzECu3ocLps=.43395add-6304-4f9f-9667-669c082082e4@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
 <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
 <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>
 <vYoyMY4WZV3N3DMkeve_kwSaYO20yigtkg7-k5NSFOg=.6828c6ab-7203-4dca-8f41-105fcd505467@github.com>
 <9hnYaiLpY43dWCDAiG8W_tDI2cg2teqSGzECu3ocLps=.43395add-6304-4f9f-9667-669c082082e4@github.com>
Message-ID: <7mnVHxWSm3mKAzHUNsWDoM4odcweENeQ6afzRRf26fM=.f65241e5-0df5-498a-a470-6b9d80dcfe52@github.com>

On Tue, 4 Nov 2025 20:03:28 GMT, jengebr <duke at openjdk.org> wrote:

>>> cl4es: Consider simplifying this to reduce code duplication:
>> 
>> or even simpler?
>> 
>> 
>> Object[] a = c.getClass() == ArrayList.class ? ((ArrayList<?>)c).elementData : a.toArray();
>> int newNum = a.length;
>> ...
>> 
>> 
>> 
>>> jengebr: Interestingly, this hurt the fast-path about 5%, but the control case about 35%.
>> 
>> what is the control case, LinkedList.addAll() ?
>
> No, ArrayList.addAll(LinkedList).  This is the slow path that ideally will perform the same as before this change - and the initial change achieves that.  Rewriting to reduce duplication increased runtime of both the optimized and control.
> 
> I'll benchmark your suggestion as well.

That variant is incorrect since `size <= a.length`, potentially adding a surprising tail of `null` elements to the list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491936650

From nbenalla at openjdk.org  Tue Nov  4 20:24:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Nov 2025 20:24:52 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v3]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <Tk-NvGBIdEw-6vRKcbJD0hfB-q3Zzu8hTsrk9w_yQbQ=.553395d1-799c-4390-93f1-d5f9bb058f05@github.com>

> Get JDK 27 underway.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  update links to JVMS 26 and 27

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/647904b3..b51f2324

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

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

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

From duke at openjdk.org  Tue Nov  4 20:26:25 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 4 Nov 2025 20:26:25 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <7mnVHxWSm3mKAzHUNsWDoM4odcweENeQ6afzRRf26fM=.f65241e5-0df5-498a-a470-6b9d80dcfe52@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
 <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
 <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>
 <vYoyMY4WZV3N3DMkeve_kwSaYO20yigtkg7-k5NSFOg=.6828c6ab-7203-4dca-8f41-105fcd505467@github.com>
 <9hnYaiLpY43dWCDAiG8W_tDI2cg2teqSGzECu3ocLps=.43395add-6304-4f9f-9667-669c082082e4@github.com>
 <7mnVHxWSm3mKAzHUNsWDoM4odcweENeQ6afzRRf26fM=.f65241e5-0df5-498a-a470-6b9d80dcfe52@github.com>
Message-ID: <snbrFNFeuDl4vazzOdXpVyQ6mW44g9cw3t7QHpbZtlk=.3aee28c4-adeb-435c-885b-aad86be61eb0@github.com>

On Tue, 4 Nov 2025 20:18:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> That variant is incorrect since `size <= a.length`, potentially adding a surprising tail of `null` elements to the list.

@cl4es right, my suggestion was incorrect, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491949708

From duke at openjdk.org  Tue Nov  4 20:40:48 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 20:40:48 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <7mnVHxWSm3mKAzHUNsWDoM4odcweENeQ6afzRRf26fM=.f65241e5-0df5-498a-a470-6b9d80dcfe52@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
 <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
 <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>
 <vYoyMY4WZV3N3DMkeve_kwSaYO20yigtkg7-k5NSFOg=.6828c6ab-7203-4dca-8f41-105fcd505467@github.com>
 <9hnYaiLpY43dWCDAiG8W_tDI2cg2teqSGzECu3ocLps=.43395add-6304-4f9f-9667-669c082082e4@github.com>
 <7mnVHxWSm3mKAzHUNsWDoM4odcweENeQ6afzRRf26fM=.f65241e5-0df5-498a-a470-6b9d80dcfe52@github.com>
Message-ID: <YXIFhZcksi8nzSWkSgHc8i8WvHOiJ0P69nAZaoywo5M=.2505addc-029b-4e0f-a25e-897a50dbb5a2@github.com>

On Tue, 4 Nov 2025 20:18:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> No, ArrayList.addAll(LinkedList).  This is the slow path that ideally will perform the same as before this change - and the initial change achieves that.  Rewriting to reduce duplication increased runtime of both the optimized and control.
>> 
>> I'll benchmark your suggestion as well.
>
> That variant is incorrect since `size <= a.length`, potentially adding a surprising tail of `null` elements to the list.

Thank you both!  @cl4es splitting it out had zero performance impact (per the benchmark).  As you said, it's a bit subjective... how strongly do you feel?  Other opinions are welcome too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491983023

From rriggs at openjdk.org  Tue Nov  4 20:43:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Nov 2025 20:43:55 GMT
Subject: Integrated: 8364361: [process] java.lang.Process should implement
 Closeable
In-Reply-To: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
Message-ID: <a_nLV8R5y9q-JItJMgP_O1dt_-iUOpOxdVQN2OhSIS4=.bc3596ef-9a90-4875-a1f3-385d6fd6e967@github.com>

On Tue, 5 Aug 2025 18:21:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
> 
> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
> 
> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.

This pull request has now been integrated.

Changeset: 32508230
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/325082302266f25d4fac33d0d4a9492c72de3ffc
Stats:     945 lines in 3 files changed: 939 ins; 0 del; 6 mod

8364361: [process] java.lang.Process should implement Closeable

Reviewed-by: lancea, darcy, naoto, jpai, alanb, prappo

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

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

From sspitsyn at openjdk.org  Tue Nov  4 20:49:19 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 20:49:19 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
Message-ID: <wPQlWFIZCeBMq589X81beQ-LNEwEBI0UHFATEarQXFI=.4bcd8d39-252c-4222-836e-5f7ec7d07fd3@github.com>

On Tue, 4 Nov 2025 15:47:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix to JvmtiHideSingleStepping

test/hotspot/jtreg/serviceability/jvmti/vthread/SingleStepKlassInit/libSingleStepKlassInit.cpp line 38:

> 36: SingleStep(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread,
> 37:            jmethodID method, jlocation location) {
> 38: }

Q: Would it make sense to verify that `SingleStep` events are posted or not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2491981248

From duke at openjdk.org  Tue Nov  4 20:54:32 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 4 Nov 2025 20:54:32 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <RsQ5PECszF1LnGTUHUnli8g0GWjU492cbsSThnkzBJ8=.46b8d5f1-4964-4824-b926-abd17f9deee3@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <RsQ5PECszF1LnGTUHUnli8g0GWjU492cbsSThnkzBJ8=.46b8d5f1-4964-4824-b926-abd17f9deee3@github.com>
Message-ID: <0K58pfvu0CqcWrQGk5siqGbQMLWttri3eKZQF-e22vE=.61cb7fbd-53ec-49d3-bc40-1ccade1449ae@github.com>

On Tue, 4 Nov 2025 18:35:23 GMT, jengebr <duke at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding direct unit tests, minor revisions to optimizations

test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 63:

> 61: public class ArrayListBulkOpsBenchmark {
> 62:     @Param({"0", "1", "5", "75"})
> 63:     int size;

The size parameter is used twice:
- to construct a collection of varying sizes which is to be added
- as initialCapacity of the receiving ArrayList
Can this impact the benchmark results? Maybe introduce two independent params.

test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 68:

> 66:     String type;
> 67: 
> 68:     List<String> source;

Suggestion: rename, e.g. `toBeAdded`

test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 110:

> 108:     @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> 109:     @Fork(value = 1, jvmArgs = { "-XX:+UseParallelGC", "-Xmx3g" })
> 110:     public static class SingletonSet {

Your PR targets bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() and introduces two independent optimizations. Having a inner class which benchmarks Collections.SingletonSet.toArray() performance by calling ArrayList.addAll() is a bit confusing. Maybe split into two independent benchmarks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2492014189
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491983107
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2491980487

From naoto at openjdk.org  Tue Nov  4 21:03:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Nov 2025 21:03:25 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v6]
In-Reply-To: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
Message-ID: <lk88O_Hl0JhBkVIT3Bo4Q2pT_nYg46lKDRR9bg3oBk8=.45d85019-7252-4ba6-b4dd-78eccb3317fa@github.com>

> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits:

 - Addressing review comments
 - Merge branch 'master' into JDK-8354548-CLDR-48
 - Minor header fix
 - Unicode copyright update for the generated sources
 - `#` fix for "tok" locale
 - .md files
 - v48 final
 - Merge branch 'master' into JDK-8354548-CLDR-48
 - Merge branch 'master' into JDK-8354548-CLDR-48
 - Merge branch 'master' into JDK-8354548-CLDR-48
 - ... and 48 more: https://git.openjdk.org/jdk/compare/9f972008...b5c74834

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

Changes: https://git.openjdk.org/jdk/pull/28076/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28076&range=05
  Stats: 135921 lines in 390 files changed: 94379 ins; 15578 del; 25964 mod
  Patch: https://git.openjdk.org/jdk/pull/28076.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28076/head:pull/28076

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

From naoto at openjdk.org  Tue Nov  4 21:05:06 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Nov 2025 21:05:06 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v5]
In-Reply-To: <Xqr1K8y32oOFAvtBNvzJHig31D6LpR7qmTQ1F4L1-4U=.e0b8c48c-bf9e-42dc-bc3c-fea415850f08@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
 <uQzj0iMIvdDIFMxz6ZpI8x_pFbMh2sh5okn-uBp0Qoc=.97175766-315c-414f-a129-e2e15c5fac0e@github.com>
 <Xqr1K8y32oOFAvtBNvzJHig31D6LpR7qmTQ1F4L1-4U=.e0b8c48c-bf9e-42dc-bc3c-fea415850f08@github.com>
Message-ID: <WD2InaqAFg1m5xVBGUPjUC9AIgSizS0n-zxwuZhFNhA=.220bbe8d-8b6f-4a4c-820e-2ac694b47b06@github.com>

On Tue, 4 Nov 2025 20:02:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor header fix
>
> make/data/cldr/LICENSE line 1:
> 
>> 1: ?UNICODE LICENSE V3
> 
> I guess a line ending change on their end?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28076#discussion_r2492033121

From duke at openjdk.org  Tue Nov  4 21:09:09 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 21:09:09 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <0K58pfvu0CqcWrQGk5siqGbQMLWttri3eKZQF-e22vE=.61cb7fbd-53ec-49d3-bc40-1ccade1449ae@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <RsQ5PECszF1LnGTUHUnli8g0GWjU492cbsSThnkzBJ8=.46b8d5f1-4964-4824-b926-abd17f9deee3@github.com>
 <0K58pfvu0CqcWrQGk5siqGbQMLWttri3eKZQF-e22vE=.61cb7fbd-53ec-49d3-bc40-1ccade1449ae@github.com>
Message-ID: <mAHm1lxWBlXx_yXG4Xzezzxkr8LmlEmwR3zcooiUYf4=.78041fa5-f88d-4761-911d-c171d02f0315@github.com>

On Tue, 4 Nov 2025 20:37:26 GMT, Johannes D?bler <duke at openjdk.org> wrote:

> is a bit confusing

I definitely get your point on this.  :)  I went in circles setting up the PR for this same reason.  However, the benchmark(s) ultimately are testing ArrayList.addAll() in three different scenarios: ArrayList, SingletonSet, and LinkedList.  The inner class magic was suggested to simplify the benchmarking by allowing parameterized size on the ArrayList flavor, while truthfully reporting the fixed size of SingletonSet.

I'm not sure there's a great solution here, but splitting up benchmarks that all call ArrayList.addAll() isn't intuitive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2492047856

From sspitsyn at openjdk.org  Tue Nov  4 21:12:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 21:12:51 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
Message-ID: <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>

On Tue, 4 Nov 2025 15:47:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix to JvmtiHideSingleStepping

I've reviewed the latest incremental SVC related update. It is good and nice to have in general. Thank you for adding the test!

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3418644332

From duke at openjdk.org  Tue Nov  4 21:19:48 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Nov 2025 21:19:48 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <0K58pfvu0CqcWrQGk5siqGbQMLWttri3eKZQF-e22vE=.61cb7fbd-53ec-49d3-bc40-1ccade1449ae@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <RsQ5PECszF1LnGTUHUnli8g0GWjU492cbsSThnkzBJ8=.46b8d5f1-4964-4824-b926-abd17f9deee3@github.com>
 <0K58pfvu0CqcWrQGk5siqGbQMLWttri3eKZQF-e22vE=.61cb7fbd-53ec-49d3-bc40-1ccade1449ae@github.com>
Message-ID: <-9rKqS9XMZZhXpMuwmp2A4vHiDqenW7GOfpw2puzaQw=.7364a78f-a161-49f2-8d0e-e05e16fd9894@github.com>

On Tue, 4 Nov 2025 20:51:41 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> jengebr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding direct unit tests, minor revisions to optimizations
>
> test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 63:
> 
>> 61: public class ArrayListBulkOpsBenchmark {
>> 62:     @Param({"0", "1", "5", "75"})
>> 63:     int size;
> 
> The size parameter is used twice:
> - to construct a collection of varying sizes which is to be added
> - as initialCapacity of the receiving ArrayList
> Can this impact the benchmark results? Maybe introduce two independent params.

This is deliberate, ensuring that the add operation does not require growing the internal array.  Growth isn't affected by the change and eliminating it reduces a key variable from the measurements.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2492072181

From pchilanomate at openjdk.org  Tue Nov  4 21:28:15 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 21:28:15 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
 <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>
Message-ID: <VG_RAxmnHcPnUVQI7EBYMIHKnvtU8r1t8INuNjpfKKY=.917a3276-95c0-4982-ae7a-380963b9495c@github.com>

On Tue, 4 Nov 2025 21:10:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the latest incremental SVC related update. It is good and nice to have in general. Thank you for adding the test!
>
Great, thanks for the review Serguei!

> test/hotspot/jtreg/serviceability/jvmti/vthread/SingleStepKlassInit/libSingleStepKlassInit.cpp line 38:
> 
>> 36: SingleStep(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread,
>> 37:            jmethodID method, jlocation location) {
>> 38: }
> 
> Q: Would it make sense to verify that `SingleStep` events are posted or not?

Good idea, I added a check for it. Let me know if that works.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3488063416
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2492084640

From pchilanomate at openjdk.org  Tue Nov  4 21:28:14 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 21:28:14 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v15]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Add check for SingleStep events
 - Merge branch 'master' into JDK-8369238
 - fix to JvmtiHideSingleStepping
 - Suggested fix in macroAssembler_ppc.cpp
 - Improve comment and assert msg
 - More fixes from David's comments
 - Merge branch 'master' into JDK-8369238
 - add const to references
 - Improve comment in anchor_mark_set_pd
 - More comments from Coleen
 - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198

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

Changes: https://git.openjdk.org/jdk/pull/27802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=14
  Stats: 2373 lines in 102 files changed: 1928 ins; 125 del; 320 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

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

From asemenyuk at openjdk.org  Tue Nov  4 21:41:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 21:41:55 GMT
Subject: RFR: 8371184: Improve jpackage test coverage for "--app-image"
 option [v3]
In-Reply-To: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
References: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
Message-ID: <5ByrHTd6VMHvS52FFXOCO0n2O7KnWff_1KEpCrmjKVA=.a1aaf6b6-24b9-428b-bd7d-ac88024bb2cc@github.com>

> - Verify that when `--app-image` option is specified, files from the predefined app image are copied verbatim into the output app image (JPackageCommand: add `PREDEFINED_APP_IMAGE_COPY`).
> - Add `LauncherVerifier.launcherDescription()` and use it from LiunuxHelper; extend PropertyFinder class for `LauncherVerifier.launcherDescription()`.
>  - Automatically reapply verifications to launchers in the predefined app image to the command referencing the predefined app image through `--app-image` option. Other changes relate to this update.
> 
> Supplementary:
> - Clean up redundancies after [8351369: [macos] Use --install-dir option with DMG packaging](https://bugs.openjdk.org/browse/JDK-8351369) fix: remove `JPackageCommand.dmgInstallDir`, simplify InstallDirTest test.
>  - AppContentTest.java: fix to make test logs stable.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - JPackageCommand: verify contents of the predefined app image copied verbatim using more appropriate TKit.assertSameFileContent()
 - TKit: revert the change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28118/files
  - new: https://git.openjdk.org/jdk/pull/28118/files/c76e49f2..7bf2fa34

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

  Stats: 109 lines in 2 files changed: 18 ins; 60 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/28118.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28118/head:pull/28118

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

From asemenyuk at openjdk.org  Tue Nov  4 21:41:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 21:41:57 GMT
Subject: RFR: 8371184: Improve jpackage test coverage for "--app-image"
 option [v2]
In-Reply-To: <LMat5LM8fJrgs9FD0UVzWsMwHE1QbrKH2hcfQjYrlmQ=.f3052bac-28ce-47e0-9ae3-847371a66118@github.com>
References: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
 <LMat5LM8fJrgs9FD0UVzWsMwHE1QbrKH2hcfQjYrlmQ=.f3052bac-28ce-47e0-9ae3-847371a66118@github.com>
Message-ID: <1TqDaamAt2VHQlwCmS7V7krTrPsQxNPUHuFgI3nywss=.fedd8f02-a905-44bf-827e-dfffd0251e7c@github.com>

On Tue, 4 Nov 2025 02:19:41 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Verify that when `--app-image` option is specified, files from the predefined app image are copied verbatim into the output app image (JPackageCommand: add `PREDEFINED_APP_IMAGE_COPY`).
>> - Add `LauncherVerifier.launcherDescription()` and use it from LiunuxHelper; extend PropertyFinder class for `LauncherVerifier.launcherDescription()`.
>>  - Automatically reapply verifications to launchers in the predefined app image to the command referencing the predefined app image through `--app-image` option. Other changes relate to this update.
>> 
>> Supplementary:
>> - Clean up redundancies after [8351369: [macos] Use --install-dir option with DMG packaging](https://bugs.openjdk.org/browse/JDK-8351369) fix: remove `JPackageCommand.dmgInstallDir`, simplify InstallDirTest test.
>>  - AppContentTest.java: fix to make test logs stable.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AppContentTest: keep test log stable

Rolled back changes to TKit and reworked the code that verifies copying of the contents of the predefined app image using more appropriate `TKit.assertSameFileContent()`

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

PR Comment: https://git.openjdk.org/jdk/pull/28118#issuecomment-3488103427

From asemenyuk at openjdk.org  Tue Nov  4 21:46:49 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 21:46:49 GMT
Subject: RFR: 8371184: Improve jpackage test coverage for "--app-image"
 option [v4]
In-Reply-To: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
References: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
Message-ID: <ARICUpfRtzoRiiwhPwvMz6UFeYV18Sz-SMeGC3hZ5Gw=.2360a583-7eff-41ff-90b8-9e3925eb6aff@github.com>

> - Verify that when `--app-image` option is specified, files from the predefined app image are copied verbatim into the output app image (JPackageCommand: add `PREDEFINED_APP_IMAGE_COPY`).
> - Add `LauncherVerifier.launcherDescription()` and use it from LiunuxHelper; extend PropertyFinder class for `LauncherVerifier.launcherDescription()`.
>  - Automatically reapply verifications to launchers in the predefined app image to the command referencing the predefined app image through `--app-image` option. Other changes relate to this update.
> 
> Supplementary:
> - Clean up redundancies after [8351369: [macos] Use --install-dir option with DMG packaging](https://bugs.openjdk.org/browse/JDK-8351369) fix: remove `JPackageCommand.dmgInstallDir`, simplify InstallDirTest test.
>  - AppContentTest.java: fix to make test logs stable.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - run ./bin/blessed-modifier-order.sh
 - Fix a typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28118/files
  - new: https://git.openjdk.org/jdk/pull/28118/files/7bf2fa34..1f29dcf5

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

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

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

From naoto at openjdk.org  Tue Nov  4 21:47:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Nov 2025 21:47:01 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v7]
In-Reply-To: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
Message-ID: <c_vyr86pndvzrVNkMJiM1Y9P-IfpKFuawONeB-clCAI=.76032eb3-b8b4-4928-af98-4efce34481dc@github.com>

> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Test data fix for zh_HK which uses '[' and ']' literals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28076/files
  - new: https://git.openjdk.org/jdk/pull/28076/files/b5c74834..5de0854a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28076&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28076&range=05-06

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

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

From almatvee at openjdk.org  Tue Nov  4 22:03:48 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 4 Nov 2025 22:03:48 GMT
Subject: RFR: 8371184: Improve jpackage test coverage for "--app-image"
 option [v4]
In-Reply-To: <ARICUpfRtzoRiiwhPwvMz6UFeYV18Sz-SMeGC3hZ5Gw=.2360a583-7eff-41ff-90b8-9e3925eb6aff@github.com>
References: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
 <ARICUpfRtzoRiiwhPwvMz6UFeYV18Sz-SMeGC3hZ5Gw=.2360a583-7eff-41ff-90b8-9e3925eb6aff@github.com>
Message-ID: <7NVLx1aVpJeF-9OyAbHKSmhRKvcKcDYAjgOWgfjFKmk=.99c32254-e84c-40b0-b582-928b78475736@github.com>

On Tue, 4 Nov 2025 21:46:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Verify that when `--app-image` option is specified, files from the predefined app image are copied verbatim into the output app image (JPackageCommand: add `PREDEFINED_APP_IMAGE_COPY`).
>> - Add `LauncherVerifier.launcherDescription()` and use it from LiunuxHelper; extend PropertyFinder class for `LauncherVerifier.launcherDescription()`.
>>  - Automatically reapply verifications to launchers in the predefined app image to the command referencing the predefined app image through `--app-image` option. Other changes relate to this update.
>> 
>> Supplementary:
>> - Clean up redundancies after [8351369: [macos] Use --install-dir option with DMG packaging](https://bugs.openjdk.org/browse/JDK-8351369) fix: remove `JPackageCommand.dmgInstallDir`, simplify InstallDirTest test.
>>  - AppContentTest.java: fix to make test logs stable.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - run ./bin/blessed-modifier-order.sh
>  - Fix a typo

Latest changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28118#pullrequestreview-3418772974

From duke at openjdk.org  Tue Nov  4 22:09:20 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Tue, 4 Nov 2025 22:09:20 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments
In-Reply-To: <IRN2eQoZzT1hVSvzh5JeDAO80x2f4ckPz8UW4dJLwZQ=.5098ac80-d667-4bc3-b43d-a1425882ce33@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <IRN2eQoZzT1hVSvzh5JeDAO80x2f4ckPz8UW4dJLwZQ=.5098ac80-d667-4bc3-b43d-a1425882ce33@github.com>
Message-ID: <ajXncFMu1cVeNLveAlDsjNtksrBsPx40OAK72JjH_KA=.e7bc30df-0f88-419d-88cd-16a64ad68471@github.com>

On Tue, 4 Nov 2025 09:35:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> length being zero -- because that's a valid value for asSlice (but not for access).

does it mean `checkBounds(...)` version in `master` works incorrectly for access now? Since length == 0 is not treated as an error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2492172778

From sspitsyn at openjdk.org  Tue Nov  4 22:41:18 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:41:18 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v15]
In-Reply-To: <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
Message-ID: <vR7s_qA4KIDxPjqxYFoDKmIAqenU_LILmD4Tr2pgwU8=.5716e1a8-1900-42d2-907c-d7f57e0708e2@github.com>

On Tue, 4 Nov 2025 21:28:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Add check for SingleStep events
>  - Merge branch 'master' into JDK-8369238
>  - fix to JvmtiHideSingleStepping
>  - Suggested fix in macroAssembler_ppc.cpp
>  - Improve comment and assert msg
>  - More fixes from David's comments
>  - Merge branch 'master' into JDK-8369238
>  - add const to references
>  - Improve comment in anchor_mark_set_pd
>  - More comments from Coleen
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3418852425

From sspitsyn at openjdk.org  Tue Nov  4 22:41:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:41:20 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <VG_RAxmnHcPnUVQI7EBYMIHKnvtU8r1t8INuNjpfKKY=.917a3276-95c0-4982-ae7a-380963b9495c@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
 <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>
 <VG_RAxmnHcPnUVQI7EBYMIHKnvtU8r1t8INuNjpfKKY=.917a3276-95c0-4982-ae7a-380963b9495c@github.com>
Message-ID: <CyU-vZ-DK4lL1hzptQL8ISdjoNLqPGAozPFVgFNTRv4=.a6296035-c3b4-403c-a488-db6a63dca16a@github.com>

On Tue, 4 Nov 2025 21:23:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/SingleStepKlassInit/libSingleStepKlassInit.cpp line 38:
>> 
>>> 36: SingleStep(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread,
>>> 37:            jmethodID method, jlocation location) {
>>> 38: }
>> 
>> Q: Would it make sense to verify that `SingleStep` events are posted or not?
>
> Good idea, I added a check for it. Let me know if that works.

Thanks! It is good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2492228658

From asemenyuk at openjdk.org  Tue Nov  4 22:44:05 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Nov 2025 22:44:05 GMT
Subject: Integrated: 8371184: Improve jpackage test coverage for "--app-image"
 option
In-Reply-To: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
References: <kCkCxduvevcVLoyVflGhEHTIsZYshjQPs5UwbnPQBOY=.5a25428c-d29e-4902-b5ae-50cdf3f4422c@github.com>
Message-ID: <TTYUA5vhjUUkHTzs85KDFfg859Ia0q2Xbbk3dJKw6cg=.98041e45-5e31-4ff7-8ccf-fb9d5b06ffa0@github.com>

On Mon, 3 Nov 2025 21:45:35 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Verify that when `--app-image` option is specified, files from the predefined app image are copied verbatim into the output app image (JPackageCommand: add `PREDEFINED_APP_IMAGE_COPY`).
> - Add `LauncherVerifier.launcherDescription()` and use it from LiunuxHelper; extend PropertyFinder class for `LauncherVerifier.launcherDescription()`.
>  - Automatically reapply verifications to launchers in the predefined app image to the command referencing the predefined app image through `--app-image` option. Other changes relate to this update.
> 
> Supplementary:
> - Clean up redundancies after [8351369: [macos] Use --install-dir option with DMG packaging](https://bugs.openjdk.org/browse/JDK-8351369) fix: remove `JPackageCommand.dmgInstallDir`, simplify InstallDirTest test.
>  - AppContentTest.java: fix to make test logs stable.

This pull request has now been integrated.

Changeset: c8f5fd6f
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8f5fd6ff3808804eda03c9754698a00dd06449c
Stats:     411 lines in 20 files changed: 230 ins; 80 del; 101 mod

8371184: Improve jpackage test coverage for "--app-image" option

Reviewed-by: almatvee

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

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

From pchilanomate at openjdk.org  Tue Nov  4 23:35:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 23:35:55 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v15]
In-Reply-To: <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
Message-ID: <lfcJgXrHP0jBeObaX7-9Aex071uKMQ6IIibSiBtcndg=.ba41e77c-9443-4baf-913f-ff9dbd6d28d0@github.com>

On Tue, 4 Nov 2025 21:28:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Add check for SingleStep events
>  - Merge branch 'master' into JDK-8369238
>  - fix to JvmtiHideSingleStepping
>  - Suggested fix in macroAssembler_ppc.cpp
>  - Improve comment and assert msg
>  - More fixes from David's comments
>  - Merge branch 'master' into JDK-8369238
>  - add const to references
>  - Improve comment in anchor_mark_set_pd
>  - More comments from Coleen
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198

Thanks everyone for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3488372018

From pchilanomate at openjdk.org  Tue Nov  4 23:35:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 23:35:58 GMT
Subject: Integrated: 8369238: Allow virtual thread preemption on some common
 class initialization paths
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <uBoqZEVMoW7Qe0xjtksGNookxMDWSiNTxf0iIYJ7Ygo=.bc63a4b1-97df-4386-8610-617103f46ed2@github.com>

On Tue, 14 Oct 2025 13:42:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

This pull request has now been integrated.

Changeset: c6a88155
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6a88155b519a5d0b22f6009e75a0e6388601756
Stats:     2373 lines in 102 files changed: 1928 ins; 125 del; 320 mod

8369238: Allow virtual thread preemption on some common class initialization paths

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Fei Yang <fyang at openjdk.org>
Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Reviewed-by: sspitsyn, dholmes, coleenp, fbredberg

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

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

From duke at openjdk.org  Wed Nov  5 03:00:01 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Wed, 5 Nov 2025 03:00:01 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <YXIFhZcksi8nzSWkSgHc8i8WvHOiJ0P69nAZaoywo5M=.2505addc-029b-4e0f-a25e-897a50dbb5a2@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
 <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
 <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>
 <vYoyMY4WZV3N3DMkeve_kwSaYO20yigtkg7-k5NSFOg=.6828c6ab-7203-4dca-8f41-105fcd505467@github.com>
 <9hnYaiLpY43dWCDAiG8W_tDI2cg2teqSGzECu3ocLps=.43395add-6304-4f9f-9667-669c082082e4@github.com>
 <7mnVHxWSm3mKAzHUNsWDoM4odcweENeQ6afzRRf26fM=.f65241e5-0df5-498a-a470-6b9d80dcfe52@github.com>
 <YXIFhZcksi8nzSWkSgHc8i8WvHOiJ0P69nAZaoywo5M=.2505addc-029b-4e0f-a25e-897a50dbb5a2@github.com>
Message-ID: <KGySTjtiQfD6KOtWqazclaw0-tNw6JGCffNfk0T6z2w=.d15cd61b-f516-4b99-af4d-4d99b07d4e33@github.com>

On Tue, 4 Nov 2025 20:38:35 GMT, jengebr <duke at openjdk.org> wrote:

>> That variant is incorrect since `size <= a.length`, potentially adding a surprising tail of `null` elements to the list.
>
> Thank you both!  @cl4es splitting it out had zero performance impact (per the benchmark).  As you said, it's a bit subjective... how strongly do you feel?  Other opinions are welcome too.

I would think that you need to check `src.modCount` has same value at start and end of the method.


final int expectedSrcModCount = src.modCount;
//access src internals....
checkForComodification(expectedSrcModCount)


Looks like ArrayList::toArray is not doing this check either.  So perhaps it is not needed.  I would have thought mod check would have been needed in toArray to mimic iterator behavior.  Therefore needed in addAll.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2492622937

From smarks at openjdk.org  Wed Nov  5 05:26:01 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 5 Nov 2025 05:26:01 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <KGySTjtiQfD6KOtWqazclaw0-tNw6JGCffNfk0T6z2w=.d15cd61b-f516-4b99-af4d-4d99b07d4e33@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
 <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
 <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>
 <vYoyMY4WZV3N3DMkeve_kwSaYO20yigtkg7-k5NSFOg=.6828c6ab-7203-4dca-8f41-105fcd505467@github.com>
 <9hnYaiLpY43dWCDAiG8W_tDI2cg2teqSGzECu3ocLps=.43395add-6304-4f9f-9667-669c082082e4@github.com>
 <7mnVHxWSm3mKAzHUNsWDoM4odcweENeQ6afzRRf26fM=.f65241e5-0df5-498a-a470-6b9d80dcfe52@github.com>
 <YXIFhZcksi8nzSWkSgHc8i8WvHOiJ0P69nAZaoywo5M=.2505addc-029b-4e0f-a25e-897a50dbb5a2@github.com>
 <KGySTjtiQfD6KOtWqazclaw0-tNw6JGCffN
 fk0T6z2w=.d15cd61b-f516-4b99-af4d-4d99b07d4e33@github.com>
Message-ID: <VKIyLXtFSwLk8XloXbY0k4Nf7H6mTC-6u_iCc_ik0bE=.a9baec42-3630-4866-8c67-1d23da895c03@github.com>

On Wed, 5 Nov 2025 02:35:13 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> Thank you both!  @cl4es splitting it out had zero performance impact (per the benchmark).  As you said, it's a bit subjective... how strongly do you feel?  Other opinions are welcome too.
>
> I would think that you need to check `src.modCount` has same value at start and end of the method.
> 
> 
> final int expectedSrcModCount = src.modCount;
> //access src internals....
> checkForComodification(expectedSrcModCount)
> 
> 
> Looks like ArrayList::toArray is not doing this check either.  So perhaps it is not needed.  I would have thought mod check would have been needed in toArray to mimic iterator behavior.  Therefore needed in addAll.

I'd have to see the code with the split methods to know for sure, but if it involves duplicating code, then I'd prefer to try harder to avoid the duplication. What's the main optimization here? Direct access to the argument ArrayList's array, avoiding an intermediate copy? If this is the case, then it's hard to believe that it's necessary to duplicate the remainder of the method, which does the growth and copying, which I think aren't changed by this optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2493058610

From jpai at openjdk.org  Wed Nov  5 07:35:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Nov 2025 07:35:00 GMT
Subject: RFR: 8365699: Remove jdk.internal.javac.PreviewFeature.Feature
 enum values for features finalized in Java 25 or earlier
In-Reply-To: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
References: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
Message-ID: <_xpL77wWdAxgipvuOdMQqVMnhY2vMO8Yh3RDJYtdtMs=.5f233ff6-2357-4fed-9f77-2432d14290f6@github.com>

On Tue, 4 Nov 2025 10:33:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the outdated enum constants in the internal `jdk.internal.javac.PreviewFeature$Feature` enum?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8365699. As noted in that issue, this enum has accumulated some outdated preview feature constants which are no longer needed. The changes in this PR removes those enum constants whose preview features have been finalized in Java 25 or earlier (the current mainline bootstrap JDK is Java 25). A code comment explaining the lifetime of these enum constants has also been added.
> 
> No new tests have been introduced and tier1, tier2, tier3 testing is currently in progress in the CI.

tier1, tier2 and tier3 testing of this change completed without any failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/28128#issuecomment-3489743887

From mbaesken at openjdk.org  Wed Nov  5 08:08:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Nov 2025 08:08:03 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly [v2]
In-Reply-To: <xAWa8o65tL6Syy71GCH_3gvOoeWsF3ah0OVY2snF9n4=.bb997a2c-7595-4580-abc4-43ef1c25150a@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
 <xAWa8o65tL6Syy71GCH_3gvOoeWsF3ah0OVY2snF9n4=.bb997a2c-7595-4580-abc4-43ef1c25150a@github.com>
Message-ID: <3DrRXpA2tp_sHI34pEugtcLNstNe4RpekKAwgeNhS00=.983daaf2-92fd-4c21-bb32-96daac3e0bc2@github.com>

On Tue, 4 Nov 2025 19:06:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.
>> 
>> Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.
>> 
>>> Minimum supported client: 	Windows Vista
>>> Minimum supported server: 	Windows Server 2008
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove dynamic loading and call directly

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28119#pullrequestreview-3420458873

From daniel.peintner at gmail.com  Wed Nov  5 09:16:03 2025
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Wed, 5 Nov 2025 10:16:03 +0100
Subject: [External] : Re: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <98fc3c7c-d485-487b-9ab5-f4257c40cacf@oracle.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
 <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
 <CAAoP7T7XG_zWj0GSM37oMMvPq=NJ300Aac9skq8erXjYzqvmqw@mail.gmail.com>
 <98fc3c7c-d485-487b-9ab5-f4257c40cacf@oracle.com>
Message-ID: <CAAoP7T5PfnKaF6XFGaUcrBSUxQ58=eOKwSLkj+4rVPdQOL-FTQ@mail.gmail.com>

Hi Alexey,

Thank you for your reply.

Does the warning message resembles the one at [1]?
>

Yes, exactly.


> I think your evaluation that the step 1 failed is correct. I'd suggest
> adding "--verbose" option to the step 1 command line to get more details.
>

I updated a demo/test project to demonstrate the problem. You can now also
try it yourself.
https://github.com/danielpeintner/Java11Test/tree/non-modular

There you can also find the 3 jpackage commands I use
https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151

W.r.t. sharing the logs file. I will send them to you *privately*. I
quickly scanned them and I would rather not have them on the reflector.

The weird thing is, that the difference seems to happen in step 1. Anyhow,
running these commands the difference is also somehow in step 2 where
* JDK21 makes popping up a dialog which asks me whether I want to allow
access to my keys
* JDK25 does not need any interaction

I hope this helps to find the "difference".

Thanks,

-- Daniel





>
> [1]
> https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties#L85
>
> - Alexey
>
> On 11/4/2025 12:32 PM, Daniel Peintner wrote:
>
> Hi Alexey, all,
>
> I nailed down the problem to the following, which seems to differ between
> JDK25 and JDK21.
> Maybe this helps to reproduce the issue.
>
> jpackage is called 3 times in my process
>
>    1. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>    --type app-image --input
>    /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib
>    --main-jar myPROJECT-25.11.03.jar --main-class
>    eu.my_company.myproject.Launcher --dest
>    /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT
>    --app-version 25.11.03 --runtime-image
>    /Users/daniel/Documents/GitHub/myPROJECT/build/jre --java-options
>    --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED
>    --java-options --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED
>    --java-options
>    --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED
>    --java-options
>    --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED
>    --java-options
>    --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED
>    --java-options --add-exports=java.management/javax.management=ALL-UNNAMED
>    --java-options
>    --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED
>    --java-options --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED
>    --icon src/main/deploy/package/macosx/myPROJECT.icns
>    --mac-package-identifier eu.my-company.myproject --mac-sign
>
>    2. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>    --type pkg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>    --name myPROJECT --app-version 25.11.03 --app-image
>    /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>    --file-associations src/main/resources/associations.properties
>    --app-version 25.11.03 --vendor "My Company" --copyright "My Company"
>    --mac-sign
>
>    3. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>    --type dmg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>    --name myPROJECT --app-version 25.11.03 --app-image
>    /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>    --file-associations src/main/resources/associations.properties
>    --app-version 25.11.03 --vendor "My Company" --copyright "My Company"
>    --mac-sign
>
>
> First it creates the app-image and afterwards it creates pkg and dmg and
> signs it.
>
> As you can see in the 3 commands, it uses JDK21.
> Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after step 2 already
> with the following message in German
>
> Warnung: Nicht signiertes app-image wird zum Erstellen von signiertem pkg
> verwendet.
>
> It translates to something like: it tries to sign pkg and complains that
> the app-image is not signed.
> Hence, somehow step 1 failed already but does not show any error/warning.
>
> Please let me know whether the above helps to reproduce the issue.
>
> Thanks,
>
> -- Daniel
>
>
>
> On Tue, Nov 4, 2025 at 4:01?PM Daniel Peintner <daniel.peintner at gmail.com>
> wrote:
>
>> Hi Alexey,
>>
>> Thank you for your reply.
>> I am using the badass runtime plugin which calls jpackage under the hood.
>>
>> While trying to create an example project, I noticed that there were some
>> changes
>> '--mac-package-identifier' needs to go into imageOptions and
>> not installerOptions.
>> see
>> https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385
>> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-K4xefEo$>
>>
>> That fixed the problem with jpackage. Anyhow, it still does not work with
>> JDK25 and macOS signing.
>> Using the JDK25 seems to need additional options (compared to JDK21).
>>
>> With JDK25 and --mac-sign the process no longer opens the KeyChain access
>> and asks for the credentials. Hence, the image itself is no longer signed
>> which matches with what I see on the debug console
>> "non signed app-image used to sign dmg"  ... freely translated into
>> English since I see the German version only
>>
>> Therefore, apple's notary service says invalid with the logs like "The
>> binary is not signed with a valid Developer ID certificate".
>>
>> Using the *same* gradle file, switching to JDK21 works without any issues
>> again.
>> I will try to investigate further.
>>
>> Thanks,
>>
>> -- Daniel
>>
>>
>>
>>
>> On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk <
>> alexey.semenyuk at oracle.com> wrote:
>>
>>> Hi Daniel,
>>>
>>> I can not reproduce the issue you experience with jdk25.0.1:
>>>
>>> ---
>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest
>>> output --type app-image --main-jar hello.jar --main-class
>>> com.my_domain.project.Hello --mac-package-identifier com.my-domain.project
>>> $ echo $?
>>> 0
>>> ---
>>>
>>> If I run the same command line without ` --mac-package-identifier`
>>> option it fails as expected:
>>> ---
>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest
>>> output --type app-image --main-jar hello.jar --main-class
>>> com.my_domain.project.Hello
>>> Bundler Mac Application Image skipped because of a configuration
>>> problem: invalid mac bundle identifier [com.my_domain.project].
>>> Advice to fix: specify identifier with "--mac-package-identifier".
>>> ---
>>>
>>> The same failure for `--mac-package-identifier com.my_domain.project`
>>> (with the underscore):
>>> ---
>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest
>>> output --type app-image --main-jar hello.jar --main-class
>>> com.my_domain.project.Hello --mac-package-identifier com.my_domain.project
>>> Bundler Mac Application Image skipped because of a configuration
>>> problem: invalid mac bundle identifier [com.my_domain.project].
>>> Advice to fix: specify identifier with "--mac-package-identifier".
>>> ---
>>>
>>> Any chance you accidentally put the string with the underscore instead
>>> of the hyphen as a value of the `--mac-package-identifier` option on your
>>> command line?
>>>
>>> - Alexey
>>>
>>> On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>>
>>> Hi,
>>>
>>> I am about to switch a JavaFX project from JDK21 to JDK25 and I noticed
>>> a problem when running jpackage.
>>>
>>> My domain has a hyphen, like in www.my-domain.com
>>> <https://urldefense.com/v3/__http://www.my-domain.com__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-KS5-g-8$>
>>> Hence, my Java package reads like this: com.my_domain.project
>>> Note: hyphen becomes underscore.
>>>
>>> Running vanilla jpackage in JDK21 complained with
>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>> due to the *invalid* underscore and suggests me to use
>>> "--mac-package-identifier"
>>>
>>> Hence, I added --mac-package-identifier com.my-domain.project (with the
>>> hyphen again)
>>> All good so far.
>>>
>>> Running the same code with JDK25 with the above settings shows the error
>>> message again
>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>>
>>> I can add any argument to  --mac-package-identifier
>>> It seems it is simply not taken into account.
>>>
>>> I am using JDK 25.0.1
>>>
>>> Is this a known issue with JDK25 and jpackage?
>>> Is there any other way to make jpackage work?
>>>
>>> Thanks,
>>>
>>> -- Daniel
>>>
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251105/da7202d0/attachment-0001.htm>

From ihse at openjdk.org  Wed Nov  5 09:59:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Nov 2025 09:59:21 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v11]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <MOfXxjbt2Qf5ZFFHWZMOGWPot8DPiXeihjTQtSYGOA8=.0d996271-944d-4c32-984e-f6fe34c6aec4@github.com>

> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
> 
> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into static-relaunchers
 - Fix typo
 - Remove debug code
 - Use strlen to get literal string lenght
 - Merge branch 'master' into static-relaunchers
 - Update based on review
 - Merge branch 'master' into static-relaunchers
 - Use ReadFile instead
 - Merge branch 'master' into static-relaunchers
 - Remove problemlisting
 - ... and 13 more: https://git.openjdk.org/jdk/compare/0737a562...a925dc3e

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

Changes: https://git.openjdk.org/jdk/pull/24380/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=10
  Stats: 818 lines in 14 files changed: 628 ins; 144 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/24380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380

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

From volkan at yazi.ci  Wed Nov  5 10:31:59 2025
From: volkan at yazi.ci (=?UTF-8?B?Vm9sa2FuIFlhesSxY8Sx?=)
Date: Wed, 5 Nov 2025 11:31:59 +0100
Subject: HttpServer should implement AutoCloseable?
In-Reply-To: <CAA9v-_Mem7TqqhNa6SKQPZrAOjKvzuhBka6G4U5LTNditE0nJg@mail.gmail.com>
References: <CAA9v-_Mem7TqqhNa6SKQPZrAOjKvzuhBka6G4U5LTNditE0nJg@mail.gmail.com>
Message-ID: <CABDM8gDx_Wc=26WkK88SazWrFFP1j4kts_eAKtBEWL-Z8eqLHg@mail.gmail.com>

Given `close()` involves performing I/O, I suggest implementing `Closeable`
instead of `AutoCloseable`. Also note that `Closeable::close` is required
to be idempotent, which fits our bill.

On Fri, Oct 24, 2025 at 12:11?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello @core-libs-dev <core-libs-dev at openjdk.org>,
>
> Would it be ok if we made HttpServer from the jdk.httpserver module
> implement AutoCloseable? Having this would prevent people from forgetting
> to close the server after use.
>
> The close() implementation could call stop(int delay) with a reasonable
> default. This implementation should be a default one, so that existing
> child classes that also implemented AutoCloseable lose no functionality.
>
> Thank you for your time and consideration.
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251105/d7b6bcf1/attachment.htm>

From davidalayachew at gmail.com  Wed Nov  5 10:39:01 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 5 Nov 2025 05:39:01 -0500
Subject: HttpServer should implement AutoCloseable?
In-Reply-To: <CABDM8gDx_Wc=26WkK88SazWrFFP1j4kts_eAKtBEWL-Z8eqLHg@mail.gmail.com>
References: <CAA9v-_Mem7TqqhNa6SKQPZrAOjKvzuhBka6G4U5LTNditE0nJg@mail.gmail.com>
 <CABDM8gDx_Wc=26WkK88SazWrFFP1j4kts_eAKtBEWL-Z8eqLHg@mail.gmail.com>
Message-ID: <CAA9v-_MHh6Z2pyOuMw7V-TP6T-N1e1j_KMrgGEc=v3cQsCQGmA@mail.gmail.com>

Oh yes, using Closeable would be much better, ty vm.

On Wed, Nov 5, 2025, 5:32?AM Volkan Yaz?c? <volkan at yazi.ci> wrote:

> Given `close()` involves performing I/O, I suggest implementing
> `Closeable` instead of `AutoCloseable`. Also note that `Closeable::close`
> is required to be idempotent, which fits our bill.
>
> On Fri, Oct 24, 2025 at 12:11?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Hello @core-libs-dev <core-libs-dev at openjdk.org>,
>>
>> Would it be ok if we made HttpServer from the jdk.httpserver module
>> implement AutoCloseable? Having this would prevent people from forgetting
>> to close the server after use.
>>
>> The close() implementation could call stop(int delay) with a reasonable
>> default. This implementation should be a default one, so that existing
>> child classes that also implemented AutoCloseable lose no functionality.
>>
>> Thank you for your time and consideration.
>> David Alayachew
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251105/1cea07bb/attachment-0001.htm>

From ihse at openjdk.org  Wed Nov  5 10:41:05 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Nov 2025 10:41:05 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v12]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <k13uCtdn94ui9akpRBwIqGpskqIumMcjMzJ-qxEbH3E=.3c880942-5c2a-470e-aafa-92fae4bcc29b@github.com>

> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
> 
> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Use size_t for string lengths
 - Also quote the executable name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24380/files
  - new: https://git.openjdk.org/jdk/pull/24380/files/a925dc3e..dd8919a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=10-11

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

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

From ihse at openjdk.org  Wed Nov  5 10:41:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Nov 2025 10:41:07 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
In-Reply-To: <xOfXXkHET1mY9vC6f57zKsjsaIfsbq6ghbvTvO-F6a0=.653777df-9083-469f-9027-66657b60689f@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
 <xOfXXkHET1mY9vC6f57zKsjsaIfsbq6ghbvTvO-F6a0=.653777df-9083-469f-9027-66657b60689f@github.com>
Message-ID: <3Y3RYCDUDZQXtNpoBeR65eZSgZ_JpJjwmTdI2ShHMJc=.3b752647-d561-4d42-910b-c7614b03cdfe@github.com>

On Mon, 15 Sep 2025 16:37:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. 
>> 
>> As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run.
>
>> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this.
> 
> I think it's okay, and good for testing. I went through the relauncher closely, just not 100% sure of the quoting in the Windows implementation so I'm hoping Roger will have a few mins to scan that function.

@AlanBateman I updated the PR with a fix for the issue Roger found about quoting the executable name. Can you please re-approve?

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

PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3490429458

From ihse at openjdk.org  Wed Nov  5 10:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Nov 2025 10:41:10 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
 <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
Message-ID: <FsYrHCA1NDol6eN6H_IbbhTfndY00Il8FwGw7UGGclw=.f4553690-cb95-4318-80c8-26dd60410af2@github.com>

On Mon, 15 Sep 2025 17:29:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug code
>
> src/java.base/windows/native/launcher/relauncher.c line 153:
> 
>> 151:     }
>> 152: 
>> 153:     // Our executable name (should not be quoted)
> 
> ok here, because the full path is being explicitly passed to CreateProcess.
> If the command line is to be parsed and the executable path contains a space, CreateProcess does say it should be quoted.  It would be good to have a test case with a space in the executable path.

@RogerRiggs 
I fixed so that the launcher name is also quoted, and verified that it works as it should. Thanks for pointing it out!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2493891717

From pavel.rappo at gmail.com  Wed Nov  5 11:10:11 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Wed, 5 Nov 2025 11:10:11 +0000
Subject: On throwing InterruptedException
Message-ID: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>

I've seen code that wraps InterruptedException in some other exception
prior to throwing that other exception; for example:

    catch (InterruptedException e) {
        throw new IOException(e);
    }

I wonder if there are any legitimate cases for this, because I cannot
think of any. In my mind, it's always InterruptedException itself that
should be thrown; and if it cannot be done, then the interrupted
status should be set.

This is because if code that catches exceptions expects
InterruptedException, it expects to catch it directly rather than
search the exception graph (i.e. cause/suppressed) of the caught
exception for InterruptedException.

-Pavel

From alanb at openjdk.org  Wed Nov  5 11:32:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Nov 2025 11:32:07 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v12]
In-Reply-To: <k13uCtdn94ui9akpRBwIqGpskqIumMcjMzJ-qxEbH3E=.3c880942-5c2a-470e-aafa-92fae4bcc29b@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <k13uCtdn94ui9akpRBwIqGpskqIumMcjMzJ-qxEbH3E=.3c880942-5c2a-470e-aafa-92fae4bcc29b@github.com>
Message-ID: <66QgNnDkrSei0QThaCX_U-qVGiNRstbOLhDeptZVLuo=.af677780-2161-4993-9e12-b866545fdf33@github.com>

On Wed, 5 Nov 2025 10:41:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use size_t for string lengths
>  - Also quote the executable name

Thanks, I assume you'll run all the tiers with build targets before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24380#pullrequestreview-3421402845

From alan.bateman at oracle.com  Wed Nov  5 11:41:18 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Nov 2025 11:41:18 +0000
Subject: On throwing InterruptedException
In-Reply-To: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
Message-ID: <a196de40-8957-4e9c-ab66-1fb8ed9ad02a@oracle.com>

On 05/11/2025 11:10, Pavel Rappo wrote:
> I've seen code that wraps InterruptedException in some other exception
> prior to throwing that other exception; for example:
>
>      catch (InterruptedException e) {
>          throw new IOException(e);
>      }
>
> I wonder if there are any legitimate cases for this, because I cannot
> think of any. In my mind, it's always InterruptedException itself that
> should be thrown; and if it cannot be done, then the interrupted
> status should be set.
>
Right, if you catch InterruptedException then you should re-throw it, or 
reset the interrupted status if continuing or throwing a different 
exception. As it happens, I am hoping to adding "Thread Interruption" 
section to the Thread class description that includes guidance on this, 
and also gives us a place to link to from other parts of the API docs. 
Work in progress [1], not a PR as it's ready for review.

-Alan

[1] 
https://github.com/openjdk/jdk/compare/master...AlanBateman:jdk:JDK-8371226
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251105/983b05c7/attachment.htm>

From jvernee at openjdk.org  Wed Nov  5 12:17:32 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Nov 2025 12:17:32 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
 <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
Message-ID: <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>

On Tue, 4 Nov 2025 15:39:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments Patricio
>
> Thanks for the reviews!

> @JornVernee: The new test has failed on AIX:
> 
> ```
> [fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
> [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
> [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
> [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
> [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
> [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
> [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
> [fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
> [fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)
> ```
> 
> Should I file a new issue?

Please file a new issue. We haven't seen this failure in our CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3490884908

From alanb at openjdk.org  Wed Nov  5 12:19:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Nov 2025 12:19:27 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v14]
In-Reply-To: <2RIunJzmUUCMaaqbfPrIfeXJWc6Is7cme519UWUBLNc=.7441d786-0b49-4466-a994-7800bec9acde@github.com>
References: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
 <2RIunJzmUUCMaaqbfPrIfeXJWc6Is7cme519UWUBLNc=.7441d786-0b49-4466-a994-7800bec9acde@github.com>
Message-ID: <PDunvuFSGxOOJoxXci-R1ayNt5xvp9qD3GBmLCW1MS8=.e7b602f8-e85a-428b-9d6d-2b63aa4cf5ad@github.com>

On Tue, 4 Nov 2025 01:49:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355342: Do not fail wcanonicalize if getFinalPath fails

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27324#pullrequestreview-3421620541

From alanb at openjdk.org  Wed Nov  5 12:19:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Nov 2025 12:19:30 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v14]
In-Reply-To: <_JFRaQ0UqNC-030AkAhPfmKRV7MOwEs1N9OZzibLMxU=.3c55410e-8314-4869-ba49-d9498aeaee7b@github.com>
References: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
 <2RIunJzmUUCMaaqbfPrIfeXJWc6Is7cme519UWUBLNc=.7441d786-0b49-4466-a994-7800bec9acde@github.com>
 <dDNl9fxEjNuG4kiZXlI7rbIIAlS8AceAq3n6t97kDIY=.ceecc515-86e2-4ba0-b39b-4c7178d4e923@github.com>
 <FL6NV5CUwnzfwezOVmsq1Jv2quROjst6NG3mRwT2FSw=.9c98c6d2-9acc-4d46-b499-37edf02d213d@github.com>
 <_JFRaQ0UqNC-030AkAhPfmKRV7MOwEs1N9OZzibLMxU=.3c55410e-8314-4869-ba49-d9498aeaee7b@github.com>
Message-ID: <lmxrAvIzB3boF2EL3bp1mCxTwjmF3H2PpgSfwOaK4Sk=.dcb088e3-a0e4-4a3c-b731-6bb3ec1a4226@github.com>

On Tue, 4 Nov 2025 16:52:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Not definitively, but I think if could be. The Windows system error code was `ERROR_PATH_NOT_FOUND` (3).

Okay, in that case it should be okay to treat it as a broken link.

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

PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3490895033

From jaikiran.pai at oracle.com  Wed Nov  5 13:29:06 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Wed, 5 Nov 2025 18:59:06 +0530
Subject: state of openjdk-zlib on s390x
In-Reply-To: <7c022649373db9fbfc4a8d2426316429d76c9d61.camel@linux.ibm.com>
References: <7c022649373db9fbfc4a8d2426316429d76c9d61.camel@linux.ibm.com>
Message-ID: <64425285-ff54-4352-b67c-d39da31c9a38@oracle.com>

Hello Eddy,

On 04/11/25 1:19 pm, Eduard Stefes wrote:
> ...
> # the problem
>
> due to the differences of the hardware implementation, some tests in
> the openjdk JREG tests fail(tracked here[1][2])
>
> - java/util/zip/CloseInflaterDeflaterTest.java
>       fails due to dfltcc's flushing behaviour. The test should check if
>       the openjdk wrapper around the jni and native library will
>       successfully detect writes to closed output streams. This was
>       created because there where bugs with and race conditions in the
>       write/close/flush.

I had a look at https://bugs.openjdk.org/browse/JDK-8339216. That JBS 
issue lacks the actual failure/exception that happens for that test. 
Would it be possible to attach the .jtr file from a test execution where 
it fails? Depending on what the failure is, I think it could be 
addressed in that test.

> - tools/jlink/JLinkReproducibleTest.java:
> - tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java:
>       This tests fail due to two calls to dfltcc will not generate the
>       same compressed data for the same input data. I want to
>       emphasize that RFC 1950 and 1951 do not guarantee the same output
>       for two deflate/zlib data streams if feed the same input data.
I will have to read up the RFCs in detail, but these reproducibility 
tests have intentionally be written to catch issues like these. We want 
the ZIP/JAR artifacts generated for the JDK to be reproducible. We have 
been fixing bugs in the JDK, wherever possible, to make these artifacts 
reproducible.
> ## reproducible compression
>
> I don't know how much openjdk relies on reproducible data compression.
> I assume it is preferable if its possible to create the same .jar twice
> and get the same binary data. The zlib dfltcc implementation could be
> controlled via an env variable to disable the hardware compression[5].
> Also usually dftcc will only be used for certain compression levels and
> this can also be changed via env variables[6].
I am not familiar with that zlib code linked in [5] and [6]. But if you 
or anyone else is familiar with it, then instead of this being a 
environment variable evaluated at runtime on the host where the JDK 
runs, maybe it could be implemented as a build time macro(?) in that 
project? That would then allow you to pass a specific value during build 
time of that project and control this behaviour? You would then still 
have to do the work of "bundling" this zlib with the vendor specific JDK 
that you build, but at least for that, the OpenJDK build has the 
necessary infrastructure, see "--with-zlib" option in the build docs of 
OpenJDK.
> # Finally
>
> I hope i did not overwhelm you all with this email. As I don't have a
> bugs.openjdk.org account, I thought the mailing list is the best place
> to discuss this mater.

These mailing lists are indeed the right place to discuss this level of 
details. We are aware that recently there's been more than one variant 
of "zlib" being distributed by OS vendors, and we have noticed 
differences in the generated output from those implementations. These 
differences may (and will very likely) keep increasing over time. I 
think we will have to address each of these issues on a case-by-case 
basis for now.

-Jaikiran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251105/9be6af88/attachment-0001.htm>

From mdoerr at openjdk.org  Wed Nov  5 13:30:15 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 5 Nov 2025 13:30:15 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
 <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
 <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>
Message-ID: <fRuhTAKiblYVhQ-OOIYwGQAbRcXJrm2pGomSaWxNZ-g=.ebd8170f-5842-4cdf-9834-4621080512b9@github.com>

On Wed, 5 Nov 2025 12:14:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > @JornVernee: The new test has failed on AIX:
> > ```
> > [fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
> > [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
> > [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
> > [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
> > [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
> > [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
> > [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
> > [fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
> > [fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Should I file a new issue?
> 
> Please file a new issue. We haven't seen this failure in our CI.

Filed [JDK-8371340](https://bugs.openjdk.org/browse/JDK-8371340). Is the test supposed to work on platforms other than linux? It passes on linux PPC64 (both, big and little endian).

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3491224600

From pavel.rappo at gmail.com  Wed Nov  5 13:46:33 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Wed, 5 Nov 2025 13:46:33 +0000
Subject: On throwing InterruptedException
In-Reply-To: <a196de40-8957-4e9c-ab66-1fb8ed9ad02a@oracle.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <a196de40-8957-4e9c-ab66-1fb8ed9ad02a@oracle.com>
Message-ID: <CAChcVukhs6HxTAeFXEbQ8ng1BzTncrqCQYsZxzg2zbCTbAK90A@mail.gmail.com>

Thank you, Alan. I've read the proposed documentation and it reads
good. One minor, personal nit is that I would use "re-set" instead of
"reset" to disambiguate and be extra clear. In my mind, "reset" sets
something to its default or initial state. If read cursorily, it may
be interpreted as Thread.interrupted() rather than Thread.interrupt().
FWIW, other parts of documentation use "re-assert".

Back to the main topic. I'm sure you know that AutoCloseable.close()
has a paragraph [^1] that warns developers against throwing
InterruptedException from that method, and that there's a relevant
javac warning [^2]:

> Implementers of this interface are also strongly advised to not have the close method throw InterruptedException. This exception interacts with a thread's interrupted status, and runtime misbehavior is likely to occur if an InterruptedException is suppressed. More generally, if it would cause problems for an exception to be suppressed, the AutoCloseable.close method should not throw it.

Given how easy it is to get interruption wrong, would it be helpful to
provide similar verbiage directly in Throwable? Maybe in its
constructors, initCause, and addSuppressed?

Perhaps we can even add more relevant warnigns to javac. Now, I do
understand that javac is not a code-quality tool, and that the
aforementioned warning [^2] was added only because
AutoCloseable.close() interacts with the language feature,
try-with-resources. But given how important interruption is, maybe
javac could still warn on explicit calls such as
addSuppressed(InterruptedException), initCause(InterruptedException),
or calls to an exception constructor with InterruptedException as a
cause.  Just a thought.

[^1]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/AutoCloseable.html#:~:text=Implementers%20of%20this%20interface%20are%20also%20strongly%20advised
[^2]: https://bugs.openjdk.org/browse/JDK-7027157


On Wed, Nov 5, 2025 at 11:41?AM Alan Bateman <alan.bateman at oracle.com> wrote:
>
> On 05/11/2025 11:10, Pavel Rappo wrote:
>
> I've seen code that wraps InterruptedException in some other exception
> prior to throwing that other exception; for example:
>
>     catch (InterruptedException e) {
>         throw new IOException(e);
>     }
>
> I wonder if there are any legitimate cases for this, because I cannot
> think of any. In my mind, it's always InterruptedException itself that
> should be thrown; and if it cannot be done, then the interrupted
> status should be set.
>
> Right, if you catch InterruptedException then you should re-throw it, or reset the interrupted status if continuing or throwing a different exception. As it happens, I am hoping to adding "Thread Interruption" section to the Thread class description that includes guidance on this, and also gives us a place to link to from other parts of the API docs. Work in progress [1], not a PR as it's ready for review.
>
> -Alan
>
> [1] https://github.com/openjdk/jdk/compare/master...AlanBateman:jdk:JDK-8371226

From stefank at openjdk.org  Wed Nov  5 13:55:26 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 5 Nov 2025 13:55:26 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v4]
In-Reply-To: <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
Message-ID: <6okkjYqNRawvQ6BM8Oq5VVMTpfsE4LeMq31hIjjAh5s=.0ca7b626-40a2-456c-8636-086668c29651@github.com>

On Tue, 4 Nov 2025 11:56:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
>> 
>> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
>> 
>> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
>> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
>> 
>> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
>> 
>> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
>> 
>> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use String... as suggested by @stefank

OK. So, this misleading naming is already present in the OutputAnalyzer and this patch doesn't make things worse than what it already is.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3491341099

From stefank at openjdk.org  Wed Nov  5 13:58:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 5 Nov 2025 13:58:37 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v4]
In-Reply-To: <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
Message-ID: <EZRSEpeaOmf7Un8IbzarszQpJz-92qUa31M-YRldfQ8=.3fe3184a-2be6-4ce8-a1a1-70b78d5df388@github.com>

On Tue, 4 Nov 2025 11:56:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
>> 
>> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
>> 
>> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
>> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
>> 
>> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
>> 
>> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
>> 
>> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use String... as suggested by @stefank

Marked as reviewed by stefank (Reviewer).

Looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/28077#pullrequestreview-3422216751
PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3491355552

From forax at univ-mlv.fr  Wed Nov  5 14:00:24 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 5 Nov 2025 15:00:24 +0100 (CET)
Subject: On throwing InterruptedException
In-Reply-To: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
Message-ID: <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Pavel Rappo" <pavel.rappo at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Wednesday, November 5, 2025 12:10:11 PM
> Subject: On throwing InterruptedException

> I've seen code that wraps InterruptedException in some other exception
> prior to throwing that other exception; for example:
> 
>    catch (InterruptedException e) {
>        throw new IOException(e);
>    }
> 
> I wonder if there are any legitimate cases for this, because I cannot
> think of any. In my mind, it's always InterruptedException itself that
> should be thrown; and if it cannot be done, then the interrupted
> status should be set.
> 
> This is because if code that catches exceptions expects
> InterruptedException, it expects to catch it directly rather than
> search the exception graph (i.e. cause/suppressed) of the caught
> exception for InterruptedException.

It depends on whether you have faith in your fellow developers :)

If a thread is interrupted, it should stop ASAP.
So if you catch InterruptedException and rethrow a new exception, this should be okay (as Alan said).

But in practice, it may be a bad idea because people tend to write code that catch exceptions and do nothing,
so throwing an IOError is usually safer.

> 
> -Pavel

regards,
R?mi

From ihse at openjdk.org  Wed Nov  5 14:01:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Nov 2025 14:01:04 GMT
Subject: Integrated: 8346719: Add relaunchers to the static JDK image for
 missing executables
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <Uqe0tSNfoa8hZicVWycqBMPb_7TssZV8iJ__JYfGKVo=.ee5bb135-e5a3-4db4-833b-5655e17a4ce9@github.com>

On Wed, 2 Apr 2025 14:54:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
> 
> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.

This pull request has now been integrated.

Changeset: 2dd15cf5
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2dd15cf5bf1614e4b74ad9675723562e14ced8ab
Stats:     822 lines in 14 files changed: 632 ins; 144 del; 46 mod

8346719: Add relaunchers to the static JDK image for missing executables

Reviewed-by: alanb, erikj

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

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

From pavel.rappo at gmail.com  Wed Nov  5 15:36:15 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Wed, 5 Nov 2025 15:36:15 +0000
Subject: On throwing InterruptedException
In-Reply-To: <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAChcVukGQr5Q-thDix96GG+mdeVWgPkNac_nOjruT7_znjEpVw@mail.gmail.com>

I'm not sure that's what Alan said. Unless stated otherwise, re-throw
an exception `e` means `throw e`, so that `e` is the outermost,
unwrapped exception. Also you didn't say anything about "interrupted
status". But maybe, it's better to let Alan clarify what he meant.

For the sake of greater clarity, let me provide a few examples of
handling InterruptedException, and label them "good" or "bad" as per
my own understanding. In this examples I assume that code in question
does _not_ control or know what's on the stack above it:

    } catch (InterruptedException e) { // good
        Thread.currentThread().interrupt();
        return;
    }

    } catch (InterruptedException e) { // bad
        return;
    }

    } catch (InterruptedException e) { // good
        Thread.currentThread().interrupt();
        throw new IOException();
    }

    } catch (InterruptedException e) { // bad
        throw new IOException();
    }

    } catch (InterruptedException e) { // bad
        throw new IOException(e);
    }

    } catch (InterruptedException e) { // probably avoid as confusing
        Thread.currentThread().interrupt();
        throw new IOException(e);
    }

Specifically:

    } catch (InterruptedException e) { // bad
        throw new IOError();
    }

    } catch (InterruptedException e) { // bad
        throw new IOError(e);
    }

-Pavel


-Pavel

On Wed, Nov 5, 2025 at 2:00?PM Remi Forax <forax at univ-mlv.fr> wrote:
>
> ----- Original Message -----
> > From: "Pavel Rappo" <pavel.rappo at gmail.com>
> > To: "core-libs-dev" <core-libs-dev at openjdk.org>
> > Sent: Wednesday, November 5, 2025 12:10:11 PM
> > Subject: On throwing InterruptedException
>
> > I've seen code that wraps InterruptedException in some other exception
> > prior to throwing that other exception; for example:
> >
> >    catch (InterruptedException e) {
> >        throw new IOException(e);
> >    }
> >
> > I wonder if there are any legitimate cases for this, because I cannot
> > think of any. In my mind, it's always InterruptedException itself that
> > should be thrown; and if it cannot be done, then the interrupted
> > status should be set.
> >
> > This is because if code that catches exceptions expects
> > InterruptedException, it expects to catch it directly rather than
> > search the exception graph (i.e. cause/suppressed) of the caught
> > exception for InterruptedException.
>
> It depends on whether you have faith in your fellow developers :)
>
> If a thread is interrupted, it should stop ASAP.
> So if you catch InterruptedException and rethrow a new exception, this should be okay (as Alan said).
>
> But in practice, it may be a bad idea because people tend to write code that catch exceptions and do nothing,
> so throwing an IOError is usually safer.
>
> >
> > -Pavel
>
> regards,
> R?mi

From pavel.rappo at gmail.com  Wed Nov  5 15:38:14 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Wed, 5 Nov 2025 15:38:14 +0000
Subject: On throwing InterruptedException
In-Reply-To: <CAChcVukGQr5Q-thDix96GG+mdeVWgPkNac_nOjruT7_znjEpVw@mail.gmail.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <CAChcVukGQr5Q-thDix96GG+mdeVWgPkNac_nOjruT7_znjEpVw@mail.gmail.com>
Message-ID: <CAChcVukNQKiMaubssDHuKBfdOBZO4zpKkqFo059jh5O9P8iHnw@mail.gmail.com>

Oops, forgot to add one more:

    } catch (InterruptedException e) { // good
        throw e;
    }

On Wed, Nov 5, 2025 at 3:36?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
>
> I'm not sure that's what Alan said. Unless stated otherwise, re-throw
> an exception `e` means `throw e`, so that `e` is the outermost,
> unwrapped exception. Also you didn't say anything about "interrupted
> status". But maybe, it's better to let Alan clarify what he meant.
>
> For the sake of greater clarity, let me provide a few examples of
> handling InterruptedException, and label them "good" or "bad" as per
> my own understanding. In this examples I assume that code in question
> does _not_ control or know what's on the stack above it:
>
>     } catch (InterruptedException e) { // good
>         Thread.currentThread().interrupt();
>         return;
>     }
>
>     } catch (InterruptedException e) { // bad
>         return;
>     }
>
>     } catch (InterruptedException e) { // good
>         Thread.currentThread().interrupt();
>         throw new IOException();
>     }
>
>     } catch (InterruptedException e) { // bad
>         throw new IOException();
>     }
>
>     } catch (InterruptedException e) { // bad
>         throw new IOException(e);
>     }
>
>     } catch (InterruptedException e) { // probably avoid as confusing
>         Thread.currentThread().interrupt();
>         throw new IOException(e);
>     }
>
> Specifically:
>
>     } catch (InterruptedException e) { // bad
>         throw new IOError();
>     }
>
>     } catch (InterruptedException e) { // bad
>         throw new IOError(e);
>     }
>
> -Pavel
>
>
> -Pavel
>
> On Wed, Nov 5, 2025 at 2:00?PM Remi Forax <forax at univ-mlv.fr> wrote:
> >
> > ----- Original Message -----
> > > From: "Pavel Rappo" <pavel.rappo at gmail.com>
> > > To: "core-libs-dev" <core-libs-dev at openjdk.org>
> > > Sent: Wednesday, November 5, 2025 12:10:11 PM
> > > Subject: On throwing InterruptedException
> >
> > > I've seen code that wraps InterruptedException in some other exception
> > > prior to throwing that other exception; for example:
> > >
> > >    catch (InterruptedException e) {
> > >        throw new IOException(e);
> > >    }
> > >
> > > I wonder if there are any legitimate cases for this, because I cannot
> > > think of any. In my mind, it's always InterruptedException itself that
> > > should be thrown; and if it cannot be done, then the interrupted
> > > status should be set.
> > >
> > > This is because if code that catches exceptions expects
> > > InterruptedException, it expects to catch it directly rather than
> > > search the exception graph (i.e. cause/suppressed) of the caught
> > > exception for InterruptedException.
> >
> > It depends on whether you have faith in your fellow developers :)
> >
> > If a thread is interrupted, it should stop ASAP.
> > So if you catch InterruptedException and rethrow a new exception, this should be okay (as Alan said).
> >
> > But in practice, it may be a bad idea because people tend to write code that catch exceptions and do nothing,
> > so throwing an IOError is usually safer.
> >
> > >
> > > -Pavel
> >
> > regards,
> > R?mi

From jvernee at openjdk.org  Wed Nov  5 16:11:14 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Nov 2025 16:11:14 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
 <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
 <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>
Message-ID: <zFkGU6kSxenXCj2kGPyjMxB0cOXADIDIbTww8FOA1FQ=.20ab2d90-0cdf-4c37-b6f3-ba84fbe517ea@github.com>

On Wed, 5 Nov 2025 12:14:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Thanks for the reviews!
>
>> @JornVernee: The new test has failed on AIX:
>> 
>> ```
>> [fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
>> [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
>> [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
>> [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
>> [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
>> [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
>> [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
>> [fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
>> [fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)
>> ```
>> 
>> Should I file a new issue?
> 
> Please file a new issue. We haven't seen this failure in our CI.

> > > @JornVernee: The new test has failed on AIX:
> > > ```
> > > [fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
> > > [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
> > > [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
> > > [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
> > > [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
> > > [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
> > > [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
> > > [fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
> > > [fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > Should I file a new issue?
> > 
> > 
> > Please file a new issue. We haven't seen this failure in our CI.
> 
> Filed [JDK-8371340](https://bugs.openjdk.org/browse/JDK-8371340). Is the test supposed to work on platforms other than linux? It passes on linux PPC64 (both, big and little endian).

Yes, it is supposed to work on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3492077297

From naoto at openjdk.org  Wed Nov  5 17:09:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Nov 2025 17:09:48 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v8]
In-Reply-To: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
Message-ID: <ovVSp7pCJgGGKRfERIZJ3RU8k7MdyWSryUqHWJ8Xgvo=.386ab4fe-2794-43c0-b513-8f86b0a87f7a@github.com>

> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  More test data

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28076/files
  - new: https://git.openjdk.org/jdk/pull/28076/files/5de0854a..45ba153f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28076&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28076&range=06-07

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

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

From henryjen at openjdk.org  Wed Nov  5 17:47:38 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 5 Nov 2025 17:47:38 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking
Message-ID: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>

This PR include build changes from @magicus and jlink change to verify the build signature.

Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.

? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
                                                                                                                                                                 
? java --version
openjdk 26-internal 2026-03-17
OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
                                                                                                                                                                 
? jlink --version                                                                       
26-internal
                                                                                                                                                                 
? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
                                                                                                                                                                 
? jlink --add-modules java.base --output macos
                                                            
? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
                                                                                                                                                                 
? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

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

Commit messages:
 - JLink to check java build information
 - Build changes to generate release.txt for java.base and jdk.jlink.

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

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

From bpb at openjdk.org  Wed Nov  5 18:09:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Nov 2025 18:09:09 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v3]
In-Reply-To: <3qJ75D8p2yA6Dm_m0QjVS-S0WlWP6XXEj7wF1CmUWcU=.73d8689f-acc5-4b9d-9a22-b2f64fb6932d@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
 <3qJ75D8p2yA6Dm_m0QjVS-S0WlWP6XXEj7wF1CmUWcU=.73d8689f-acc5-4b9d-9a22-b2f64fb6932d@github.com>
Message-ID: <VkmlPLtriNWAAQI8Wi0munzdL2Y8VvJvJCYAh1lfT2Q=.d0f80c42-cd7e-4de4-9173-665625aa5cbe@github.com>

On Mon, 3 Nov 2025 18:09:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367943: Address reviewer comments

If this change looks all right, would someone please peruse the CSR? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28078#issuecomment-3492645498

From erikj at openjdk.org  Wed Nov  5 18:10:01 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Nov 2025 18:10:01 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking
In-Reply-To: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
Message-ID: <uAPYKyB67t3o4uDgCqaeXrrDHwObdCa13aqX_sLhFNc=.27a3811d-2968-498b-b5ed-9a7d9a182c71@github.com>

On Wed, 5 Nov 2025 17:41:44 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> This PR include build changes from @magicus and jlink change to verify the build signature.
> 
> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
> 
> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>                                                                                                                                                                  
> ? java --version
> openjdk 26-internal 2026-03-17
> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>                                                                                                                                                                  
> ? jlink --version                                                                       
> 26-internal
>                                                                                                                                                                  
> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>                                                                                                                                                                  
> ? jlink --add-modules java.base --output macos
>                                                             
> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>                                                                                                                                                                  
> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

I'm not thrilled about the code duplication between Gensrc.gmk in java.base and and jdk.jlink. I think this should be extracted out into a common file in some way. Having 2 copies of the template file also seems suboptimal.

make/modules/java.base/Gensrc.gmk line 129:

> 127: RELEASE_FILE_VARDEPS := $(COMPANY_NAME) $(VERSION_STRING) $(VERSION_DATE)
> 128: RELEASE_FILE_VARDEPS_FILE := $(call DependOnVariable, RELEASE_FILE_VARDEPS, \
> 129:   $(SUPPORT_OUTPUTDIR)/gensrc/$(MODULE)/jlink_release_txt.vardeps)

Continuation indentation should be 4 spaces (see https://openjdk.org/groups/build/doc/code-conventions.html).

make/modules/java.base/Gensrc.gmk line 134:

> 132:   SOURCE_FILES := $(RELEASE_FILE_TEMPLATE), \
> 133:   OUTPUT_FILE := $(RELEASE_FILE_TARGET), \
> 134:   REPLACEMENTS := \

Continuation indentation 4 spaces.

make/modules/java.base/Gensrc.gmk line 140:

> 138: ))
> 139: 
> 140: $(OUTPUT_FILE): $(RELEASE_FILE_VARDEPS_FILE)

There is no variable `OUTPUT_FILE` defined. I think this should be `$(BUILD_RELEASE_FILE)`.

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

PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3423620882
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2495596212
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2495596793
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2495599114

From sgehwolf at openjdk.org  Wed Nov  5 18:30:06 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Nov 2025 18:30:06 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping function
Message-ID: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>

Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.

For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):


f(x) = {(x - 2) \times 9999 + 1 \over 262142}


This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:


f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}


Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.

Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.

Thoughts?

**Testing:**
- [x] GHA
- [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

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

Commit messages:
 - Fix include
 - Add asserts/checks for input domain
 - Add regression test for jdk-8370492
 - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

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

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

From alexey.semenyuk at oracle.com  Wed Nov  5 18:31:38 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 5 Nov 2025 13:31:38 -0500
Subject: [External] : Re: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <CAAoP7T5PfnKaF6XFGaUcrBSUxQ58=eOKwSLkj+4rVPdQOL-FTQ@mail.gmail.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
 <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
 <CAAoP7T7XG_zWj0GSM37oMMvPq=NJ300Aac9skq8erXjYzqvmqw@mail.gmail.com>
 <98fc3c7c-d485-487b-9ab5-f4257c40cacf@oracle.com>
 <CAAoP7T5PfnKaF6XFGaUcrBSUxQ58=eOKwSLkj+4rVPdQOL-FTQ@mail.gmail.com>
Message-ID: <7aa147c9-108e-4194-be46-84399000578a@oracle.com>

Daniel,

I've commented on the logs you shared privately. Adding some thoughts to 
the mail list.

jpackage configuration at [1] is missing "--mac-signing-key-user-name" 
or "--mac-app-image-sign-identity" option. I noted it the private email 
as well.
At first I assumed it was a mistake, but then I came across an old 
thread about the very same jpackage issue at [2] where you state that 
"--mac-sign" option is sufficient to make jpackage find the signing 
identity. So this is intentional.

jdk25 jpackage will not look up for the signing identity unless 
"--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option 
is specified. I'm surprised it did in older releases.

For the sake of backward compatibility we can restore this behavior. But 
I think jpackage should exit with an error if the "--mac-sign" option is 
specified, but neither "--mac-signing-key-user-name" nor 
"--mac-app-image-sign-identity" is. The old behavior, when without these 
options jpackage picked the first available certificate with the common 
name starting with "Developer ID Application: " substring is not secure. 
It literally tells jpackage to pick any certificate without any 
filtering. If there is only one such certificate installed and it gets 
replaced, you will not even notice that your app is signed with a 
different certificate.

I suggest you add "--mac-signing-key-user-name" or 
"--mac-app-image-sign-identity" option to jpackage command line at [1] 
to make it work.

[1] 
https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151
[2] https://mail.openjdk.org/pipermail/core-libs-dev/2021-August/080291.html

- Alexey

On 11/5/2025 4:16 AM, Daniel Peintner wrote:
> Hi Alexey,
>
> Thank?you for your reply.
>
>     Does the warning message resembles the one at [1]?
>
>
> Yes, exactly.
>
>     I think your evaluation that the step 1 failed is correct. I'd
>     suggest adding "--verbose" option to the step 1 command line to
>     get more details.
>
>
> I updated a demo/test project to demonstrate the problem. You can now 
> also try it yourself.
> https://github.com/danielpeintner/Java11Test/tree/non-modular 
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMJdEvoaQ$>
>
> There you can also find the 3 jpackage commands I use
> https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151 
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle*L148-L151__;Iw!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMSE1bEoY$>
>
> W.r.t. sharing?the logs file. I will send them to you *privately*. I 
> quickly scanned them and I would rather not have them on the reflector.
>
> The weird thing is, that the difference seems to happen in step 1. 
> Anyhow, running these commands the difference is also somehow in step 
> 2 where
> * JDK21 makes popping up a dialog which asks me whether I want to 
> allow access?to my keys
> * JDK25 does not need any interaction
>
> I hope this?helps to find the "difference".
>
> Thanks,
>
> -- Daniel
>
>
>
>
>     [1]
>     https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties#L85
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties*L85__;Iw!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMd-s2VkQ$>
>
>     - Alexey
>
>     On 11/4/2025 12:32 PM, Daniel Peintner wrote:
>>     Hi Alexey, all,
>>
>>     I nailed down the problem to the following, which seems to differ
>>     between JDK25 and JDK21.
>>     Maybe this helps to reproduce the issue.
>>
>>     jpackage is called 3 times in my process
>>
>>      1. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>         --type app-image --input
>>         /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib
>>         --main-jar myPROJECT-25.11.03.jar --main-class
>>         eu.my_company.myproject.Launcher --dest
>>         /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>         --name myPROJECT --app-version 25.11.03 --runtime-image
>>         /Users/daniel/Documents/GitHub/myPROJECT/build/jre
>>         --java-options
>>         --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED
>>         --java-options
>>         --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED
>>         --java-options
>>         --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED
>>         --java-options
>>         --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED
>>         --java-options
>>         --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED
>>         --java-options
>>         --add-exports=java.management/javax.management=ALL-UNNAMED
>>         --java-options
>>         --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED
>>         --java-options
>>         --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED
>>         --icon src/main/deploy/package/macosx/myPROJECT.icns
>>         --mac-package-identifier eu.my-company.myproject --mac-sign
>>
>>      2. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>         --type pkg --dest
>>         /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>         --name myPROJECT --app-version 25.11.03 --app-image
>>         /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>>         --file-associations
>>         src/main/resources/associations.properties --app-version
>>         25.11.03 --vendor "My Company" --copyright "My Company"
>>         --mac-sign
>>
>>      3. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>         --type dmg --dest
>>         /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>         --name myPROJECT --app-version 25.11.03 --app-image
>>         /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>>         --file-associations
>>         src/main/resources/associations.properties --app-version
>>         25.11.03 --vendor "My Company" --copyright "My Company"
>>         --mac-sign
>>
>>
>>     First it creates the app-image and afterwards it creates pkg and
>>     dmg and signs it.
>>
>>     As you can see in the 3 commands, it uses JDK21.
>>     Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after step
>>     2 already with the following message in German
>>
>>     Warnung: Nicht signiertes app-image wird zum Erstellen von
>>     signiertem pkg verwendet.
>>
>>     It translates to something?like: it tries to sign pkg and
>>     complains that the app-image is not signed.
>>     Hence, somehow step 1 failed already but does not show any
>>     error/warning.
>>
>>     Please let me know whether the above helps to reproduce the issue.
>>
>>     Thanks,
>>
>>     -- Daniel
>>
>>
>>
>>     On Tue, Nov 4, 2025 at 4:01?PM Daniel Peintner
>>     <daniel.peintner at gmail.com> wrote:
>>
>>         Hi Alexey,
>>
>>         Thank you for your reply.
>>         I am using the?badass runtime plugin which calls jpackage
>>         under the hood.
>>
>>         While trying to create an example project, I noticed that
>>         there were some changes
>>         '--mac-package-identifier' needs to go into?imageOptions and
>>         not?installerOptions.
>>         see
>>         https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385
>>         <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-K4xefEo$>
>>
>>         That fixed the problem with jpackage. Anyhow, it still does
>>         not work with JDK25 and macOS signing.
>>         Using the JDK25 seems to need additional options (compared to
>>         JDK21).
>>
>>         With JDK25 and --mac-sign the process no longer opens the
>>         KeyChain access and asks for the credentials. Hence, the
>>         image itself is no longer signed which matches with what I
>>         see on the debug console
>>         "non signed app-image used to sign dmg"? ... freely
>>         translated into English since I see the German version only
>>
>>         Therefore, apple's notary service says invalid with the logs
>>         like "The binary is not signed with a valid Developer ID
>>         certificate".
>>
>>         Using the *same* gradle file, switching to JDK21 works
>>         without any issues again.
>>         I will try to investigate further.
>>
>>         Thanks,
>>
>>         -- Daniel
>>
>>
>>
>>
>>         On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk
>>         <alexey.semenyuk at oracle.com> wrote:
>>
>>             Hi Daniel,
>>
>>             I can not reproduce the issue you experience with jdk25.0.1:
>>
>>             ---
>>             $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input
>>             input --dest output --type app-image --main-jar hello.jar
>>             --main-class com.my_domain.project.Hello
>>             --mac-package-identifier com.my-domain.project
>>             $ echo $?
>>             0
>>             ---
>>
>>             If I run the same command line without `
>>             --mac-package-identifier` option it fails as expected:
>>             ---
>>             $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input
>>             input --dest output --type app-image --main-jar hello.jar
>>             --main-class com.my_domain.project.Hello
>>             Bundler Mac Application Image skipped because of a
>>             configuration problem: invalid mac bundle identifier
>>             [com.my_domain.project].
>>             Advice to fix: specify identifier with
>>             "--mac-package-identifier".
>>             ---
>>
>>             The same failure for `--mac-package-identifier
>>             com.my_domain.project` (with the underscore):
>>             ---
>>             $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input
>>             input --dest output --type app-image --main-jar hello.jar
>>             --main-class com.my_domain.project.Hello
>>             --mac-package-identifier com.my_domain.project
>>             Bundler Mac Application Image skipped because of a
>>             configuration problem: invalid mac bundle identifier
>>             [com.my_domain.project].
>>             Advice to fix: specify identifier with
>>             "--mac-package-identifier".
>>             ---
>>
>>             Any chance you accidentally put the string with the
>>             underscore instead of the hyphen as a value of the
>>             `--mac-package-identifier` option on your command line?
>>
>>             - Alexey
>>
>>             On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>>             Hi,
>>>
>>>             I am about to switch a JavaFX project from JDK21 to
>>>             JDK25 and I noticed a problem when running jpackage.
>>>
>>>             My domain has a hyphen, like in www.my-domain.com
>>>             <https://urldefense.com/v3/__http://www.my-domain.com__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-KS5-g-8$>
>>>             Hence, my Java package reads like this:
>>>             com.my_domain.project
>>>             Note: hyphen becomes underscore.
>>>
>>>             Running vanilla jpackage in JDK21 complained with
>>>             Invalid Mac-Bundle-ID [com.my_domain.project]
>>>             due to the *invalid* underscore and suggests me to use
>>>             "--mac-package-identifier"
>>>
>>>             Hence, I added --mac-package-identifier
>>>             com.my-domain.project (with the hyphen again)
>>>             All good so far.
>>>
>>>             Running the same code with JDK25 with the above settings
>>>             shows the error message again
>>>             Invalid Mac-Bundle-ID [com.my_domain.project]
>>>
>>>             I can add any argument to --mac-package-identifier
>>>             It seems it is simply not taken into account.
>>>
>>>             I am using JDK 25.0.1
>>>
>>>             Is this a known issue with?JDK25 and jpackage?
>>>             Is there any other way to make jpackage work?
>>>
>>>             Thanks,
>>>
>>>             -- Daniel
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251105/1c068a04/attachment-0001.htm>

From bpb at openjdk.org  Wed Nov  5 18:33:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Nov 2025 18:33:22 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v3]
In-Reply-To: <VkmlPLtriNWAAQI8Wi0munzdL2Y8VvJvJCYAh1lfT2Q=.d0f80c42-cd7e-4de4-9173-665625aa5cbe@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
 <3qJ75D8p2yA6Dm_m0QjVS-S0WlWP6XXEj7wF1CmUWcU=.73d8689f-acc5-4b9d-9a22-b2f64fb6932d@github.com>
 <VkmlPLtriNWAAQI8Wi0munzdL2Y8VvJvJCYAh1lfT2Q=.d0f80c42-cd7e-4de4-9173-665625aa5cbe@github.com>
Message-ID: <cQIoNAU5rPK_4lxiWLliRPD0CpRPiCIK8nZsddXd2Ck=.f4c3a86c-019b-4f52-88dc-0a206405de07@github.com>

On Wed, 5 Nov 2025 18:06:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> would someone please peruse the CSR

Thanks @jaikiran.

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

PR Comment: https://git.openjdk.org/jdk/pull/28078#issuecomment-3492733176

From jlu at openjdk.org  Wed Nov  5 22:19:36 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Nov 2025 22:19:36 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly [v3]
In-Reply-To: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
Message-ID: <ZQeOuXAbP5kB2z1Rij8pJurBHbYGfSnI_1cxHCMUbzk=.28b7e2ae-f3f3-4206-b4ee-3d1b15169c33@github.com>

> This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.
> 
> Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.
> 
>> Minimum supported client: 	Windows Vista
>> Minimum supported server: 	Windows Server 2008

Justin Lu 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 branch 'master' into JDK-8370420-Windows
 - Merge branch 'master' into JDK-8370420-Windows
 - Remove dynamic loading and call directly
 - Merge branch 'master' into JDK-8370420-Windows
 - init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28119/files
  - new: https://git.openjdk.org/jdk/pull/28119/files/e18a5744..e6d45424

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

  Stats: 12203 lines in 397 files changed: 7768 ins; 3189 del; 1246 mod
  Patch: https://git.openjdk.org/jdk/pull/28119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28119/head:pull/28119

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

From pavel.rappo at gmail.com  Wed Nov  5 23:10:18 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Wed, 5 Nov 2025 23:10:18 +0000
Subject: On throwing InterruptedException
In-Reply-To: <CAChcVukNQKiMaubssDHuKBfdOBZO4zpKkqFo059jh5O9P8iHnw@mail.gmail.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <CAChcVukGQr5Q-thDix96GG+mdeVWgPkNac_nOjruT7_znjEpVw@mail.gmail.com>
 <CAChcVukNQKiMaubssDHuKBfdOBZO4zpKkqFo059jh5O9P8iHnw@mail.gmail.com>
Message-ID: <CAChcVunyDTzcTDXUUhzcXJAgD7NQKkZHS20hDuhHVy0KMwd+EA@mail.gmail.com>

And also this, which is a bit contrived but valid nonetheless:

    } catch (InterruptedException e) { // good
        throw new InterruptedException();

    }


On Wed, Nov 5, 2025 at 3:38?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
>
> Oops, forgot to add one more:
>
>     } catch (InterruptedException e) { // good
>         throw e;
>     }
>
> On Wed, Nov 5, 2025 at 3:36?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
> >
> > I'm not sure that's what Alan said. Unless stated otherwise, re-throw
> > an exception `e` means `throw e`, so that `e` is the outermost,
> > unwrapped exception. Also you didn't say anything about "interrupted
> > status". But maybe, it's better to let Alan clarify what he meant.
> >
> > For the sake of greater clarity, let me provide a few examples of
> > handling InterruptedException, and label them "good" or "bad" as per
> > my own understanding. In this examples I assume that code in question
> > does _not_ control or know what's on the stack above it:
> >
> >     } catch (InterruptedException e) { // good
> >         Thread.currentThread().interrupt();
> >         return;
> >     }
> >
> >     } catch (InterruptedException e) { // bad
> >         return;
> >     }
> >
> >     } catch (InterruptedException e) { // good
> >         Thread.currentThread().interrupt();
> >         throw new IOException();
> >     }
> >
> >     } catch (InterruptedException e) { // bad
> >         throw new IOException();
> >     }
> >
> >     } catch (InterruptedException e) { // bad
> >         throw new IOException(e);
> >     }
> >
> >     } catch (InterruptedException e) { // probably avoid as confusing
> >         Thread.currentThread().interrupt();
> >         throw new IOException(e);
> >     }
> >
> > Specifically:
> >
> >     } catch (InterruptedException e) { // bad
> >         throw new IOError();
> >     }
> >
> >     } catch (InterruptedException e) { // bad
> >         throw new IOError(e);
> >     }
> >
> > -Pavel
> >
> >
> > -Pavel
> >
> > On Wed, Nov 5, 2025 at 2:00?PM Remi Forax <forax at univ-mlv.fr> wrote:
> > >
> > > ----- Original Message -----
> > > > From: "Pavel Rappo" <pavel.rappo at gmail.com>
> > > > To: "core-libs-dev" <core-libs-dev at openjdk.org>
> > > > Sent: Wednesday, November 5, 2025 12:10:11 PM
> > > > Subject: On throwing InterruptedException
> > >
> > > > I've seen code that wraps InterruptedException in some other exception
> > > > prior to throwing that other exception; for example:
> > > >
> > > >    catch (InterruptedException e) {
> > > >        throw new IOException(e);
> > > >    }
> > > >
> > > > I wonder if there are any legitimate cases for this, because I cannot
> > > > think of any. In my mind, it's always InterruptedException itself that
> > > > should be thrown; and if it cannot be done, then the interrupted
> > > > status should be set.
> > > >
> > > > This is because if code that catches exceptions expects
> > > > InterruptedException, it expects to catch it directly rather than
> > > > search the exception graph (i.e. cause/suppressed) of the caught
> > > > exception for InterruptedException.
> > >
> > > It depends on whether you have faith in your fellow developers :)
> > >
> > > If a thread is interrupted, it should stop ASAP.
> > > So if you catch InterruptedException and rethrow a new exception, this should be okay (as Alan said).
> > >
> > > But in practice, it may be a bad idea because people tend to write code that catch exceptions and do nothing,
> > > so throwing an IOError is usually safer.
> > >
> > > >
> > > > -Pavel
> > >
> > > regards,
> > > R?mi

From vromero at openjdk.org  Wed Nov  5 23:26:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 5 Nov 2025 23:26:06 GMT
Subject: RFR: 8365699: Remove jdk.internal.javac.PreviewFeature.Feature
 enum values for features finalized in Java 25 or earlier
In-Reply-To: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
References: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
Message-ID: <OikhabP7Vrmi0GYrU9LwZUcj-C6CpARGm4ZOOyCw2xI=.4b4fa110-f4e1-40a0-8c3d-7c9e47ca364d@github.com>

On Tue, 4 Nov 2025 10:33:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the outdated enum constants in the internal `jdk.internal.javac.PreviewFeature$Feature` enum?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8365699. As noted in that issue, this enum has accumulated some outdated preview feature constants which are no longer needed. The changes in this PR removes those enum constants whose preview features have been finalized in Java 25 or earlier (the current mainline bootstrap JDK is Java 25). A code comment explaining the lifetime of these enum constants has also been added.
> 
> No new tests have been introduced and tier1, tier2, tier3 testing is currently in progress in the CI.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28128#pullrequestreview-3424936525

From liach at openjdk.org  Wed Nov  5 23:34:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Nov 2025 23:34:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
Message-ID: <qdoshJM6YkMk1XK055rk8NLEb_mw0INP_ylFKSMPx2Y=.c52d2295-74d3-4681-8c56-14207a47a62e@github.com>

On Fri, 24 Oct 2025 09:01:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework toString implementations

src/java.base/share/classes/java/lang/LazyConstant.java line 94:

> 92:  * lazy constant remains uninitialized.
> 93:  *
> 94:  * <h2 id="composition">Composing lazy constants</h2>

This section has some interesting usage, but I don't believe it should be included in the API specification. Behaviors described here can be derived from the formal specifications.

src/java.base/share/classes/java/lang/LazyConstant.java line 209:

> 207: 
> 208:     /**
> 209:      * {@return the contents of this lazy constant if initialized, otherwise,\

Suggestion:

     * {@return the contents of this lazy constant if initialized, otherwise,

src/java.base/share/classes/java/util/AbstractMap.java line 34:

> 32: 
> 33: import jdk.internal.vm.annotation.AOTSafeClassInitializer;
> 34: import jdk.internal.vm.annotation.Stable;

Suggestion:

src/java.base/share/classes/java/util/Currency.java line 146:

> 144:     private static ConcurrentMap<String, Currency> instances = new ConcurrentHashMap<>(7);
> 145:     private static final LazyConstant<HashSet<Currency>> available =
> 146:             LazyConstant.of(new Supplier<HashSet<Currency>>() {

Why can't we retain the method reference here? This is not used in early bootstrap.

src/java.base/share/classes/java/util/LazyCollections.java line 516:

> 514: 
> 515:         @ForceInline
> 516:         private void disposeOfMutex(long offset) {

I recommend removing this unused and otherwise confusing method.

src/java.base/share/classes/java/util/LazyCollections.java line 559:

> 557:     }
> 558: 
> 559:     public static <E> int lastIndexOf(List<LazyConstant<E>> list, Object o) {

This indexOf and lastIndexOf appear unused.

src/java.base/share/classes/java/util/Map.java line 1814:

> 1812:         final Set<K> keyCopies = Set.copyOf(keys);
> 1813:         Objects.requireNonNull(computingFunction);
> 1814:         if (keys instanceof EnumSet<?> && !keys.isEmpty()) {

I wonder if it's premature for us to optimize like this - for example, this would be wasteful if the key set contains one enum constant but there are 1000 enum constants in this enum.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496459406
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496468213
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496478562
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496479687
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496503928
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496514844
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496516750

From liach at openjdk.org  Wed Nov  5 23:51:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Nov 2025 23:51:01 GMT
Subject: RFR: 8365699: Remove jdk.internal.javac.PreviewFeature.Feature
 enum values for features finalized in Java 25 or earlier
In-Reply-To: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
References: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
Message-ID: <Wf66k1edEzzh7Ty5wwjeBp3e698XV39M4aBKHjSkRcY=.24facdb5-bdf9-4ace-af87-8d1fe599db80@github.com>

On Tue, 4 Nov 2025 10:33:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the outdated enum constants in the internal `jdk.internal.javac.PreviewFeature$Feature` enum?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8365699. As noted in that issue, this enum has accumulated some outdated preview feature constants which are no longer needed. The changes in this PR removes those enum constants whose preview features have been finalized in Java 25 or earlier (the current mainline bootstrap JDK is Java 25). A code comment explaining the lifetime of these enum constants has also been added.
> 
> No new tests have been introduced and tier1, tier2, tier3 testing is currently in progress in the CI.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28128#pullrequestreview-3424994084

From trevorkbond at gmail.com  Thu Nov  6 03:56:46 2025
From: trevorkbond at gmail.com (Trevor Bond)
Date: Wed, 5 Nov 2025 20:56:46 -0700
Subject: Questions regarding JDK-8350938
 (ResourceParsingClassHierarchyResolver)
Message-ID: <CAKsKV6Ya3XfHnkEEbj1SXJQt7AU_+wm-w5HqjLandGiW86csFQ@mail.gmail.com>

Hi all,

I'm new to contributing to OpenJDK and have been working with Dan Smith as
a mentor. I've been looking at JDK-8350938, which suggests refactoring
ResourceParsingClassHierarchyResolver to avoid inflating all UTF8 constant
pool entries by using ClassReaderImpl. ClassReaderImpl stores constant pool
offsets and later lazily reads/inflates UTF8 entries as needed, so it seems
to make sense to use here as a performance enhancement.

I have an initial prototype that removes manual parsing in getClassInfo()
and instead constructs a ClassReaderImpl and uses its helper methods to
return the needed class information.

One question before I try to move forward with contributing:
- ClassReaderImpl takes a ClassFile context. I used ClassFile.of() (a
ClassFile context with default options). Is this the correct usage here, or
should the resolver provide a more specific context?
I am also open to and would appreciate any other ideas or feedback on this
implementation.

I?ve included the small patch below for reference.

Thanks for your help,
Trevor

diff --git
a/src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
b/src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
index 5be14f42baa..463845ce612 100644
---
a/src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
+++
b/src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
@@ -30,7 +30,10 @@
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.UncheckedIOException;
+import java.lang.classfile.ClassFile;
 import java.lang.classfile.ClassHierarchyResolver;
+import java.lang.classfile.ClassReader;
+import java.lang.classfile.constantpool.ClassEntry;
 import java.lang.constant.ClassDesc;
 import java.util.Collection;
 import java.util.HashMap;
@@ -164,31 +167,12 @@ public
ResourceParsingClassHierarchyResolver(Function<ClassDesc, InputStream> cl
         public ClassHierarchyResolver.ClassHierarchyInfo
getClassInfo(ClassDesc classDesc) {
             var ci = streamProvider.apply(classDesc);
             if (ci == null) return null;
-            try (var in = new DataInputStream(new
BufferedInputStream(ci))) {
-                in.skipBytes(8);
-                int cpLength = in.readUnsignedShort();
-                String[] cpStrings = new String[cpLength];
-                int[] cpClasses = new int[cpLength];
-                for (int i = 1; i < cpLength; i++) {
-                    int tag;
-                    switch (tag = in.readUnsignedByte()) {
-                        case TAG_UTF8 -> cpStrings[i] = in.readUTF();
-                        case TAG_CLASS -> cpClasses[i] =
in.readUnsignedShort();
-                        case TAG_STRING, TAG_METHOD_TYPE, TAG_MODULE,
TAG_PACKAGE -> in.skipBytes(2);
-                        case TAG_METHOD_HANDLE -> in.skipBytes(3);
-                        case TAG_INTEGER, TAG_FLOAT, TAG_FIELDREF,
TAG_METHODREF, TAG_INTERFACE_METHODREF,
-                             TAG_NAME_AND_TYPE, TAG_DYNAMIC,
TAG_INVOKE_DYNAMIC -> in.skipBytes(4);
-                        case TAG_LONG, TAG_DOUBLE -> {
-                            in.skipBytes(8);
-                            i++;
-                        }
-                        default -> throw new IllegalStateException("Bad
tag (" + tag + ") at index (" + i + ")");
-                    }
-                }
-                boolean isInterface = (in.readUnsignedShort() &
ACC_INTERFACE) != 0;
-                in.skipBytes(2);
-                int superIndex = in.readUnsignedShort();
-                var superClass = superIndex > 0 ?
ClassDesc.ofInternalName(cpStrings[cpClasses[superIndex]]) : null;
+            try (ci) {
+                ClassReader reader = new
ClassReaderImpl(ci.readAllBytes(), (ClassFileImpl) ClassFile.of());
+                boolean isInterface = (reader.flags() & ACC_INTERFACE) !=
0;
+                ClassDesc superClass = reader.superclassEntry()
+                        .map(ClassEntry::asSymbol)
+                        .orElse(null);
                 return new ClassHierarchyInfoImpl(superClass, isInterface);
             } catch (IOException ioe) {
                 throw new UncheckedIOException(ioe);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251105/377e54ea/attachment-0001.htm>

From jpai at openjdk.org  Thu Nov  6 04:45:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Nov 2025 04:45:10 GMT
Subject: RFR: 8365699: Remove jdk.internal.javac.PreviewFeature.Feature
 enum values for features finalized in Java 25 or earlier
In-Reply-To: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
References: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
Message-ID: <CPELydD44FGoNEMtAZ8_huyJ9slRhF4Z5wWn-TFVDKM=.232538c8-29d1-4651-b4fc-c8958a5758c5@github.com>

On Tue, 4 Nov 2025 10:33:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the outdated enum constants in the internal `jdk.internal.javac.PreviewFeature$Feature` enum?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8365699. As noted in that issue, this enum has accumulated some outdated preview feature constants which are no longer needed. The changes in this PR removes those enum constants whose preview features have been finalized in Java 25 or earlier (the current mainline bootstrap JDK is Java 25). A code comment explaining the lifetime of these enum constants has also been added.
> 
> No new tests have been introduced and tier1, tier2, tier3 testing is currently in progress in the CI.

Thank you Vicente and Chen for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28128#issuecomment-3495007919

From jpai at openjdk.org  Thu Nov  6 04:45:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Nov 2025 04:45:11 GMT
Subject: Integrated: 8365699: Remove jdk.internal.javac.PreviewFeature.Feature
 enum values for features finalized in Java 25 or earlier
In-Reply-To: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
References: <jM0uMZaOWCG4EbNFXgoYwv46paZAjf7PGPEDFG7MYOc=.c7f1794f-5621-4c84-8f40-12008ff1e8a1@github.com>
Message-ID: <R31QpxfjOM2-E2-DAbct2AWzMHgE7jLR2NnkfudcO-E=.bd708f91-eccd-4757-87cf-a7eacd3b4a4c@github.com>

On Tue, 4 Nov 2025 10:33:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the outdated enum constants in the internal `jdk.internal.javac.PreviewFeature$Feature` enum?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8365699. As noted in that issue, this enum has accumulated some outdated preview feature constants which are no longer needed. The changes in this PR removes those enum constants whose preview features have been finalized in Java 25 or earlier (the current mainline bootstrap JDK is Java 25). A code comment explaining the lifetime of these enum constants has also been added.
> 
> No new tests have been introduced and tier1, tier2, tier3 testing is currently in progress in the CI.

This pull request has now been integrated.

Changeset: 188da51f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/188da51f30e5ca3945fee91fe2e94f0466151c06
Stats:     23 lines in 1 file changed: 15 ins; 6 del; 2 mod

8365699: Remove jdk.internal.javac.PreviewFeature.Feature enum values for features finalized in Java 25 or earlier

Reviewed-by: vromero, liach

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

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

From iklam at openjdk.org  Thu Nov  6 04:51:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Nov 2025 04:51:15 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v4]
In-Reply-To: <EZRSEpeaOmf7Un8IbzarszQpJz-92qUa31M-YRldfQ8=.3fe3184a-2be6-4ce8-a1a1-70b78d5df388@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
 <EZRSEpeaOmf7Un8IbzarszQpJz-92qUa31M-YRldfQ8=.3fe3184a-2be6-4ce8-a1a1-70b78d5df388@github.com>
Message-ID: <hZ7wJOCsrNAI86njK9She52xpX37XjT82litQqgoHtA=.fb0e6ca6-f691-4b4a-bc40-b7583e19859c@github.com>

On Wed, 5 Nov 2025 13:56:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use String... as suggested by @stefank
>
> Looks good.

Thanks @stefank for the review!
I tested tiers 1-5 and saw no regression, so it looks like the OutputAnalyzer changes work fine with existing tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3495030194

From iklam at openjdk.org  Thu Nov  6 04:51:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Nov 2025 04:51:16 GMT
Subject: Integrated: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE
In-Reply-To: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
Message-ID: <qCWsSfNBB_P4GcBY4GAmHSHaoa4HYx2oUarbSAVDTJI=.dd2254d9-3636-4b75-9579-37f7868b9df4@github.com>

On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
> 
> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
> 
> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
> 
> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
> 
> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.

This pull request has now been integrated.

Changeset: 3f40f4c3
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f40f4c362f6ff4d1ec7d513b4690ed5fade3e2a
Stats:     111 lines in 2 files changed: 87 ins; 13 del; 11 mod

8370975: OutputAnalyzer.matches() should use Matcher with Pattern.MULTILINE

Reviewed-by: stefank

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

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

From chen.l.liang at oracle.com  Thu Nov  6 05:01:25 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 6 Nov 2025 05:01:25 +0000
Subject: Questions regarding JDK-8350938
 (ResourceParsingClassHierarchyResolver)
In-Reply-To: <CAKsKV6Ya3XfHnkEEbj1SXJQt7AU_+wm-w5HqjLandGiW86csFQ@mail.gmail.com>
References: <CAKsKV6Ya3XfHnkEEbj1SXJQt7AU_+wm-w5HqjLandGiW86csFQ@mail.gmail.com>
Message-ID: <SJ2PR10MB7669D8FB7509C72093846670A2C2A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Trevor, I think ClassFile.of is good for this particular purpose. There is nothing in the header parsing that the default class file handling options is not suitable for.

-Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Trevor Bond <trevorkbond at gmail.com>
Sent: Wednesday, November 5, 2025 9:56 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Questions regarding JDK-8350938 (ResourceParsingClassHierarchyResolver)

Hi all,

I'm new to contributing to OpenJDK and have been working with Dan Smith as a mentor. I've been looking at JDK-8350938, which suggests refactoring ResourceParsingClassHierarchyResolver to avoid inflating all UTF8 constant pool entries by using ClassReaderImpl. ClassReaderImpl stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed, so it seems to make sense to use here as a performance enhancement.

I have an initial prototype that removes manual parsing in getClassInfo() and instead constructs a ClassReaderImpl and uses its helper methods to return the needed class information.

One question before I try to move forward with contributing:
- ClassReaderImpl takes a ClassFile context. I used ClassFile.of() (a ClassFile context with default options). Is this the correct usage here, or should the resolver provide a more specific context?
I am also open to and would appreciate any other ideas or feedback on this implementation.

I?ve included the small patch below for reference.

Thanks for your help,
Trevor

diff --git a/src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java b/src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
index 5be14f42baa..463845ce612 100644
--- a/src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
+++ b/src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
@@ -30,7 +30,10 @@
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.UncheckedIOException;
+import java.lang.classfile.ClassFile;
 import java.lang.classfile.ClassHierarchyResolver;
+import java.lang.classfile.ClassReader;
+import java.lang.classfile.constantpool.ClassEntry;
 import java.lang.constant.ClassDesc;
 import java.util.Collection;
 import java.util.HashMap;
@@ -164,31 +167,12 @@ public ResourceParsingClassHierarchyResolver(Function<ClassDesc, InputStream> cl
         public ClassHierarchyResolver.ClassHierarchyInfo getClassInfo(ClassDesc classDesc) {
             var ci = streamProvider.apply(classDesc);
             if (ci == null) return null;
-            try (var in = new DataInputStream(new BufferedInputStream(ci))) {
-                in.skipBytes(8);
-                int cpLength = in.readUnsignedShort();
-                String[] cpStrings = new String[cpLength];
-                int[] cpClasses = new int[cpLength];
-                for (int i = 1; i < cpLength; i++) {
-                    int tag;
-                    switch (tag = in.readUnsignedByte()) {
-                        case TAG_UTF8 -> cpStrings[i] = in.readUTF();
-                        case TAG_CLASS -> cpClasses[i] = in.readUnsignedShort();
-                        case TAG_STRING, TAG_METHOD_TYPE, TAG_MODULE, TAG_PACKAGE -> in.skipBytes(2);
-                        case TAG_METHOD_HANDLE -> in.skipBytes(3);
-                        case TAG_INTEGER, TAG_FLOAT, TAG_FIELDREF, TAG_METHODREF, TAG_INTERFACE_METHODREF,
-                             TAG_NAME_AND_TYPE, TAG_DYNAMIC, TAG_INVOKE_DYNAMIC -> in.skipBytes(4);
-                        case TAG_LONG, TAG_DOUBLE -> {
-                            in.skipBytes(8);
-                            i++;
-                        }
-                        default -> throw new IllegalStateException("Bad tag (" + tag + ") at index (" + i + ")");
-                    }
-                }
-                boolean isInterface = (in.readUnsignedShort() & ACC_INTERFACE) != 0;
-                in.skipBytes(2);
-                int superIndex = in.readUnsignedShort();
-                var superClass = superIndex > 0 ? ClassDesc.ofInternalName(cpStrings[cpClasses[superIndex]]) : null;
+            try (ci) {
+                ClassReader reader = new ClassReaderImpl(ci.readAllBytes(), (ClassFileImpl) ClassFile.of());
+                boolean isInterface = (reader.flags() & ACC_INTERFACE) != 0;
+                ClassDesc superClass = reader.superclassEntry()
+                        .map(ClassEntry::asSymbol)
+                        .orElse(null);
                 return new ClassHierarchyInfoImpl(superClass, isInterface);
             } catch (IOException ioe) {
                 throw new UncheckedIOException(ioe);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251106/770accea/attachment.htm>

From darcy at openjdk.org  Thu Nov  6 05:02:15 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Nov 2025 05:02:15 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
Message-ID: <LbYfgV9Gms8dQZG--UOFnysoefCwXEDuQLHUpkToeMo=.d2d02520-bce0-44e2-ab93-fc48ed669f02@github.com>

On Fri, 24 Oct 2025 09:01:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework toString implementations

src/java.base/share/classes/java/lang/LazyConstant.java line 184:

> 182:  *          Use in static initializers may interact with class initialization order;
> 183:  *          cyclic initialization may result in initialization errors as described
> 184:  *          in {@jls 12.4} of <cite>The Java Language Specification</cite>.

Please use some text like "section" or "&sect;" in from of the `@jls` tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2497396558

From jpai at openjdk.org  Thu Nov  6 07:03:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Nov 2025 07:03:01 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <Har5mcp3Inx5L2GTgZREI0J59f5NU5--aWL1NehZ-ac=.0d3b6068-ad81-4fce-a168-581f3b35a0eb@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

Hello Justin, `jimage` code is maintained in core-libs area. I have added now that label to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28087#issuecomment-3495396990

From mbaesken at openjdk.org  Thu Nov  6 08:15:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Nov 2025 08:15:04 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly [v3]
In-Reply-To: <ZQeOuXAbP5kB2z1Rij8pJurBHbYGfSnI_1cxHCMUbzk=.28b7e2ae-f3f3-4206-b4ee-3d1b15169c33@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
 <ZQeOuXAbP5kB2z1Rij8pJurBHbYGfSnI_1cxHCMUbzk=.28b7e2ae-f3f3-4206-b4ee-3d1b15169c33@github.com>
Message-ID: <DjUANKuQAUCL_BY5KYqoMRy0r2xydk-emqFMs3UK9vY=.dd76a03a-a0d4-42d3-bcae-dd56c70998c3@github.com>

On Wed, 5 Nov 2025 22:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.
>> 
>> Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.
>> 
>>> Minimum supported client: 	Windows Vista
>>> Minimum supported server: 	Windows Server 2008
>
> Justin Lu 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 branch 'master' into JDK-8370420-Windows
>  - Merge branch 'master' into JDK-8370420-Windows
>  - Remove dynamic loading and call directly
>  - Merge branch 'master' into JDK-8370420-Windows
>  - init

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28119#pullrequestreview-3426812666

From alan.bateman at oracle.com  Thu Nov  6 09:33:45 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Thu, 6 Nov 2025 09:33:45 +0000
Subject: On throwing InterruptedException
In-Reply-To: <CAChcVunyDTzcTDXUUhzcXJAgD7NQKkZHS20hDuhHVy0KMwd+EA@mail.gmail.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <CAChcVukGQr5Q-thDix96GG+mdeVWgPkNac_nOjruT7_znjEpVw@mail.gmail.com>
 <CAChcVukNQKiMaubssDHuKBfdOBZO4zpKkqFo059jh5O9P8iHnw@mail.gmail.com>
 <CAChcVunyDTzcTDXUUhzcXJAgD7NQKkZHS20hDuhHVy0KMwd+EA@mail.gmail.com>
Message-ID: <e3d667fd-00e5-4b76-add4-2f472acbe111@oracle.com>



On 05/11/2025 23:10, Pavel Rappo wrote:
> And also this, which is a bit contrived but valid nonetheless:
>
>      } catch (InterruptedException e) { // good
>          throw new InterruptedException();
>
>      }
>
The good/bad table is fun. For completeness you can also add the case 
where someone restores the interrupt status and rethrows the 
InterruptedException (or throws a new InterruptedException). It would be 
strange to do this but no different to a double whammy where two parts 
of the system are requesting you to cancel/finish-up around the same time.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251106/9b094c03/attachment-0001.htm>

From alan.bateman at oracle.com  Thu Nov  6 09:37:13 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Thu, 6 Nov 2025 09:37:13 +0000
Subject: On throwing InterruptedException
In-Reply-To: <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>



On 05/11/2025 14:00, Remi Forax wrote:
> :
>
> If a thread is interrupted, it should stop ASAP.
> So if you catch InterruptedException and rethrow a new exception, this should be okay (as Alan said).
Rethrowing the InterruptedException is okay. Throwing a new exception 
that is not an InterruptedException is okay too but only after restoring 
the interrupted status, otherwise the thread might block again is some 
catch block as it unwinds.

-Alan

From alanb at openjdk.org  Thu Nov  6 09:47:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Nov 2025 09:47:42 GMT
Subject: RFR: 8367857: Implement JEP 525: Structured Concurrency (Sixth
 Preview) [v7]
In-Reply-To: <WxvoWLt25TKhLBNVb30MtFW7u4AkUrVMezcz3wjcH3g=.0654d0d0-e5f8-466c-95a2-bf49172b2127@github.com>
References: <WxvoWLt25TKhLBNVb30MtFW7u4AkUrVMezcz3wjcH3g=.0654d0d0-e5f8-466c-95a2-bf49172b2127@github.com>
Message-ID: <BwOOpXw8nu2yiOGUr3d9Y2pain8Y_ZbbI3S6NXwVY8I=.0222c9d3-f1e2-4393-8771-9dd5995a914b@github.com>

> Updates for JEP 525.
> 
> - `Joiner:onTimeout` is added  with `join` method changed to invoke this joiner method if
>   a timeout is configured and the timeout expires before or while waiting. The `onTimeout`
>   throws `TimeoutException` or may do nothing. This allows for `Joiner` implementation that
>   are capable of returning a result from the subtasks that complete before the timeout expires.
> - The `configFunction` parameter to the 3-arg `open` is changed from
>   `Function<Configuration, Configuration>` to `UnaryOperator<Configuration>`.
> - `Subtask::get` and `Subtask::exception` changed to consistently throw if called from
>   any thread before the scope owner has joined.
> - `StructuredTaskScope::join` is now specified so that it may be called again if interrupted.
> - The parameter on `Joiner::onFork` and `Joiner::onComplete` is changed from
>   `Subtask<? extends T` to `Subtask<T>`.
> - `Joiner.allSuccessOrThrow` is changed to return a list of results instead of a stream of
>   subtasks. `Joiner.allUntil` is changed to return a list of subtasks.
> - `Joiner.anySuccessfulResultOrThrow` is renamed to `anySuccessfulOrThrow`.
> - `Joiner.allUntil(Predicate)` is changed to allow `join` return the stream of all forked
> subtasks when the timeout expires.
> - `Joiner` is no longer a `@FunctionalInterface`.
> 
> Most of the changes are to API docs and tests. Some links are changed to use double hash mark.

Alan Bateman 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 21 additional commits since the last revision:

 - Sync up from loom repo
 - Merge branch 'master' into JDK-8367857
 - Merge branch 'master' into JDK-8367857
 - Make implSpec clearer
 - Reviewer feedback, sync up from loom repo
 - Merge branch 'master' into JDK-8367857
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8367857
 - Merge branch 'master' into JDK-8367857
 - Sync up from loom repo
 - ... and 11 more: https://git.openjdk.org/jdk/compare/a887a0a8...4822c8ba

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27392/files
  - new: https://git.openjdk.org/jdk/pull/27392/files/824cc5d2..4822c8ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27392&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27392&range=05-06

  Stats: 42646 lines in 481 files changed: 21428 ins; 18780 del; 2438 mod
  Patch: https://git.openjdk.org/jdk/pull/27392.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27392/head:pull/27392

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

From alanb at openjdk.org  Thu Nov  6 09:59:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Nov 2025 09:59:39 GMT
Subject: RFR: 8367857: Implement JEP 525: Structured Concurrency (Sixth
 Preview) [v8]
In-Reply-To: <WxvoWLt25TKhLBNVb30MtFW7u4AkUrVMezcz3wjcH3g=.0654d0d0-e5f8-466c-95a2-bf49172b2127@github.com>
References: <WxvoWLt25TKhLBNVb30MtFW7u4AkUrVMezcz3wjcH3g=.0654d0d0-e5f8-466c-95a2-bf49172b2127@github.com>
Message-ID: <RvJhidp99xIreWA0t3JO49Jzuyz3CvYPTctmIGgC6Es=.28a3cd7e-76a5-45dc-8158-fe9eed4c729b@github.com>

> Updates for JEP 525.
> 
> - `Joiner:onTimeout` is added  with `join` method changed to invoke this joiner method if
>   a timeout is configured and the timeout expires before or while waiting. The `onTimeout`
>   throws `TimeoutException` or may do nothing. This allows for `Joiner` implementation that
>   are capable of returning a result from the subtasks that complete before the timeout expires.
> - The `configFunction` parameter to the 3-arg `open` is changed from
>   `Function<Configuration, Configuration>` to `UnaryOperator<Configuration>`.
> - `Subtask::get` and `Subtask::exception` changed to consistently throw if called from
>   any thread before the scope owner has joined.
> - `StructuredTaskScope::join` is now specified so that it may be called again if interrupted.
> - The parameter on `Joiner::onFork` and `Joiner::onComplete` is changed from
>   `Subtask<? extends T` to `Subtask<T>`.
> - `Joiner.allSuccessOrThrow` is changed to return a list of results instead of a stream of
>   subtasks. `Joiner.allUntil` is changed to return a list of subtasks.
> - `Joiner.anySuccessfulResultOrThrow` is renamed to `anySuccessfulOrThrow`.
> - `Joiner.allUntil(Predicate)` is changed to allow `join` return the stream of all forked
> subtasks when the timeout expires.
> - `Joiner` is no longer a `@FunctionalInterface`.
> 
> Most of the changes are to API docs and tests. Some links are changed to use double hash mark.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into JDK-8367857
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8367857
 - Merge branch 'master' into JDK-8367857
 - Make implSpec clearer
 - Reviewer feedback, sync up from loom repo
 - Merge branch 'master' into JDK-8367857
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8367857
 - Merge branch 'master' into JDK-8367857
 - ... and 12 more: https://git.openjdk.org/jdk/compare/1b3889a4...11f6a18c

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

Changes: https://git.openjdk.org/jdk/pull/27392/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27392&range=07
  Stats: 839 lines in 6 files changed: 526 ins; 55 del; 258 mod
  Patch: https://git.openjdk.org/jdk/pull/27392.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27392/head:pull/27392

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

From alanb at openjdk.org  Thu Nov  6 09:59:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Nov 2025 09:59:41 GMT
Subject: RFR: 8367857: Implement JEP 525: Structured Concurrency (Sixth
 Preview) [v7]
In-Reply-To: <BwOOpXw8nu2yiOGUr3d9Y2pain8Y_ZbbI3S6NXwVY8I=.0222c9d3-f1e2-4393-8771-9dd5995a914b@github.com>
References: <WxvoWLt25TKhLBNVb30MtFW7u4AkUrVMezcz3wjcH3g=.0654d0d0-e5f8-466c-95a2-bf49172b2127@github.com>
 <BwOOpXw8nu2yiOGUr3d9Y2pain8Y_ZbbI3S6NXwVY8I=.0222c9d3-f1e2-4393-8771-9dd5995a914b@github.com>
Message-ID: <MmxyhwY_AqtVwRnvhWN8Ps2pBRC6m1PImammqF3cr34=.662bb87d-ee04-421d-a84a-45edcca1cfcd@github.com>

On Thu, 6 Nov 2025 09:47:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates for JEP 525.
>> 
>> - `Joiner:onTimeout` is added  with `join` method changed to invoke this joiner method if
>>   a timeout is configured and the timeout expires before or while waiting. The `onTimeout`
>>   throws `TimeoutException` or may do nothing. This allows for `Joiner` implementation that
>>   are capable of returning a result from the subtasks that complete before the timeout expires.
>> - The `configFunction` parameter to the 3-arg `open` is changed from
>>   `Function<Configuration, Configuration>` to `UnaryOperator<Configuration>`.
>> - `Subtask::get` and `Subtask::exception` changed to consistently throw if called from
>>   any thread before the scope owner has joined.
>> - `StructuredTaskScope::join` is now specified so that it may be called again if interrupted.
>> - The parameter on `Joiner::onFork` and `Joiner::onComplete` is changed from
>>   `Subtask<? extends T` to `Subtask<T>`.
>> - `Joiner.allSuccessOrThrow` is changed to return a list of results instead of a stream of
>>   subtasks. `Joiner.allUntil` is changed to return a list of subtasks.
>> - `Joiner.anySuccessfulResultOrThrow` is renamed to `anySuccessfulOrThrow`.
>> - `Joiner.allUntil(Predicate)` is changed to allow `join` return the stream of all forked
>> subtasks when the timeout expires.
>> - `Joiner` is no longer a `@FunctionalInterface`.
>> 
>> Most of the changes are to API docs and tests. Some links are changed to use double hash mark.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8367857
>  - Merge branch 'master' into JDK-8367857
>  - Make implSpec clearer
>  - Reviewer feedback, sync up from loom repo
>  - Merge branch 'master' into JDK-8367857
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8367857
>  - Merge branch 'master' into JDK-8367857
>  - Sync up from loom repo
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/c47ea121...4822c8ba

Update to fix small typo in docs, and resolve conflict with changes in JDK-8365699.

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

PR Comment: https://git.openjdk.org/jdk/pull/27392#issuecomment-3496263398

From vklang at openjdk.org  Thu Nov  6 10:06:08 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 6 Nov 2025 10:06:08 GMT
Subject: RFR: 8367857: Implement JEP 525: Structured Concurrency (Sixth
 Preview) [v8]
In-Reply-To: <RvJhidp99xIreWA0t3JO49Jzuyz3CvYPTctmIGgC6Es=.28a3cd7e-76a5-45dc-8158-fe9eed4c729b@github.com>
References: <WxvoWLt25TKhLBNVb30MtFW7u4AkUrVMezcz3wjcH3g=.0654d0d0-e5f8-466c-95a2-bf49172b2127@github.com>
 <RvJhidp99xIreWA0t3JO49Jzuyz3CvYPTctmIGgC6Es=.28a3cd7e-76a5-45dc-8158-fe9eed4c729b@github.com>
Message-ID: <cRsYfI2MqM6OG1lnHelTr7iEpZyiDetudipBM7AFWw8=.1b427c7e-ef41-4614-b915-3b86880de3d1@github.com>

On Thu, 6 Nov 2025 09:59:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates for JEP 525.
>> 
>> - `Joiner:onTimeout` is added  with `join` method changed to invoke this joiner method if
>>   a timeout is configured and the timeout expires before or while waiting. The `onTimeout`
>>   throws `TimeoutException` or may do nothing. This allows for `Joiner` implementation that
>>   are capable of returning a result from the subtasks that complete before the timeout expires.
>> - The `configFunction` parameter to the 3-arg `open` is changed from
>>   `Function<Configuration, Configuration>` to `UnaryOperator<Configuration>`.
>> - `Subtask::get` and `Subtask::exception` changed to consistently throw if called from
>>   any thread before the scope owner has joined.
>> - `StructuredTaskScope::join` is now specified so that it may be called again if interrupted.
>> - The parameter on `Joiner::onFork` and `Joiner::onComplete` is changed from
>>   `Subtask<? extends T` to `Subtask<T>`.
>> - `Joiner.allSuccessOrThrow` is changed to return a list of results instead of a stream of
>>   subtasks. `Joiner.allUntil` is changed to return a list of subtasks.
>> - `Joiner.anySuccessfulResultOrThrow` is renamed to `anySuccessfulOrThrow`.
>> - `Joiner.allUntil(Predicate)` is changed to allow `join` return the stream of all forked
>> subtasks when the timeout expires.
>> - `Joiner` is no longer a `@FunctionalInterface`.
>> 
>> Most of the changes are to API docs and tests. Some links are changed to use double hash mark.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into JDK-8367857
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8367857
>  - Merge branch 'master' into JDK-8367857
>  - Make implSpec clearer
>  - Reviewer feedback, sync up from loom repo
>  - Merge branch 'master' into JDK-8367857
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8367857
>  - Merge branch 'master' into JDK-8367857
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/1b3889a4...11f6a18c

Marked as reviewed by vklang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27392#pullrequestreview-3427300979

From pavel.rappo at gmail.com  Thu Nov  6 10:24:12 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Thu, 6 Nov 2025 10:24:12 +0000
Subject: On throwing InterruptedException
In-Reply-To: <e3d667fd-00e5-4b76-add4-2f472acbe111@oracle.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <CAChcVukGQr5Q-thDix96GG+mdeVWgPkNac_nOjruT7_znjEpVw@mail.gmail.com>
 <CAChcVukNQKiMaubssDHuKBfdOBZO4zpKkqFo059jh5O9P8iHnw@mail.gmail.com>
 <CAChcVunyDTzcTDXUUhzcXJAgD7NQKkZHS20hDuhHVy0KMwd+EA@mail.gmail.com>
 <e3d667fd-00e5-4b76-add4-2f472acbe111@oracle.com>
Message-ID: <CAChcVukMQGWEKnvrzf-XiiSuZ12bkc0=B33fNU-iqdC55NKsZw@mail.gmail.com>

For absolute clarity, I think Alan is talking about these:

    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw e;
    }

    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new InterruptedException();
    }

In each of these, a single interruption is signalled twice. I think it
should be avoided as confusing. But like Alan said, in effect it's no
different from concurrent interrupts.

FWIW, I think robust code should be idempotent in respect to
interruption. It's not a three-strike system or some such. A single
interrupt should (eventually) have the same effect as any number of
them.

On Thu, Nov 6, 2025 at 9:34?AM Alan Bateman <alan.bateman at oracle.com> wrote:
>
>
>
> On 05/11/2025 23:10, Pavel Rappo wrote:
>
> And also this, which is a bit contrived but valid nonetheless:
>
>     } catch (InterruptedException e) { // good
>         throw new InterruptedException();
>
>     }
>
> The good/bad table is fun. For completeness you can also add the case where someone restores the interrupt status and rethrows the InterruptedException (or throws a new InterruptedException). It would be strange to do this but no different to a double whammy where two parts of the system are requesting you to cancel/finish-up around the same time.
>
> -Alan

From daniel.peintner at gmail.com  Thu Nov  6 10:51:26 2025
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Thu, 6 Nov 2025 11:51:26 +0100
Subject: [External] : Re: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <7aa147c9-108e-4194-be46-84399000578a@oracle.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
 <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
 <CAAoP7T7XG_zWj0GSM37oMMvPq=NJ300Aac9skq8erXjYzqvmqw@mail.gmail.com>
 <98fc3c7c-d485-487b-9ab5-f4257c40cacf@oracle.com>
 <CAAoP7T5PfnKaF6XFGaUcrBSUxQ58=eOKwSLkj+4rVPdQOL-FTQ@mail.gmail.com>
 <7aa147c9-108e-4194-be46-84399000578a@oracle.com>
Message-ID: <CAAoP7T5RubQqdUGuH9M-sYZVMzA0j8mx2Kd2kHbVDeBzLMXhYg@mail.gmail.com>

Alexey, all,

Thank you very much for your help.
I still have issues making it to work, and I shared logs privately.

Anyhow, some general comments/suggestions.

You are right, with JDK21 it was enough to state  "--mac-sign"option, and
it picked the (only/correct) certificate (in my case).

As I understand, with JDK25 this is no longer the case. I don't want to
argue whether the *old* or *new* way is preferred. However, it is a
breaking change.
Hence, what I may suggest, though, is that it throw errors if the expected
information (i.e.,  "--mac-signing-key-user-name") is missing. Otherwise, a
developer doesn't know that there is a problem.

The same goes to situations when it is not unique which certificate to
pick. You pointed me to [1] which fixes the problem that I can find the
certificate with *partial* information without the need to specify the full
--mac-signing-key-user-name.
In situations where there are more matches, I would argue the process
should fail again with an error message hinting the problem (e.g.,
certificate not uniquely identifiable). Looking at [2] I don't think this
is the case.

Thank you very much for your continuous support!

-- Daniel

[1] https://bugs.openjdk.org/browse/JDK-8371094
[2]
https://github.com/openjdk/jdk/commit/0555f6228c59c6739b8b824d64eb6c1545a5520a



On Wed, Nov 5, 2025 at 7:31?PM Alexey Semenyuk <alexey.semenyuk at oracle.com>
wrote:

> Daniel,
>
> I've commented on the logs you shared privately. Adding some thoughts to
> the mail list.
>
> jpackage configuration at [1] is missing "--mac-signing-key-user-name" or
> "--mac-app-image-sign-identity" option. I noted it the private email as
> well.
> At first I assumed it was a mistake, but then I came across an old thread
> about the very same jpackage issue at [2] where you state that "--mac-sign"
> option is sufficient to make jpackage find the signing identity. So this is
> intentional.
>
> jdk25 jpackage will not look up for the signing identity unless
> "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option is
> specified. I'm surprised it did in older releases.
>
> For the sake of backward compatibility we can restore this behavior. But I
> think jpackage should exit with an error if the "--mac-sign" option is
> specified, but neither "--mac-signing-key-user-name" nor
> "--mac-app-image-sign-identity" is. The old behavior, when without these
> options jpackage picked the first available certificate with the common
> name starting with "Developer ID Application: " substring is not secure. It
> literally tells jpackage to pick any certificate without any filtering. If
> there is only one such certificate installed and it gets replaced, you will
> not even notice that your app is signed with a different certificate.
>
> I suggest you add "--mac-signing-key-user-name" or
> "--mac-app-image-sign-identity" option to jpackage command line at [1] to
> make it work.
>
> [1]
> https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151
> [2]
> https://mail.openjdk.org/pipermail/core-libs-dev/2021-August/080291.html
>
> - Alexey
>
> On 11/5/2025 4:16 AM, Daniel Peintner wrote:
>
> Hi Alexey,
>
> Thank you for your reply.
>
> Does the warning message resembles the one at [1]?
>>
>
> Yes, exactly.
>
>
>> I think your evaluation that the step 1 failed is correct. I'd suggest
>> adding "--verbose" option to the step 1 command line to get more details.
>>
>
> I updated a demo/test project to demonstrate the problem. You can now also
> try it yourself.
> https://github.com/danielpeintner/Java11Test/tree/non-modular
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMJdEvoaQ$>
>
> There you can also find the 3 jpackage commands I use
>
> https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle*L148-L151__;Iw!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMSE1bEoY$>
>
> W.r.t. sharing the logs file. I will send them to you *privately*. I
> quickly scanned them and I would rather not have them on the reflector.
>
> The weird thing is, that the difference seems to happen in step 1. Anyhow,
> running these commands the difference is also somehow in step 2 where
> * JDK21 makes popping up a dialog which asks me whether I want to allow
> access to my keys
> * JDK25 does not need any interaction
>
> I hope this helps to find the "difference".
>
> Thanks,
>
> -- Daniel
>
>
>
>
>
>>
>> [1]
>> https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties#L85
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties*L85__;Iw!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMd-s2VkQ$>
>>
>> - Alexey
>>
>> On 11/4/2025 12:32 PM, Daniel Peintner wrote:
>>
>> Hi Alexey, all,
>>
>> I nailed down the problem to the following, which seems to differ between
>> JDK25 and JDK21.
>> Maybe this helps to reproduce the issue.
>>
>> jpackage is called 3 times in my process
>>
>>    1. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>    --type app-image --input
>>    /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib
>>    --main-jar myPROJECT-25.11.03.jar --main-class
>>    eu.my_company.myproject.Launcher --dest
>>    /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT
>>    --app-version 25.11.03 --runtime-image
>>    /Users/daniel/Documents/GitHub/myPROJECT/build/jre --java-options
>>    --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED
>>    --java-options --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED
>>    --java-options
>>    --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED
>>    --java-options
>>    --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED
>>    --java-options
>>    --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED
>>    --java-options --add-exports=java.management/javax.management=ALL-UNNAMED
>>    --java-options
>>    --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED
>>    --java-options --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED
>>    --icon src/main/deploy/package/macosx/myPROJECT.icns
>>    --mac-package-identifier eu.my-company.myproject --mac-sign
>>
>>    2. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>    --type pkg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>    --name myPROJECT --app-version 25.11.03 --app-image
>>    /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>>    --file-associations src/main/resources/associations.properties
>>    --app-version 25.11.03 --vendor "My Company" --copyright "My Company"
>>    --mac-sign
>>
>>    3. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>    --type dmg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>    --name myPROJECT --app-version 25.11.03 --app-image
>>    /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>>    --file-associations src/main/resources/associations.properties
>>    --app-version 25.11.03 --vendor "My Company" --copyright "My Company"
>>    --mac-sign
>>
>>
>> First it creates the app-image and afterwards it creates pkg and dmg and
>> signs it.
>>
>> As you can see in the 3 commands, it uses JDK21.
>> Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after step 2
>> already with the following message in German
>>
>> Warnung: Nicht signiertes app-image wird zum Erstellen von signiertem pkg
>> verwendet.
>>
>> It translates to something like: it tries to sign pkg and complains that
>> the app-image is not signed.
>> Hence, somehow step 1 failed already but does not show any error/warning.
>>
>> Please let me know whether the above helps to reproduce the issue.
>>
>> Thanks,
>>
>> -- Daniel
>>
>>
>>
>> On Tue, Nov 4, 2025 at 4:01?PM Daniel Peintner <daniel.peintner at gmail.com>
>> wrote:
>>
>>> Hi Alexey,
>>>
>>> Thank you for your reply.
>>> I am using the badass runtime plugin which calls jpackage under the hood.
>>>
>>> While trying to create an example project, I noticed that there were
>>> some changes
>>> '--mac-package-identifier' needs to go into imageOptions and
>>> not installerOptions.
>>> see
>>> https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385
>>> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-K4xefEo$>
>>>
>>> That fixed the problem with jpackage. Anyhow, it still does not work
>>> with JDK25 and macOS signing.
>>> Using the JDK25 seems to need additional options (compared to JDK21).
>>>
>>> With JDK25 and --mac-sign the process no longer opens the KeyChain
>>> access and asks for the credentials. Hence, the image itself is no longer
>>> signed which matches with what I see on the debug console
>>> "non signed app-image used to sign dmg"  ... freely translated into
>>> English since I see the German version only
>>>
>>> Therefore, apple's notary service says invalid with the logs like "The
>>> binary is not signed with a valid Developer ID certificate".
>>>
>>> Using the *same* gradle file, switching to JDK21 works without any
>>> issues again.
>>> I will try to investigate further.
>>>
>>> Thanks,
>>>
>>> -- Daniel
>>>
>>>
>>>
>>>
>>> On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk <
>>> alexey.semenyuk at oracle.com> wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>> I can not reproduce the issue you experience with jdk25.0.1:
>>>>
>>>> ---
>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest
>>>> output --type app-image --main-jar hello.jar --main-class
>>>> com.my_domain.project.Hello --mac-package-identifier com.my-domain.project
>>>> $ echo $?
>>>> 0
>>>> ---
>>>>
>>>> If I run the same command line without ` --mac-package-identifier`
>>>> option it fails as expected:
>>>> ---
>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest
>>>> output --type app-image --main-jar hello.jar --main-class
>>>> com.my_domain.project.Hello
>>>> Bundler Mac Application Image skipped because of a configuration
>>>> problem: invalid mac bundle identifier [com.my_domain.project].
>>>> Advice to fix: specify identifier with "--mac-package-identifier".
>>>> ---
>>>>
>>>> The same failure for `--mac-package-identifier com.my_domain.project`
>>>> (with the underscore):
>>>> ---
>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest
>>>> output --type app-image --main-jar hello.jar --main-class
>>>> com.my_domain.project.Hello --mac-package-identifier com.my_domain.project
>>>> Bundler Mac Application Image skipped because of a configuration
>>>> problem: invalid mac bundle identifier [com.my_domain.project].
>>>> Advice to fix: specify identifier with "--mac-package-identifier".
>>>> ---
>>>>
>>>> Any chance you accidentally put the string with the underscore instead
>>>> of the hyphen as a value of the `--mac-package-identifier` option on your
>>>> command line?
>>>>
>>>> - Alexey
>>>>
>>>> On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am about to switch a JavaFX project from JDK21 to JDK25 and I noticed
>>>> a problem when running jpackage.
>>>>
>>>> My domain has a hyphen, like in www.my-domain.com
>>>> <https://urldefense.com/v3/__http://www.my-domain.com__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-KS5-g-8$>
>>>> Hence, my Java package reads like this: com.my_domain.project
>>>> Note: hyphen becomes underscore.
>>>>
>>>> Running vanilla jpackage in JDK21 complained with
>>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>>> due to the *invalid* underscore and suggests me to use
>>>> "--mac-package-identifier"
>>>>
>>>> Hence, I added --mac-package-identifier com.my-domain.project (with the
>>>> hyphen again)
>>>> All good so far.
>>>>
>>>> Running the same code with JDK25 with the above settings shows the
>>>> error message again
>>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>>>
>>>> I can add any argument to  --mac-package-identifier
>>>> It seems it is simply not taken into account.
>>>>
>>>> I am using JDK 25.0.1
>>>>
>>>> Is this a known issue with JDK25 and jpackage?
>>>> Is there any other way to make jpackage work?
>>>>
>>>> Thanks,
>>>>
>>>> -- Daniel
>>>>
>>>>
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251106/0b2ab808/attachment-0001.htm>

From alanb at openjdk.org  Thu Nov  6 11:10:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Nov 2025 11:10:09 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking
In-Reply-To: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
Message-ID: <Z6SvKuabfL_PGQs1a0FY9AZasVdpNFSmLqydcAbqS3M=.05da86cb-2619-46b0-afe1-d2bec04739b3@github.com>

On Wed, 5 Nov 2025 17:41:44 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> This PR include build changes from @magicus and jlink change to verify the build signature.
> 
> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
> 
> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>                                                                                                                                                                  
> ? java --version
> openjdk 26-internal 2026-03-17
> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>                                                                                                                                                                  
> ? jlink --version                                                                       
> 26-internal
>                                                                                                                                                                  
> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>                                                                                                                                                                  
> ? jlink --add-modules java.base --output macos
>                                                             
> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>                                                                                                                                                                  
> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

I'm puzzling as to why the resource has to be saved in the jdk.jlink module. When cross linking, jlink should only need to check the company/version of java.base in the current image vs. company/version of the java.base found on the module path.

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

PR Comment: https://git.openjdk.org/jdk/pull/28155#issuecomment-3496614334

From jvernee at openjdk.org  Thu Nov  6 11:42:32 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Nov 2025 11:42:32 GMT
Subject: RFR: 8371315: java/foreign/sharedclosejfr/TestSharedCloseJFR.java
 failed with -XX:-TieredCompilation
Message-ID: <6uxmGNjwdkz4zRsIv2Yn8fgzbFbo-uO9cmv50lH7uzY=.542706bd-425c-4463-a39e-850e04e73137@github.com>

Borrowed from the original `InternalErrorTest` which this test was based on, disabling compilation of the main method fixes this issue. (I've found that `-XX:-UseOnStackReplacement` works as well, which effectively does the same thing).

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

Commit messages:
 - Disable compilation of main method

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

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

From lancea at openjdk.org  Thu Nov  6 14:04:33 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Nov 2025 14:04:33 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v9]
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: <g4H5VfJ-Rqx9PFrrQ6_McNZNaVe7eI9sY86y1riNGgc=.ee9efab8-8bec-452c-9bb8-2aaba80ef2c9@github.com>

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Updates based on internal discussions and CSR suggested wordsmithing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27693/files
  - new: https://git.openjdk.org/jdk/pull/27693/files/385dc016..ee8e6bd4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27693&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27693&range=07-08

  Stats: 1858 lines in 16 files changed: 1445 ins; 295 del; 118 mod
  Patch: https://git.openjdk.org/jdk/pull/27693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27693/head:pull/27693

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

From lancea at openjdk.org  Thu Nov  6 14:22:40 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Nov 2025 14:22:40 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v10]
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: <6KMJBNIUuyO002oWj1R-UpJatEtmAIxS2A-haONaGh4=.9877a510-2dc3-4d74-ba06-a1a88bfae019@github.com>

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra space in copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27693/files
  - new: https://git.openjdk.org/jdk/pull/27693/files/ee8e6bd4..8ccfcdf9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27693&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27693&range=08-09

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

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

From alanb at openjdk.org  Thu Nov  6 14:29:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Nov 2025 14:29:07 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v10]
In-Reply-To: <6KMJBNIUuyO002oWj1R-UpJatEtmAIxS2A-haONaGh4=.9877a510-2dc3-4d74-ba06-a1a88bfae019@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 <6KMJBNIUuyO002oWj1R-UpJatEtmAIxS2A-haONaGh4=.9877a510-2dc3-4d74-ba06-a1a88bfae019@github.com>
Message-ID: <dgOvIohO4UCs9xmOxOEVP03aXeAhlcFwppX4FFueyBU=.44785f42-19bc-4206-aab9-318251b2b1c3@github.com>

On Thu, 6 Nov 2025 14:22:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra space in copyright header

I through went several iterations of the API docs with Lance, all good there. I have not reviewed SQLUtils or the tests.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27693#pullrequestreview-3428455352

From liach at openjdk.org  Thu Nov  6 15:48:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Nov 2025 15:48:46 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
 [v3]
In-Reply-To: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
References: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
Message-ID: <g_cuWHVBU-hfRhN4dB4jWUkhai3q5Q91LL1H2UJhKuI=.688311a5-a860-449a-bd11-b02056439f9d@github.com>

> java.lang.reflect.Proxy has some surprising behaviors associated with protected methods in Object, covariant/contravariant overrides in interfaces, and package-private types in method signatures. Such behaviors should have tests, so that they are not accidentally perturbed in Proxy updates.

Chen Liang 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 six additional commits since the last revision:

 - Consolidate duplicate tests
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
 - Tweaks
 - 8370839: Tests to verify peculiar Proxy dispatching behaviors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28023/files
  - new: https://git.openjdk.org/jdk/pull/28023/files/1c6bba31..3b8c6d2a

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

  Stats: 72120 lines in 1027 files changed: 38899 ins; 27733 del; 5488 mod
  Patch: https://git.openjdk.org/jdk/pull/28023.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28023/head:pull/28023

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

From bpb at openjdk.org  Thu Nov  6 16:04:28 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Nov 2025 16:04:28 GMT
Subject: Integrated: 8367943: PipedOutputStream write(0,
 0) successful after close()
In-Reply-To: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
References: <V8G-H9C3Bpeq1hUZzF-SJIeML-SNGc0bnVcvmYEyJkQ=.71659e8e-d5a3-421a-be6b-2522e2d3a240@github.com>
Message-ID: <BMthHI4O5PXoyjg0ujleTXOkyCwejlyVBw1oCf2dIQQ=.6e9109a1-8a42-4978-882c-8dccac1537a0@github.com>

On Thu, 30 Oct 2025 23:41:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.

This pull request has now been integrated.

Changeset: 13211865
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1321186547bddd3f8615cf5d110489ec383f47ab
Stats:     33 lines in 2 files changed: 13 ins; 3 del; 17 mod

8367943: PipedOutputStream write(0, 0) successful after close()

Reviewed-by: rriggs, jpai

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

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

From bpb at openjdk.org  Thu Nov  6 16:04:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Nov 2025 16:04:27 GMT
Subject: Integrated: 8355342: File.getCanonicalPath on Java 24 resolves paths
 on network drives to UNC format
In-Reply-To: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
References: <VQZQI1VZ8lZSognaM-SglcJJvtK4JpBUun6XEdPfPCw=.af8dd319-a8c5-4662-ac44-1db03a830d4c@github.com>
Message-ID: <1EG0zxotrDW1k1F0LNJS9jpVhIziisD5bb495lLNcjY=.9958858c-c55f-4156-a062-840278812a23@github.com>

On Tue, 16 Sep 2025 21:13:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

This pull request has now been integrated.

Changeset: 1f08a3ed
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f08a3ede2445fb05d9700a1293d681ca89cbf5b
Stats:     176 lines in 4 files changed: 117 ins; 35 del; 24 mod

8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format

Reviewed-by: alanb

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

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

From jlu at openjdk.org  Thu Nov  6 17:12:34 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Nov 2025 17:12:34 GMT
Subject: RFR: 8370420: HostLocaleProviderAdapter_md.c from libjava can use
 GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly [v3]
In-Reply-To: <ZQeOuXAbP5kB2z1Rij8pJurBHbYGfSnI_1cxHCMUbzk=.28b7e2ae-f3f3-4206-b4ee-3d1b15169c33@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
 <ZQeOuXAbP5kB2z1Rij8pJurBHbYGfSnI_1cxHCMUbzk=.28b7e2ae-f3f3-4206-b4ee-3d1b15169c33@github.com>
Message-ID: <6fZEpffL-VLzAHZ1pstX_i-KlEjYev4CPGyYv2cJMDk=.83c45c0e-9051-47e6-920a-a23748313de7@github.com>

On Wed, 5 Nov 2025 22:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.
>> 
>> Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.
>> 
>>> Minimum supported client: 	Windows Vista
>>> Minimum supported server: 	Windows Server 2008
>
> Justin Lu 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 branch 'master' into JDK-8370420-Windows
>  - Merge branch 'master' into JDK-8370420-Windows
>  - Remove dynamic loading and call directly
>  - Merge branch 'master' into JDK-8370420-Windows
>  - init

Thank you all for the reviews and suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/28119#issuecomment-3498417066

From jlu at openjdk.org  Thu Nov  6 17:15:45 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Nov 2025 17:15:45 GMT
Subject: Integrated: 8370420: HostLocaleProviderAdapter_md.c from libjava can
 use GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly
In-Reply-To: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
References: <Z1dZZw56tLdc3B3htVp4GQAKcSm3n4SV7EpRvzpf-JE=.499dcc2c-15ce-4d72-b0f0-456d80ae6d7e@github.com>
Message-ID: <8yUS7ZLAkcQ23T1qnXzqdWyeE0Nm3k3yG1_X2vTPkZ4=.cb20a15d-961b-4a3c-bc63-11e4de66d943@github.com>

On Mon, 3 Nov 2025 23:48:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR cleans up some native code for Windows i18n functions. These particular calls are designed to run on Windows Vista and later. Since Vista (and older) are not supported Windows platforms, the calls no longer need to be checked if they are supported and can be called directly.
> 
> Reference to docs: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex.
> 
>> Minimum supported client: 	Windows Vista
>> Minimum supported server: 	Windows Server 2008

This pull request has now been integrated.

Changeset: 0026967e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0026967e030fd4557b5365870d55f863fe2a4512
Stats:     90 lines in 2 files changed: 6 ins; 63 del; 21 mod

8370420: HostLocaleProviderAdapter_md.c from libjava can use GetLocaleInfoEx, GetCalendarInfoEx, EnumCalendarInfoExEx directly

Reviewed-by: naoto, mbaesken, bpb

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

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

From bpb at openjdk.org  Thu Nov  6 17:24:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Nov 2025 17:24:54 GMT
Subject: RFR: 8370216: Fix of new File("").exists() causes undefined behavior
 in libraries
Message-ID: <UlWA6NspyDBtVQEyD9V1UiyDp1Qn1nQznVk4q4Gx7E4=.82f7e8e0-9c11-49ff-8458-65ae70265d94@github.com>

Add a system property, `jdk.io.File.failIfEmptyPath`, which when `true` reverts to legacy, pre-JDK 25 behavior, as to how `java.io.File` handles an empty pathname string.

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

Commit messages:
 - 8370216: Fix of new File().exists() causes undefined behavior in libraries

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

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

From bpb at openjdk.org  Thu Nov  6 17:24:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Nov 2025 17:24:55 GMT
Subject: RFR: 8370216: Fix of new File("").exists() causes undefined
 behavior in libraries
In-Reply-To: <UlWA6NspyDBtVQEyD9V1UiyDp1Qn1nQznVk4q4Gx7E4=.82f7e8e0-9c11-49ff-8458-65ae70265d94@github.com>
References: <UlWA6NspyDBtVQEyD9V1UiyDp1Qn1nQznVk4q4Gx7E4=.82f7e8e0-9c11-49ff-8458-65ae70265d94@github.com>
Message-ID: <m6S9I4eJl8BDoXmIYuwavnKcOt1snjxpISqdxDO5aj8=.941c1dd4-1d70-4cbf-b824-354de1368283@github.com>

On Wed, 5 Nov 2025 18:14:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a system property, `jdk.io.File.failIfEmptyPath`, which when `true` reverts to legacy, pre-JDK 25 behavior, as to how `java.io.File` handles an empty pathname string.

The implementation modification which resolved [JDK-8024695](https://bugs.openjdk.org/browse/JDK-8024695) caused a `java.io.File` created from the empty string `""` to be treated as if the file was created from the pathname string of the current working directory, `System.getProperty("user.dir")`. This change caused failures in code which relied on the inconsistent, undocumented behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/28158#issuecomment-3492681612

From mcimadamore at openjdk.org  Thu Nov  6 17:32:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 6 Nov 2025 17:32:14 GMT
Subject: RFR: 8371315: java/foreign/sharedclosejfr/TestSharedCloseJFR.java
 failed with -XX:-TieredCompilation
In-Reply-To: <6uxmGNjwdkz4zRsIv2Yn8fgzbFbo-uO9cmv50lH7uzY=.542706bd-425c-4463-a39e-850e04e73137@github.com>
References: <6uxmGNjwdkz4zRsIv2Yn8fgzbFbo-uO9cmv50lH7uzY=.542706bd-425c-4463-a39e-850e04e73137@github.com>
Message-ID: <JnU21NdSnInhHI_NhvWLjJkkFZXW5qv2IX7WLNXD7M8=.9dba6f46-31e9-4fd1-b51d-1418f1e1a717@github.com>

On Wed, 5 Nov 2025 12:30:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Borrowed from the original `InternalErrorTest` which this test was based on, disabling compilation of the main method fixes this issue. (I've found that `-XX:-UseOnStackReplacement` works as well, which effectively does the same thing).

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28149#pullrequestreview-3429545349

From bpb at openjdk.org  Thu Nov  6 18:46:18 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Nov 2025 18:46:18 GMT
Subject: RFR: 8191963: Path.equals() and File.equals() return true for two
 different files on Windows [v3]
In-Reply-To: <NCo0xUhjlO0iyFcgAUTO-qCeNav5SCe6kidCLwUqIsw=.3aaab032-8c6d-4b8f-abbf-3d260955c963@github.com>
References: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>
 <NCo0xUhjlO0iyFcgAUTO-qCeNav5SCe6kidCLwUqIsw=.3aaab032-8c6d-4b8f-abbf-3d260955c963@github.com>
Message-ID: <oQxZ3D3wOlZsieJcgun--86PUuy_ctnnPN7e0vVZwig=.bdff1977-0afd-4038-8fc3-cb59e6d4bcc1@github.com>

On Tue, 14 Oct 2025 20:55:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from `sun.nio.fs.WindowsPath.compareTo(Path)`.
>
> Brian Burkhalter 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:
> 
>  - 8191963: Make legacy behavior be the default
>  - Merge
>  - 8191963: Add system property to enable legacy behavior
>  - Merge
>  - 8191963: Path.equals() and File.equals() return true for two different files on Windows

The associated issue has been closed as Won't Fix hence this request is being closed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-3498873974

From bpb at openjdk.org  Thu Nov  6 18:46:20 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Nov 2025 18:46:20 GMT
Subject: Withdrawn: 8191963: Path.equals() and File.equals() return true for
 two different files on Windows
In-Reply-To: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>
References: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>
Message-ID: <P-AiZDg4Mtl35FJq4saMuV_D9VPzL1R12NBgOxBtK00=.c371f288-ff7c-47ea-a31e-db13112a80e4@github.com>

On Thu, 12 Jun 2025 21:12:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from `sun.nio.fs.WindowsPath.compareTo(Path)`.

This pull request has been closed without being integrated.

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

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

From stuart.marks at oracle.com  Thu Nov  6 18:48:51 2025
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 6 Nov 2025 10:48:51 -0800
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlByb3Bvc2UgdG8gcmVtb3ZlIHN1cHBvcnQgZm9y?=
 =?UTF-8?Q?_CompactStrings_off?=
In-Reply-To: <09039475-af3e-43ed-8d6b-8e7678a2a053@oracle.com>
References: <b27a2c9d-d268-4489-8b57-920090635dca.shaojin.wensj@alibaba-inc.com>
 <f46d0109-3dbe-4764-8c52-0b3843c85195@oracle.com>
 <08d048b2-5eb1-4db1-a169-a45e9f617b62.shaojin.wensj@alibaba-inc.com>
 <d26f06b5-cc53-4ec4-97bd-69eb9944f779@oracle.com>
 <09039475-af3e-43ed-8d6b-8e7678a2a053@oracle.com>
Message-ID: <42963962-8763-46b7-aa7a-631838324efd@oracle.com>

Hi wenshao,

I've written up a draft JEP for deprecating the disabling of Compact Strings. There 
hasn't been a good term for running the system with Compact Strings disabled, so I 
made up a term "UTF-16-only" and used it here.

https://openjdk.org/jeps/8371379

I also filed an enhancement to cover the change to add a warning message when 
-XX:-CompactStrings is used, and I've assigned it to you (wenshao). Not that this 
change can't be integrated until the JEP is moved into the Targeted state.

https://bugs.openjdk.org/browse/JDK-8371431

You might want to associate PR 27995 with this bug report.

s'marks

On 11/3/25 10:04 PM, Stuart Marks wrote:
>
> Hi wenshao,
>
> I think removing Compact Strings is a great idea! As you noted in your first 
> message, removing it would make String easier to maintain. Just so that everybody 
> here understands the issues, every string algorithm has THREE implementations:
>
> 1. compact strings enabled, using ISO Latin 1 coder
>
> 2. compact strings enabled, using UTF-16 coder
>
> 3. compact strings disabled
>
> In recent years I suspect our test coverage of the compact-strings disabled case 
> is lacking, as some bugs have occurred in only that case. For example, see 
> JDK-8321514 <https://bugs.openjdk.org/browse/JDK-8321514>, JDK-8316879 
> <https://bugs.openjdk.org/browse/JDK-8316879>, JDK-8360271 
> <https://bugs.openjdk.org/browse/JDK-8360271>, JDK-8360255 
> <https://bugs.openjdk.org/browse/JDK-8360255>, JDK-8221430 
> <https://bugs.openjdk.org/browse/JDK-8221430>, etc. (Some of these have been 
> fixed, but some are still open.)
>
> As Alan noted, however, we can't simply remove this case. We also can't simply 
> deprecate the command-line option; we need to deprecate the feature of running 
> without Compact Strings before we can remove that feature.
>
> Compact Strings were introduced with JEP 254 <https://openjdk.org/jeps/254>. The 
> JEP doesn't mention that there is an option to disable compact strings, but the 
> JVM Guide 
> <https://docs.oracle.com/en/java/javase/25/vm/java-hotspot-virtual-machine-performance-enhancements.html#GUID-D2E3DC58-D18B-4A6C-8167-4A1DFB4888E4> 
> describes the Compact Strings feature and also the ability to disable it using the 
> -XX:-CompactStrings command line option. This section doesn't say much about when 
> you might want to disable the feature, though; it merely says "This feature can be 
> disabled if you observe performance regression issues in an application." Articles 
> like this one from Baeldung <https://www.baeldung.com/java-9-compact-string>, and 
> vendor documentation from IBM 
> <https://www.ibm.com/docs/en/sdk-java-technology/8?topic=options-xx-compactstrings> 
> also document this option, but they offer similarly vague advice.
>
> Since the option is fairly well-known, it's not merely a matter of looking at the 
> status of the various ports (though those are significant, of course). It could be 
> that some installations out there running with option to disable compact strings, 
> perhaps if they encountered a performance regression, or for other reasons. 
> They'll need to be informed that the feature is going away, and the best way to do 
> that is with a JEP.
>
> There are some additional issues to consider as well.
>
>   * As Alan noted,? the ARM32 port has compact strings disabled by default. It's
>     not clear whether it even works if compact strings are enabled.
>   * Compact strings increases storage requirements of CJK character data. Our
>     /assumption/ has been that even CJK-heavy applications use a lot of ASCII data
>     for config files, message headers, JSON, etc., and that compact strings are
>     still a net win for such applications. However, that's an assumption. There's
>     the possibility that some installation run those applications with compact
>     strings disabled.
>   * The JNI GetStringCritical call returns a direct pointer in the non compact
>     strings case but makes a copy when compact strings are enabled. Some
>     applications may suffer regressions because of this; see this Stack Overflow
>     <https://stackoverflow.com/questions/76913323/string-compact-has-introduced-some-performance-issues-for-the-current-jni-how>
>     question.
>
> There are probably some other issues we haven't considered yet. The best way to 
> flush them out is to post a JEP, and then use other channels to publicize the JEP. 
> The JEP is mostly a formality about changing the official status of running in the 
> compact-strings-disabled mode to "deprecated". Even though it seems like a lot of 
> overhead to write a JEP for this, the fact is that many people in the tech press 
> look only at the list of JEPs for each release and not much else. Any many Java 
> users look only at tech publications to keep up with Java; they don't look at 
> GitHub or follow the OpenJDK mailing lists. Thus, posting a JEP is the best chance 
> we have to reach a broad set of Java users, some of whom might be affected by this 
> change.
>
> Actual changes that go along with the deprecation will probably only involve 
> adding warning messages and possibly updating documentation. We don't need to 
> resolve issues like the ARM32 port yet. However, that will need to be resolved 
> before we actually remove the feature.
>
> Since I'm "Dr Deprecator" I'll volunteer to draft the JEP.
>
> s'marks
>
>
> On 10/27/25 11:56 PM, Alan Bateman wrote:
>> On 28/10/2025 06:32, wenshao wrote:
>>>
>>> Thanks to Alan for your feedback.
>>>
>>> Based on Chen Liang's suggestion, I submitted a new draft PR 
>>> https://github.com/openjdk/jdk/pull/27995 
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27995__;!!ACWV5N9M2RV99hQ!OKe3zURFdlME6esFh_Travsoq4L0s3h71P8bsjCEG5RrmA0nzVmARS7ZAmOZEL0-DWdIg9P8orcXs26SZtYD-c8ZB8h_Fg$> 
>>> to add a warning message to the ComactStrings option.
>>
>> I think? first step has to be establish what or who might be using 
>> -XX:-CompactStrings in 2025. This means looking into the status of ports. Andrew 
>> Haley is going to check with folks in IBM as some of the bug reports for the 
>> -CompactString code paths come from ports there.
>>
>> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251106/ebf6e9ee/attachment-0001.htm>

From rgiulietti at openjdk.org  Thu Nov  6 19:11:09 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Nov 2025 19:11:09 GMT
Subject: RFR: 8367603: Optimize exact division in BigDecimal [v24]
In-Reply-To: <EuZWNav2MQA6OJ0vFrFKgGiAyrxCokgCkq8HXUPajms=.60c97500-4b56-4c79-a844-10e3eb613e6b@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
 <gMpgM_vzCr879wnmTmebhqWKa99YNVA63h_XkgdXhcE=.9b175f8a-3b97-4240-91e7-6850fe8d709d@github.com>
 <bCiGm_iFyMyVXol6dxTyKwk3XuGqWnL-i3LWHryquhs=.284b4e0a-1f0a-4944-8663-69eb67f4a689@github.com>
 <0zUQlypv2Mno6YgOv2DXfRgaPtCrz_Lu9diNMsgrI1I=.ffa6a6d2-e171-493a-8593-8011a7ada5cf@github.com>
 <EuZWNav2MQA6OJ0vFrFKgGiAyrxCokgCkq8HXUPajms=.60c97500-4b56-4c79-a844-10e3eb613e6b@github.com>
Message-ID: <m_7xBudr8dWh-y-qfSwXopUC_DohfCBi76-Qm0-noHg=.e7fac12a-58b6-4ae4-80ab-235225a0765b@github.com>

On Thu, 6 Nov 2025 19:07:11 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I think they do, @rgiulietti do you think the test coverage is adequate?
>
> Sorry @fabioromano1 for being late.
> 
> From what I see, the tests that involve terminating quotients are in `powersOf2and5()` and `properScaleTests()`.
> 
> I would add a specific additional test method where dividends and divisors are not just of the form 2^e2 ? 5^e5, but a bit more general, like 21?10^3 / 140?10^6 and similar.
> The test cases should exercise the implementation's cases of e2 ? e5, e2 > e5, `scaleDiff` in the `int` range and outside (in both directions), and maybe even some cases where the theoretical quotient is terminating but where limits are exceeded, leading to exceptions that need to be caught in the test.

The implementation looks fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27271#discussion_r2500455649

From rgiulietti at openjdk.org  Thu Nov  6 19:11:09 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Nov 2025 19:11:09 GMT
Subject: RFR: 8367603: Optimize exact division in BigDecimal [v24]
In-Reply-To: <0zUQlypv2Mno6YgOv2DXfRgaPtCrz_Lu9diNMsgrI1I=.ffa6a6d2-e171-493a-8593-8011a7ada5cf@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
 <gMpgM_vzCr879wnmTmebhqWKa99YNVA63h_XkgdXhcE=.9b175f8a-3b97-4240-91e7-6850fe8d709d@github.com>
 <bCiGm_iFyMyVXol6dxTyKwk3XuGqWnL-i3LWHryquhs=.284b4e0a-1f0a-4944-8663-69eb67f4a689@github.com>
 <0zUQlypv2Mno6YgOv2DXfRgaPtCrz_Lu9diNMsgrI1I=.ffa6a6d2-e171-493a-8593-8011a7ada5cf@github.com>
Message-ID: <EuZWNav2MQA6OJ0vFrFKgGiAyrxCokgCkq8HXUPajms=.60c97500-4b56-4c79-a844-10e3eb613e6b@github.com>

On Wed, 29 Oct 2025 11:48:04 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 1794:
>> 
>>> 1792:         if (this.signum() == 0) // 0/y
>>> 1793:             return zeroValueOf(preferredScale);
>>> 1794:         else {
>> 
>> The old algorithm has relatively few paths through it for different arguments.
>> 
>> Do the existing test cases provide adequate coverage of the new set of code paths?
>
> I think they do, @rgiulietti do you think the test coverage is adequate?

Sorry @fabioromano1 for being late.

>From what I see, the tests that involve terminating quotients are in `powersOf2and5()` and `properScaleTests()`.

I would add a specific additional test method where dividends and divisors are not just of the form 2^e2 ? 5^e5, but a bit more general, like 21?10^3 / 140?10^6 and similar.
The test cases should exercise the implementation's cases of e2 ? e5, e2 > e5, `scaleDiff` in the `int` range and outside (in both directions), and maybe even some cases where the theoretical quotient is terminating but where limits are exceeded, leading to exceptions that need to be caught in the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27271#discussion_r2500451515

From naoto at openjdk.org  Thu Nov  6 19:43:15 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Nov 2025 19:43:15 GMT
Subject: RFR: 8371339: Illegal pattern char 'B' with locale.providers as HOST
 on macOS for Taiwanese
Message-ID: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>

This is a leftover when we introduced "dayperiods" in the JDK ([JDK-8247781](https://bugs.openjdk.org/browse/JDK-8247781)). The CLDR Converter was modified to generate patterns for SimpleDateFormat for dayperiods (simply replacing them with ampm), and the same processing should have been applied to Host provider on mac, which also uses LDML patterns. As in the bug report, macos recently started using dayperiods, thus the issue was revealed. Regression test is not provided as it would require the macos's default locale should be configured to zh_TW. I have manually confirmed that the proposed fix would work for the problem case.

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

Commit messages:
 - initial commit

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

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

From duke at openjdk.org  Thu Nov  6 20:12:40 2025
From: duke at openjdk.org (jengebr)
Date: Thu, 6 Nov 2025 20:12:40 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v3]
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <9RqAXonEJv4rR9W2eSp8kMwgwqfnpp5Js2_qCjQZ9o4=.2ed78abe-3b29-4d18-8b35-a9d4d5ae4795@github.com>

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

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

  Simplifying ArrayList.addAll() fastpath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28116/files
  - new: https://git.openjdk.org/jdk/pull/28116/files/626dabbe..7725441a

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

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

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

From duke at openjdk.org  Thu Nov  6 20:12:41 2025
From: duke at openjdk.org (jengebr)
Date: Thu, 6 Nov 2025 20:12:41 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <RsQ5PECszF1LnGTUHUnli8g0GWjU492cbsSThnkzBJ8=.46b8d5f1-4964-4824-b926-abd17f9deee3@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <RsQ5PECszF1LnGTUHUnli8g0GWjU492cbsSThnkzBJ8=.46b8d5f1-4964-4824-b926-abd17f9deee3@github.com>
Message-ID: <_9IEA2Ry-QyIC3YmOFWP6m-a9wGqdEBnlDKYKtgtXFE=.6cf71fd5-fbab-482b-97ed-2fc7bfcfc719@github.com>

On Tue, 4 Nov 2025 18:35:23 GMT, jengebr <duke at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding direct unit tests, minor revisions to optimizations

Further investigation into the duplication/de-duplication of the fastpath shows that I *cannot reproduce* the negative results - they are clearly logged, I simply can't generate new runs with the same data.  No idea why.

I've updated the code with the simplified branching, all comments are addressed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3499205653

From duke at openjdk.org  Thu Nov  6 20:12:42 2025
From: duke at openjdk.org (jengebr)
Date: Thu, 6 Nov 2025 20:12:42 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v3]
In-Reply-To: <VKIyLXtFSwLk8XloXbY0k4Nf7H6mTC-6u_iCc_ik0bE=.a9baec42-3630-4866-8c67-1d23da895c03@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <DbbwbiKWfssaVwhVk6TV9xmC5S7047BDxUKOzVrPH1Q=.d07264e3-21a9-4c65-9466-1ac6876661c3@github.com>
 <7gM7Nkoc5GtZzq17xkf8n1QL-n0AggHrZkNXHACw1m8=.fa0ba6cb-0d5a-4d33-a3ef-8604ef07d6e3@github.com>
 <qi4wAL1proBKSpORkfzoQzDvyPGdEMXagLTOZoUmXhg=.42085ba4-0698-4aca-b711-0d5a77a03399@github.com>
 <Mb3XLH8Al8PypzlqUqhaR_pWFo_bCW_slxui3z4L7VE=.32e6801c-70ee-430a-b140-a0e2e18d8b9d@github.com>
 <RGYcA6baOVRb-LO8qbYydsLvsL1o5wdSMug3boqHX2U=.efc41245-d38a-4883-9242-2cea1aadde33@github.com>
 <vYoyMY4WZV3N3DMkeve_kwSaYO20yigtkg7-k5NSFOg=.6828c6ab-7203-4dca-8f41-105fcd505467@github.com>
 <9hnYaiLpY43dWCDAiG8W_tDI2cg2teqSGzECu3ocLps=.43395add-6304-4f9f-9667-669c082082e4@github.com>
 <7mnVHxWSm3mKAzHUNsWDoM4odcweENeQ6afzRRf26fM=.f65241e5-0df5-498a-a470-6b9d80dcfe52@github.com>
 <YXIFhZcksi8nzSWkSgHc8i8WvHOiJ0P69nAZaoywo5M=.2505addc-029b-4e0f-a25e-897a50dbb5a2@github.com>
 <KGySTjtiQfD6KOtWqazclaw0-tNw6JGCffN
 fk0T6z2w=.d15cd61b-f516-4b99-af4d-4d99b07d4e33@github.com>
 <VKIyLXtFSwLk8XloXbY0k4Nf7H6mTC-6u_iCc_ik0bE=.a9baec42-3630-4866-8c67-1d23da895c03@github.com>
Message-ID: <H8QBFcNrvMFVIYmoyh9AQQk56cWuXpI1bmvWWKvmF1k=.f6316b97-3997-4783-9d4d-5cf528049dce@github.com>

On Wed, 5 Nov 2025 05:23:37 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I would think that you need to check `src.modCount` has same value at start and end of the method.
>> 
>> 
>> final int expectedSrcModCount = src.modCount;
>> //access src internals....
>> checkForComodification(expectedSrcModCount)
>> 
>> 
>> Looks like ArrayList::toArray is not doing this check either.  So perhaps it is not needed.  I would have thought mod check would have been needed in toArray to mimic iterator behavior.  Therefore needed in addAll.
>
> I'd have to see the code with the split methods to know for sure, but if it involves duplicating code, then I'd prefer to try harder to avoid the duplication. What's the main optimization here? Direct access to the argument ArrayList's array, avoiding an intermediate copy? If this is the case, then it's hard to believe that it's necessary to duplicate the remainder of the method, which does the growth and copying, which I think aren't changed by this optimization.

I just addressed this in a higher-level comment on this PR.  I cannot reproduce the negative result, so proceeded with the simpler and less-duplicative code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2500662816

From liach at openjdk.org  Thu Nov  6 20:43:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Nov 2025 20:43:37 GMT
Subject: RFR: 4517644: Core reflection setter type conversion spec bugs
 [v3]
In-Reply-To: <Wqm24e-XwNxVzcq2TVY7DveM1RJhU_25wNguyTqOg4I=.afb40c2e-ae62-48f8-9fcd-b9606cb1b91d@github.com>
References: <Wqm24e-XwNxVzcq2TVY7DveM1RJhU_25wNguyTqOg4I=.afb40c2e-ae62-48f8-9fcd-b9606cb1b91d@github.com>
Message-ID: <__a7AqZo67VmQO-iJ7d7rX1MtgbEaKyj6osuOtyYSDs=.5301f110-5d13-4008-8bc1-2684c73bf547@github.com>

> ### Current Status
> In core reflection, there are a few holes with the documentation on the type conversions performed on the different setters. They generally follow this process:
> 
> 1. The Object-valued setters checks the destination type. If that type is primitive, unbox the object.
> 2. Perform identity or (primitive/reference, depending on destination type) widening conversions.
> 
> For each step, they can fail with IllegalArgumentException, which has been the long standing behavior.
> 
> Note that this process is more restrictive than the JLS 5.2 assignment context, which allows boxing conversions, while the primitive reflective setters consistently reject them.
> 
> ### Problems
> There are some problems with current specs:
> 1. No mention that boxing is never done for primitive-typed setters
> 2. Array.set missing description for the final identity or widening conversion (reference or primitive) and the associated IAE condition
> 3. Class specification of field mentions widening/narrowing conversion rules that is not sensible for get/set Object accessors
> 4. Field.set misses the identity or widening in IAE clause (but mentioned in main body)
> 5. Field primitive setters incorrectly claim they are equivalent to set(instance, wrapper) which is wrong due to lack of boxing conversion
> 6. Field primitive setters refer to nonsense "unwrapping conversion"
> 
> ### Solutions
> 1. Make sure the unbox -> identity/widen process and the IAE conditions are present in both Field and Array.set
> 2. Add that boxing is absent for all primitive setters
> 3. Update Field class spec to mention the narrowing/widening conversion limits are for primitive accessors only
> 4. Fix the Field primitive setters' "unwrapping conversion" to be "identity or primitive widening conversion" as in Array primitive setters
> 5. Qualify the Field primitive setters assertion with "if this field is of a primitive type" to make it correct

Chen Liang 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 seven additional commits since the last revision:

 - Link
 - Update
 - Redundant
 - Stuff for the class spec
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/reflect-set
 - the narrowing conversion restriction is primitive-only
 - 4517644: (reflect spec) Array.set documentation hole for array/value ref type mismatch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28029/files
  - new: https://git.openjdk.org/jdk/pull/28029/files/5559e613..7fdcc3e5

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

  Stats: 72364 lines in 1035 files changed: 39096 ins; 27728 del; 5540 mod
  Patch: https://git.openjdk.org/jdk/pull/28029.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28029/head:pull/28029

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

From alexey.semenyuk at oracle.com  Thu Nov  6 20:57:46 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 6 Nov 2025 15:57:46 -0500
Subject: [External] : Re: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <CAAoP7T5RubQqdUGuH9M-sYZVMzA0j8mx2Kd2kHbVDeBzLMXhYg@mail.gmail.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
 <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
 <CAAoP7T7XG_zWj0GSM37oMMvPq=NJ300Aac9skq8erXjYzqvmqw@mail.gmail.com>
 <98fc3c7c-d485-487b-9ab5-f4257c40cacf@oracle.com>
 <CAAoP7T5PfnKaF6XFGaUcrBSUxQ58=eOKwSLkj+4rVPdQOL-FTQ@mail.gmail.com>
 <7aa147c9-108e-4194-be46-84399000578a@oracle.com>
 <CAAoP7T5RubQqdUGuH9M-sYZVMzA0j8mx2Kd2kHbVDeBzLMXhYg@mail.gmail.com>
Message-ID: <1c56649f-91f9-4421-a3d7-9c8c57189927@oracle.com>

Daniel,

I filed [1] CR to track the work on fixing the breaking change in jpackage.
I'm on the fence about how to fix it, though.
Restoring the old behavior imposes security risk.
Making jpackage fail if the "--mac-sign" option is specified without 
options specifying signing identity makes it redundant.

If you have a preference, please share.

In situations when it is ambiguous which certificate to pick jpackage 
will pick the first one and issues a warning. E.g.:
---
WARNING: Multiple certificates found matching [Developer ID Application: 
jpackage.openjdk.java.net] using keychain 
[jpackagerTest-duplicate.keychain], using first one
---

I agree with your suggestion that jpackage should exit with an error in 
this situation instead of issuing a warning. I filed [2] to track this 
change.

[1] https://bugs.openjdk.org/browse/JDK-8371438
[2] https://bugs.openjdk.org/browse/JDK-8371440

- Alexey

On 11/6/2025 5:51 AM, Daniel Peintner wrote:
> Alexey, all,
>
> Thank you very much for your help.
> I still have issues making it to work, and I shared logs privately.
>
> Anyhow, some general comments/suggestions.
>
> You are right, with JDK21 it was enough to state "--mac-sign"option, 
> and it picked the (only/correct) certificate (in my case).
>
> As I understand, with JDK25 this is no longer the?case. I don't want 
> to argue whether the *old* or *new* way is preferred. However, it is a 
> breaking change.
> Hence, what I may suggest, though, is that it throw errors if the 
> expected information (i.e., "--mac-signing-key-user-name") is missing. 
> Otherwise, a developer?doesn't know that there is a problem.
>
> The same goes to situations when it is not unique which certificate to 
> pick. You pointed me to [1] which fixes the problem that I can find 
> the certificate with *partial* information without the need to specify 
> the full --mac-signing-key-user-name.
> In situations where there are more matches, I would?argue the process 
> should fail again with an error message hinting the problem (e.g., 
> certificate not uniquely identifiable). Looking at [2] I don't think 
> this is the case.
>
> Thank you very much for your?continuous?support!
>
> -- Daniel
>
> [1] https://bugs.openjdk.org/browse/JDK-8371094
> [2] 
> https://github.com/openjdk/jdk/commit/0555f6228c59c6739b8b824d64eb6c1545a5520a 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/0555f6228c59c6739b8b824d64eb6c1545a5520a__;!!ACWV5N9M2RV99hQ!J9oKLyj9n-_FtPD_BoRVwSb7xOZS7pc5TH8lXgkpNrCsgfImgZSBnSHzMCb5uslFMX6y38jJLJpUjkaIrEAJOrozjxjNy2Y$>
>
>
>
> On Wed, Nov 5, 2025 at 7:31?PM Alexey Semenyuk 
> <alexey.semenyuk at oracle.com> wrote:
>
>     Daniel,
>
>     I've commented on the logs you shared privately. Adding some
>     thoughts to the mail list.
>
>     jpackage configuration at [1] is missing
>     "--mac-signing-key-user-name" or "--mac-app-image-sign-identity"
>     option. I noted it the private email as well.
>     At first I assumed it was a mistake, but then I came across an old
>     thread about the very same jpackage issue at [2] where you state
>     that "--mac-sign" option is sufficient to make jpackage find the
>     signing identity. So this is intentional.
>
>     jdk25 jpackage will not look up for the signing identity unless
>     "--mac-signing-key-user-name" or "--mac-app-image-sign-identity"
>     option is specified. I'm surprised it did in older releases.
>
>     For the sake of backward compatibility we can restore this
>     behavior. But I think jpackage should exit with an error if the
>     "--mac-sign" option is specified, but neither
>     "--mac-signing-key-user-name" nor "--mac-app-image-sign-identity"
>     is. The old behavior, when without these options jpackage picked
>     the first available certificate with the common name starting with
>     "Developer ID Application: " substring is not secure. It literally
>     tells jpackage to pick any certificate without any filtering. If
>     there is only one such certificate installed and it gets replaced,
>     you will not even notice that your app is signed with a different
>     certificate.
>
>     I suggest you add "--mac-signing-key-user-name" or
>     "--mac-app-image-sign-identity" option to jpackage command line at
>     [1] to make it work.
>
>     [1]
>     https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151
>     <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle*L148-L151__;Iw!!ACWV5N9M2RV99hQ!J9oKLyj9n-_FtPD_BoRVwSb7xOZS7pc5TH8lXgkpNrCsgfImgZSBnSHzMCb5uslFMX6y38jJLJpUjkaIrEAJOrozs2mvjF8$>
>     [2]
>     https://mail.openjdk.org/pipermail/core-libs-dev/2021-August/080291.html
>
>     - Alexey
>
>     On 11/5/2025 4:16 AM, Daniel Peintner wrote:
>>     Hi Alexey,
>>
>>     Thank?you for your reply.
>>
>>         Does the warning message resembles the one at [1]?
>>
>>
>>     Yes, exactly.
>>
>>         I think your evaluation that the step 1 failed is correct.
>>         I'd suggest adding "--verbose" option to the step 1 command
>>         line to get more details.
>>
>>
>>     I updated a demo/test project to demonstrate the problem. You can
>>     now also try it yourself.
>>     https://github.com/danielpeintner/Java11Test/tree/non-modular
>>     <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMJdEvoaQ$>
>>
>>     There you can also find the 3 jpackage commands I use
>>     https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151
>>     <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle*L148-L151__;Iw!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMSE1bEoY$>
>>
>>     W.r.t. sharing?the logs file. I will send them to you
>>     *privately*. I quickly scanned them and I would rather not have
>>     them on the reflector.
>>
>>     The weird thing is, that the difference seems to happen in step
>>     1. Anyhow, running these commands the difference is also somehow
>>     in step 2 where
>>     * JDK21 makes popping up a dialog which asks me whether I want to
>>     allow access?to my keys
>>     * JDK25 does not need any interaction
>>
>>     I hope this?helps to find the "difference".
>>
>>     Thanks,
>>
>>     -- Daniel
>>
>>
>>
>>
>>         [1]
>>         https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties#L85
>>         <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties*L85__;Iw!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMd-s2VkQ$>
>>
>>         - Alexey
>>
>>         On 11/4/2025 12:32 PM, Daniel Peintner wrote:
>>>         Hi Alexey, all,
>>>
>>>         I nailed down the problem to the following, which seems to
>>>         differ between JDK25 and JDK21.
>>>         Maybe this helps to reproduce the issue.
>>>
>>>         jpackage is called 3 times in my process
>>>
>>>          1. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>>             --type app-image --input
>>>             /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib
>>>             --main-jar myPROJECT-25.11.03.jar --main-class
>>>             eu.my_company.myproject.Launcher --dest
>>>             /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>>             --name myPROJECT --app-version 25.11.03 --runtime-image
>>>             /Users/daniel/Documents/GitHub/myPROJECT/build/jre
>>>             --java-options
>>>             --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED
>>>             --java-options
>>>             --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED
>>>             --java-options
>>>             --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED
>>>             --java-options
>>>             --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED
>>>             --java-options
>>>             --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED
>>>             --java-options
>>>             --add-exports=java.management/javax.management=ALL-UNNAMED
>>>             --java-options
>>>             --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED
>>>             --java-options
>>>             --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED
>>>             --icon src/main/deploy/package/macosx/myPROJECT.icns
>>>             --mac-package-identifier eu.my-company.myproject --mac-sign
>>>
>>>          2. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>>             --type pkg --dest
>>>             /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>>             --name myPROJECT --app-version 25.11.03 --app-image
>>>             /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>>>             --file-associations
>>>             src/main/resources/associations.properties --app-version
>>>             25.11.03 --vendor "My Company" --copyright "My Company"
>>>             --mac-sign
>>>
>>>          3. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>>             --type dmg --dest
>>>             /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>>             --name myPROJECT --app-version 25.11.03 --app-image
>>>             /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>>>             --file-associations
>>>             src/main/resources/associations.properties --app-version
>>>             25.11.03 --vendor "My Company" --copyright "My Company"
>>>             --mac-sign
>>>
>>>
>>>         First it creates the app-image and afterwards it creates pkg
>>>         and dmg and signs it.
>>>
>>>         As you can see in the 3 commands, it uses JDK21.
>>>         Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after
>>>         step 2 already with the following message in German
>>>
>>>         Warnung: Nicht signiertes app-image wird zum Erstellen von
>>>         signiertem pkg verwendet.
>>>
>>>         It translates to something?like: it tries to sign pkg and
>>>         complains that the app-image is not signed.
>>>         Hence, somehow step 1 failed already but does not show any
>>>         error/warning.
>>>
>>>         Please let me know whether the above helps to reproduce the
>>>         issue.
>>>
>>>         Thanks,
>>>
>>>         -- Daniel
>>>
>>>
>>>
>>>         On Tue, Nov 4, 2025 at 4:01?PM Daniel Peintner
>>>         <daniel.peintner at gmail.com> wrote:
>>>
>>>             Hi Alexey,
>>>
>>>             Thank you for your reply.
>>>             I am using the?badass runtime plugin which calls
>>>             jpackage under the hood.
>>>
>>>             While trying to create an example project, I noticed
>>>             that there were some changes
>>>             '--mac-package-identifier' needs to go into?imageOptions
>>>             and not?installerOptions.
>>>             see
>>>             https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385
>>>             <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-K4xefEo$>
>>>
>>>             That fixed the problem with jpackage. Anyhow, it still
>>>             does not work with JDK25 and macOS signing.
>>>             Using the JDK25 seems to need additional options
>>>             (compared to JDK21).
>>>
>>>             With JDK25 and --mac-sign the process no longer opens
>>>             the KeyChain access and asks for the credentials. Hence,
>>>             the image itself is no longer signed which matches with
>>>             what I see on the debug console
>>>             "non signed app-image used to sign dmg"? ... freely
>>>             translated into English since I see the German version only
>>>
>>>             Therefore, apple's notary service says invalid with the
>>>             logs like "The binary is not signed with a valid
>>>             Developer ID certificate".
>>>
>>>             Using the *same* gradle file, switching to JDK21 works
>>>             without any issues again.
>>>             I will try to investigate further.
>>>
>>>             Thanks,
>>>
>>>             -- Daniel
>>>
>>>
>>>
>>>
>>>             On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk
>>>             <alexey.semenyuk at oracle.com> wrote:
>>>
>>>                 Hi Daniel,
>>>
>>>                 I can not reproduce the issue you experience with
>>>                 jdk25.0.1:
>>>
>>>                 ---
>>>                 $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage
>>>                 --input input --dest output --type app-image
>>>                 --main-jar hello.jar --main-class
>>>                 com.my_domain.project.Hello --mac-package-identifier
>>>                 com.my-domain.project
>>>                 $ echo $?
>>>                 0
>>>                 ---
>>>
>>>                 If I run the same command line without `
>>>                 --mac-package-identifier` option it fails as expected:
>>>                 ---
>>>                 $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage
>>>                 --input input --dest output --type app-image
>>>                 --main-jar hello.jar --main-class
>>>                 com.my_domain.project.Hello
>>>                 Bundler Mac Application Image skipped because of a
>>>                 configuration problem: invalid mac bundle identifier
>>>                 [com.my_domain.project].
>>>                 Advice to fix: specify identifier with
>>>                 "--mac-package-identifier".
>>>                 ---
>>>
>>>                 The same failure for `--mac-package-identifier
>>>                 com.my_domain.project` (with the underscore):
>>>                 ---
>>>                 $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage
>>>                 --input input --dest output --type app-image
>>>                 --main-jar hello.jar --main-class
>>>                 com.my_domain.project.Hello --mac-package-identifier
>>>                 com.my_domain.project
>>>                 Bundler Mac Application Image skipped because of a
>>>                 configuration problem: invalid mac bundle identifier
>>>                 [com.my_domain.project].
>>>                 Advice to fix: specify identifier with
>>>                 "--mac-package-identifier".
>>>                 ---
>>>
>>>                 Any chance you accidentally put the string with the
>>>                 underscore instead of the hyphen as a value of the
>>>                 `--mac-package-identifier` option on your command line?
>>>
>>>                 - Alexey
>>>
>>>                 On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>>>                 Hi,
>>>>
>>>>                 I am about to switch a JavaFX project from JDK21 to
>>>>                 JDK25 and I noticed a problem when running jpackage.
>>>>
>>>>                 My domain has a hyphen, like in www.my-domain.com
>>>>                 <https://urldefense.com/v3/__http://www.my-domain.com__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-KS5-g-8$>
>>>>                 Hence, my Java package reads like this:
>>>>                 com.my_domain.project
>>>>                 Note: hyphen becomes underscore.
>>>>
>>>>                 Running vanilla jpackage in JDK21 complained with
>>>>                 Invalid Mac-Bundle-ID [com.my_domain.project]
>>>>                 due to the *invalid* underscore and suggests me to
>>>>                 use "--mac-package-identifier"
>>>>
>>>>                 Hence, I added --mac-package-identifier
>>>>                 com.my-domain.project (with the hyphen again)
>>>>                 All good so far.
>>>>
>>>>                 Running the same code with JDK25 with the above
>>>>                 settings shows the error message again
>>>>                 Invalid Mac-Bundle-ID [com.my_domain.project]
>>>>
>>>>                 I can add any argument to? --mac-package-identifier
>>>>                 It seems it is simply not taken into account.
>>>>
>>>>                 I am using JDK 25.0.1
>>>>
>>>>                 Is this a known issue with?JDK25 and jpackage?
>>>>                 Is there any other way to make jpackage work?
>>>>
>>>>                 Thanks,
>>>>
>>>>                 -- Daniel
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251106/99f77e86/attachment-0001.htm>

From henryjen at openjdk.org  Fri Nov  7 00:46:44 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 7 Nov 2025 00:46:44 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
Message-ID: <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>

> This PR include build changes from @magicus and jlink change to verify the build signature.
> 
> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
> 
> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>                                                                                                                                                                  
> ? java --version
> openjdk 26-internal 2026-03-17
> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>                                                                                                                                                                  
> ? jlink --version                                                                       
> 26-internal
>                                                                                                                                                                  
> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>                                                                                                                                                                  
> ? jlink --add-modules java.base --output macos
>                                                             
> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>                                                                                                                                                                  
> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Use release.txt from java.base module in current and target for comparison

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28155/files
  - new: https://git.openjdk.org/jdk/pull/28155/files/c311f098..7df6e157

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

  Stats: 74 lines in 5 files changed: 14 ins; 35 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/28155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155

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

From rriggs at openjdk.org  Fri Nov  7 01:20:36 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Nov 2025 01:20:36 GMT
Subject: RFR: 8371421: [AIX] new test ProcessCloseTest fails
Message-ID: <ilSDh-67gl29IFUKJOSUuy6HLgR5hTG5pPQnQA1DSuE=.cddf8673-1118-46ac-8c4d-b14da018d1cd@github.com>

Replace the test case for the child writing to stderr and then exit 1. 
`cat` on AIX writes the error message to stdout.
Use JavaChild instead of `cat` to have the same sequence of output, input, and exit status.

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

Commit messages:
 - 8371421: [AIX] new test ProcessCloseTest fails

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

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

From syan at openjdk.org  Fri Nov  7 01:46:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Nov 2025 01:46:01 GMT
Subject: RFR: 8371315: java/foreign/sharedclosejfr/TestSharedCloseJFR.java
 failed with -XX:-TieredCompilation
In-Reply-To: <6uxmGNjwdkz4zRsIv2Yn8fgzbFbo-uO9cmv50lH7uzY=.542706bd-425c-4463-a39e-850e04e73137@github.com>
References: <6uxmGNjwdkz4zRsIv2Yn8fgzbFbo-uO9cmv50lH7uzY=.542706bd-425c-4463-a39e-850e04e73137@github.com>
Message-ID: <0WqrmPpZGMRh6wnjKRt5csz7GFmtfzGBV8GZvfYQUuc=.5fe932e5-a425-4279-8541-4441f29463ca@github.com>

On Wed, 5 Nov 2025 12:30:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Borrowed from the original `InternalErrorTest` which this test was based on, disabling compilation of the main method fixes this issue. (I've found that `-XX:-UseOnStackReplacement` works as well, which effectively does the same thing).

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28149#pullrequestreview-3431230930

From asemenyuk at openjdk.org  Fri Nov  7 03:58:47 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 7 Nov 2025 03:58:47 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line
Message-ID: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>

Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.

All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.

### Error reporting improved

1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.

Command line (Windows): 

jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir

Old error output:

Error: Option [--linux-shortcut] is not valid on this platform


New error output:

Error: Option [--linux-shortcut] is not valid on this platform
Error: Option [--mac-package-name] is not valid on this platform
Error: Option [-p] is not valid with type [exe]
Error: Option [--linux-menu-group] is not valid on this platform


 2. Fix misleading error messages.

Command line (Windows): 

jpackage --input no --main-jar no.jar

Old error output:

jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory


New error output:

The value "no" provided for parameter --input is not a directory




### Help output fixed

Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 

The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.

The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.

Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.

### Functional changes

Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.

Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.

In addition to `--option-name <value>` variant to set option value, supports `--option-name=<value>`, `-option-name=<value>`, `-option-name <value>` variants - courtesy of [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package.

### Misc

All "params"-specific code removed.

The format of the `.jpackage.xml` file has changed: 
- The name of the main launcher is stored as the `@name` attribute of the `/jpackage-state/main-launcher` element.
- Child elements of the `/jpackage-state` element with the values of the main launcher properties are stored as child elements of the `/jpackage-state/main-launcher` element.
- "launcher-as-service" property of an additional launcher is stored as a text value of the `/jpackage-state/add-launcher/service` element instead of the value of the `/jpackage-state/add-launcher/@service` attribute.

Changes to the format of the `.jpackage.xml` file are to simplify handling of properties of additional and the main launcher.

[Autogenerated summary of all recognized options (jdk/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/jpackage-options.md)](https://github.com/alexeysemenyukoracle/jdk/blob/JDK-8333727/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/jpackage-options.md).

### Testing

The same testing as in the https://github.com/openjdk/jdk/pull/19668 PR. Additionally, verified no unexpected diffs in the test logs after running all jpackage tests.

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

Commit messages:
 - Rework ExternalApplication and AppImageFile
 - the cli: after params removed
 - Add test to run multiple instances of jpackage tool provider asynchronously
 - MainResources.properties, MacResources.properties: remove obsolete IDs
 - Remove redundant copy of ObjectMapper.java
 - ErrorTest: follow up for changes in jpackage because of the cli; MainResources.properties: remove unused IDs
 - JPackageToolProvider.java: remove
 - Make jtreg tests work with the cli
 - main/Main.java: make it a proxy for the cli's Main
 - *Resources.properties: remove obsolete IDs
 - ... and 30 more: https://git.openjdk.org/jdk/compare/c8f5fd6f...2d975def

Changes: https://git.openjdk.org/jdk/pull/28163/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28163&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333727
  Stats: 24858 lines in 169 files changed: 18015 ins; 6339 del; 504 mod
  Patch: https://git.openjdk.org/jdk/pull/28163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28163/head:pull/28163

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

From forax at univ-mlv.fr  Fri Nov  7 08:23:29 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 7 Nov 2025 09:23:29 +0100 (CET)
Subject: On throwing InterruptedException
In-Reply-To: <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>
Message-ID: <201020871.33839121.1762503809121.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Alan Bateman" <alan.bateman at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Pavel Rappo" <pavel.rappo at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Thursday, November 6, 2025 10:37:13 AM
> Subject: Re: On throwing InterruptedException

> On 05/11/2025 14:00, Remi Forax wrote:
>> :
>>
>> If a thread is interrupted, it should stop ASAP.
>> So if you catch InterruptedException and rethrow a new exception, this should be
>> okay (as Alan said).
> Rethrowing the InterruptedException is okay. Throwing a new exception
> that is not an InterruptedException is okay too but only after restoring
> the interrupted status, otherwise the thread might block again is some
> catch block as it unwinds.

and I disagree here :)

Let's take a step back, in Java code
1/ people are writing many catch blocks that they should not and usually the code in the catch block is not exercised enough so it is a little brittle. 
2/ the normal behavior is to either get an InterruptedException or to have the flag "interrupted" set, but not both.

If you throw an exception AND set the flag, usually the code in a catch block will behave weirdly because the catch code has not be written with that corner case in mind.

Throwing an unrecoverable error usually avoid that problem (and yes, i'm aware it may clash with the way old executors work but virtual threads are our saviors).

> 
> -Alan

regards,
R?mi

From viktor.klang at oracle.com  Fri Nov  7 09:31:36 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 7 Nov 2025 10:31:36 +0100
Subject: On throwing InterruptedException
In-Reply-To: <201020871.33839121.1762503809121.JavaMail.zimbra@univ-eiffel.fr>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>
 <201020871.33839121.1762503809121.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <7011948d-b21e-48fb-b44d-44eb00035c8b@oracle.com>

My 2c,

As an interrupt can come from anywhere, not necessarily from the 
caller/consumer?if you react to interruption by either throwing a new 
Exception, or wrap an InterruptedException, then the knowledge that the 
situation was caused by an interrupt is lost. Lost information tends to 
be a bad thing unless one is sure that no one will ever need that 
information.

On 2025-11-07 09:23, forax at univ-mlv.fr wrote:
> ----- Original Message -----
>> From: "Alan Bateman" <alan.bateman at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>, "Pavel Rappo" <pavel.rappo at gmail.com>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
>> Sent: Thursday, November 6, 2025 10:37:13 AM
>> Subject: Re: On throwing InterruptedException
>> On 05/11/2025 14:00, Remi Forax wrote:
>>> :
>>>
>>> If a thread is interrupted, it should stop ASAP.
>>> So if you catch InterruptedException and rethrow a new exception, this should be
>>> okay (as Alan said).
>> Rethrowing the InterruptedException is okay. Throwing a new exception
>> that is not an InterruptedException is okay too but only after restoring
>> the interrupted status, otherwise the thread might block again is some
>> catch block as it unwinds.
> and I disagree here :)
>
> Let's take a step back, in Java code
> 1/ people are writing many catch blocks that they should not and usually the code in the catch block is not exercised enough so it is a little brittle.
> 2/ the normal behavior is to either get an InterruptedException or to have the flag "interrupted" set, but not both.
>
> If you throw an exception AND set the flag, usually the code in a catch block will behave weirdly because the catch code has not be written with that corner case in mind.
>
> Throwing an unrecoverable error usually avoid that problem (and yes, i'm aware it may clash with the way old executors work but virtual threads are our saviors).
>
>> -Alan
> regards,
> R?mi

-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


From mdoerr at openjdk.org  Fri Nov  7 09:40:01 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 7 Nov 2025 09:40:01 GMT
Subject: RFR: 8371421: [AIX] new test ProcessCloseTest fails
In-Reply-To: <ilSDh-67gl29IFUKJOSUuy6HLgR5hTG5pPQnQA1DSuE=.cddf8673-1118-46ac-8c4d-b14da018d1cd@github.com>
References: <ilSDh-67gl29IFUKJOSUuy6HLgR5hTG5pPQnQA1DSuE=.cddf8673-1118-46ac-8c4d-b14da018d1cd@github.com>
Message-ID: <zNDWSUjtUoZqNnsKo9j_U6q5KW7m3twpbdQCyjCs6_E=.e2c332ae-632b-4bd4-9279-a03d6eddc99b@github.com>

On Fri, 7 Nov 2025 01:15:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Replace the test case for the child writing to stderr and then exit 1. 
> `cat` on AIX writes the error message to stdout.
> Use JavaChild instead of `cat` to have the same sequence of output, input, and exit status.

LGTM and fixes the issue on AIX. Thanks!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28185#pullrequestreview-3432580038

From alan.bateman at oracle.com  Fri Nov  7 09:46:36 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 7 Nov 2025 09:46:36 +0000
Subject: On throwing InterruptedException
In-Reply-To: <201020871.33839121.1762503809121.JavaMail.zimbra@univ-eiffel.fr>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>
 <201020871.33839121.1762503809121.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <ecbe0caf-6177-4839-9542-71dd4609833e@oracle.com>



On 07/11/2025 08:23, forax at univ-mlv.fr wrote:
>> :
> and I disagree here :)
>
> Let's take a step back, in Java code
> 1/ people are writing many catch blocks that they should not and usually the code in the catch block is not exercised enough so it is a little brittle.
> 2/ the normal behavior is to either get an InterruptedException or to have the flag "interrupted" set, but not both.

Could you clarify what you are disagreeing with?

The methods that throw IE clear the interrupted status. If you catch IE 
then the interrupted status will be clear.? The guidance is to either 
(a) rethrow the IE, or (b) restore the interrupted status if you 
continue normally or abnormally (abnormally is throwing an exception 
that is not an IE). You could get unlucky and be interrupted again while 
handling the IE, so if you rethrow the IE then you would be doing so 
with the interrupted status set - this would be unusual of course, but 
possible.

-Alan

From cstein at openjdk.org  Fri Nov  7 09:49:33 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 7 Nov 2025 09:49:33 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR file
Message-ID: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>

Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.

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

Commit messages:
 - Compact implementation
 - Inline method
 - Manifest is optional, no need to add it here
 - 8268613: jar --validate should check inital entries of a JAR file

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

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

From alanb at openjdk.org  Fri Nov  7 10:25:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Nov 2025 10:25:05 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
Message-ID: <77TzIw84nfa3sIqFqINBceemnxhJ3RkCdjaqy6yKbSk=.e3d844d9-68ae-4302-b344-6c686c54b169@github.com>

On Fri, 7 Nov 2025 00:46:44 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR include build changes from @magicus and jlink change to verify the build signature.
>> 
>> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
>> 
>> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>>                                                                                                                                                                  
>> ? java --version
>> openjdk 26-internal 2026-03-17
>> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
>> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>>                                                                                                                                                                  
>> ? jlink --version                                                                       
>> 26-internal
>>                                                                                                                                                                  
>> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>>                                                                                                                                                                  
>> ? jlink --add-modules java.base --output macos
>>                                                             
>> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>>                                                                                                                                                                  
>> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use release.txt from java.base module in current and target for comparison

src/java.base/share/classes/jdk/internal/jmod/resources/release.txt.template line 1:

> 1: @@COMPANY_NAME@@-@@VERSION_STRING@@-@@VERSION_DATE@@

jdk.internal.jmod is for the code to access JMOD files. I think we'll need to find a better location for release.txt  Putting in the top-level directory of java.base would create an attractive nuisance so jdk.internal.* is better. Maybe put it in misc for now until we find somewhere better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502620339

From alanb at openjdk.org  Fri Nov  7 11:05:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Nov 2025 11:05:07 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
Message-ID: <VtSdmJSKc-Ll7Bt-OD4A5W2ov2zEj_8bjjXW3riswwk=.bf654dd9-42b4-4a29-9b28-dc77dc91ec1a@github.com>

On Fri, 7 Nov 2025 00:46:44 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR include build changes from @magicus and jlink change to verify the build signature.
>> 
>> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
>> 
>> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>>                                                                                                                                                                  
>> ? java --version
>> openjdk 26-internal 2026-03-17
>> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
>> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>>                                                                                                                                                                  
>> ? jlink --version                                                                       
>> 26-internal
>>                                                                                                                                                                  
>> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>>                                                                                                                                                                  
>> ? jlink --add-modules java.base --output macos
>>                                                             
>> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>>                                                                                                                                                                  
>> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use release.txt from java.base module in current and target for comparison

The updated version is much simpler, thank you. Just a few small comments on the jlink changes.

> This PR include build changes from @magicus and jlink change to verify the build signature.

In that case, you'll need to list Magnus (`/contributor` command).

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 245:

> 243:     public static final String OPTIONS_RESOURCE = "jdk/tools/jlink/internal/options";
> 244:     // Release information as in the java.base module for target image
> 245:     public static final String JDK_RELEASE_RESOURCE = "jdk/internal/jmod/resources/release.txt";

I assume this can be private.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 256:

> 254:         }
> 255: 
> 256:         try (var r = new BufferedReader(new InputStreamReader(in.get()))) {

It's not immediately obvious that `in` is an `Optional<InputStream>` , so maybe rename and/or avoid var for this case.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 600:

> 598:             ModuleReference target = finder.find("java.base").get();
> 599:             String currentRelease = getReleaseInfo(current).orElseThrow(() ->
> 600:                 new IllegalArgumentException("Cannot find release.txt"));

I assume this is an err.jlink.version.mismatch case too. The packaged version of java.base on the module path is missing the resource file so it must be an older version, hence a mismatch.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 603:

> 601:             String targetRelease = getReleaseInfo(target).orElse("N/A");
> 602:             if (! currentRelease.equals(targetRelease)) {
> 603:                 // jlink version and java.base version do not match.

The comment could be clearer. It's a version mismatch between the current runtime and the target runtime image.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 610:

> 608:             }
> 609:         } catch (NoSuchElementException e) {
> 610:             assert false : "Should have found java.base module";

I think you can drop the catching of NoSuchElementException, jlink should just fail if this were to happen.

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

PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3432931919
PR Comment: https://git.openjdk.org/jdk/pull/28155#issuecomment-3501891672
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502816169
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502693905
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502804031
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502808353
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502682900

From erikj at openjdk.org  Fri Nov  7 13:52:01 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 7 Nov 2025 13:52:01 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
Message-ID: <sBgWf0DZMzkznGy52BE7JYQettAjQ2EiLpTZY73fKgI=.e730826f-d1eb-4149-897d-86773bd0d9dd@github.com>

On Fri, 7 Nov 2025 00:46:44 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR include build changes from @magicus and jlink change to verify the build signature.
>> 
>> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
>> 
>> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>>                                                                                                                                                                  
>> ? java --version
>> openjdk 26-internal 2026-03-17
>> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
>> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>>                                                                                                                                                                  
>> ? jlink --version                                                                       
>> 26-internal
>>                                                                                                                                                                  
>> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>>                                                                                                                                                                  
>> ? jlink --add-modules java.base --output macos
>>                                                             
>> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>>                                                                                                                                                                  
>> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use release.txt from java.base module in current and target for comparison

Build changes look good now, pending Alan's comment about location of the output file.

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

PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3434055982

From asemenyuk at openjdk.org  Fri Nov  7 13:53:08 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 7 Nov 2025 13:53:08 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line
In-Reply-To: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
Message-ID: <OuA83g6bf_F2geLVvUoSS1YlgxiLOkkvp4VvHJHA9Ww=.591a3b14-df84-47af-b333-2b7cb37a2544@github.com>

On Wed, 5 Nov 2025 19:29:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
> 
> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
> 
> ### Error reporting improved
> 
> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
> 
> Command line (Windows): 
> 
> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
> 
> Old error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> 
> 
> New error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> Error: Option [--mac-package-name] is not valid on this platform
> Error: Option [-p] is not valid with type [exe]
> Error: Option [--linux-menu-group] is not valid on this platform
> 
> 
>  2. Fix misleading error messages.
> 
> Command line (Windows): 
> 
> jpackage --input no --main-jar no.jar
> 
> Old error output:
> 
> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
> 
> 
> New error output:
> 
> The value "no" provided for parameter --input is not a directory
> 
> 
> 
> 
> ### Help output fixed
> 
> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
> 
> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
> 
> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
> 
> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
> 
> ### Functional changes
> 
> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
> 
> Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.
> 
> In addition to `--opt...

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/28163#issuecomment-3502680445

From jvernee at openjdk.org  Fri Nov  7 14:09:15 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Nov 2025 14:09:15 GMT
Subject: Integrated: 8371315:
 java/foreign/sharedclosejfr/TestSharedCloseJFR.java failed with
 -XX:-TieredCompilation
In-Reply-To: <6uxmGNjwdkz4zRsIv2Yn8fgzbFbo-uO9cmv50lH7uzY=.542706bd-425c-4463-a39e-850e04e73137@github.com>
References: <6uxmGNjwdkz4zRsIv2Yn8fgzbFbo-uO9cmv50lH7uzY=.542706bd-425c-4463-a39e-850e04e73137@github.com>
Message-ID: <Sp6qoUEjthXIjLKc18dJcNX9noZGWEQHOIoOH3NJe6A=.007c39a7-0b71-4fa4-8dcf-46e9c1dc9885@github.com>

On Wed, 5 Nov 2025 12:30:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Borrowed from the original `InternalErrorTest` which this test was based on, disabling compilation of the main method fixes this issue. (I've found that `-XX:-UseOnStackReplacement` works as well, which effectively does the same thing).

This pull request has now been integrated.

Changeset: d5803aa7
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5803aa78a84caccd5c3f14ac788817c5a3b4725
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8371315: java/foreign/sharedclosejfr/TestSharedCloseJFR.java failed with -XX:-TieredCompilation

Reviewed-by: mcimadamore, syan

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

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

From alanb at openjdk.org  Fri Nov  7 15:01:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Nov 2025 15:01:06 GMT
Subject: RFR: 8370216: Fix of new File("").exists() causes undefined
 behavior in libraries
In-Reply-To: <UlWA6NspyDBtVQEyD9V1UiyDp1Qn1nQznVk4q4Gx7E4=.82f7e8e0-9c11-49ff-8458-65ae70265d94@github.com>
References: <UlWA6NspyDBtVQEyD9V1UiyDp1Qn1nQznVk4q4Gx7E4=.82f7e8e0-9c11-49ff-8458-65ae70265d94@github.com>
Message-ID: <wHGRmOmXZKhNVprWKCtY23sF-Gbg93X2SqVRacTAbx0=.bf517efa-1b66-4784-86fa-0edd58c1413c@github.com>

On Wed, 5 Nov 2025 18:14:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a system property, `jdk.io.File.failIfEmptyPath`, which when `true` reverts to legacy, pre-JDK 25 behavior, as to how `java.io.File` handles an empty pathname string.

It's problematic when the spec is clear that accessing a file with the empty path is equivalent to accessing the current directory. So I think this more as a way to get access to the current directory to fail. In any case, I think this is a forced move as we under estimated the compatibility impact of fixing the long standing inconsistency.

src/java.base/share/classes/java/io/FileSystem.java line 41:

> 39: 
> 40:     protected static final boolean FAIL_IF_EMPTY_PATH =
> 41:         Boolean.getBoolean(FAIL_IF_EMPTY_PATH_PROPERTY);

This doesn't need to be protected as FileSystem is package-private so can't be extended by classes in other package. I assume you make it protected to make it clearer that it intended for concrete subclass implementations.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28158#pullrequestreview-3434490018
PR Review Comment: https://git.openjdk.org/jdk/pull/28158#discussion_r2504007892

From sgehwolf at openjdk.org  Fri Nov  7 15:28:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Nov 2025 15:28:01 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf 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 branch 'master' into jdk-8370492-fix-cpushares-mapping
 - Fix include
 - Add asserts/checks for input domain
 - Add regression test for jdk-8370492
 - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/2866c0a7..464d162f

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

  Stats: 17030 lines in 439 files changed: 10578 ins; 4853 del; 1599 mod
  Patch: https://git.openjdk.org/jdk/pull/28157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28157/head:pull/28157

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

From asemenyuk at openjdk.org  Fri Nov  7 15:57:33 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 7 Nov 2025 15:57:33 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v2]
In-Reply-To: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
Message-ID: <EqnjV2k0Bw7Oe9ESCww1ns6bbJEPNcvKS8MzyzMvTXw=.0a843033-0087-4e3e-bf31-0440af3d567e@github.com>

> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
> 
> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
> 
> ### Error reporting improved
> 
> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
> 
> Command line (Windows): 
> 
> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
> 
> Old error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> 
> 
> New error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> Error: Option [--mac-package-name] is not valid on this platform
> Error: Option [-p] is not valid with type [exe]
> Error: Option [--linux-menu-group] is not valid on this platform
> 
> 
>  2. Fix misleading error messages.
> 
> Command line (Windows): 
> 
> jpackage --input no --main-jar no.jar
> 
> Old error output:
> 
> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
> 
> 
> New error output:
> 
> The value "no" provided for parameter --input is not a directory
> 
> 
> 
> 
> ### Help output fixed
> 
> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
> 
> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
> 
> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
> 
> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
> 
> ### Functional changes
> 
> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
> 
> Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.
> 
> In addition to `--opt...

Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 24 new commits since the last revision:

 - Rework ExternalApplication and AppImageFile
 - the cli: after params removed
 - Add test to run multiple instances of jpackage tool provider asynchronously
 - MainResources.properties, MacResources.properties: remove obsolete IDs
 - Remove redundant copy of ObjectMapper.java
 - ErrorTest: follow up for changes in jpackage because of the cli; MainResources.properties: remove unused IDs
 - JPackageToolProvider.java: remove
 - Make jtreg tests work with the cli
 - main/Main.java: make it a proxy for the cli's Main
 - *Resources.properties: remove obsolete IDs
 - ... and 14 more: https://git.openjdk.org/jdk/compare/2d975def...fde4f4b9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28163/files
  - new: https://git.openjdk.org/jdk/pull/28163/files/2d975def..fde4f4b9

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

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

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

From bpb at openjdk.org  Fri Nov  7 16:37:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Nov 2025 16:37:07 GMT
Subject: RFR: 8370216: Fix of new File("").exists() causes undefined
 behavior in libraries
In-Reply-To: <wHGRmOmXZKhNVprWKCtY23sF-Gbg93X2SqVRacTAbx0=.bf517efa-1b66-4784-86fa-0edd58c1413c@github.com>
References: <UlWA6NspyDBtVQEyD9V1UiyDp1Qn1nQznVk4q4Gx7E4=.82f7e8e0-9c11-49ff-8458-65ae70265d94@github.com>
 <wHGRmOmXZKhNVprWKCtY23sF-Gbg93X2SqVRacTAbx0=.bf517efa-1b66-4784-86fa-0edd58c1413c@github.com>
Message-ID: <FaQuOLJYQvRC5mvORfpcF3gRGqzfdOb98wr182okK_o=.5ae69365-1c89-421e-b799-f310c7122855@github.com>

On Fri, 7 Nov 2025 14:58:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you make it protected to make it clearer that it intended for concrete subclass implementations.

That's correct. Would it be better to change it to package scope?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28158#discussion_r2504482275

From henryjen at openjdk.org  Fri Nov  7 16:46:04 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 7 Nov 2025 16:46:04 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <VtSdmJSKc-Ll7Bt-OD4A5W2ov2zEj_8bjjXW3riswwk=.bf654dd9-42b4-4a29-9b28-dc77dc91ec1a@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
 <VtSdmJSKc-Ll7Bt-OD4A5W2ov2zEj_8bjjXW3riswwk=.bf654dd9-42b4-4a29-9b28-dc77dc91ec1a@github.com>
Message-ID: <mrJgjSdUdbZzewM92E1bX5xpySlITzVZbiXZ6CwaE9o=.cdf90a68-8147-41ae-8244-e8765e41da88@github.com>

On Fri, 7 Nov 2025 10:57:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use release.txt from java.base module in current and target for comparison
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 600:
> 
>> 598:             ModuleReference target = finder.find("java.base").get();
>> 599:             String currentRelease = getReleaseInfo(current).orElseThrow(() ->
>> 600:                 new IllegalArgumentException("Cannot find release.txt"));
> 
> I assume this is an err.jlink.version.mismatch case too. The packaged version of java.base on the module path is missing the resource file so it must be an older version, hence a mismatch.

This is for the current runtime of jlink, so this should never happen?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2504531025

From sgehwolf at openjdk.org  Fri Nov  7 17:43:18 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Nov 2025 17:43:18 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory limit
 fix in JDK-8370572
Message-ID: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>

Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.

The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.

Testing (all on Linux x86_64):
- [x] CG version 2, run as root. Engine: docker. Test is skipped.
- [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
- [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
- [X] CG version 1, run as non-root. Test skipped.
- [x] GHA, though I don't think this is very useful for this change.

Thoughts?

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

Commit messages:
 - 8370966: Create regression test for hierarchical memory limit fix in JDK-8370572

Changes: https://git.openjdk.org/jdk/pull/28201/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28201&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370966
  Stats: 191 lines in 8 files changed: 154 ins; 32 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28201/head:pull/28201

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

From rriggs at openjdk.org  Fri Nov  7 17:51:32 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Nov 2025 17:51:32 GMT
Subject: Integrated: 8371421: [AIX] new test ProcessCloseTest fails
In-Reply-To: <ilSDh-67gl29IFUKJOSUuy6HLgR5hTG5pPQnQA1DSuE=.cddf8673-1118-46ac-8c4d-b14da018d1cd@github.com>
References: <ilSDh-67gl29IFUKJOSUuy6HLgR5hTG5pPQnQA1DSuE=.cddf8673-1118-46ac-8c4d-b14da018d1cd@github.com>
Message-ID: <pLJFRl9JXFszS5AHrPVaNlkTGWWQmxZdRMBu-b6-hFs=.d9465244-1827-455d-a448-44631ed23177@github.com>

On Fri, 7 Nov 2025 01:15:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Replace the test case for the child writing to stderr and then exit 1. 
> `cat` on AIX writes the error message to stdout.
> Use JavaChild instead of `cat` to have the same sequence of output, input, and exit status.

This pull request has now been integrated.

Changeset: a90fc266
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a90fc2661a7c11077ea17d37563dfb3dfba28016
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8371421: [AIX] new test ProcessCloseTest fails

Reviewed-by: mdoerr

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

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

From joehw at openjdk.org  Fri Nov  7 18:32:06 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 7 Nov 2025 18:32:06 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v8]
In-Reply-To: <ovVSp7pCJgGGKRfERIZJ3RU8k7MdyWSryUqHWJ8Xgvo=.386ab4fe-2794-43c0-b513-8f86b0a87f7a@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
 <ovVSp7pCJgGGKRfERIZJ3RU8k7MdyWSryUqHWJ8Xgvo=.386ab4fe-2794-43c0-b513-8f86b0a87f7a@github.com>
Message-ID: <LYO8UukI9BtRXckLG-P1jLqsmt6n2FkMSFnVLVXs-Yg=.0ee1ce87-9df5-45be-8eaa-5ee175cd65c5@github.com>

On Wed, 5 Nov 2025 17:09:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More test data

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28076#pullrequestreview-3435649380

From henryjen at openjdk.org  Fri Nov  7 18:53:42 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 7 Nov 2025 18:53:42 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v3]
In-Reply-To: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
Message-ID: <Ipli7ix-JYQ7VY7xkKC3i2C7bH5mZBiaGtjY05nb9h8=.43888bb3-98e2-423c-b02b-1135693321f9@github.com>

> This PR include build changes from @magicus and jlink change to verify the build signature.
> 
> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
> 
> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>                                                                                                                                                                  
> ? java --version
> openjdk 26-internal 2026-03-17
> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>                                                                                                                                                                  
> ? jlink --version                                                                       
> 26-internal
>                                                                                                                                                                  
> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>                                                                                                                                                                  
> ? jlink --add-modules java.base --output macos
>                                                             
> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>                                                                                                                                                                  
> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedbacks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28155/files
  - new: https://git.openjdk.org/jdk/pull/28155/files/7df6e157..8df7e809

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

  Stats: 21 lines in 3 files changed: 3 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155

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

From naoto at openjdk.org  Fri Nov  7 19:36:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Nov 2025 19:36:24 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v8]
In-Reply-To: <ovVSp7pCJgGGKRfERIZJ3RU8k7MdyWSryUqHWJ8Xgvo=.386ab4fe-2794-43c0-b513-8f86b0a87f7a@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
 <ovVSp7pCJgGGKRfERIZJ3RU8k7MdyWSryUqHWJ8Xgvo=.386ab4fe-2794-43c0-b513-8f86b0a87f7a@github.com>
Message-ID: <l-gZrwGElrrHbdmkzPxLZtZurXP3gVVMqaqGWT05s0E=.968d91b2-ba5d-404f-9f00-8177b5b9a597@github.com>

On Wed, 5 Nov 2025 17:09:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More test data

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28076#issuecomment-3504507613

From naoto at openjdk.org  Fri Nov  7 19:36:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Nov 2025 19:36:26 GMT
Subject: Integrated: 8354548: Update CLDR to Version 48.0
In-Reply-To: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
References: <eaNvczVXsydsLgN0PizFgyeCO4LZJcCaG4SCfCOYsKk=.5e67b56f-a4c8-4ef2-990d-b0d0b7c31a8f@github.com>
Message-ID: <f_ehdoq8uLyLBvKP2t6uOISBjnH_VtGp4n60ZQ0A5yA=.98baaabd-2d5a-49b8-b98d-53e65c522aa6@github.com>

On Thu, 30 Oct 2025 22:37:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 2c3c4707
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2c3c4707c0ac7f4432ada9621f4b2e5fe4aef51f
Stats:     135950 lines in 390 files changed: 94406 ins; 15578 del; 25966 mod

8354548: Update CLDR to Version 48.0

Reviewed-by: joehw, jlu

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

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

From rriggs at openjdk.org  Fri Nov  7 20:35:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Nov 2025 20:35:05 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: <AHtBR8KtQsMG9sup-cEEPY07xRW8aLMkooVJeWWV5sY=.adf6db85-cb73-4e38-a8b4-abc0d3108052@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <AHtBR8KtQsMG9sup-cEEPY07xRW8aLMkooVJeWWV5sY=.adf6db85-cb73-4e38-a8b4-abc0d3108052@github.com>
Message-ID: <J8h3gAFPE8bV7k1mfLCSZLq2eM58d2feTd7EEMUVS_Y=.0de96996-d9ed-4c7a-aeb7-e25dd1901d75@github.com>

On Thu, 30 Oct 2025 02:59:45 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:
> 
>   update to use value long for folding

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

> 276:             return 1;
> 277:         }
> 278:         if (k2 < olast || f1 != 0) {

Should `f1` here be `f2`, partial codePoint remaining in 2nd string?

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

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

From rriggs at openjdk.org  Fri Nov  7 20:35:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Nov 2025 20:35:05 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: <J8h3gAFPE8bV7k1mfLCSZLq2eM58d2feTd7EEMUVS_Y=.0de96996-d9ed-4c7a-aeb7-e25dd1901d75@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <AHtBR8KtQsMG9sup-cEEPY07xRW8aLMkooVJeWWV5sY=.adf6db85-cb73-4e38-a8b4-abc0d3108052@github.com>
 <J8h3gAFPE8bV7k1mfLCSZLq2eM58d2feTd7EEMUVS_Y=.0de96996-d9ed-4c7a-aeb7-e25dd1901d75@github.com>
Message-ID: <QHGK6B57YDYKQGeclXkKMKcc3Aof5hBrzEDbPebbwYY=.d4aac655-66fc-4373-9e75-37ec23a13560@github.com>

On Fri, 7 Nov 2025 20:30:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to use value long for folding
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 278:
> 
>> 276:             return 1;
>> 277:         }
>> 278:         if (k2 < olast || f1 != 0) {
> 
> Should `f1` here be `f2`, partial codePoint remaining in 2nd string?

A new test case maybe useful.

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

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

From jlu at openjdk.org  Fri Nov  7 21:19:00 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Nov 2025 21:19:00 GMT
Subject: RFR: 8371339: Illegal pattern char 'B' with locale.providers as
 HOST on macOS for Taiwanese
In-Reply-To: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
References: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
Message-ID: <0EbAV9233uo0bDUJaJPkCGuVQMxoA-EutwMEHMC1BqU=.1a32b36e-8bba-4939-80dd-d692c76be59f@github.com>

On Thu, 6 Nov 2025 19:35:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover when we introduced "dayperiods" in the JDK ([JDK-8247781](https://bugs.openjdk.org/browse/JDK-8247781)). The CLDR Converter was modified to generate patterns for SimpleDateFormat for dayperiods (simply replacing them with ampm), and the same processing should have been applied to Host provider on mac, which also uses LDML patterns. As in the bug report, macos recently started using dayperiods, thus the issue was revealed. Regression test is not provided as it would require the macos's default locale should be configured to zh_TW. I have manually confirmed that the proposed fix would work for the problem case.

Case handling for day period looks the same as in _cldrconverter/Bundle.java_

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28181#pullrequestreview-3436454712

From rriggs at openjdk.org  Fri Nov  7 22:36:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Nov 2025 22:36:11 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: <AHtBR8KtQsMG9sup-cEEPY07xRW8aLMkooVJeWWV5sY=.adf6db85-cb73-4e38-a8b4-abc0d3108052@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <AHtBR8KtQsMG9sup-cEEPY07xRW8aLMkooVJeWWV5sY=.adf6db85-cb73-4e38-a8b4-abc0d3108052@github.com>
Message-ID: <NPPeE5V5So2nS47cMyWWG8k3RI_L2-ew_DmbiHBkBnM=.854c1ae0-7e76-4e9d-8f70-4c1181f183a2@github.com>

On Thu, 30 Oct 2025 02:59:45 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:
> 
>   update to use value long for folding

Looking good.
I'll look at the javadoc again when the CSR comments are addressed.

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

> 51:     public static boolean isDefined(int cp) {
> 52:          return getDefined(cp) != -1;
> 53:      }

Extra space.

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

> 105:     * family may appears independently or within a class.
> 106:     * <p>
> 107:     * For loose/case-insensitive matching, the back-refs, slices and singles apply {code toUpperCase} and

Missing at-sign in markup:
Suggestion:

    * For loose/case-insensitive matching, the back-refs, slices and singles apply {@code toUpperCase} and

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

> 134:     *
> 135:     * <p>
> 136:     * @spec https://www.unicode.org/reports/tr18/#Simple_Loose_Matches

I'd put @spec after @return.

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

> 150:                 }
> 151:             }
> 152:         }

If expanded_case_cps was sorted, Array.binarySearch could be used to find the index of the first character in the range.
And the loop could break when cp reaches the end of the range.

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

> 161:       .stream()
> 162:       .mapToInt(Integer::intValue)
> 163:       .toArray();

It might be worthwhile to sort these to enable skipping a quicker break when the last one in the range is seen.

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

> 167:     private static final int HASH_NEXT = 2;
> 168: 
> 169:     private static int[][] hashKeys(int[] keys) {

It may be worthwhile to round up the hash modulo to a prime number to avoid unfortunate hash collisions.

test/jdk/java/lang/String/UnicodeCaseFoldingTest.java line 31:

> 29:  * @compile --add-exports java.base/jdk.internal.lang=ALL-UNNAMED
> 30:  * UnicodeCaseFoldingTest.java
> 31:  * @run junit/othervm --add-exports java.base/jdk.internal.lang=ALL-UNNAMED

The @module directive can replace the explicit --add-exports and the explicit @compile may be unnecessary.

* @modules java.base/jdk.internal.lang:+open

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

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3436511645
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505610221
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505623056
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505629880
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505705459
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505699712
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505714395
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505728277

From smarks at openjdk.org  Sat Nov  8 00:42:07 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 8 Nov 2025 00:42:07 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <_9IEA2Ry-QyIC3YmOFWP6m-a9wGqdEBnlDKYKtgtXFE=.6cf71fd5-fbab-482b-97ed-2fc7bfcfc719@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <RsQ5PECszF1LnGTUHUnli8g0GWjU492cbsSThnkzBJ8=.46b8d5f1-4964-4824-b926-abd17f9deee3@github.com>
 <_9IEA2Ry-QyIC3YmOFWP6m-a9wGqdEBnlDKYKtgtXFE=.6cf71fd5-fbab-482b-97ed-2fc7bfcfc719@github.com>
Message-ID: <WVR_t9MyNW76En_8qt0lFL2Qtr9Y_VvA7pBdl0Z_pKI=.39e45727-a079-4fbe-b201-0e114e2d292c@github.com>

On Thu, 6 Nov 2025 20:08:31 GMT, jengebr <duke at openjdk.org> wrote:

>> jengebr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding direct unit tests, minor revisions to optimizations
>
> Further investigation into the duplication/de-duplication of the fastpath shows that I *cannot reproduce* the negative results - they are clearly logged, I simply can't generate new runs with the same data.  No idea why.
> 
> I've updated the code with the simplified branching, all comments are addressed.

@jengebr Thanks for rechecking the benchmark. The ArrayList change looks much more sensible now, and I'm glad it performs to your expectations!

Regarding tests... I see you added a new test `SingletonSetToArray`. I took a quick look and it seems to me that these paths are already tested by the Collection [MOAT](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java) test. This test is somewhat difficult to follow, but it tries to test all the proper assertions over all the different collection implementations. For this case it creates a singleton set at [line 201](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L201), which calls [testCollection()](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L1243), which calls [testCollection1()](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L1248), which eventually calls [checkFunctionalInvariants()](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L793). And finally at [line 815](https://github
 .com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L815) it checks toArray() with arrays of various lengths. So it may be that `SingletonSetToArray` isn't necessary. I see it does a check with a singleton set containing null, but I'm not sure that's actually necessary.

In the changes to the `ArrayList/AddAll.java` there is a test method `testSingletonSetToArray()`. Is this necessary, especially in light of the above?

Also in `ArrayList/AddAll.java` there are test methods `testArrayListFastPath()` and `testArrayListSubclassUsesSlowPath()`. These don't actually test whether the fast path or the slow path is used (and indeed, doing so would be hard, but we might have a discussion about how that could be tested, or even whether it should be tested). Instead, they mainly test that the *results* are as expected when calls are made that go through the different code paths. Hm, it doesn't seem like MOAT tests addAll(); that seems like an oversight. Well, it seems like some simplifications that can be done. There are a few combinations of inputs:

 * source is ArrayList or ArrayList subclass
 * source is empty or non-empty
 * destination is empty or non-empty
 * source contains nulls or not

(I'm not convinced we need separate cases for null in the contents.) In every case though there should be a unified set of assertion checks over the actual result.

It might be easier to do write this as a JUnit test instead of as open code in an old-school style `main` test. Or, it could be done as some enhancements to the MOAT tests. This poses its own challenges, but fundamentally it isn't difficult; you just have to wallow in that style for a while. :-)

I didn't look too closely at the `testModCountIncrement()` test method, but I'll observe that both JUnit and MOAT have an "expect this statement to throw an exception" construct.

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

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3505487562

From jvernee at openjdk.org  Sat Nov  8 01:18:13 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 8 Nov 2025 01:18:13 GMT
Subject: RFR: 8371474: Wrong object class or methodID passed to JNI call in
 TestSharedCloseJvmti with -Xshare:off
Message-ID: <CaWgC9giYzU1NtZCOvMnuDHwC8N4FoUoC-l2m3ODy3o=.5651ae4a-b733-44f3-95e6-7a94c9accffd@github.com>

The existing test uses the JVMTI `VMStart` callback to look up a class. This works when using CDS, because the class is already available, but because `VMStart` is called while the VM is still being initialized, it fails to find the target class when CDS is turned off.

Instead, the `VMInit` callback should be used instead, which runs after the VM has been initialized. This patch does this. Additionally, it delays the call to allocate `OTHER_SEGMENT`. If we call `FindClass` during `VMInit`, the `<clinit>` of the class will run, which then ends up calling `checkValidStateRaw` as a result of allocating `OTHER_SEGMENT`, and we get to our method exit event code before the target class and method ID have been initialized.

As a side note: I had know about the difference between `VMInit` and `VMStart`, and had actually intended to use `VMInit` in the first place, but I seem to have gotten the two confused, because they are listed in reverse chronological order in the list under 'Set Event Notification Mode' in the JVMTI spec (https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#SetEventNotificationMode).

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

Commit messages:
 - Make test work without CDS

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

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

From jbhateja at openjdk.org  Sat Nov  8 02:22:17 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 8 Nov 2025 02:22:17 GMT
Subject: RFR: 8370691: Add new HalffloatVector type and enable intrinsification
 of float16 vector operations
Message-ID: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>

Add new HalffloatVector type and corresponding concrete vector classes in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
- Add necessary inline expander support.
   - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
- Use existing Float16 vector IR and backend support.
- Extended the existing VectorAPI JTREG test suite for the newly added HalffloatVector operations.
 
The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).

The following are the performance numbers for some of the selected HalfflotVector benchmarking kernels compared to equivalent Float16OperationsBenchmark kernels.

<img width="837" height="650" alt="{A2BA2D85-085A-489F-8DDD-0FCFB5986EA5}" src="https://github.com/user-attachments/assets/2f34138e-80f4-4870-9b5f-f64bf43c1b11" />

Initial RFP[1] was floated on the panama-dev mailing list.

Kindly review the draft PR and share your feedback.

Best Regards,
Jatin

[1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

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

Commit messages:
 - Some cleanups
 - Fix some JTREG failures
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Revamped JTreg test generation and bug fixes
 - Cleanups
 - Removing redundant warmup constraint
 - Adding a HalffloatVectorBenchmark having benchmarking kernel parity with Float16OperationsBenchmark
 - Adding IR Framework test
 - Fix JTREG failures
 - Build failure fixes
 - ... and 1 more: https://git.openjdk.org/jdk/compare/e34a8318...c60d533c

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370691
  Stats: 66541 lines in 134 files changed: 54467 ins; 460 del; 11614 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

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

From almatvee at openjdk.org  Sat Nov  8 04:21:17 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 8 Nov 2025 04:21:17 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v2]
In-Reply-To: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
Message-ID: <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge remote-tracking branch 'upstream/master' into JDK-8363980
 - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v3]
 - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v2]
 - Merge remote-tracking branch 'upstream/master' into JDK-8363980
 - Merge remote-tracking branch 'upstream/master' into JDK-8363980
 - Merge remote-tracking branch 'upstream/master' into JDK-8363980
 - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime

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

Changes: https://git.openjdk.org/jdk/pull/28033/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28033&range=01
  Stats: 48 lines in 5 files changed: 30 ins; 9 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28033/head:pull/28033

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

From asemenyuk at openjdk.org  Sat Nov  8 06:08:27 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 8 Nov 2025 06:08:27 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v3]
In-Reply-To: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
Message-ID: <kT6zQs2ffFFK-2snWF8Ud-IqSEqi1QNTciOWpdVFDEE=.ddb7a354-e070-41d1-bb44-32b8671adb5d@github.com>

> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
> 
> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
> 
> ### Error reporting improved
> 
> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
> 
> Command line (Windows): 
> 
> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
> 
> Old error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> 
> 
> New error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> Error: Option [--mac-package-name] is not valid on this platform
> Error: Option [-p] is not valid with type [exe]
> Error: Option [--linux-menu-group] is not valid on this platform
> 
> 
>  2. Fix misleading error messages.
> 
> Command line (Windows): 
> 
> jpackage --input no --main-jar no.jar
> 
> Old error output:
> 
> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
> 
> 
> New error output:
> 
> The value "no" provided for parameter --input is not a directory
> 
> 
> 
> 
> ### Help output fixed
> 
> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
> 
> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
> 
> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
> 
> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
> 
> ### Functional changes
> 
> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
> 
> Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.
> 
> In addition to `--opt...

Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 35 new commits since the last revision:

 - Rework ExternalApplication and AppImageFile
 - the cli: after params removed
 - Add test to run multiple instances of jpackage tool provider asynchronously
 - MainResources.properties, MacResources.properties: remove obsolete IDs
 - Remove redundant copy of ObjectMapper.java
 - ErrorTest: follow up for changes in jpackage because of the cli; MainResources.properties: remove unused IDs
 - JPackageToolProvider.java: remove
 - Make jtreg tests work with the cli
 - main/Main.java: make it a proxy for the cli's Main
 - *Resources.properties: remove obsolete IDs
 - ... and 25 more: https://git.openjdk.org/jdk/compare/fde4f4b9...096e4051

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28163/files
  - new: https://git.openjdk.org/jdk/pull/28163/files/fde4f4b9..096e4051

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

  Stats: 99 lines in 9 files changed: 54 ins; 20 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/28163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28163/head:pull/28163

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

From alanb at openjdk.org  Sat Nov  8 07:13:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 8 Nov 2025 07:13:03 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <mrJgjSdUdbZzewM92E1bX5xpySlITzVZbiXZ6CwaE9o=.cdf90a68-8147-41ae-8244-e8765e41da88@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
 <VtSdmJSKc-Ll7Bt-OD4A5W2ov2zEj_8bjjXW3riswwk=.bf654dd9-42b4-4a29-9b28-dc77dc91ec1a@github.com>
 <mrJgjSdUdbZzewM92E1bX5xpySlITzVZbiXZ6CwaE9o=.cdf90a68-8147-41ae-8244-e8765e41da88@github.com>
Message-ID: <Tke4bHab3Y16a8uasfNgPqYYUDhwQbwSlvpg-x7xDOw=.93010116-aba3-4ae8-9797-48729ad5f505@github.com>

On Fri, 7 Nov 2025 16:43:48 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 600:
>> 
>>> 598:             ModuleReference target = finder.find("java.base").get();
>>> 599:             String currentRelease = getReleaseInfo(current).orElseThrow(() ->
>>> 600:                 new IllegalArgumentException("Cannot find release.txt"));
>> 
>> I assume this is an err.jlink.version.mismatch case too. The packaged version of java.base on the module path is missing the resource file so it must be an older version, hence a mismatch.
>
> This is for the current runtime of jlink, so this should never happen?

That's right. If getReleaseInfo(current) were to fail then it suggests a JDK build or other bug.

For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly?

If java.base is found on the module path but it doesn't contain the release file then the updated code to use "N/A" is okay as it feeds into the error message that jlink will print.

So I think the changes are nearly there. 

I've added the "csr" label to the PR as this change will need a CSR. There may be cases today that are cross linking successfully (they got lucky) but they will fail with the change due to the stricter check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2506343704

From alanb at openjdk.org  Sat Nov  8 07:17:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 8 Nov 2025 07:17:05 GMT
Subject: RFR: 8371474: Wrong object class or methodID passed to JNI call in
 TestSharedCloseJvmti with -Xshare:off
In-Reply-To: <CaWgC9giYzU1NtZCOvMnuDHwC8N4FoUoC-l2m3ODy3o=.5651ae4a-b733-44f3-95e6-7a94c9accffd@github.com>
References: <CaWgC9giYzU1NtZCOvMnuDHwC8N4FoUoC-l2m3ODy3o=.5651ae4a-b733-44f3-95e6-7a94c9accffd@github.com>
Message-ID: <XHKo_luGcPvUr4I6fOfvUa6pbJkFVwZ6lRfN732KIjo=.3cdf09d7-a0a9-43f8-ada9-b57b3c3af9d3@github.com>

On Fri, 7 Nov 2025 17:29:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> The existing test uses the JVMTI `VMStart` callback to look up a class. This works when using CDS, because the class is already available, but because `VMStart` is called while the VM is still being initialized, it fails to find the target class when CDS is turned off.
> 
> Instead, the `VMInit` callback should be used instead, which runs after the VM has been initialized. This patch does this. Additionally, it delays the call to allocate `OTHER_SEGMENT`. If we call `FindClass` during `VMInit`, the `<clinit>` of the class will run, which then ends up calling `checkValidStateRaw` as a result of allocating `OTHER_SEGMENT`, and we get to our method exit event code before the target class and method ID have been initialized.
> 
> As a side note: I had know about the difference between `VMInit` and `VMStart`, and had actually intended to use `VMInit` in the first place, but I seem to have gotten the two confused, because they are listed in reverse chronological order in the list under 'Set Event Notification Mode' in the JVMTI spec (https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#SetEventNotificationMode).

Yes, using VMInit so the code executes when the VM is fully initialized is right.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28202#pullrequestreview-3437716082

From syan at openjdk.org  Sat Nov  8 08:17:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 8 Nov 2025 08:17:39 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
Message-ID: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>

Hi all,

The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.

This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.

Change has been verified locally on linux-x64 by run the all touched tests.

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

Commit messages:
 - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests

Changes: https://git.openjdk.org/jdk/pull/28208/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371503
  Stats: 39 lines in 11 files changed: 2 ins; 20 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/28208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28208/head:pull/28208

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

From liach at openjdk.org  Sat Nov  8 13:56:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Nov 2025 13:56:05 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <fzQCP48AOnM_sAvhD0dMRiT4X8uRzW4-TlNcTamgCmk=.480bdc6b-687a-4bc9-8d13-ff392d98c9d1@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <fzQCP48AOnM_sAvhD0dMRiT4X8uRzW4-TlNcTamgCmk=.480bdc6b-687a-4bc9-8d13-ff392d98c9d1@github.com>
Message-ID: <3JOprtfyEvBcaGwc36e-4qD7pXLFJ_bWYce2CHerALQ=.95148986-fa08-4ec7-93d9-0014d075abb0@github.com>

On Sun, 2 Nov 2025 09:50:21 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update `@bug` in correct file
>>  - Add default implementation on codePointCount in CharSequence
>>  - Update `@bug` entries in test class doc comments
>>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`
>
> The CSR text is not modified from the boilerplate, but I have no authority to modify it.

Hi @tats-u, if you can provide the text for the CSR, I can help upload your text to the JBS. Unfortunately you need a JBS account in order to update the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3506558280

From liach at openjdk.org  Sat Nov  8 15:58:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Nov 2025 15:58:32 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
 [v2]
In-Reply-To: <FZq6CBx_fyQx2YEpp2MsF6f6YRpPRwoIeVx1m_7FOjw=.ba1ed9a1-c37b-442a-b8c5-b8b489adfd3d@github.com>
References: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
 <IZXKtP1X-lxkJrUaRk61IDTKZG4D7cJJW31XtFtDjqo=.542f242c-db52-4ac7-bf22-3cf281c7dee8@github.com>
 <FZq6CBx_fyQx2YEpp2MsF6f6YRpPRwoIeVx1m_7FOjw=.ba1ed9a1-c37b-442a-b8c5-b8b489adfd3d@github.com>
Message-ID: <ST0YkJj4FEeXnQHwPTA4kkhzkHro85ACaiF0pO0_BaU=.c6719cfe-c0c3-4dca-a651-2bfdf3dd698e@github.com>

On Tue, 4 Nov 2025 14:52:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>>  - Tweaks
>>  - 8370839: Tests to verify peculiar Proxy dispatching behaviors
>
> test/jdk/java/lang/reflect/Proxy/BridgeMethodsTest.java line 49:
> 
>> 47:     }
>> 48: 
>> 49:     // Does not duplicate with Object::clone so it is not proxied
> 
> Redundant comment?

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28023#discussion_r2506990177

From liach at openjdk.org  Sat Nov  8 15:58:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Nov 2025 15:58:29 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
 [v4]
In-Reply-To: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
References: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
Message-ID: <hMTx-S5qwmM328dii3nZqKLbdiFg3RvCbrUQmdBPBBo=.96905b50-8fce-4b2d-a773-af301251133b@github.com>

> java.lang.reflect.Proxy has some surprising behaviors associated with protected methods in Object, covariant/contravariant overrides in interfaces, and package-private types in method signatures. Such behaviors should have tests, so that they are not accidentally perturbed in Proxy updates.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/lang/reflect/Proxy/BridgeMethodsTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28023/files
  - new: https://git.openjdk.org/jdk/pull/28023/files/3b8c6d2a..e8ed5fab

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

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

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

From asemenyuk at openjdk.org  Sat Nov  8 16:44:17 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 8 Nov 2025 16:44:17 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v4]
In-Reply-To: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
Message-ID: <TD3gFoQBcWh1PNu4zza1W1FJmBNQWGhnRwqCXigKkU0=.d8ed9b21-bc73-43b2-97b8-1e26050f9ff7@github.com>

> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
> 
> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
> 
> ### Error reporting improved
> 
> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
> 
> Command line (Windows): 
> 
> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
> 
> Old error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> 
> 
> New error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> Error: Option [--mac-package-name] is not valid on this platform
> Error: Option [-p] is not valid with type [exe]
> Error: Option [--linux-menu-group] is not valid on this platform
> 
> 
>  2. Fix misleading error messages.
> 
> Command line (Windows): 
> 
> jpackage --input no --main-jar no.jar
> 
> Old error output:
> 
> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
> 
> 
> New error output:
> 
> The value "no" provided for parameter --input is not a directory
> 
> 
> 
> 
> ### Help output fixed
> 
> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
> 
> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
> 
> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
> 
> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
> 
> ### Functional changes
> 
> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
> 
> Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.
> 
> In addition to `--opt...

Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 27 new commits since the last revision:

 - Rework ExternalApplication and AppImageFile
 - the cli: after params removed
 - Add test to run multiple instances of jpackage tool provider asynchronously
 - MainResources.properties, MacResources.properties: remove obsolete IDs
 - Remove redundant copy of ObjectMapper.java
 - ErrorTest: follow up for changes in jpackage because of the cli; MainResources.properties: remove unused IDs
 - JPackageToolProvider.java: remove
 - Make jtreg tests work with the cli
 - main/Main.java: make it a proxy for the cli's Main
 - *Resources.properties: remove obsolete IDs
 - ... and 17 more: https://git.openjdk.org/jdk/compare/096e4051...da39bcc1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28163/files
  - new: https://git.openjdk.org/jdk/pull/28163/files/096e4051..da39bcc1

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

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

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

From duke at openjdk.org  Sat Nov  8 20:55:41 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Sat, 8 Nov 2025 20:55:41 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v2]
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <No7003mWJIaatVoaldhb1TJ6X4myjYp68LS1NyUvTCk=.6f8d27ff-d9ff-4335-8962-d3638df814c1@github.com>

> Add more precise message for IndexOutOfBoundsException in MemorySegment

Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:

  Fixes according to reviewer's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28124/files
  - new: https://git.openjdk.org/jdk/pull/28124/files/a106ac87..adc7a068

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

  Stats: 95 lines in 4 files changed: 65 ins; 7 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/28124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28124/head:pull/28124

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

From alan.bateman at oracle.com  Sun Nov  9 13:53:17 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 9 Nov 2025 13:53:17 +0000
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlByb3Bvc2UgdG8gcmVtb3ZlIHN1cHBvcnQgZm9y?=
 =?UTF-8?Q?_CompactStrings_off?=
In-Reply-To: <42963962-8763-46b7-aa7a-631838324efd@oracle.com>
References: <b27a2c9d-d268-4489-8b57-920090635dca.shaojin.wensj@alibaba-inc.com>
 <f46d0109-3dbe-4764-8c52-0b3843c85195@oracle.com>
 <08d048b2-5eb1-4db1-a169-a45e9f617b62.shaojin.wensj@alibaba-inc.com>
 <d26f06b5-cc53-4ec4-97bd-69eb9944f779@oracle.com>
 <09039475-af3e-43ed-8d6b-8e7678a2a053@oracle.com>
 <42963962-8763-46b7-aa7a-631838324efd@oracle.com>
Message-ID: <e81b4262-f4e4-4ab8-95a8-76d267dd9848@oracle.com>



On 06/11/2025 18:48, Stuart Marks wrote:
>
> Hi wenshao,
>
> I've written up a draft JEP for deprecating the disabling of Compact 
> Strings. There hasn't been a good term for running the system with 
> Compact Strings disabled, so I made up a term "UTF-16-only" and used 
> it here.
>
> https://openjdk.org/jeps/8371379
>
>
This is deprecating something that I assume most developers have never 
heard of. It's important that anyone reading the JEP will quickly see 
that this is not deprecating String, it's not dropping UTF-16, and it's 
not changing the String constructor that take a Charset. Instead it's 
all about JDK internal representation of String. No change needed to my 
code. I think the JEP needs a clear call-to-action:? Audit your 
application launch scripts and configuration to see if you are using 
-XX:-CompactStrings. If you are, remove it, and re-test/re-benchmark to 
see if see if there is any impact, preferably with a recent JDK release.

-Alan.


From dl at openjdk.org  Sun Nov  9 16:38:06 2025
From: dl at openjdk.org (Doug Lea)
Date: Sun, 9 Nov 2025 16:38:06 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v16]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <xHe7PX9jKbPqBeLAnvh6ZlGHgxmzox5u5jBjhL63KgY=.e3fad943-fc1a-4b3a-8e76-491c46dd4c7c@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea 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 25 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8360046
 - Seperate repolling policies
 - Faster quiescent termination
 - Fix push, refactor deactivate
 - Use absolute timed waits
 - Reduce deactivate/reactivate and cancelled timeout rates
 - Merge branch 'openjdk:master' into JDK-8360046
 - Reduce park/unpark rates
 - Add @Contended WorkQueue region. Adapt accordingly.
 - Revert Exchanger for separate PR
 - ... and 15 more: https://git.openjdk.org/jdk/compare/abecbe71...0f2f5908

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/48b8bda0..0f2f5908

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=14-15

  Stats: 279423 lines in 2896 files changed: 176769 ins; 61782 del; 40872 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

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

From duke at openjdk.org  Sun Nov  9 18:26:19 2025
From: duke at openjdk.org (ExE Boss)
Date: Sun, 9 Nov 2025 18:26:19 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v23]
In-Reply-To: <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
Message-ID: <moDgiO0Wfo9G3OriAvqQU1ug42ze11uJMOoDGbFLTO0=.0b51eb1d-9566-4b05-957a-9bf580a56ccc@github.com>

On Thu, 30 Oct 2025 10:30:05 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update api note

test/jdk/java/util/UUID/UUIDTest.java line 154:

> 152:         long timestamp = System.currentTimeMillis();
> 153:         try {
> 154:             UUID u = UUID.ofEpochMillis(timestamp);

Note?that this?test will?start?failing in?20889?[HE].

[HE]: https://en.wikipedia.org/wiki/Holocene_calendar

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2508236932

From swen at openjdk.org  Mon Nov 10 01:08:08 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 10 Nov 2025 01:08:08 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v13]
In-Reply-To: <0ImrQ-C7KG5hEJS0sm4dlL0DEuEg_yVrdWBFTzNLCB4=.789c6046-a2bc-4554-8329-1e1463956e2a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <0ImrQ-C7KG5hEJS0sm4dlL0DEuEg_yVrdWBFTzNLCB4=.789c6046-a2bc-4554-8329-1e1463956e2a@github.com>
Message-ID: <7Z1XwpauLLyMz9kTxEF4ijd1fddX-2UlPBm_4V8FJIk=.782b04fd-3009-4e63-b250-9f471fd9c3b6@github.com>

On Tue, 4 Nov 2025 13:21:06 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove assert & newCapacity

In the current version, the appendLatin(char c1, char c2) method provided by JavaLangAccess can be used in more scenarios, in addition to date scenarios, it can also be used in other places.

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

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3509058184

From syan at openjdk.org  Mon Nov 10 06:24:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 06:24:07 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
Message-ID: <HdeaUOSonudRRksAEEq9KmIMVMywA5lCi3LgEw__aHg=.1d680a89-f49a-43aa-bb84-8980cdab0603@github.com>

On Fri, 7 Nov 2025 15:28:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf 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 branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Fix include
>  - Add asserts/checks for input domain
>  - Add regression test for jdk-8370492
>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

test/hotspot/jtreg/containers/docker/TestMisc.java line 43:

> 41: import jdk.test.lib.process.OutputAnalyzer;
> 42: import jdk.test.lib.process.ProcessTools;
> 43: import jtreg.SkippedException;

Does this import 'import jtreg.SkippedException;' really needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2508898251

From syan at openjdk.org  Mon Nov 10 06:43:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 06:43:03 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
Message-ID: <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>

On Fri, 7 Nov 2025 15:28:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf 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 branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Fix include
>  - Add asserts/checks for input domain
>  - Add regression test for jdk-8370492
>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

Before apply the propose patch, test jdk/internal/platform/docker/TestDockerCpuMetrics.java run failed. After apply the propose patch, test jdk/internal/platform/docker/TestDockerCpuMetrics.java run passed.

test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java line 151:

> 149:             // have a 1-to-1 mapping from the cgroup v2 value to the OCI
> 150:             // value.
> 151:             System.out.println("Debug: cgv2 - Got CPU shares of: " +

I found you 'import jtreg.SkippedException;' on file test/hotspot/jtreg/containers/docker/TestMisc.java. Do you want to 'throw new SkippedException' rather that just print 'Skipping assert'

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

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3441113583
PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2508932192

From syan at openjdk.org  Mon Nov 10 06:54:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 06:54:02 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <ASoh-fa6MT-uff-yqZsI6Dyq112cKXtEGYcWkN4ir04=.d29e6ef5-64e6-4826-a09f-ce47007e596e@github.com>

On Fri, 7 Nov 2025 16:41:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 2:

> 1: /*
> 2:  * Copyright (C) 2025, IBM

Copyright (c) 2025 IBM Corporation. All rights reserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2508961551

From alanb at openjdk.org  Mon Nov 10 07:13:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Nov 2025 07:13:02 GMT
Subject: RFR: 8371431: Warning message when turning off CompactStrings
In-Reply-To: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>
References: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>
Message-ID: <weeO8hmWRYszulDr7T6vA5lRgjR2bjK4vVo8UqK61l0=.ddc84977-28e0-4566-b958-90305f75c038@github.com>

On Mon, 27 Oct 2025 01:26:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A warning message should be given before removing the CompactStrings off option.

There is discussion on core-libs-dev about creating a JEP to document the story in a way that gets to the far reaches of the galaxy where -XX:-CompactStrings might be used.

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

PR Comment: https://git.openjdk.org/jdk/pull/27995#issuecomment-3509778753

From jpai at openjdk.org  Mon Nov 10 08:07:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 08:07:22 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v23]
In-Reply-To: <moDgiO0Wfo9G3OriAvqQU1ug42ze11uJMOoDGbFLTO0=.0b51eb1d-9566-4b05-957a-9bf580a56ccc@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
 <moDgiO0Wfo9G3OriAvqQU1ug42ze11uJMOoDGbFLTO0=.0b51eb1d-9566-4b05-957a-9bf580a56ccc@github.com>
Message-ID: <ccjONjaWl9NC1pfg5h7pftIjtCSvlgHpreCLPvpjYs0=.b40d7438-c775-41f5-b341-91fa20ff2f84@github.com>

On Sun, 9 Nov 2025 18:23:01 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update api note
>
> test/jdk/java/util/UUID/UUIDTest.java line 154:
> 
>> 152:         long timestamp = System.currentTimeMillis();
>> 153:         try {
>> 154:             UUID u = UUID.ofEpochMillis(timestamp);
> 
> Note?that this?test will?start?failing in?20889?[HE].
> 
> [HE]: https://en.wikipedia.org/wiki/Holocene_calendar

Hello @ExE-Boss, what would be the failure in that case? I had a very brief looked at the linked page and I couldn't relate how that impacts the timestamp based on `UUID.ofEpocMillis(...)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2509187188

From alanb at openjdk.org  Mon Nov 10 08:36:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Nov 2025 08:36:09 GMT
Subject: RFR: 8370216: Fix of new File("").exists() causes undefined
 behavior in libraries
In-Reply-To: <FaQuOLJYQvRC5mvORfpcF3gRGqzfdOb98wr182okK_o=.5ae69365-1c89-421e-b799-f310c7122855@github.com>
References: <UlWA6NspyDBtVQEyD9V1UiyDp1Qn1nQznVk4q4Gx7E4=.82f7e8e0-9c11-49ff-8458-65ae70265d94@github.com>
 <wHGRmOmXZKhNVprWKCtY23sF-Gbg93X2SqVRacTAbx0=.bf517efa-1b66-4784-86fa-0edd58c1413c@github.com>
 <FaQuOLJYQvRC5mvORfpcF3gRGqzfdOb98wr182okK_o=.5ae69365-1c89-421e-b799-f310c7122855@github.com>
Message-ID: <Qf3yzaHBqlKILKvf5kA_jLJNzluUtggG4sQSacvYVsw=.44a74eb0-f9d7-41f5-9078-00c514a93d52@github.com>

On Fri, 7 Nov 2025 16:34:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> That's correct. Would it be better to change it to package scope?

It doesn't matter as the class is not public so the non-private members are only access to code in the java.io package.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28158#discussion_r2509283806

From sgehwolf at openjdk.org  Mon Nov 10 09:25:05 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 09:25:05 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
 <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
Message-ID: <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>

On Mon, 10 Nov 2025 06:38:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Severin Gehwolf 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 branch 'master' into jdk-8370492-fix-cpushares-mapping
>>  - Fix include
>>  - Add asserts/checks for input domain
>>  - Add regression test for jdk-8370492
>>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function
>
> test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java line 151:
> 
>> 149:             // have a 1-to-1 mapping from the cgroup v2 value to the OCI
>> 150:             // value.
>> 151:             System.out.println("Debug: cgv2 - Got CPU shares of: " +
> 
> I found you 'import jtreg.SkippedException;' on file test/hotspot/jtreg/containers/docker/TestMisc.java. Do you want to 'throw new SkippedException' rather that just print 'Skipping assert'

I'd rather not, since by throwing `SkippedException` the other tests won't run either. It's useful to see various values for the back-mapped value. In this case it should be a value < 1024 which is asserted by the if. Later, we have actual assertions in the test for `1024` and `2048`. Does that make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2509490319

From shade at openjdk.org  Mon Nov 10 09:26:06 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Nov 2025 09:26:06 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <a0H0mH4gtx3mH7cH68EjtJwPETNifusHmrtYBoIJN8c=.d6318db1-4ae8-44b5-b8f2-47352ec7c73c@github.com>

On Fri, 7 Nov 2025 16:41:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

Looks fine, a few nits.

test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 96:

> 94:         opts.addDockerOpts("--cgroup-parent=/" + cgroupParent);
> 95:         Common.run(opts)
> 96:             .shouldContain("Hierarchical Memory Limit is: " + expectedValue);

Indenting a a bit off here.

test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 107:

> 105:         Path sysFsMemory = Path.of("/", "sys", "fs", "cgroup", "memory");
> 106:         Path cgroupParentPath = sysFsMemory.resolve(cgroupParent);
> 107:         ProcessBuilder pb = new ProcessBuilder("mkdir", "-p", cgroupParentPath.toString());

So I am guessing we are fine with leaving this cgroup behind, after the test is done?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28201#pullrequestreview-3441857489
PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2509492642
PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2509498605

From sgehwolf at openjdk.org  Mon Nov 10 09:29:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 09:29:01 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572
In-Reply-To: <a0H0mH4gtx3mH7cH68EjtJwPETNifusHmrtYBoIJN8c=.d6318db1-4ae8-44b5-b8f2-47352ec7c73c@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <a0H0mH4gtx3mH7cH68EjtJwPETNifusHmrtYBoIJN8c=.d6318db1-4ae8-44b5-b8f2-47352ec7c73c@github.com>
Message-ID: <0aHFgeT-Ikjw_Ad_evc1OoWZ97gBC-nD-_8UdoXiyO4=.ff3d18a7-35d1-4828-b8bb-3cd9db962283@github.com>

On Mon, 10 Nov 2025 09:23:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
>> 
>> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
>> 
>> Testing (all on Linux x86_64):
>> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
>> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [X] CG version 1, run as non-root. Test skipped.
>> - [x] GHA, though I don't think this is very useful for this change.
>> 
>> Thoughts?
>
> test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 107:
> 
>> 105:         Path sysFsMemory = Path.of("/", "sys", "fs", "cgroup", "memory");
>> 106:         Path cgroupParentPath = sysFsMemory.resolve(cgroupParent);
>> 107:         ProcessBuilder pb = new ProcessBuilder("mkdir", "-p", cgroupParentPath.toString());
> 
> So I am guessing we are fine with leaving this cgroup behind, after the test is done?

Yes. Unfortunately it's not easy to remove that. However, the test itself resets it to "unlimited" by setting the limit to `-1`. So it shouldn't make a difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2509510367

From syan at openjdk.org  Mon Nov 10 09:41:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 09:41:03 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
 <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
 <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>
Message-ID: <91Wq6atcQ-B9y-oxN4qsk4F80m8jw53pbmzXcVxx_sQ=.18f531f3-921b-48df-8048-550441aa2b95@github.com>

On Mon, 10 Nov 2025 09:22:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java line 151:
>> 
>>> 149:             // have a 1-to-1 mapping from the cgroup v2 value to the OCI
>>> 150:             // value.
>>> 151:             System.out.println("Debug: cgv2 - Got CPU shares of: " +
>> 
>> I found you 'import jtreg.SkippedException;' on file test/hotspot/jtreg/containers/docker/TestMisc.java. Do you want to 'throw new SkippedException' rather that just print 'Skipping assert'
>
> I'd rather not, since by throwing `SkippedException` the other tests won't run either. It's useful to see various values for the back-mapped value. In this case it should be a value < 1024 which is asserted by the if. Later, we have actual assertions in the test for `1024` and `2048`. Does that make sense?

So does the 'import jtreg.SkippedException;' in file test/hotspot/jtreg/containers/docker/TestMisc.java seems do not needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2509574859

From vklang at openjdk.org  Mon Nov 10 10:02:10 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 10 Nov 2025 10:02:10 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v16]
In-Reply-To: <xHe7PX9jKbPqBeLAnvh6ZlGHgxmzox5u5jBjhL63KgY=.e3fad943-fc1a-4b3a-8e76-491c46dd4c7c@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xHe7PX9jKbPqBeLAnvh6ZlGHgxmzox5u5jBjhL63KgY=.e3fad943-fc1a-4b3a-8e76-491c46dd4c7c@github.com>
Message-ID: <ktXkJmcQd46AGfJmyvorLrzSnQeDZuD9-NJNky_nsOo=.995bed2e-2a6b-4477-8c70-c07fa7f645ff@github.com>

On Sun, 9 Nov 2025 16:38:06 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea 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 25 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8360046
>  - Seperate repolling policies
>  - Faster quiescent termination
>  - Fix push, refactor deactivate
>  - Use absolute timed waits
>  - Reduce deactivate/reactivate and cancelled timeout rates
>  - Merge branch 'openjdk:master' into JDK-8360046
>  - Reduce park/unpark rates
>  - Add @Contended WorkQueue region. Adapt accordingly.
>  - Revert Exchanger for separate PR
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/a2d555de...0f2f5908

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2059:

> 2057:                                 rescans = 1;
> 2058:                                 if (nt != null &&         // confirm a[nk]
> 2059:                                     U.getReferenceAcquire(a, np) == nt)

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2509671315

From alanb at openjdk.org  Mon Nov 10 10:06:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Nov 2025 10:06:31 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Merge branch 'master' into JDK-8353835
 - Fix typo in test comment
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Suppress warnings from some tests
 - Change -Xcheck:jni to be warning rather than fatal error
 - Merge branch 'master' into JDK-8353835
 - Simplify filter
 - Merge branch 'master' into JDK-8353835
 - Update Xcheck:jni description
 - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=09
  Stats: 4852 lines in 70 files changed: 4667 ins; 54 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From vyazici at openjdk.org  Mon Nov 10 10:18:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 10 Nov 2025 10:18:10 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
Message-ID: <gueTV_xhVN6XvbIV-iyw87yH3RWeQNLUlDL7tTcx_8E=.99e760de-0c58-4265-a885-4b9d5ecd254b@github.com>

On Mon, 10 Nov 2025 10:06:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3442211078

From sgehwolf at openjdk.org  Mon Nov 10 10:22:07 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 10:22:07 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <91Wq6atcQ-B9y-oxN4qsk4F80m8jw53pbmzXcVxx_sQ=.18f531f3-921b-48df-8048-550441aa2b95@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
 <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
 <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>
 <91Wq6atcQ-B9y-oxN4qsk4F80m8jw53pbmzXcVxx_sQ=.18f531f3-921b-48df-8048-550441aa2b95@github.com>
Message-ID: <XW4XWiVMXxs8Mf4hzTxGEGfCnQ-v5WrEp2QJaoq2l40=.f42bb708-d928-4ed9-994e-f1e75ba9bdc4@github.com>

On Mon, 10 Nov 2025 09:38:32 GMT, SendaoYan <syan at openjdk.org> wrote:

>> I'd rather not, since by throwing `SkippedException` the other tests won't run either. It's useful to see various values for the back-mapped value. In this case it should be a value < 1024 which is asserted by the if. Later, we have actual assertions in the test for `1024` and `2048`. Does that make sense?
>
> So does the 'import jtreg.SkippedException;' in file test/hotspot/jtreg/containers/docker/TestMisc.java seems do not needed

Yes, indeed. I'll remove it from `test/hotspot/jtreg/containers/docker/TestMisc.java`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2509756250

From alanb at openjdk.org  Mon Nov 10 10:41:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Nov 2025 10:41:03 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file
In-Reply-To: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
Message-ID: <abkeyn3jtyH1VohQUhenrEDArvEM-kQNfGvYwidGMIo=.42d838ad-4df9-426e-99a7-6ae20086ad58@github.com>

On Wed, 5 Nov 2025 17:29:10 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 257:

> 255:                         errorAndInvalid(formatMsg("error.validator.wrong.position", firstName, "0"));
> 256:                     }
> 257:                 }

This looks right, except that `entryInfo.cen().order()` is confusing to read. At some point we need to re-visit EntryEncounter and EntryInfo as the naming is very confusing. The cen member suggests it returns the CEN, and the order member is confusing too. Maybe

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2509860450

From pminborg at openjdk.org  Mon Nov 10 11:11:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 11:11:05 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v21]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <mW7TeaAZkRkmps0ITBT8LMdbEP7JPKL1lSixAc45KWQ=.7bdcb888-ae4b-428f-b286-bebb28078a8b@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits:

 - Merge master
 - Rework toString implementations
 - Update after doc comments
 - Merge branch 'master' into lazy-constants
 - Revert the AbstractMap.keySet @Stable annotation
 - Update docs after comments
 - Improve method docs
 - Improve equals/hashCode document
 - Update wording on List/Map Object methods
 - Update javadocs
 - ... and 97 more: https://git.openjdk.org/jdk/compare/681dab72...f775aaf1

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

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=20
  Stats: 8482 lines in 60 files changed: 3875 ins; 4490 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From pminborg at openjdk.org  Mon Nov 10 11:17:43 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 11:17:43 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v22]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <i7TM8ZzBjWYHIV28uZ2yCqPuRsYd-xeerIaSRpASFPI=.f9898317-3e6e-428e-ab18-c53d3e2f5059@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/f775aaf1..003eaf1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=20-21

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

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

From mdoerr at openjdk.org  Mon Nov 10 12:00:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 10 Nov 2025 12:00:02 GMT
Subject: RFR: 8371474: Wrong object class or methodID passed to JNI call in
 TestSharedCloseJvmti with -Xshare:off
In-Reply-To: <CaWgC9giYzU1NtZCOvMnuDHwC8N4FoUoC-l2m3ODy3o=.5651ae4a-b733-44f3-95e6-7a94c9accffd@github.com>
References: <CaWgC9giYzU1NtZCOvMnuDHwC8N4FoUoC-l2m3ODy3o=.5651ae4a-b733-44f3-95e6-7a94c9accffd@github.com>
Message-ID: <Gm5L4YE0v696RnCRbGJQMPEP04I0QZF1gUdFIzcZIhk=.a164d496-b892-4fb8-904d-e7d5f0576c6c@github.com>

On Fri, 7 Nov 2025 17:29:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> The existing test uses the JVMTI `VMStart` callback to look up a class. This works when using CDS, because the class is already available, but because `VMStart` is called while the VM is still being initialized, it fails to find the target class when CDS is turned off.
> 
> Instead, the `VMInit` callback should be used, which runs after the VM has been initialized. This patch does this. Additionally, it delays the call to allocate `OTHER_SEGMENT`. If we call `FindClass` during `VMInit`, the `<clinit>` of the class will run, which then ends up calling `checkValidStateRaw` as a result of allocating `OTHER_SEGMENT`, and we get to our method exit event code before the target class and method ID have been initialized.
> 
> As a side note: I had know about the difference between `VMInit` and `VMStart`, and had actually intended to use `VMInit` in the first place, but I seem to have gotten the two confused, because they are listed in reverse chronological order in the list under 'Set Event Notification Mode' in the JVMTI spec (https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#SetEventNotificationMode).

LGTM and fixes the issue. Thanks!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28202#pullrequestreview-3442830168

From pminborg at openjdk.org  Mon Nov 10 12:36:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 12:36:12 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <qdoshJM6YkMk1XK055rk8NLEb_mw0INP_ylFKSMPx2Y=.c52d2295-74d3-4681-8c56-14207a47a62e@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
 <qdoshJM6YkMk1XK055rk8NLEb_mw0INP_ylFKSMPx2Y=.c52d2295-74d3-4681-8c56-14207a47a62e@github.com>
Message-ID: <uAti75Ny7_zN9LInVXAewUujk3kcqIkzJuW_KqxbEro=.6652f9d9-2f8f-471d-83e0-69b90d5c9a51@github.com>

On Wed, 5 Nov 2025 23:31:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework toString implementations
>
> src/java.base/share/classes/java/util/Map.java line 1814:
> 
>> 1812:         final Set<K> keyCopies = Set.copyOf(keys);
>> 1813:         Objects.requireNonNull(computingFunction);
>> 1814:         if (keys instanceof EnumSet<?> && !keys.isEmpty()) {
> 
> I wonder if it's premature for us to optimize like this - for example, this would be wasteful if the key set contains one enum constant but there are 1000 enum constants in this enum.

There is a `min` and a `max` ordinal calculated, so in your example above, only one array item is used. I.e., if there are 1,000 enum constant and we are using enum with ordinal 42, then min = max = 42 and only a one-element array is ever allocated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2510377932

From duke at openjdk.org  Mon Nov 10 12:42:24 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Mon, 10 Nov 2025 12:42:24 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v3]
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <gQlFvGpBZow65qK_3USrhEpg1tV6NfcOtwLcpObPrvE=.017c85bd-2647-4a10-8feb-20f84767a2b5@github.com>

> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach

Igor Rudenko 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 three additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8346657
 - Fixes according to reviewer's comments
 - JDK-8346657: Improve out of bounds exception messages for MemorySegments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28124/files
  - new: https://git.openjdk.org/jdk/pull/28124/files/adc7a068..49c35fa7

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

  Stats: 165301 lines in 1040 files changed: 112298 ins; 24618 del; 28385 mod
  Patch: https://git.openjdk.org/jdk/pull/28124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28124/head:pull/28124

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

From pminborg at openjdk.org  Mon Nov 10 13:00:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 13:00:35 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v23]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <VdvBzwLN3yzDRSz3UYvaEJOKYaUtQVRVorlbDJc-dls=.81b0a2b8-3654-4cb0-bcd4-2f5649a222dc@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Address comments in PR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/003eaf1c..03616ef6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=21-22

  Stats: 119 lines in 6 files changed: 17 ins; 72 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From jvernee at openjdk.org  Mon Nov 10 13:45:18 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Nov 2025 13:45:18 GMT
Subject: RFR: 8371474: Wrong object class or methodID passed to JNI call in
 TestSharedCloseJvmti with -Xshare:off
In-Reply-To: <Gm5L4YE0v696RnCRbGJQMPEP04I0QZF1gUdFIzcZIhk=.a164d496-b892-4fb8-904d-e7d5f0576c6c@github.com>
References: <CaWgC9giYzU1NtZCOvMnuDHwC8N4FoUoC-l2m3ODy3o=.5651ae4a-b733-44f3-95e6-7a94c9accffd@github.com>
 <Gm5L4YE0v696RnCRbGJQMPEP04I0QZF1gUdFIzcZIhk=.a164d496-b892-4fb8-904d-e7d5f0576c6c@github.com>
Message-ID: <mvZ-DiiFFuOUZlNGm0LMzGLIiGYYS6atnRsyzuBuxiA=.1fdf63c4-7d7a-454d-86b0-9b2185ef3ac9@github.com>

On Mon, 10 Nov 2025 11:57:43 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> LGTM and fixes the issue. Thanks!

Thanks for the initial investigation!

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

PR Comment: https://git.openjdk.org/jdk/pull/28202#issuecomment-3511731763

From jvernee at openjdk.org  Mon Nov 10 13:58:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Nov 2025 13:58:50 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file
In-Reply-To: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
Message-ID: <0kXR9LUYkpot1AJkkAk659sl0To-INwK5nOwR9wxozI=.9c076fb1-04d9-4e54-89ef-28c48c30f3b1@github.com>

On Wed, 5 Nov 2025 17:29:10 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.

test/jdk/tools/jar/ValidatorTest.java line 354:

> 352:             jar("--validate --file " + path);
> 353:             fail("Expecting non-zero exit code validating: " + path);
> 354:         } catch (IOException e) {

It's just that `jar` method that throws the expected exception, right? Could you limit the length of the `try` block to not cover the nested try block? Otherwise, if `JarInputStream` starts throwing the same exception, this test would stop testing the `jar` method. (also I think it makes it a little clearer which line is expected to throw)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2510675268

From pminborg at openjdk.org  Mon Nov 10 14:59:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 14:59:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v24]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add @AOTSafeClassInitializer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/03616ef6..e479cb4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=22-23

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

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

From jvernee at openjdk.org  Mon Nov 10 15:00:47 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Nov 2025 15:00:47 GMT
Subject: Integrated: 8371474: Wrong object class or methodID passed to JNI call
 in TestSharedCloseJvmti with -Xshare:off
In-Reply-To: <CaWgC9giYzU1NtZCOvMnuDHwC8N4FoUoC-l2m3ODy3o=.5651ae4a-b733-44f3-95e6-7a94c9accffd@github.com>
References: <CaWgC9giYzU1NtZCOvMnuDHwC8N4FoUoC-l2m3ODy3o=.5651ae4a-b733-44f3-95e6-7a94c9accffd@github.com>
Message-ID: <ITfUmW43GTDg-3eaevfsPpz05HiGzbyC7Ob8sK2aHxU=.467c0d10-e88b-4e33-87cc-0fa2308f7db0@github.com>

On Fri, 7 Nov 2025 17:29:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> The existing test uses the JVMTI `VMStart` callback to look up a class. This works when using CDS, because the class is already available, but because `VMStart` is called while the VM is still being initialized, it fails to find the target class when CDS is turned off.
> 
> Instead, the `VMInit` callback should be used, which runs after the VM has been initialized. This patch does this. Additionally, it delays the call to allocate `OTHER_SEGMENT`. If we call `FindClass` during `VMInit`, the `<clinit>` of the class will run, which then ends up calling `checkValidStateRaw` as a result of allocating `OTHER_SEGMENT`, and we get to our method exit event code before the target class and method ID have been initialized.
> 
> As a side note: I had know about the difference between `VMInit` and `VMStart`, and had actually intended to use `VMInit` in the first place, but I seem to have gotten the two confused, because they are listed in reverse chronological order in the list under 'Set Event Notification Mode' in the JVMTI spec (https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#SetEventNotificationMode).

This pull request has now been integrated.

Changeset: 6e838d6f
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e838d6f9a59e4f14d4d1a6d4ff6ea857c0615e9
Stats:     7 lines in 2 files changed: 2 ins; 1 del; 4 mod

8371474: Wrong object class or methodID passed to JNI call in TestSharedCloseJvmti with -Xshare:off

Reviewed-by: alanb, mdoerr

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

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

From nbenalla at openjdk.org  Mon Nov 10 16:15:38 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 10 Nov 2025 16:15:38 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v4]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <_XezcddmMuD5koE3C1dJPmKhQGSfPHvi0tNBwaUv7oI=.0ffc5492-ca89-43ef-ac6c-b3e44bc11255@github.com>

> Get JDK 27 underway.

Nizar Benalla 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 six additional commits since the last revision:

 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Merge branch 'master' into start-of-release-27
 - update links to JVMS 26 and 27
 - add missing enum
 - initial commit start-of-JDK-27

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/b51f2324..0652d5d3

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

  Stats: 164507 lines in 1034 files changed: 112814 ins; 23251 del; 28442 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

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

From duke at openjdk.org  Mon Nov 10 16:18:23 2025
From: duke at openjdk.org (jengebr)
Date: Mon, 10 Nov 2025 16:18:23 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v4]
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <fdSWM3RautX5dbXujiKS6G1lGo2Gs_TyjNCzpmdHnV4=.f3dba870-f881-42e6-a709-4a4adf27fa66@github.com>

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

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

  Cleaning up tests per PR feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28116/files
  - new: https://git.openjdk.org/jdk/pull/28116/files/7725441a..6c333bdc

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

  Stats: 288 lines in 3 files changed: 36 ins; 250 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28116/head:pull/28116

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

From duke at openjdk.org  Mon Nov 10 16:31:37 2025
From: duke at openjdk.org (jengebr)
Date: Mon, 10 Nov 2025 16:31:37 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v5]
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <vSVVYdKkOvUOmmdFbICM87-yqIkBKShCnSUmt3sUsmo=.37a8728b-8e3a-4961-a84f-f179c93acec9@github.com>

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

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

  Whitespace fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28116/files
  - new: https://git.openjdk.org/jdk/pull/28116/files/6c333bdc..dd713ae0

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

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

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

From duke at openjdk.org  Mon Nov 10 16:31:37 2025
From: duke at openjdk.org (jengebr)
Date: Mon, 10 Nov 2025 16:31:37 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v2]
In-Reply-To: <WVR_t9MyNW76En_8qt0lFL2Qtr9Y_VvA7pBdl0Z_pKI=.39e45727-a079-4fbe-b201-0e114e2d292c@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <RsQ5PECszF1LnGTUHUnli8g0GWjU492cbsSThnkzBJ8=.46b8d5f1-4964-4824-b926-abd17f9deee3@github.com>
 <_9IEA2Ry-QyIC3YmOFWP6m-a9wGqdEBnlDKYKtgtXFE=.6cf71fd5-fbab-482b-97ed-2fc7bfcfc719@github.com>
 <WVR_t9MyNW76En_8qt0lFL2Qtr9Y_VvA7pBdl0Z_pKI=.39e45727-a079-4fbe-b201-0e114e2d292c@github.com>
Message-ID: <5riMTC0D0zfdjxs3rrDLTCyxp9-5dpGAU7AE_MveF8A=.ffdecdf1-d67b-4c17-ad83-8af8657ba2dc@github.com>

On Sat, 8 Nov 2025 00:39:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Further investigation into the duplication/de-duplication of the fastpath shows that I *cannot reproduce* the negative results - they are clearly logged, I simply can't generate new runs with the same data.  No idea why.
>> 
>> I've updated the code with the simplified branching, all comments are addressed.
>
> @jengebr Thanks for rechecking the benchmark. The ArrayList change looks much more sensible now, and I'm glad it performs to your expectations!
> 
> Regarding tests... I see you added a new test `SingletonSetToArray`. I took a quick look and it seems to me that these paths are already tested by the Collection [MOAT](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java) test. This test is somewhat difficult to follow, but it tries to test all the proper assertions over all the different collection implementations. For this case it creates a singleton set at [line 201](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L201), which calls [testCollection()](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L1243), which calls [testCollection1()](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L1248), which eventually calls [checkFunctionalInvariants()](https://github.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L793). And finally at [line 815](https://gith
 ub.com/openjdk/jdk/blob/jdk-26%2B23/test/jdk/java/util/Collection/MOAT.java#L815) it checks toArray() with arrays of various lengths. So it may be that `SingletonSetToArray` isn't necessary. I see it does a check with a singleton set containing null, but I'm not sure that's actually necessary.
> 
> In the changes to the `ArrayList/AddAll.java` there is a test method `testSingletonSetToArray()`. Is this necessary, especially in light of the above?
> 
> Also in `ArrayList/AddAll.java` there are test methods `testArrayListFastPath()` and `testArrayListSubclassUsesSlowPath()`. These don't actually test whether the fast path or the slow path is used (and indeed, doing so would be hard, but we might have a discussion about how that could be tested, or even whether it should be tested). Instead, they mainly test that the *results* are as expected when calls are made that go through the different code paths. Hm, it doesn't seem like MOAT tests addAll(); that seems like an oversight. Well, it seems like some simplifications that can be done. There are a few combinations of inputs:
> 
>  * source is ArrayList or ArrayList subclass
>  * source is empty or non-empty
>  * destination is empty or non-empty
>  * source contains nulls or not
> 
> (I'm not convinced we need separate cases for null in the contents.) In every case though there should be a unified set of asserti...

@stuart-marks thank you for the detailed feedback!  I've updated as follows:
1. Reverted ArrayList/AddAll, deleted the singleton test.
2. Added `testAddAll(Collection<Integer> c)` to MOAT
3. I implemented mostly as you described:
  1. I agree with "I'm not convinced we need separate cases for null in the contents." and did not implement them.
  1. I verified functionality of fast- and slow-paths, but did not attempt to verify which path executed.
  2. I stuck with MOAT-style.  JUnit has plenty of advantages, but this fits as a small change to the larger test.

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

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3512681722

From henryjen at openjdk.org  Mon Nov 10 16:35:13 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 10 Nov 2025 16:35:13 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <Tke4bHab3Y16a8uasfNgPqYYUDhwQbwSlvpg-x7xDOw=.93010116-aba3-4ae8-9797-48729ad5f505@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
 <VtSdmJSKc-Ll7Bt-OD4A5W2ov2zEj_8bjjXW3riswwk=.bf654dd9-42b4-4a29-9b28-dc77dc91ec1a@github.com>
 <mrJgjSdUdbZzewM92E1bX5xpySlITzVZbiXZ6CwaE9o=.cdf90a68-8147-41ae-8244-e8765e41da88@github.com>
 <Tke4bHab3Y16a8uasfNgPqYYUDhwQbwSlvpg-x7xDOw=.93010116-aba3-4ae8-9797-48729ad5f505@github.com>
Message-ID: <Z7kFecz4rYk0iq9blhcDOcD_tiLg99HXoAr2AV8sFdI=.e17fe485-a475-46af-8da7-0fe0049e5919@github.com>

On Sat, 8 Nov 2025 07:10:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly?

Yes, that's same behavior as before. I agree jlink should handle java.base not in the module path gracefully, I will add another error message to handle that. Do we want that for target release.txt as well? Since that's currently throwing IllegalArgumentException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511227667

From iris at openjdk.org  Mon Nov 10 16:35:13 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Nov 2025 16:35:13 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v4]
In-Reply-To: <_XezcddmMuD5koE3C1dJPmKhQGSfPHvi0tNBwaUv7oI=.0ffc5492-ca89-43ef-ac6c-b3e44bc11255@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <_XezcddmMuD5koE3C1dJPmKhQGSfPHvi0tNBwaUv7oI=.0ffc5492-ca89-43ef-ac6c-b3e44bc11255@github.com>
Message-ID: <4hRkyQC_Dpj1ojQuuFvjJEkFiFqCHqDQm_nnPjDRxfc=.c0a10797-cb7a-4987-9574-0b570acd21b0@github.com>

On Mon, 10 Nov 2025 16:15:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla 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 six additional commits since the last revision:
> 
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Merge branch 'master' into start-of-release-27
>  - update links to JVMS 26 and 27
>  - add missing enum
>  - initial commit start-of-JDK-27

Expected changes for JDK 27 looking good.

make/conf/version-numbers.conf line 36:

> 34: DEFAULT_VERSION_EXTRA2=0
> 35: DEFAULT_VERSION_EXTRA3=0
> 36: DEFAULT_VERSION_DATE=2026-09-15

Anticipated GA date confirmed.

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

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3444133407
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2511223183

From alanb at openjdk.org  Mon Nov 10 16:37:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Nov 2025 16:37:25 GMT
Subject: Integrated: 8367857: Implement JEP 525: Structured Concurrency (Sixth
 Preview)
In-Reply-To: <WxvoWLt25TKhLBNVb30MtFW7u4AkUrVMezcz3wjcH3g=.0654d0d0-e5f8-466c-95a2-bf49172b2127@github.com>
References: <WxvoWLt25TKhLBNVb30MtFW7u4AkUrVMezcz3wjcH3g=.0654d0d0-e5f8-466c-95a2-bf49172b2127@github.com>
Message-ID: <RGwFEHqkFHNf--FJmfFVErfKS8Xgexdu0LRWbl88xEw=.d555112d-fcb0-4a52-86e1-5c91c7632930@github.com>

On Fri, 19 Sep 2025 14:49:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Updates for JEP 525.
> 
> - `Joiner:onTimeout` is added  with `join` method changed to invoke this joiner method if
>   a timeout is configured and the timeout expires before or while waiting. The `onTimeout`
>   throws `TimeoutException` or may do nothing. This allows for `Joiner` implementation that
>   are capable of returning a result from the subtasks that complete before the timeout expires.
> - The `configFunction` parameter to the 3-arg `open` is changed from
>   `Function<Configuration, Configuration>` to `UnaryOperator<Configuration>`.
> - `Subtask::get` and `Subtask::exception` changed to consistently throw if called from
>   any thread before the scope owner has joined.
> - `StructuredTaskScope::join` is now specified so that it may be called again if interrupted.
> - The parameter on `Joiner::onFork` and `Joiner::onComplete` is changed from
>   `Subtask<? extends T` to `Subtask<T>`.
> - `Joiner.allSuccessOrThrow` is changed to return a list of results instead of a stream of
>   subtasks. `Joiner.allUntil` is changed to return a list of subtasks.
> - `Joiner.anySuccessfulResultOrThrow` is renamed to `anySuccessfulOrThrow`.
> - `Joiner.allUntil(Predicate)` is changed to allow `join` return the stream of all forked
> subtasks when the timeout expires.
> - `Joiner` is no longer a `@FunctionalInterface`.
> 
> Most of the changes are to API docs and tests. Some links are changed to use double hash mark.

This pull request has now been integrated.

Changeset: 0bae56b6
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bae56b6149f87e8ebd09291f96033d3e558263b
Stats:     839 lines in 6 files changed: 526 ins; 55 del; 258 mod

8367857: Implement JEP 525: Structured Concurrency (Sixth Preview)

Reviewed-by: vklang

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

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

From alanb at openjdk.org  Mon Nov 10 16:48:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Nov 2025 16:48:50 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <Z7kFecz4rYk0iq9blhcDOcD_tiLg99HXoAr2AV8sFdI=.e17fe485-a475-46af-8da7-0fe0049e5919@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
 <VtSdmJSKc-Ll7Bt-OD4A5W2ov2zEj_8bjjXW3riswwk=.bf654dd9-42b4-4a29-9b28-dc77dc91ec1a@github.com>
 <mrJgjSdUdbZzewM92E1bX5xpySlITzVZbiXZ6CwaE9o=.cdf90a68-8147-41ae-8244-e8765e41da88@github.com>
 <Tke4bHab3Y16a8uasfNgPqYYUDhwQbwSlvpg-x7xDOw=.93010116-aba3-4ae8-9797-48729ad5f505@github.com>
 <Z7kFecz4rYk0iq9blhcDOcD_tiLg99HXoAr2AV8sFdI=.e17fe485-a475-46af-8da7-0fe0049e5919@github.com>
Message-ID: <I1--01mGGSCbWCHMj0S47dMQxG_--zs6FdQEHDUVZJk=.6e9d943a-19cb-4dd0-baf1-4fe4de50929b@github.com>

On Mon, 10 Nov 2025 16:32:41 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> That's right. If getReleaseInfo(current) were to fail then it suggests a JDK build or other bug.
>> 
>> For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly?
>> 
>> If java.base is found on the module path but it doesn't contain the release file then the updated code to use "N/A" is okay as it feeds into the error message that jlink will print.
>> 
>> So I think the changes are nearly there. 
>> 
>> I've added the "csr" label to the PR as this change will need a CSR. There may be cases today that are cross linking successfully (they got lucky) but they will fail with the change due to the stricter check.
>
>> For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly?
> 
> Yes, that's same behavior as before. I agree jlink should handle java.base not in the module path gracefully, I will add another error message to handle that. Do we want that for target release.txt as well? Since that's currently throwing IllegalArgumentException.

I think this is an err.jlink.version.mismatch, of sorts, case. The user has run the jlink command with a module path containing a version of java.base that is at least one feature release old. I think a mismatch would be less confusing than an IllegalArgumentException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511266937

From sgehwolf at openjdk.org  Mon Nov 10 17:43:03 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 17:43:03 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <YMQBd3jKhOf-3EpB2EYiC-1_RB-hfyRyt_M0vEranrU=.515ae5d2-8f2f-4bcc-929c-ac7493e0f2e2@github.com>

On Fri, 7 Nov 2025 16:41:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

Thanks for the reviews. Updated the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/28201#issuecomment-3513094003

From sgehwolf at openjdk.org  Mon Nov 10 17:43:05 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 17:43:05 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <ASoh-fa6MT-uff-yqZsI6Dyq112cKXtEGYcWkN4ir04=.d29e6ef5-64e6-4826-a09f-ce47007e596e@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <ASoh-fa6MT-uff-yqZsI6Dyq112cKXtEGYcWkN4ir04=.d29e6ef5-64e6-4826-a09f-ce47007e596e@github.com>
Message-ID: <1qZYZuODZnsxbV1e3S7_xemZyrGNBwtBuUns2K1hJrU=.c0282af9-4ed8-4b52-82f9-6b4f62b41ae8@github.com>

On Mon, 10 Nov 2025 06:51:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Indenting and copyright
>
> test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (C) 2025, IBM
> 
> Copyright (c) 2025 IBM Corporation. All rights reserved.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2511417869

From sgehwolf at openjdk.org  Mon Nov 10 17:43:02 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 17:43:02 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Indenting and copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28201/files
  - new: https://git.openjdk.org/jdk/pull/28201/files/86f8e1b8..faeff2a1

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

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

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

From shade at openjdk.org  Mon Nov 10 17:45:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Nov 2025 17:45:17 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
Message-ID: <K6EsU8RCj9JycGg_Vid0pH9gfe3wqRxb6JP9Tq5TLZk=.a40ab45d-f446-4151-8fe3-8c074af7b227@github.com>

On Mon, 10 Nov 2025 17:43:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
>> 
>> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
>> 
>> Testing (all on Linux x86_64):
>> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
>> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [X] CG version 1, run as non-root. Test skipped.
>> - [x] GHA, though I don't think this is very useful for this change.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting and copyright

Still good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28201#pullrequestreview-3444430112

From sgehwolf at openjdk.org  Mon Nov 10 17:45:57 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 17:45:57 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v3]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <iXsBU0cKqFLwnH1Zn5F9X2anCrFXg3hXnIzEgfJoDFg=.78353547-8be9-43ed-b485-18da00e7a96b@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Remove SkippedException import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/464d162f..8ba999a9

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

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

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

From henryjen at openjdk.org  Mon Nov 10 17:56:36 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 10 Nov 2025 17:56:36 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <I1--01mGGSCbWCHMj0S47dMQxG_--zs6FdQEHDUVZJk=.6e9d943a-19cb-4dd0-baf1-4fe4de50929b@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
 <VtSdmJSKc-Ll7Bt-OD4A5W2ov2zEj_8bjjXW3riswwk=.bf654dd9-42b4-4a29-9b28-dc77dc91ec1a@github.com>
 <mrJgjSdUdbZzewM92E1bX5xpySlITzVZbiXZ6CwaE9o=.cdf90a68-8147-41ae-8244-e8765e41da88@github.com>
 <Tke4bHab3Y16a8uasfNgPqYYUDhwQbwSlvpg-x7xDOw=.93010116-aba3-4ae8-9797-48729ad5f505@github.com>
 <Z7kFecz4rYk0iq9blhcDOcD_tiLg99HXoAr2AV8sFdI=.e17fe485-a475-46af-8da7-0fe0049e5919@github.com>
 <I1--01mGGSCbWCHMj0S47dMQxG_--zs6FdQEHDUVZJk=.6e9d943a-19cb-4dd0-baf1-4fe4de50929b@github.com>
Message-ID: <8L7V95kBIoSQmh13eBqQqk9C1syY8k1Ry2KdFBo7unc=.818ea522-47a8-4b6f-b30f-0ba17b60b9db@github.com>

On Mon, 10 Nov 2025 16:45:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly?
>> 
>> Yes, that's same behavior as before. I agree jlink should handle java.base not in the module path gracefully, I will add another error message to handle that. Do we want that for target release.txt as well? Since that's currently throwing IllegalArgumentException.
>
> I think this is an err.jlink.version.mismatch, of sorts, case. The user has run the jlink command with a module path containing a version of java.base that is at least one feature release old. I think a mismatch would be less confusing than an IllegalArgumentException.

For target java.base not having release.txt will show mismatch against build "N/A". But I am thinking I will tighten it up to avoid current release.txt is have a value "N/A".

What I am talking about is should we fail gracefully on current java.base for jlink not having a release.txt, which should not happen with a proper build. In that sense, an IllegalArgumentException is not that bad.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511460040

From liach at openjdk.org  Mon Nov 10 18:06:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Nov 2025 18:06:03 GMT
Subject: RFR: 8371319: java.lang.reflect.Method#equals doesn't short-circuit
 with same instances
Message-ID: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>

There is currently no shortcut for fast equals for Method or Constructor. While the comparison for declaring class, name (interned strings' identity), and return type are very efficient with identity comparison, the comparison for parameter type is not so much: We always have to iterate through every parameter.

Luckily, even though we are burdened with the different method and constructor instance due to setAccessible, their parameter type arrays are shared most of the time; in particular, in the same root method/constructor hierarchy, all instances share the same method object. Thus, we can perform a `==` check on the incoming array to provide a fast path.

Benchmark numbers before and after:

Benchmark                                    Mode  Cnt  Score   Error  Units
ExecutableCompareBenchmark.distinctParams    avgt    5  1.189 ? 0.024  ns/op
ExecutableCompareBenchmark.equalMethods      avgt    5  2.449 ? 0.033  ns/op
ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.541 ? 0.027  ns/op

Benchmark                                    Mode  Cnt  Score   Error  Units
ExecutableCompareBenchmark.distinctParams    avgt    5  1.186 ? 0.042  ns/op
ExecutableCompareBenchmark.equalMethods      avgt    5  1.078 ? 0.049  ns/op
ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.395 ? 0.018  ns/op

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

Commit messages:
 - Short-circuiting for equal methods

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

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

From henryjen at openjdk.org  Mon Nov 10 18:22:15 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 10 Nov 2025 18:22:15 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v2]
In-Reply-To: <8L7V95kBIoSQmh13eBqQqk9C1syY8k1Ry2KdFBo7unc=.818ea522-47a8-4b6f-b30f-0ba17b60b9db@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <uJa6Sb8iQ2SF-UULYUWv0wTmOihIAWc28JN9ClL3UcY=.0ad9a6c0-fb8e-4eb4-b365-c803acb385f7@github.com>
 <VtSdmJSKc-Ll7Bt-OD4A5W2ov2zEj_8bjjXW3riswwk=.bf654dd9-42b4-4a29-9b28-dc77dc91ec1a@github.com>
 <mrJgjSdUdbZzewM92E1bX5xpySlITzVZbiXZ6CwaE9o=.cdf90a68-8147-41ae-8244-e8765e41da88@github.com>
 <Tke4bHab3Y16a8uasfNgPqYYUDhwQbwSlvpg-x7xDOw=.93010116-aba3-4ae8-9797-48729ad5f505@github.com>
 <Z7kFecz4rYk0iq9blhcDOcD_tiLg99HXoAr2AV8sFdI=.e17fe485-a475-46af-8da7-0fe0049e5919@github.com>
 <I1--01mGGSCbWCHMj0S47dMQxG_--zs6FdQEHDUVZJk=.6e9d943a-19cb-4dd0-baf1-4fe4de50929b@github.com>
 <8L7V95kBIoSQmh13eBqQqk9C1syY8k1Ry2KdFBo7unc=.818ea522-47a8-4b6f-b30f-0ba17b60b9db@github.com>
Message-ID: <-dh84-9SlqU-Gpo4nEu7gt_YUKV_D_qep1P15RjmNgo=.76d9de05-8062-430d-ab9a-c5fdb5bb4fc7@github.com>

On Mon, 10 Nov 2025 17:53:50 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> I think this is an err.jlink.version.mismatch, of sorts, case. The user has run the jlink command with a module path containing a version of java.base that is at least one feature release old. I think a mismatch would be less confusing than an IllegalArgumentException.
>
> For target java.base not having release.txt will show mismatch against build "N/A". But I am thinking I will tighten it up to avoid current release.txt is have a value "N/A".
> 
> What I am talking about is should we fail gracefully on current java.base for jlink not having a release.txt, which should not happen with a proper build. In that sense, an IllegalArgumentException is not that bad.

Sorry for the confusion, if a java.base cannot be found with given module path, java.base from current jlink runtime is to be used. That has been checked in initJlinkConfig() before calling checkBaseJavaVersion. That's why NoSuchElementException is caught with an assert in the initial PR.

I'll rafactor the code to make that more clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511535066

From forax at openjdk.org  Mon Nov 10 18:33:35 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 10 Nov 2025 18:33:35 GMT
Subject: RFR: 8371319: java.lang.reflect.Method#equals doesn't
 short-circuit with same instances
In-Reply-To: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
References: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
Message-ID: <1fSUyBsHvyymAKXHq7DNLw25wVlbMpvYkPcF-CII94U=.687f5dba-acc6-4596-a051-323dd51b5f89@github.com>

On Mon, 10 Nov 2025 17:59:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There is currently no shortcut for fast equals for Method or Constructor. While the comparison for declaring class, name (interned strings' identity), and return type are very efficient with identity comparison, the comparison for parameter type is not so much: We always have to iterate through every parameter.
> 
> Luckily, even though we are burdened with the different method and constructor instance due to setAccessible, their parameter type arrays are shared most of the time; in particular, in the same root method/constructor hierarchy, all instances share the same method object. Thus, we can perform a `==` check on the incoming array to provide a fast path.
> 
> Benchmark numbers before and after:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.189 ? 0.024  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  2.449 ? 0.033  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.541 ? 0.027  ns/op
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.186 ? 0.042  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  1.078 ? 0.049  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.395 ? 0.018  ns/op

Hello Chen,
Beware !

You may have also to test with ZGC (during the relocation phase),
because == may not be as fast as a pointer check.

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

PR Comment: https://git.openjdk.org/jdk/pull/28221#issuecomment-3513311587

From stuart.marks at oracle.com  Mon Nov 10 20:09:45 2025
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 10 Nov 2025 12:09:45 -0800
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlByb3Bvc2UgdG8gcmVtb3ZlIHN1cHBvcnQgZm9y?=
 =?UTF-8?Q?_CompactStrings_off?=
In-Reply-To: <e81b4262-f4e4-4ab8-95a8-76d267dd9848@oracle.com>
References: <b27a2c9d-d268-4489-8b57-920090635dca.shaojin.wensj@alibaba-inc.com>
 <f46d0109-3dbe-4764-8c52-0b3843c85195@oracle.com>
 <08d048b2-5eb1-4db1-a169-a45e9f617b62.shaojin.wensj@alibaba-inc.com>
 <d26f06b5-cc53-4ec4-97bd-69eb9944f779@oracle.com>
 <09039475-af3e-43ed-8d6b-8e7678a2a053@oracle.com>
 <42963962-8763-46b7-aa7a-631838324efd@oracle.com>
 <e81b4262-f4e4-4ab8-95a8-76d267dd9848@oracle.com>
Message-ID: <198051d4-3ee9-4f13-a8bf-d2b096a2b5b3@oracle.com>



>> I've written up a draft JEP for deprecating the disabling of Compact Strings. 
>> There hasn't been a good term for running the system with Compact Strings 
>> disabled, so I made up a term "UTF-16-only" and used it here.
>>
>> https://openjdk.org/jeps/8371379
>>
> This is deprecating something that I assume most developers have never heard of. 
> It's important that anyone reading the JEP will quickly see that this is not 
> deprecating String, it's not dropping UTF-16, and it's not changing the String 
> constructor that take a Charset. Instead it's all about JDK internal representation 
> of String. No change needed to my code. I think the JEP needs a clear call-to- 
> action:? Audit your application launch scripts and configuration to see if you are 
> using -XX:-CompactStrings. If you are, remove it, and re-test/re-benchmark to see if 
> see if there is any impact, preferably with a recent JDK release.

Good points about what the JEP should say. I've updated it.

Pretty much every article I've seen that describes Compact Strings also mentions the 
-XX:-CompactStrings option, so the option seems fairly well known. (In addition to 
it appearing in our documentation.) However, we don't know how many people actually 
*use* the option. I suspect there might be a long tail of conservative ("don't touch 
anything!") folks who added it a long time ago out of an abundance of caution and 
forgot about it, so it would be good to get the word out as widely as possible.

s'marks


From liach at openjdk.org  Mon Nov 10 20:27:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Nov 2025 20:27:39 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
Message-ID: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>

On Mon, 10 Nov 2025 10:06:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02

I still wonder about the decision for JNI to call final Field.set with an unconditional export check instead of an unconditional open check - the open check is done for all Java code already.

src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 56:

> 54:     <li><a href="../Field.html#setDouble(java.lang.Object,double)">
> 55:         java.lang.reflect.Field.setDouble(Object, double)</a></li>
> 56:     <li><a href="{@docRoot}/java.base/java/lang/invoke/MethodHandles.Lookup.html#unreflectSetter(java.lang.reflect.Field)">

Nit: Since javadoc process tags here, you could just use `{@link Field#set java.lang.reflect.Field.set(Object, Object)}` instead of full-fledged a tags.

src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 66:

> 64: <p> In the reference implementation, a module can be granted the capability to mutate
> 65: final instance fields of classes in packages that are open to the module using
> 66: the command line option <code>--enable-final-field-mutation=M1,M2, ... M}</code> where

Suggestion:

the command line option <code>--enable-final-field-mutation=M1,M2, ... Mn}</code> where

src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 72:

> 70: <em>illegal</em>.
> 71: 
> 72: The command line option <code>--illegal-final-field-mutation</code> controls how illegal

Missing `<p>`?

test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 234:

> 232:     @Test
> 233:     void testSetPropertyToAllow() throws Exception {
> 234:         test("setSystemPropertyToAllow+testFieldSetInt")

I thought this was setting the property before the VM boot. Can we have another test that does something like:

test("testFieldSetInt", "-Djdk.module.illegal.final.field.mutation=allow")

Which I think is closer to what @vy asks for.

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

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3444803078
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511838513
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511840059
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511841318
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511708135

From liach at openjdk.org  Mon Nov 10 20:27:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Nov 2025 20:27:41 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: <hHCto7awcMiCRgApOPp3OEpbrGy5BcQAVnwhVAyBwH0=.d8974829-8f29-491c-b09d-ce3e2e544463@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <e9iXm-BSdvvUoZQK3aAarNc0ER3GwByVS9UorOyeyJs=.cab06bfc-81be-4f9c-ac06-b142af67db0f@github.com>
 <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
 <hHCto7awcMiCRgApOPp3OEpbrGy5BcQAVnwhVAyBwH0=.d8974829-8f29-491c-b09d-ce3e2e544463@github.com>
Message-ID: <VtpwemFcbpFE0MfmBirqkyqvjWyoIqUvk-biNoPdxms=.1aa009e3-d9b1-4bf3-a3ed-64ac68dbc25e@github.com>

On Tue, 30 Sep 2025 08:12:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 2281:
>> 
>>> 2279:       }
>>> 2280:     } else if (match_option(option, "--illegal-final-field-mutation=", &tail)) {
>>> 2281:       if (strcmp(tail, "allow") == 0 || strcmp(tail, "warn") == 0 || strcmp(tail, "debug") == 0 || strcmp(tail, "deny") == 0) {
>> 
>> Is the `jdk.module.illegal.final.field.mutation` property intended as a public API? If so, where is it documented?
>
> System properties are used to "communicate" the value of options from the VM to the library code. All internal/undocumented.  There is a test in mutateFinal/cli/CommandLineTests.java that checks that specifying the system property on the command line is not effective.

In my followup investigation for how InternalProperty/internal() flag really works, I noted it has been effectively broken since the recent updates - back in 2018, the referenced VM.saveAndRemoveProperties is gone, and now filtering is done by System.createProperties. We should probably address that in another RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511752805

From henryjen at openjdk.org  Mon Nov 10 20:44:34 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 10 Nov 2025 20:44:34 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
Message-ID: <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>

> This PR include build changes from @magicus and jlink change to verify the build signature.
> 
> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
> 
> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>                                                                                                                                                                  
> ? java --version
> openjdk 26-internal 2026-03-17
> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>                                                                                                                                                                  
> ? jlink --version                                                                       
> 26-internal
>                                                                                                                                                                  
> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>                                                                                                                                                                  
> ? jlink --add-modules java.base --output macos
>                                                             
> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>                                                                                                                                                                  
> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Refactoring to clarify version checking cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28155/files
  - new: https://git.openjdk.org/jdk/pull/28155/files/8df7e809..68584d93

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

  Stats: 54 lines in 1 file changed: 27 ins; 13 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/28155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155

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

From acobbs at openjdk.org  Mon Nov 10 22:24:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 10 Nov 2025 22:24:52 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v5]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@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 135 commits:

 - Suppress new unnecessary suppresion warnings created by recent commits.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - 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.
 - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=04
  Stats: 1667 lines in 35 files changed: 1492 ins; 49 del; 126 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 asemenyuk at openjdk.org  Mon Nov 10 22:38:05 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 10 Nov 2025 22:38:05 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v2]
In-Reply-To: <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>
Message-ID: <nbdJKX6qhYxeWcjvykwCrENkY627SFUUYXxNZGCN9mc=.be3aa5be-52d1-464f-a393-94f526d1fdc6@github.com>

On Sat, 8 Nov 2025 04:21:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added JDK specific keys/values to Info.plist of embedded runtime.
>> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
>> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.
>
> Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8363980
>  - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v3]
>  - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v2]
>  - Merge remote-tracking branch 'upstream/master' into JDK-8363980
>  - Merge remote-tracking branch 'upstream/master' into JDK-8363980
>  - Merge remote-tracking branch 'upstream/master' into JDK-8363980
>  - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime

Loogs good. The missing piece is testing that the info plist file of the embedded runtime contains/doesn't contain JDK keys.

For this purpose, I'd add a new item to the list of standard verifiers in the JPackageCommand class. This way, the info plist file of the embedded runtime will be automatically verified in all jpackage tests. Something like:

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

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3514185661

From liach at openjdk.org  Mon Nov 10 23:18:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Nov 2025 23:18:06 GMT
Subject: RFR: 8371319: java.lang.reflect.Method#equals doesn't
 short-circuit with same instances
In-Reply-To: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
References: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
Message-ID: <ktMMUzu6RHO-qW1z-4UuKb7pDqfJ18OUYi3FE7km5fU=.ec73b71f-a722-4db0-9532-d82da49036f5@github.com>

On Mon, 10 Nov 2025 17:59:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There is currently no shortcut for fast equals for Method or Constructor. While the comparison for declaring class, name (interned strings' identity), and return type are very efficient with identity comparison, the comparison for parameter type is not so much: We always have to iterate through every parameter.
> 
> Luckily, even though we are burdened with the different method and constructor instance due to setAccessible, their parameter type arrays are shared most of the time; in particular, in the same root method/constructor hierarchy, all instances share the same method object. Thus, we can perform a `==` check on the incoming array to provide a fast path.
> 
> Benchmark numbers before and after:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.189 ? 0.024  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  2.449 ? 0.033  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.541 ? 0.027  ns/op
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.186 ? 0.042  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  1.078 ? 0.049  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.395 ? 0.018  ns/op

Remi, are you talking about my optimization code or the == case in my benchmark?
I think the Method/Constructor equals implementations are already == heavy; it might not hurt that much with one more == before the array content comparisons.

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

PR Comment: https://git.openjdk.org/jdk/pull/28221#issuecomment-3514294668

From duke at openjdk.org  Mon Nov 10 23:37:20 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Mon, 10 Nov 2025 23:37:20 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v4]
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <HfVBDCcdYxJzKq7dgGlZ3WPi3u66awEMEXJ750XoAC8=.93066c6a-a499-4a7b-809f-a261de842fe6@github.com>

> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach

Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:

  Remove the length > 0 condition, as it brakes multiple unit tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28124/files
  - new: https://git.openjdk.org/jdk/pull/28124/files/49c35fa7..53f68ba9

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

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

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

From psandoz at openjdk.org  Tue Nov 11 00:02:04 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 11 Nov 2025 00:02:04 GMT
Subject: RFR: 8370691: Add new HalffloatVector type and enable
 intrinsification of float16 vector operations
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>

On Mon, 27 Oct 2025 15:19:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Add new HalffloatVector type and corresponding concrete vector classes in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added HalffloatVector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected HalfflotVector benchmarking kernels compared to equivalent Float16OperationsBenchmark kernels.
> 
> <img width="837" height="650" alt="{A2BA2D85-085A-489F-8DDD-0FCFB5986EA5}" src="https://github.com/user-attachments/assets/2f34138e-80f4-4870-9b5f-f64bf43c1b11" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Some quick comments.

We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.

When you generate the fallback code for unary/binary etc can you push the carrier type and conversations into the uOp/bOp implementations so you don't have to explicitly operate on the carrier type and do the conversions as you do now e.g.,:

v0.uOp(m, (i, a) -> float16ToShortBits(Float16.valueOf(-(shortBitsToFloat16(($type$)a).floatValue()))));


The transition of intrinsic arguments from `vsp.elementType()` to `vsp.carrierType(), vsp.operType()` is a little unfortunate. Is this because HotSpot cannot directly refer to the `Float16` class from the incubating module? Requiring two arguments means they can get out of sync. Previously the class provided all the information needed, now arguably the type does.

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

PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3445662107

From duke at openjdk.org  Tue Nov 11 00:06:23 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Tue, 11 Nov 2025 00:06:23 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v5]
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <IDHizqRpokw7EAIwhtptzqtp67-nB2wqB5fj0DEFPhI=.c24ba8a3-845a-4f1a-89bb-e14c47c89913@github.com>

> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach

Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:

  missed condition fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28124/files
  - new: https://git.openjdk.org/jdk/pull/28124/files/53f68ba9..fb7b28c0

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

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

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

From darcy at openjdk.org  Tue Nov 11 01:02:05 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 11 Nov 2025 01:02:05 GMT
Subject: RFR: 8370691: Add new HalffloatVector type and enable
 intrinsification of float16 vector operations
In-Reply-To: <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
Message-ID: <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>

On Mon, 10 Nov 2025 23:58:57 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Some quick comments.
> 
> We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
>

I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3514526479

From duke at openjdk.org  Tue Nov 11 02:53:23 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 11 Nov 2025 02:53:23 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder()
Message-ID: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>

When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.

Example:


TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
sortedSet.add(1);
sortedSet.add(2);
// SortedOps.OfRef.opWrapSink is not a no-op
sortedSet.stream().sorted().forEach(System.out::println);

or

TreeSet<Integer> sortedSet = new TreeSet<>();
sortedSet.add(1);
sortedSet.add(2);
// SortedOps.OfRef.opWrapSink is not a no-op
sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);


This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

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

Commit messages:
 - 8362958: Unnecessary copying / sorting in Streams using Comparator.naturalOrder()

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

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

From syan at openjdk.org  Tue Nov 11 02:57:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Nov 2025 02:57:08 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v3]
In-Reply-To: <iXsBU0cKqFLwnH1Zn5F9X2anCrFXg3hXnIzEgfJoDFg=.78353547-8be9-43ed-b485-18da00e7a96b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <iXsBU0cKqFLwnH1Zn5F9X2anCrFXg3hXnIzEgfJoDFg=.78353547-8be9-43ed-b485-18da00e7a96b@github.com>
Message-ID: <9_mUShL9w0WJOY_mRnI9Q6kjahjGy5C4r2nskAj84UU=.b998be5a-042f-4bcc-8eae-e5aaf485642c@github.com>

On Mon, 10 Nov 2025 17:45:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove SkippedException import

This fix works for me

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3446022550

From davidalayachew at gmail.com  Tue Nov 11 03:36:29 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Nov 2025 22:36:29 -0500
Subject: Difficulties of recursion with Streams
Message-ID: <CAA9v-_OMFfDGHCOgqDe1jA7LgFZ6hT4owtkd5d5+sxhHOQvCQQ@mail.gmail.com>

Hello @core-libs-dev <core-libs-dev at openjdk.org>,

When working with streams, I often run into situations where I have to
"demote" back to imperative code because I am trying to solve a problem
best solved by recursion.

Consider the common use case of cycling through permutations to find all
permutations that satisfy some condition. With recursion, the answer is
incredibly simple -- just grab an element from the set, then call the
recursive method with a copy of the set minus the grabbed element. Once you
reach the empty set, you've reached your terminal condition.

Use cases like that are not only incredibly common, but usually,
embarrassingly parallel. The example above of cycling through permutations
is only a few lines of imperative code, but I struggle to imagine how I
would do this with Streams.

I guess let me start by asking -- are there any good ways currently to
accomplish the above permutation example with Streams? And if not, should
there be?

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251110/cc86ae0a/attachment-0001.htm>

From syan at openjdk.org  Tue Nov 11 03:36:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Nov 2025 03:36:04 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
Message-ID: <TG5MxAPNDtgIdqNZW3C75fGk6oL7ZxQt6CSa2CeLia8=.6e42a275-362c-42ad-a9c1-ea4afb83890d@github.com>

On Mon, 10 Nov 2025 17:43:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
>> 
>> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
>> 
>> Testing (all on Linux x86_64):
>> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
>> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [X] CG version 1, run as non-root. Test skipped.
>> - [x] GHA, though I don't think this is very useful for this change.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting and copyright

The touch tests and new tests run passed on my local machine.

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28201#pullrequestreview-3446098295

From davidalayachew at gmail.com  Tue Nov 11 03:43:16 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Nov 2025 22:43:16 -0500
Subject: Difficulties of recursion with Streams
In-Reply-To: <CAA9v-_OMFfDGHCOgqDe1jA7LgFZ6hT4owtkd5d5+sxhHOQvCQQ@mail.gmail.com>
References: <CAA9v-_OMFfDGHCOgqDe1jA7LgFZ6hT4owtkd5d5+sxhHOQvCQQ@mail.gmail.com>
Message-ID: <CAA9v-_PGxuPDcus+zbu6FXG18KTLhTmH3aobL-cvhb=s1fzFLQ@mail.gmail.com>

And to clarify, the closest I have ever gotten has been when I happen to
know the "depth" of recursion ahead of time. But even then, the best I can
do is call as many flatMap's as there are levels, and that can get
untenable when dealing with recursion that can go down many levels.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251110/6f3d1738/attachment.htm>

From jpai at openjdk.org  Tue Nov 11 06:46:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Nov 2025 06:46:04 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <yp9bE9rha3wVFpIbCFF12n7ZbqhPq053AROtCWCkQ48=.adb800fc-3807-45f1-93cd-9a1b395c3159@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

src/java.base/share/native/libjimage/imageFile.cpp line 334:

> 332:     // Memory map image (minimally the index.)
> 333:     _index_data = (u1*)osSupport::map_memory(_fd, _name, 0, (size_t)map_size());
> 334:     if (_index_data == nullptr) {

The rest of the code in the `libjimage` library uses `NULL`, including the return value in `osSupport::map_memory(...)`. So I think it would be better to use `NULL` here for consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28087#discussion_r2513032659

From jpai at openjdk.org  Tue Nov 11 06:50:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Nov 2025 06:50:04 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <FJD2GpAp1aRZ4UDqt_A04nXeRLDXOKHxQwTG4JiVLJU=.e862b3a9-95f1-4262-9484-2670f99051f7@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

The change looks reasonable to me. This function gets called from `ClassLoader::lookup_vm_options()` and returning `false` from here appears to be handled correctly in the hotspot classfile code.

It would be good to have Alan or Sundar review this change before integrating @AlanBateman @sundararajana.

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

PR Comment: https://git.openjdk.org/jdk/pull/28087#issuecomment-3515228335

From pminborg at openjdk.org  Tue Nov 11 08:01:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 11 Nov 2025 08:01:08 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v24]
In-Reply-To: <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
Message-ID: <vqHNGKFE_YgCSlw0IFjWYKp7jxAEQGXAG8EkvjwyI78=.e505b8b6-ed21-4cb8-aa39-978db6cc0bef@github.com>

On Mon, 10 Nov 2025 14:59:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @AOTSafeClassInitializer

As per https://github.com/openjdk/jdk/pull/27605/commits/e479cb4bbe54f3e0caa129cc45aec2ec2bffd9cf, this PR passes tier 1-4 on multiple platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3515424778

From alanb at openjdk.org  Tue Nov 11 08:28:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 08:28:45 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
Message-ID: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>

This is docs only change to a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.

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

Commit messages:
 - More word smithing, drop link to VirtualThreadSchedulerMXBean
 - Merge branch 'master' into JDK-8371226
 - Improve javadoc, add apiNote to interrupted()
 - Merge branch 'master' into JDK-8371226
 - More wordsmithing
 - Improve wording
 - Merge branch 'master' into JDK-8371226
 - Merge branch 'master' into JDK-8371226
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/28216/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28216&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371226
  Stats: 85 lines in 2 files changed: 58 ins; 5 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/28216.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28216/head:pull/28216

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

From vklang at openjdk.org  Tue Nov 11 08:28:45 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 11 Nov 2025 08:28:45 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
Message-ID: <uZsgzNrGnHUQgw-B8vUf_HMICZjlpo6Z2u3WHQ5UMYY=.fd012ca4-bfd8-440d-9ae2-ad7501b24425@github.com>

On Mon, 10 Nov 2025 14:37:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is docs only change to a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.

src/java.base/share/classes/java/lang/Thread.java line 157:

> 155:  * }
> 156:  *
> 157:  * <h2><a id="inheritance">Inheritance When Creating Threads</a></h2>

Detected an inconsistency: Capital "W" on When but not capital "A" on "and" in the previous heading

src/java.base/share/classes/java/lang/Thread.java line 185:

> 183:  * <p> If a thread executing {@link #sleep(long) Thread.sleep} or {@link Object#wait()
> 184:  * Object.wait} is interrupted then it causes the method to return early and throw
> 185:  * {@link InterruptedException}. Methods that throw {@code InterruptedException} do so after

I think something like this is clearer:

Suggestion:

 * Object.wait} is interrupted then it causes the method to exit early by throwing an
 * {@link InterruptedException}. Methods that throw {@code InterruptedException} do so after

src/java.base/share/classes/java/lang/Thread.java line 189:

> 187:  * should rethrow the exception, or restore the current thread's interrupted status, with
> 188:  * {@link #currentThread() Thread.currentThread()}.{@link #interrupt()}, before continuing
> 189:  * normally or handling it by throwing another type of exception.

Perhaps add "even if wrapping the InterruptedException"?

src/java.base/share/classes/java/lang/Thread.java line 205:

> 203:  * {@code Thread} also defines the static {@link #interrupted() Thread.interrupted()}
> 204:  * method to test the current thread's interrupted status and clear it. It should be rare
> 205:  * to need to use this method.

I wonder if we can give clearer instructions/examples as to when to use this method?

src/java.base/share/classes/java/lang/Thread.java line 1643:

> 1641:      * to test if interrupted and clear the interrupted status to allow the code
> 1642:      * retry the <em>interruptible</em> method. The <em>uninterruptible</em> method
> 1643:      * should restore the interrupted status before it completes.

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511026652
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511057549
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511072080
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511164109
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511944188

From alanb at openjdk.org  Tue Nov 11 08:28:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 08:28:46 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <uZsgzNrGnHUQgw-B8vUf_HMICZjlpo6Z2u3WHQ5UMYY=.fd012ca4-bfd8-440d-9ae2-ad7501b24425@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
 <uZsgzNrGnHUQgw-B8vUf_HMICZjlpo6Z2u3WHQ5UMYY=.fd012ca4-bfd8-440d-9ae2-ad7501b24425@github.com>
Message-ID: <TTcExzQReSZOu8Pjmdz6OxwuB00xHve-xHh_rogHv3U=.99ee3c62-c039-40a6-b70d-1311e259a9e4@github.com>

On Mon, 10 Nov 2025 15:31:31 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This is docs only change to a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.
>
> src/java.base/share/classes/java/lang/Thread.java line 157:
> 
>> 155:  * }
>> 156:  *
>> 157:  * <h2><a id="inheritance">Inheritance When Creating Threads</a></h2>
> 
> Detected an inconsistency: Capital "W" on When but not capital "A" on "and" in the previous heading

These headings are in in title case so "When" is capitalised but not "and".

> src/java.base/share/classes/java/lang/Thread.java line 185:
> 
>> 183:  * <p> If a thread executing {@link #sleep(long) Thread.sleep} or {@link Object#wait()
>> 184:  * Object.wait} is interrupted then it causes the method to return early and throw
>> 185:  * {@link InterruptedException}. Methods that throw {@code InterruptedException} do so after
> 
> I think something like this is clearer:
> 
> Suggestion:
> 
>  * Object.wait} is interrupted then it causes the method to exit early by throwing an
>  * {@link InterruptedException}. Methods that throw {@code InterruptedException} do so after

The previous paragraph establishes the phrase "return early" so this is why it is re-used here maybe "method to exit" would be better here, I'll play with it.

> src/java.base/share/classes/java/lang/Thread.java line 189:
> 
>> 187:  * should rethrow the exception, or restore the current thread's interrupted status, with
>> 188:  * {@link #currentThread() Thread.currentThread()}.{@link #interrupt()}, before continuing
>> 189:  * normally or handling it by throwing another type of exception.
> 
> Perhaps add "even if wrapping the InterruptedException"?

I've added a sentence for this.

> src/java.base/share/classes/java/lang/Thread.java line 205:
> 
>> 203:  * {@code Thread} also defines the static {@link #interrupted() Thread.interrupted()}
>> 204:  * method to test the current thread's interrupted status and clear it. It should be rare
>> 205:  * to need to use this method.
> 
> I wonder if we can give clearer instructions/examples as to when to use this method?

That's good idea, I've put a first version in interrupted() as an apiNote.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511850457
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511858145
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511859774
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511852468

From liach at openjdk.org  Tue Nov 11 08:28:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Nov 2025 08:28:46 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
Message-ID: <1A_bKVnbCUKbUa3qc28g46552S81HBrEGRDwZO39wbU=.4622e02d-cbb4-42ae-93cc-73527213e1aa@github.com>

On Mon, 10 Nov 2025 14:37:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is docs only change to a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.

src/java.base/share/classes/java/lang/Thread.java line 244:

> 242:  * </table>
> 243:  * <p> The virtual thread scheduler can be monitored and managed with the
> 244:  * {@link jdk.management/jdk.management.VirtualThreadSchedulerMXBean} management

Links to jdk. modules will break the Java SE API doc from `make docs-javase` when it runs the jdkCheckLinks test. We may have to use `{@code}` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2511888660

From alanb at openjdk.org  Tue Nov 11 08:28:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 08:28:46 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <1A_bKVnbCUKbUa3qc28g46552S81HBrEGRDwZO39wbU=.4622e02d-cbb4-42ae-93cc-73527213e1aa@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
 <1A_bKVnbCUKbUa3qc28g46552S81HBrEGRDwZO39wbU=.4622e02d-cbb4-42ae-93cc-73527213e1aa@github.com>
Message-ID: <edWQ5_hazamIrEuPJSyq5PF-dhGgMEX11FaJT49OnrY=.e8d7da69-89c6-48dc-9fbb-7bf1bb190d19@github.com>

On Mon, 10 Nov 2025 20:31:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is docs only change to a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.
>
> src/java.base/share/classes/java/lang/Thread.java line 244:
> 
>> 242:  * </table>
>> 243:  * <p> The virtual thread scheduler can be monitored and managed with the
>> 244:  * {@link jdk.management/jdk.management.VirtualThreadSchedulerMXBean} management
> 
> Links to jdk. modules will break the Java SE API doc from `make docs-javase` when it runs the jdkCheckLinks test. We may have to use `{@code}` instead.

Thanks. It's not an issue for the "docs" target as that includes the JDK-specific modules so that implNotes can cross link to JDK-specific modules. But you are right that "docs-javase" (used for JCP submissions) can't link to non-standard modules.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2513062205

From alanb at openjdk.org  Tue Nov 11 08:36:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 08:36:12 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
Message-ID: <TFENi52GHOakL---BDTzGKEB6gXwyUBp-4EJYbmLKjM=.40aabbe9-cade-4568-9825-118bf58bfddd@github.com>

On Mon, 10 Nov 2025 20:11:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - Merge branch 'master' into JDK-8353835
>>  - Fix typo in test comment
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Suppress warnings from some tests
>>  - Change -Xcheck:jni to be warning rather than fatal error
>>  - Merge branch 'master' into JDK-8353835
>>  - Simplify filter
>>  - Merge branch 'master' into JDK-8353835
>>  - Update Xcheck:jni description
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02
>
> src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 56:
> 
>> 54:     <li><a href="../Field.html#setDouble(java.lang.Object,double)">
>> 55:         java.lang.reflect.Field.setDouble(Object, double)</a></li>
>> 56:     <li><a href="{@docRoot}/java.base/java/lang/invoke/MethodHandles.Lookup.html#unreflectSetter(java.lang.reflect.Field)">
> 
> Nit: Since javadoc process tags here, you could just use `{@link Field#set java.lang.reflect.Field.set(Object, Object)}` instead of full-fledged a tags.

I wasn't aware that javadoc allowed this in .html docs-files, thanks for the tip.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2513298915

From alanb at openjdk.org  Tue Nov 11 09:00:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 09:00:11 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
Message-ID: <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>

On Mon, 10 Nov 2025 20:24:53 GMT, Chen Liang <liach at openjdk.org> wrote:

> I still wonder about the decision for JNI to call final Field.set with an unconditional export check instead of an unconditional open check - the open check is done for all Java code already.

It's aligned with setAccessible. It's a bit of corner case, but if a JNI attached thread invokes setAccessible with no java frames on the stack, then it specified to only succeed if the API element is public and declared in a public class in an exported package.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3515650487

From sgehwolf at openjdk.org  Tue Nov 11 09:21:43 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Nov 2025 09:21:43 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
Message-ID: <x8lwdeGS1I_9k2OWiS60WAnUSaYmKacg4melgyB6VJA=.79bbea30-d8b3-4357-922d-15baa07da462@github.com>

On Mon, 10 Nov 2025 17:43:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
>> 
>> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
>> 
>> Testing (all on Linux x86_64):
>> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
>> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [X] CG version 1, run as non-root. Test skipped.
>> - [x] GHA, though I don't think this is very useful for this change.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting and copyright

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28201#issuecomment-3515752649

From sgehwolf at openjdk.org  Tue Nov 11 09:21:45 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Nov 2025 09:21:45 GMT
Subject: Integrated: 8370966: Create regression test for the hierarchical
 memory limit fix in JDK-8370572
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <mw60Y6T7DQnUia9RpJxCpX1oMigEbgmySAhgXT_-LBU=.79d5dadb-a6f3-4f2f-a1fd-35f9ed3009ae@github.com>

On Fri, 7 Nov 2025 16:41:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 29100320
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/291003208c025ce4f9a94ba6093e207d0792bbb9
Stats:     191 lines in 8 files changed: 154 ins; 32 del; 5 mod

8370966: Create regression test for the hierarchical memory limit fix in JDK-8370572

Reviewed-by: shade, syan

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

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

From sgehwolf at openjdk.org  Tue Nov 11 09:44:05 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Nov 2025 09:44:05 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
Message-ID: <VpxU4VbRHEOB1lboXmxqgp-aMGqvJ3Do2Md_j3DKeBk=.4e073851-01d2-4145-bf8d-dbe5c43069ed@github.com>

On Mon, 10 Nov 2025 20:44:34 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR include build changes from @magicus and jlink change to verify the build signature.
>> 
>> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
>> 
>> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>>                                                                                                                                                                  
>> ? java --version
>> openjdk 26-internal 2026-03-17
>> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
>> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>>                                                                                                                                                                  
>> ? jlink --version                                                                       
>> 26-internal
>>                                                                                                                                                                  
>> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>>                                                                                                                                                                  
>> ? jlink --add-modules java.base --output macos
>>                                                             
>> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>>                                                                                                                                                                  
>> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring to clarify version checking cases

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 620:

> 618:             // silently ignore and fall through to version mismatch
> 619:             targetRelease = "missing";
> 620:         }

Instead of claiming that the `release.txt` file contains the string "missing", we could just throw a specific exception to that effect, no? Something along the lines of:


Error: java.base module specified on the module path does not contain critical resource needed for verifying compatibility to the current runtime with version <currrent-version>

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2513527647

From sgehwolf at openjdk.org  Tue Nov 11 09:57:39 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Nov 2025 09:57:39 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf 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 seven additional commits since the last revision:

 - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
 - Remove SkippedException import
 - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
 - Fix include
 - Add asserts/checks for input domain
 - Add regression test for jdk-8370492
 - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/8ba999a9..a2c6b160

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

  Stats: 152084 lines in 669 files changed: 106238 ins; 18592 del; 27254 mod
  Patch: https://git.openjdk.org/jdk/pull/28157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28157/head:pull/28157

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

From alanb at openjdk.org  Tue Nov 11 10:04:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 10:04:13 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
Message-ID: <gZCxrZvEIOLDUqJivktGsA96-y3Y0Tpdm_JAXaMQGPc=.03a10aaa-0d05-4362-91f5-5b0d2ccb6a8e@github.com>

On Mon, 10 Nov 2025 20:44:34 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR include build changes from @magicus and jlink change to verify the build signature.
>> 
>> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
>> 
>> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>>                                                                                                                                                                  
>> ? java --version
>> openjdk 26-internal 2026-03-17
>> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
>> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>>                                                                                                                                                                  
>> ? jlink --version                                                                       
>> 26-internal
>>                                                                                                                                                                  
>> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>>                                                                                                                                                                  
>> ? jlink --add-modules java.base --output macos
>>                                                             
>> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>>                                                                                                                                                                  
>> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring to clarify version checking cases

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 589:

> 587:     }
> 588: 
> 589:     private static String getJlinkRuntimeVersion() {

Maybe rename to getCurrentRuntimeVersion as that makes it clearer what t his method returns.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 625:

> 623:         throw new IllegalArgumentException(taskHelper.getMessage("err.jlink.version.mismatch",
> 624:                 currentRelease,
> 625:                 targetRelease));

Would it be possible to paste in the error that the jlink user will see? (assuming jdk.debug is not set). I just want to be sure that the IllegalArgumentException isn't shown to the user.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2513565593
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2513579541

From ogillespie at openjdk.org  Tue Nov 11 10:42:03 2025
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 11 Nov 2025 10:42:03 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v5]
In-Reply-To: <vSVVYdKkOvUOmmdFbICM87-yqIkBKShCnSUmt3sUsmo=.37a8728b-8e3a-4961-a84f-f179c93acec9@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <vSVVYdKkOvUOmmdFbICM87-yqIkBKShCnSUmt3sUsmo=.37a8728b-8e3a-4961-a84f-f179c93acec9@github.com>
Message-ID: <3_tkbna4YcBv08iau23SskhDkViJ9eLeZvBtH4w2A4M=.6e53a9f7-99fc-4a8c-b730-018e2035e3e4@github.com>

On Mon, 10 Nov 2025 16:31:37 GMT, jengebr <duke at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace fixes

Marked as reviewed by ogillespie (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/28116#pullrequestreview-3447395599

From jvernee at openjdk.org  Tue Nov 11 11:12:05 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Nov 2025 11:12:05 GMT
Subject: RFR: 8371319: java.lang.reflect.Method#equals doesn't
 short-circuit with same instances
In-Reply-To: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
References: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
Message-ID: <wbX_8e40nwUvtPS2olEKfV1NIOrGXxjmCDQTEUZQ7AE=.7a6a5c3e-dab5-44d2-9ca8-31bae827803a@github.com>

On Mon, 10 Nov 2025 17:59:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There is currently no shortcut for fast equals for Method or Constructor. While the comparison for declaring class, name (interned strings' identity), and return type are very efficient with identity comparison, the comparison for parameter type is not so much: We always have to iterate through every parameter.
> 
> Luckily, even though we are burdened with the different method and constructor instance due to setAccessible, their parameter type arrays are shared most of the time; in particular, in the same root method/constructor hierarchy, all instances share the same method object. Thus, we can perform a `==` check on the incoming array to provide a fast path.
> 
> Benchmark numbers before and after:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.189 ? 0.024  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  2.449 ? 0.033  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.541 ? 0.027  ns/op
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.186 ? 0.042  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  1.078 ? 0.049  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.395 ? 0.018  ns/op

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28221#pullrequestreview-3447523235

From epeter at openjdk.org  Tue Nov 11 12:11:06 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 11 Nov 2025 12:11:06 GMT
Subject: RFR: 8370691: Add new HalffloatVector type and enable
 intrinsification of float16 vector operations
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <_ryF0SNpSLahH4HkGqSnGKc_6d9P1fWrKYTS0jRPvtk=.ff2143aa-d3a5-4776-bdd0-95646dfd35e9@github.com>

On Mon, 27 Oct 2025 15:19:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Add new HalffloatVector type and corresponding concrete vector classes in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added HalffloatVector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected HalfflotVector benchmarking kernels compared to equivalent Float16OperationsBenchmark kernels.
> 
> <img width="837" height="650" alt="{A2BA2D85-085A-489F-8DDD-0FCFB5986EA5}" src="https://github.com/user-attachments/assets/2f34138e-80f4-4870-9b5f-f64bf43c1b11" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

We already have a lot of things in the codebase now from previous issues that use `HF` everywhere, for example some node names, and the type. Should we maybe rename all of them to `F16`, or something else? Open question, not sure of the answer yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3516579087

From vklang at openjdk.org  Tue Nov 11 12:13:13 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 11 Nov 2025 12:13:13 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
Message-ID: <USIt-AyxN4fPoGwku2DP_K4NfvPgmyLPLIfnRznA3Uk=.62539a03-6f0d-4695-98fc-ba1c96d3d2f2@github.com>

On Mon, 10 Nov 2025 14:37:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is docs only change to a add a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.

Great work, Alan!

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

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28216#pullrequestreview-3447770882

From egahlin at openjdk.org  Tue Nov 11 12:40:21 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 11 Nov 2025 12:40:21 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <uIxLQJE7F6w8qDRRX1NWF4kc8iHQe5RTNTV0JBTLF-k=.01d912c3-af44-4a02-8d48-b62141fdb20a@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
 <k6_-Fsk4Q3cQH8q1j3qAVbhkuDQXtWOcBn-c1QyBsFY=.03be8309-396e-46d5-9c0e-d4cf29fd327a@github.com>
 <uIxLQJE7F6w8qDRRX1NWF4kc8iHQe5RTNTV0JBTLF-k=.01d912c3-af44-4a02-8d48-b62141fdb20a@github.com>
Message-ID: <r6Fj8N9_nN1-XJo171i_-vxJ66j44jav2y5L1oovrhw=.92ca7ab8-5f35-4798-924a-c4dc0001b1d7@github.com>

On Tue, 7 Oct 2025 07:59:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The APIs are in Field and Lookup so having the API method as the top frame is useful. It would be possible to reduce the filter to `{ "java.lang.reflect.ReflectAccess", "java.lang.invoke.MethodHandles$Lookup::unreflectField" }` with determineStackTraceOffset returning 6 but it's too fiddly and requires knowing about two "faraway places" when doing any refactoring. Mutating final fields is the slow path so performance is not a concern. So I think the trade-off to keep it as maintainable as possible is okay. The test checks the top frame and also scans the StackFilter to ensure the class is visible and that any filter value with a method name at least names a method that is declared in the class.

 We shouldn't push it as high as 6, that's fragile, but the offer(...) method could be skipped immediately if the offset is bumped. Class filters avoid specifying individual methods, which are more likely to be refactored.

I can see the argument for not having the user's method as the top frame. A user may get a quick hint (instead of looking at the line number) if they see something like setInt(...), but this doesn?t work as well with tooling when you want to group stack traces by top frame, for example in a tree view. You typically want to see the application frame and then expand the nodes. If setInt, setFloat, setLong, etc. appear as the top nodes, users have to click and expand every setter, instead of seeing an aggregated list directly of packages, classes, or methods where finals are modified.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3516700622

From duke at openjdk.org  Tue Nov 11 12:43:41 2025
From: duke at openjdk.org (Jesse Glick)
Date: Tue, 11 Nov 2025 12:43:41 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
Message-ID: <hhpTt97mJhKq1xoZ0iVQ7hQPjCzvyo_-hMgc0LsmiZo=.247d98e8-8c50-41ac-8ba5-d31914aab06c@github.com>

On Thu, 17 Oct 2024 04:51:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's man page inputs

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 264:

> 262: \                             versions.
> 263: main.help.opt.any=\
> 264: \ Operation modifiers valid in any mode:\n\

This text _valid in any mode_ was present in earlier releases but does not seem to have been true for `-C` with `-x`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/2752#discussion_r2514095868

From alan.bateman at oracle.com  Tue Nov 11 13:53:02 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Nov 2025 13:53:02 +0000
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlByb3Bvc2UgdG8gcmVtb3ZlIHN1cHBvcnQgZm9y?=
 =?UTF-8?Q?_CompactStrings_off?=
In-Reply-To: <198051d4-3ee9-4f13-a8bf-d2b096a2b5b3@oracle.com>
References: <b27a2c9d-d268-4489-8b57-920090635dca.shaojin.wensj@alibaba-inc.com>
 <f46d0109-3dbe-4764-8c52-0b3843c85195@oracle.com>
 <08d048b2-5eb1-4db1-a169-a45e9f617b62.shaojin.wensj@alibaba-inc.com>
 <d26f06b5-cc53-4ec4-97bd-69eb9944f779@oracle.com>
 <09039475-af3e-43ed-8d6b-8e7678a2a053@oracle.com>
 <42963962-8763-46b7-aa7a-631838324efd@oracle.com>
 <e81b4262-f4e4-4ab8-95a8-76d267dd9848@oracle.com>
 <198051d4-3ee9-4f13-a8bf-d2b096a2b5b3@oracle.com>
Message-ID: <ff9ec20c-4c9e-40e8-ade8-ce49d69f8a30@oracle.com>



On 10/11/2025 20:09, Stuart Marks wrote:
>
> Good points about what the JEP should say. I've updated it.
>
> Pretty much every article I've seen that describes Compact Strings 
> also mentions the -XX:-CompactStrings option, so the option seems 
> fairly well known. (In addition to it appearing in our documentation.) 
> However, we don't know how many people actually *use* the option. I 
> suspect there might be a long tail of conservative ("don't touch 
> anything!") folks who added it a long time ago out of an abundance of 
> caution and forgot about it, so it would be good to get the word out 
> as widely as possible.

I see Alex'sedits, the Motivation and Description are very clear now, at 
the right level for the expected reader.

-Alan

From haraldei at openjdk.org  Tue Nov 11 14:17:55 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Tue, 11 Nov 2025 14:17:55 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
Message-ID: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>

`jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.

However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.

To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.

This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.

This work was sponsored by: The FreeBSD Foundation

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

Commit messages:
 - 8371637: allocateNativeInternal sometimes return incorrectly aligned memory

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

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

From alanb at openjdk.org  Tue Nov 11 14:34:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 14:34:33 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
Message-ID: <unQ-BEV3uyKQItzqb09Vf12E2zQRgy-4LUiAGTlfRNg=.1383bb38-9b6b-4b9e-8a73-fa59d3767944@github.com>

On Mon, 10 Nov 2025 19:26:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - Merge branch 'master' into JDK-8353835
>>  - Fix typo in test comment
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Suppress warnings from some tests
>>  - Change -Xcheck:jni to be warning rather than fatal error
>>  - Merge branch 'master' into JDK-8353835
>>  - Simplify filter
>>  - Merge branch 'master' into JDK-8353835
>>  - Update Xcheck:jni description
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02
>
> test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 234:
> 
>> 232:     @Test
>> 233:     void testSetPropertyToAllow() throws Exception {
>> 234:         test("setSystemPropertyToAllow+testFieldSetInt")
> 
> I thought this was setting the property before the VM boot. Can we have another test that does something like:
> 
> test("testFieldSetInt", "-Djdk.module.illegal.final.field.mutation=allow")
> 
> Which I think is closer to what @vy asks for.

The test sets the internal property at runtime in the launched VM. You are right that another test could launch with the internal property set on the command line with -D.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2514460463

From vklang at openjdk.org  Tue Nov 11 14:39:26 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 11 Nov 2025 14:39:26 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder()
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <C_hKZUAfyi8CGvX-nYLxzw52oRwWofOslU8WRlofQXg=.797d4c30-d1bd-4dbf-8d5e-aaaa2069a7c5@github.com>

On Tue, 11 Nov 2025 02:43:14 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

src/java.base/share/classes/java/util/stream/SortedOps.java line 64:

> 62:                                 Comparator<? super T> comparator) {
> 63:         return Comparator.naturalOrder().equals(comparator) ?
> 64:                 new OfRef<>(upstream) : new OfRef<>(upstream, comparator);

I think it would be better to address this directly in the OfRef constructor, and let the 1-arg constructor delegate to the 2-arg constructor.

src/java.base/share/classes/java/util/stream/StreamOpFlag.java line 754:

> 752:         if ((characteristics & Spliterator.SORTED) != 0 &&
> 753:                 !(spliterator.getComparator() == null ||
> 754:                         spliterator.getComparator().equals(Comparator.naturalOrder()))) {

The following would avoid having to call getComparator() twice and be all &&s.

Suggestion:

        if ((characteristics & Spliterator.SORTED) != 0 &&
                spliterator.getComparator() instanceof Comparator c &&
                !c.equals(Comparator.naturalOrder()))) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28226#discussion_r2514463670
PR Review Comment: https://git.openjdk.org/jdk/pull/28226#discussion_r2514464014

From liach at openjdk.org  Tue Nov 11 15:04:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Nov 2025 15:04:38 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
 <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>
Message-ID: <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>

On Tue, 11 Nov 2025 08:56:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's aligned with setAccessible. It's corner case of course but if a JNI attached thread invokes setAccessible with no java frames on the stack, then it is specified to only succeed if the API element is public and declared in a public class in an exported package.

Consider setting the field `java.lang.constant.DirectMethodHandleDesc$Kind.refKind` (public final instance field in public class in exported, non-open package) in 3 ways:
1. `Field.setAccessible` + `set` in Java code: Now `set` fails without `--add-opens` (not open)
2. Performing the 2 Java calls in JNI: Completely permitted (exported)
3. jni_Set##Result##Field: Completely permitted, one warning message

I find it a bit weird that 1 is inconsistent with 2, but given case 3, we have plenty of time to restrict 2 and 3 together in future releases.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3517325736

From liach at openjdk.org  Tue Nov 11 15:09:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Nov 2025 15:09:12 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
Message-ID: <mSvVIasRfWK3Xlyn1hH89nz7vR2FiAjlAebJTpNnFEg=.489627c9-53cd-4803-b3f3-418c70d42a24@github.com>

On Mon, 10 Nov 2025 14:37:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is docs only change to a add a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.

Proofread the text, appears very straightforward.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28216#pullrequestreview-3448517794

From jvernee at openjdk.org  Tue Nov 11 15:35:18 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Nov 2025 15:35:18 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <Je2Oo3je_3wr83M-HrC_rDFgOnvasJkKAiX2vy150EQ=.0c362396-101a-4a86-9705-4d187cb3c220@github.com>

On Tue, 11 Nov 2025 14:11:28 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Are you saying that jemalloc aligns allocations that are _exactly_ 16 bytes on an 8 byte boundary? How does this work when you want to allocate space for a single 16-byte size, 16-byte aligned value? (e.g. long double? I think FreeBSD uses the SysV ABI, right?)

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3517472567

From viktor.klang at oracle.com  Tue Nov 11 15:48:08 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 11 Nov 2025 16:48:08 +0100
Subject: Difficulties of recursion with Streams
In-Reply-To: <CAA9v-_OMFfDGHCOgqDe1jA7LgFZ6hT4owtkd5d5+sxhHOQvCQQ@mail.gmail.com>
References: <CAA9v-_OMFfDGHCOgqDe1jA7LgFZ6hT4owtkd5d5+sxhHOQvCQQ@mail.gmail.com>
Message-ID: <d1cab2a7-1a56-4091-bbf4-7e6cfbecf181@oracle.com>

Hi David,

I think it would be easier to offer feedback if you could elaborate 
where the point occurs where you feel the need to drop out of Streams 
and into imperative code.

It is also worth noting that sometimes imperative code is the right 
choice for maintainability, reviewability, performance and/or other reasons.

On 2025-11-11 04:36, David Alayachew wrote:
> Hello @core-libs-dev <mailto:core-libs-dev at openjdk.org>,
>
> When working with streams, I often run into situations where I have to 
> "demote" back to imperative code because I am trying to solve a 
> problem best solved by recursion.
>
> Consider the common use case of cycling through permutations to find 
> all permutations that satisfy some condition. With recursion, the 
> answer is incredibly simple -- just grab an element from the set, then 
> call the recursive method with a copy of the set minus the grabbed 
> element. Once you reach the empty set, you've reached your terminal 
> condition.
>
> Use cases like that are not only incredibly common, but usually, 
> embarrassingly parallel. The example above of cycling through 
> permutations is only a few lines of imperative code, but I struggle to 
> imagine how I would do this with Streams.
>
> I guess let me start by asking -- are there any good ways currently to 
> accomplish the above permutation example with Streams? And if not, 
> should there be?
>
> Thank you for your time and consideration.
> David Alayachew

-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251111/f952d266/attachment.htm>

From haraldei at openjdk.org  Tue Nov 11 15:54:01 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Tue, 11 Nov 2025 15:54:01 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <Je2Oo3je_3wr83M-HrC_rDFgOnvasJkKAiX2vy150EQ=.0c362396-101a-4a86-9705-4d187cb3c220@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <Je2Oo3je_3wr83M-HrC_rDFgOnvasJkKAiX2vy150EQ=.0c362396-101a-4a86-9705-4d187cb3c220@github.com>
Message-ID: <ApOFXHD7jcNqLHK743xYkdn6F5o71B0xa00BjShENt0=.e4e0569f-3bb9-4dea-a6e2-dd374c3a9fbb@github.com>

On Tue, 11 Nov 2025 15:32:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Are you saying that jemalloc aligns allocations that are _exactly_ 16 bytes on an 8 byte boundary? 

No. A 16 byte allocation will fall on a 16 byte boundary. But a 8 byte or smaller allocation will fall on a 8 byte boundary. And since the original code would not adjust the size if `byteAlignment` was exactly 16, this would mean that the requested alignment was not honoured. This caused the `TestMemoryAlignment` test to fail intermittently for exacrly 16 byte alignment requests. For all other valid values of `byteAlignment` the alignment would be as expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3517555345

From prappo at openjdk.org  Tue Nov 11 16:09:11 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Nov 2025 16:09:11 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
Message-ID: <FmJLEn9tj9G3xESdUzLlowxBH8sAWCKmr7phzEkaLAE=.911e6751-fde7-48cc-843c-322508adfca6@github.com>

On Mon, 10 Nov 2025 14:37:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is docs only change to a add a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.

Thanks for taking care of this and for taking on board my earlier suggestion from a core-libs-dev thread not to use "reset" when talking about re-asserting interrupted status. I can see that you chose "restore" instead. This is much better and matches, for example, "Java Concurrency in Practice".

src/java.base/share/classes/java/lang/InterruptedException.java line 30:

> 28: /**
> 29:  * Thrown when a thread executing a blocking method is {@linkplain Thread#interrupt()
> 30:  * interrupted}. {@link Thread#sleep(long)}, {@link Object#wait()} and many other

I can see that you moved `Thread#sleep(long)` from `@see` to here. However, since the initial documentation was created, a few other `sleep` methods have been added. Consider using this "generic sleep" text instead (which is what you use in Thread anyway):

    {@link Thread#sleep(long) Thread.sleep}

src/java.base/share/classes/java/lang/InterruptedException.java line 40:

> 38:  * normally or handling it by throwing another type of exception. Code that throws a
> 39:  * different type of exception with the {@code InterruptedException} as {@linkplain
> 40:  * Throwable#getCause() cause} should also restore the interrupted status before

Here and in Thread: should we add that code that suppresses InterruptedException should also restore interrupted status before throwing the primary exception?

src/java.base/share/classes/java/lang/Thread.java line 197:

> 195:  * java.nio.channels.InterruptibleChannel} is interrupted then it causes the channel to be
> 196:  * closed, and the blocking I/O operation to throw {@link java.nio.channels.ClosedByInterruptException}
> 197:  * with the thread's interrupted status set. If a thread is blocked in a {@linkplain

Suggestion:

 * with the thread's interrupted status set. If a thread that is blocked in a {@linkplain

Otherwise that sentence reads really weird.

src/java.base/share/classes/java/lang/Thread.java line 202:

> 200:  *
> 201:  * <p> Code that doesn't invoke any interruptible methods can still respond to interrupt
> 202:  * by polling the current thread's interrupt status with

Suggestion:

 * by polling the current thread's interrupted status with

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

PR Review: https://git.openjdk.org/jdk/pull/28216#pullrequestreview-3448613289
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2514740481
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2514653869
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2514793865
PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2514796925

From jvernee at openjdk.org  Tue Nov 11 16:27:07 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Nov 2025 16:27:07 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <M8b27hvhTw4LY0ArUpPvJjo7md6lxeDYAX04Inf1oQk=.42b70a05-1bb8-43e1-9f99-6edb0592b8c4@github.com>

On Tue, 11 Nov 2025 14:11:28 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Thanks, I think I get it. What happens if you try to allocate 4 bytes of memory and request 8 byte alignment? Won't the result only be 4 byte aligned?

I think the assumption of the current optimization is wrong: that malloc always returns memory aligned to a _constant_ `MAX_MALLOC_ALIGN`, and instead it depends on the size of the allocation, and the underlying allocator. I think ideally we'd be able to ask the allocator what the alignment of the memory it will return of a certain size is (or ask it to do an aligned allocation). We could also use a helper method that returns the alignment for a certain allocation size:


private static final boolean IS_FREEBSD = System.getProperty("os.name").equals(...);

private long alignmentForSize(long size) {
    if (IS_FREEBSD) {
        ...
    } else {
        return Unsafe.ADDRESS_SIZE == 4 ? 8 : 16;
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3517732223

From psandoz at openjdk.org  Tue Nov 11 16:34:04 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 11 Nov 2025 16:34:04 GMT
Subject: RFR: 8370691: Add new HalffloatVector type and enable
 intrinsification of float16 vector operations
In-Reply-To: <_ryF0SNpSLahH4HkGqSnGKc_6d9P1fWrKYTS0jRPvtk=.ff2143aa-d3a5-4776-bdd0-95646dfd35e9@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <_ryF0SNpSLahH4HkGqSnGKc_6d9P1fWrKYTS0jRPvtk=.ff2143aa-d3a5-4776-bdd0-95646dfd35e9@github.com>
Message-ID: <sarGywPvaDEM5GZdW_6tFu6RqpdYzsD-mpzPpgDETeo=.7f7d2de6-0631-493b-bbde-50c36cb624e0@github.com>

On Tue, 11 Nov 2025 12:08:42 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> We already have a lot of things in the codebase now from previous issues that use `HF` everywhere, for example some node names, and the type. Should we maybe rename all of them to `F16`, or something else? Open question, not sure of the answer yet.

I was only referring to the Java code, esp. the new public classes so they align with the `Float16` element type. I do think it worthwhile to align so we are consistent across the platform. Revisiting the names in HotSpot, and their internal connection in Java, could be done in a separate PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3517758143

From epeter at openjdk.org  Tue Nov 11 16:34:05 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 11 Nov 2025 16:34:05 GMT
Subject: RFR: 8370691: Add new HalffloatVector type and enable
 intrinsification of float16 vector operations
In-Reply-To: <sarGywPvaDEM5GZdW_6tFu6RqpdYzsD-mpzPpgDETeo=.7f7d2de6-0631-493b-bbde-50c36cb624e0@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <_ryF0SNpSLahH4HkGqSnGKc_6d9P1fWrKYTS0jRPvtk=.ff2143aa-d3a5-4776-bdd0-95646dfd35e9@github.com>
 <sarGywPvaDEM5GZdW_6tFu6RqpdYzsD-mpzPpgDETeo=.7f7d2de6-0631-493b-bbde-50c36cb624e0@github.com>
Message-ID: <KDJOj1Y0dGLhWOGrAm4Fjzpbiw_hWOkba91BC0sftO8=.1d776b96-8e2c-4de0-94ac-240cea9c6847@github.com>

On Tue, 11 Nov 2025 16:28:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Revisiting the names in HotSpot, and their internal connection in Java, could be done in a separate PR?

Yes, exactly. Maybe even in a quick renaming PR before this issue. Would be quickly reviewed, and would allow us to see complete consistency going forward with this PR here.

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3517766354

From duke at openjdk.org  Tue Nov 11 16:34:21 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 11 Nov 2025 16:34:21 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v2]
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <NWxQlK3_BVl6Fy5YCSa2S5u4SAzVEWNi73iS_D3OuhU=.1a6c85eb-533e-4bad-8984-b313f0f26717@github.com>

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/stream/StreamOpFlag.java
  
  Simplify comparison
  
  Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28226/files
  - new: https://git.openjdk.org/jdk/pull/28226/files/c4fb5d0f..7c8fea3a

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

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

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

From duke at openjdk.org  Tue Nov 11 16:34:23 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 11 Nov 2025 16:34:23 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v2]
In-Reply-To: <C_hKZUAfyi8CGvX-nYLxzw52oRwWofOslU8WRlofQXg=.797d4c30-d1bd-4dbf-8d5e-aaaa2069a7c5@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <C_hKZUAfyi8CGvX-nYLxzw52oRwWofOslU8WRlofQXg=.797d4c30-d1bd-4dbf-8d5e-aaaa2069a7c5@github.com>
Message-ID: <D4-pp4zKihF6-dtpznyew2TNrvVoKGzMu5u0RL7p--U=.c505b9fc-d826-4389-be10-29e0bfc3aba1@github.com>

On Tue, 11 Nov 2025 14:32:20 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/util/stream/StreamOpFlag.java
>>   
>>   Simplify comparison
>>   
>>   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>
> src/java.base/share/classes/java/util/stream/SortedOps.java line 64:
> 
>> 62:                                 Comparator<? super T> comparator) {
>> 63:         return Comparator.naturalOrder().equals(comparator) ?
>> 64:                 new OfRef<>(upstream) : new OfRef<>(upstream, comparator);
> 
> I think it would be better to address this directly in the OfRef constructor, and let the 1-arg constructor delegate to the 2-arg constructor.

I had originally tried that approach, let me go back to it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28226#discussion_r2514896974

From henryjen at openjdk.org  Tue Nov 11 16:38:05 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 11 Nov 2025 16:38:05 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <gZCxrZvEIOLDUqJivktGsA96-y3Y0Tpdm_JAXaMQGPc=.03a10aaa-0d05-4362-91f5-5b0d2ccb6a8e@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
 <gZCxrZvEIOLDUqJivktGsA96-y3Y0Tpdm_JAXaMQGPc=.03a10aaa-0d05-4362-91f5-5b0d2ccb6a8e@github.com>
Message-ID: <GXDEo2GY0tUp0iCIw2i-vg1xRP1yAQ63jid_wj0oPbI=.81e2cb35-325f-4c80-bd1a-108b679bc015@github.com>

On Tue, 11 Nov 2025 09:58:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactoring to clarify version checking cases
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 625:
> 
>> 623:         throw new IllegalArgumentException(taskHelper.getMessage("err.jlink.version.mismatch",
>> 624:                 currentRelease,
>> 625:                 targetRelease));
> 
> Would it be possible to paste in the error that the jlink user will see? (assuming jdk.debug is not set). I just want to be sure that the IllegalArgumentException isn't shown to the user.

Instead of showing N/A, it is now show missing. Output is still like above in the description.


jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25
Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2514914094

From rriggs at openjdk.org  Tue Nov 11 16:48:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Nov 2025 16:48:03 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
Message-ID: <4Pz7eC89zrlQud3vvrl8T5Li4xl9JVw1NlATpymohmg=.1770f2fb-0a46-4cc6-8723-aa70fd1c31d2@github.com>

On Mon, 10 Nov 2025 14:37:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is docs only change to a add a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.

Nice improvement.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28216#pullrequestreview-3448979328

From henryjen at openjdk.org  Tue Nov 11 16:56:05 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 11 Nov 2025 16:56:05 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <VpxU4VbRHEOB1lboXmxqgp-aMGqvJ3Do2Md_j3DKeBk=.4e073851-01d2-4145-bf8d-dbe5c43069ed@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
 <VpxU4VbRHEOB1lboXmxqgp-aMGqvJ3Do2Md_j3DKeBk=.4e073851-01d2-4145-bf8d-dbe5c43069ed@github.com>
Message-ID: <HnoobwuLz2v674j1Md6-bGccJOOID-SPKk91Ot3MOS8=.2b72df9f-7de9-41f0-afc4-411b95d65178@github.com>

On Tue, 11 Nov 2025 09:41:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactoring to clarify version checking cases
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 620:
> 
>> 618:             // silently ignore and fall through to version mismatch
>> 619:             targetRelease = "missing";
>> 620:         }
> 
> Instead of claiming that the `release.txt` file contains the string "missing", we could just throw a specific exception to that effect, no? Something along the lines of:
> 
> 
> Error: java.base module specified on the module path does not contain critical resource needed for verifying compatibility to the current runtime with version <currrent-version>

Sure we can. I do want to keep a message consistent and softer as this can happen to releases before this get merged. Thought 'missing' is a little better than 'N/A' which is more likely in a release.txt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2514962713

From forax at openjdk.org  Tue Nov 11 16:59:01 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 11 Nov 2025 16:59:01 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v2]
In-Reply-To: <NWxQlK3_BVl6Fy5YCSa2S5u4SAzVEWNi73iS_D3OuhU=.1a6c85eb-533e-4bad-8984-b313f0f26717@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <NWxQlK3_BVl6Fy5YCSa2S5u4SAzVEWNi73iS_D3OuhU=.1a6c85eb-533e-4bad-8984-b313f0f26717@github.com>
Message-ID: <p4lQ-B2UBHgzBLSQY3GQf1bCCRB01DWkIN_jLRiSwXY=.f890f186-7618-4bcb-89b4-997fa4a8edbd@github.com>

On Tue, 11 Nov 2025 16:34:21 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/stream/StreamOpFlag.java
>   
>   Simplify comparison
>   
>   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

I wonder if it's not better to replace Comparator.naturalOrder() by null in the constructor of TreeSet, given that TreeSet does not provide a getter for it so the only way to get the comparator is using treeSet.spliterator().getComparator().

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

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3517882648

From duke at openjdk.org  Tue Nov 11 17:10:39 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 11 Nov 2025 17:10:39 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v3]
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <QWIfL591j5h0q8zWYJAOX2M2UfIUoGKd4IGW8YzYB1c=.03b09d3f-8200-49cf-8f47-29008f7d3502@github.com>

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Check for Comparator.naturalOrder() in OfRef constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28226/files
  - new: https://git.openjdk.org/jdk/pull/28226/files/7c8fea3a..caeb8f37

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

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

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

From henryjen at openjdk.org  Tue Nov 11 17:13:06 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 11 Nov 2025 17:13:06 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <GXDEo2GY0tUp0iCIw2i-vg1xRP1yAQ63jid_wj0oPbI=.81e2cb35-325f-4c80-bd1a-108b679bc015@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
 <gZCxrZvEIOLDUqJivktGsA96-y3Y0Tpdm_JAXaMQGPc=.03a10aaa-0d05-4362-91f5-5b0d2ccb6a8e@github.com>
 <GXDEo2GY0tUp0iCIw2i-vg1xRP1yAQ63jid_wj0oPbI=.81e2cb35-325f-4c80-bd1a-108b679bc015@github.com>
Message-ID: <vuesPeNzcrp3R0vKDT8kqGqfyHiWxzpodjnmQ4w2wCI=.f3882a9c-2562-4ebd-a15b-808af4ea4bb6@github.com>

On Tue, 11 Nov 2025 16:35:39 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 625:
>> 
>>> 623:         throw new IllegalArgumentException(taskHelper.getMessage("err.jlink.version.mismatch",
>>> 624:                 currentRelease,
>>> 625:                 targetRelease));
>> 
>> Would it be possible to paste in the error that the jlink user will see? (assuming jdk.debug is not set). I just want to be sure that the IllegalArgumentException isn't shown to the user.
>
> Instead of showing N/A, it is now show missing. Output is still like above in the description.
> 
> 
> jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing

IllegalArgumentException and most others are caught in run() and showing message as an Error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515013456

From duke at openjdk.org  Tue Nov 11 17:13:06 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 11 Nov 2025 17:13:06 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v2]
In-Reply-To: <p4lQ-B2UBHgzBLSQY3GQf1bCCRB01DWkIN_jLRiSwXY=.f890f186-7618-4bcb-89b4-997fa4a8edbd@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <NWxQlK3_BVl6Fy5YCSa2S5u4SAzVEWNi73iS_D3OuhU=.1a6c85eb-533e-4bad-8984-b313f0f26717@github.com>
 <p4lQ-B2UBHgzBLSQY3GQf1bCCRB01DWkIN_jLRiSwXY=.f890f186-7618-4bcb-89b4-997fa4a8edbd@github.com>
Message-ID: <hMA3EPOMFlD4JKHktdABoBOXDQPkz5Wakx86l2fkovM=.7139475b-2219-4ec4-945b-5682d5de4236@github.com>

On Tue, 11 Nov 2025 16:56:18 GMT, R?mi Forax <forax at openjdk.org> wrote:

> I wonder if it's not better to replace Comparator.naturalOrder() by null in the constructor of TreeSet, given that TreeSet does not provide a getter for it so the only way to get the comparator is using treeSet.spliterator().getComparator().

That wouldn't help with the `stream().sorted(Comparator.naturalOrder())` case; the example I supplied is somewhat contrived, I originally ran into this in Guava (see the [issue](https://github.com/google/guava/issues/6187) I opened there); the library is null-hostile and so always supplies a comparator to its sorted collections. Note that this won't directly fix the issue there until they move away from their custom natural order comparator to the one from the JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3517933722

From henryjen at openjdk.org  Tue Nov 11 17:19:03 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 11 Nov 2025 17:19:03 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <HnoobwuLz2v674j1Md6-bGccJOOID-SPKk91Ot3MOS8=.2b72df9f-7de9-41f0-afc4-411b95d65178@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
 <VpxU4VbRHEOB1lboXmxqgp-aMGqvJ3Do2Md_j3DKeBk=.4e073851-01d2-4145-bf8d-dbe5c43069ed@github.com>
 <HnoobwuLz2v674j1Md6-bGccJOOID-SPKk91Ot3MOS8=.2b72df9f-7de9-41f0-afc4-411b95d65178@github.com>
Message-ID: <bMfPBB44qiZYQFudEH6Anr7hYjHtehleU-B31K5C9yc=.8d6e1ce9-f074-43b5-95e4-cf827d2293a4@github.com>

On Tue, 11 Nov 2025 16:53:02 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 620:
>> 
>>> 618:             // silently ignore and fall through to version mismatch
>>> 619:             targetRelease = "missing";
>>> 620:         }
>> 
>> Instead of claiming that the `release.txt` file contains the string "missing", we could just throw a specific exception to that effect, no? Something along the lines of:
>> 
>> 
>> Error: java.base module specified on the module path does not contain critical resource needed for verifying compatibility to the current runtime with version <currrent-version>
>
> Sure we can. I do want to keep a message consistent and softer as this can happen to releases before this get merged. Thought 'missing' is a little better than 'N/A' which is more likely in a release.txt.

Actually, if we just leave it blank, that message still works in all translation, I think.


src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
81:err.jlink.version.mismatch=jlink?????{0}???????java.base?????{1}???????

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
81:err.jlink.version.mismatch=jlink ?? {0} ??? java.base ?? {1} ???

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
81:err.jlink.version.mismatch=jlink-Version {0} stimmt nicht mit Ziel-java.base-Version {1} ?berein

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
133:err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515029024

From henryjen at openjdk.org  Tue Nov 11 17:25:43 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 11 Nov 2025 17:25:43 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v5]
In-Reply-To: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
Message-ID: <O4Zm7TRWShmHC7f1BvS6sO-3Pc1Wl6x-qynZFTjcx8Q=.35306041-d424-40e2-8f74-b5b0bacef3c5@github.com>

> This PR include build changes from @magicus and jlink change to verify the build signature.
> 
> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
> 
> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>                                                                                                                                                                  
> ? java --version
> openjdk 26-internal 2026-03-17
> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>                                                                                                                                                                  
> ? jlink --version                                                                       
> 26-internal
>                                                                                                                                                                  
> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>                                                                                                                                                                  
> ? jlink --add-modules java.base --output macos
>                                                             
> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>                                                                                                                                                                  
> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Treat missing release.txt as emptry release signature

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28155/files
  - new: https://git.openjdk.org/jdk/pull/28155/files/68584d93..0f1c9351

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

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

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

From alanb at openjdk.org  Tue Nov 11 17:30:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:30:05 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <vuesPeNzcrp3R0vKDT8kqGqfyHiWxzpodjnmQ4w2wCI=.f3882a9c-2562-4ebd-a15b-808af4ea4bb6@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
 <gZCxrZvEIOLDUqJivktGsA96-y3Y0Tpdm_JAXaMQGPc=.03a10aaa-0d05-4362-91f5-5b0d2ccb6a8e@github.com>
 <GXDEo2GY0tUp0iCIw2i-vg1xRP1yAQ63jid_wj0oPbI=.81e2cb35-325f-4c80-bd1a-108b679bc015@github.com>
 <vuesPeNzcrp3R0vKDT8kqGqfyHiWxzpodjnmQ4w2wCI=.f3882a9c-2562-4ebd-a15b-808af4ea4bb6@github.com>
Message-ID: <lnO3YRKbBD0NB0HwAcyYKKazWxhXGi7BBeqXbaGwXZg=.4a0bc86c-6f10-49d2-af5d-2b0e671b8e0a@github.com>

On Tue, 11 Nov 2025 17:10:30 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Instead of showing N/A, it is now show missing. Output is still like above in the description.
>> 
>> 
>> jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing
>
> IllegalArgumentException and most others are caught in run() and showing message as an Error.

> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing

"java.base build missing" is a bit confusing as it suggests that java.base is missing when it trying to say that the release resource is missing. Have you tried creating a separate resource/message for this case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515059195

From vklang at openjdk.org  Tue Nov 11 17:33:29 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 11 Nov 2025 17:33:29 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
Message-ID: <OMhBQoI-U8WEuxS4BDx0K7cgwZwVZkP92eM0MDfHQus=.ca8f413c-1ba1-4c99-9ace-c7f5010bd0d8@github.com>

On Mon, 10 Nov 2025 10:06:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02

src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 79:

> 77: </body>
> 78: 
> 79: </body>

Many-body problem?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2515065507

From alanb at openjdk.org  Tue Nov 11 17:36:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:36:29 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <FmJLEn9tj9G3xESdUzLlowxBH8sAWCKmr7phzEkaLAE=.911e6751-fde7-48cc-843c-322508adfca6@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
 <FmJLEn9tj9G3xESdUzLlowxBH8sAWCKmr7phzEkaLAE=.911e6751-fde7-48cc-843c-322508adfca6@github.com>
Message-ID: <Jg3MeJaiB4fV2KnK2C-6eQbKxetJcckkxlE9roMqpm8=.520e7041-3bdb-4d4d-b8e1-44ce1fa7ee29@github.com>

On Tue, 11 Nov 2025 15:26:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This is docs only change to a add a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.
>
> src/java.base/share/classes/java/lang/InterruptedException.java line 40:
> 
>> 38:  * normally or handling it by throwing another type of exception. Code that throws a
>> 39:  * different type of exception with the {@code InterruptedException} as {@linkplain
>> 40:  * Throwable#getCause() cause} should also restore the interrupted status before
> 
> Here and in Thread: should we add that code that suppresses InterruptedException should also restore interrupted status before throwing the primary exception?

I think that would be too much to try to put in the InterruptedException class description but we could potentially extend the sentence in the Thread Interruption section to include the case where someone chooses to add the InterruptedException as a suppressed exception.

I would prefer not get into further guidance for unwrapping, e.g.  catch FooException, get the InterruptedException cause, clear the interrupted status before re-throwing the cause.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2515073463

From alanb at openjdk.org  Tue Nov 11 17:39:24 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:39:24 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <FmJLEn9tj9G3xESdUzLlowxBH8sAWCKmr7phzEkaLAE=.911e6751-fde7-48cc-843c-322508adfca6@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
 <FmJLEn9tj9G3xESdUzLlowxBH8sAWCKmr7phzEkaLAE=.911e6751-fde7-48cc-843c-322508adfca6@github.com>
Message-ID: <cHmX1AXVQBEQq4M7wqXtYFn7yIBThXmMYJ_O4i7h0aA=.d2101155-1141-49ce-b5da-63f9287c8a65@github.com>

On Tue, 11 Nov 2025 16:03:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This is docs only change to a add a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.
>
> src/java.base/share/classes/java/lang/Thread.java line 197:
> 
>> 195:  * java.nio.channels.InterruptibleChannel} is interrupted then it causes the channel to be
>> 196:  * closed, and the blocking I/O operation to throw {@link java.nio.channels.ClosedByInterruptException}
>> 197:  * with the thread's interrupted status set. If a thread is blocked in a {@linkplain
> 
> Suggestion:
> 
>  * with the thread's interrupted status set. If a thread that is blocked in a {@linkplain
> 
> Otherwise that sentence reads really weird.

You are right that this could be improved but rather than inserting "that", it can be shortened to "If a thread blocked in a selection operation is interrupted".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2515083266

From prappo at openjdk.org  Tue Nov 11 17:48:05 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Nov 2025 17:48:05 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <cHmX1AXVQBEQq4M7wqXtYFn7yIBThXmMYJ_O4i7h0aA=.d2101155-1141-49ce-b5da-63f9287c8a65@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
 <FmJLEn9tj9G3xESdUzLlowxBH8sAWCKmr7phzEkaLAE=.911e6751-fde7-48cc-843c-322508adfca6@github.com>
 <cHmX1AXVQBEQq4M7wqXtYFn7yIBThXmMYJ_O4i7h0aA=.d2101155-1141-49ce-b5da-63f9287c8a65@github.com>
Message-ID: <oeQ_3xO69HaqVVhXkFXukH8tn1j9yZMr8gJCfetIVXM=.2884da3c-e360-4084-9ef5-11c880e53e42@github.com>

On Tue, 11 Nov 2025 17:37:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 197:
>> 
>>> 195:  * java.nio.channels.InterruptibleChannel} is interrupted then it causes the channel to be
>>> 196:  * closed, and the blocking I/O operation to throw {@link java.nio.channels.ClosedByInterruptException}
>>> 197:  * with the thread's interrupted status set. If a thread is blocked in a {@linkplain
>> 
>> Suggestion:
>> 
>>  * with the thread's interrupted status set. If a thread that is blocked in a {@linkplain
>> 
>> Otherwise that sentence reads really weird.
>
> You are right that this could be improved but rather than inserting "that", it can be shortened to "If a thread blocked in a selection operation is interrupted".

That works too; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2515102204

From alanb at openjdk.org  Tue Nov 11 17:48:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:48:43 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v11]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - Remove dup end body tag
 - Change FinalFieldMutationEvent so that caller is top frame in stack trace
 - Merge branch 'master' into JDK-8353835
 - Review feedback: Add tests for setting internal properties, improve links in Mutation methods page
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Fix typo in test comment
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Suppress warnings from some tests
 - ... and 40 more: https://git.openjdk.org/jdk/compare/2902436f...b22947c7

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=10
  Stats: 4882 lines in 71 files changed: 4697 ins; 54 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From alanb at openjdk.org  Tue Nov 11 17:48:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:48:44 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <r6Fj8N9_nN1-XJo171i_-vxJ66j44jav2y5L1oovrhw=.92ca7ab8-5f35-4798-924a-c4dc0001b1d7@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
 <k6_-Fsk4Q3cQH8q1j3qAVbhkuDQXtWOcBn-c1QyBsFY=.03be8309-396e-46d5-9c0e-d4cf29fd327a@github.com>
 <uIxLQJE7F6w8qDRRX1NWF4kc8iHQe5RTNTV0JBTLF-k=.01d912c3-af44-4a02-8d48-b62141fdb20a@github.com>
 <r6Fj8N9_nN1-XJo171i_-vxJ66j44jav2y5L1oovrhw=.92ca7ab8-5f35-4798-924a-c4dc0001b1d7@github.com>
Message-ID: <CGw008kTqnsokeBHs_NFQ6KpJzNUjo32UWvQyKSyc6E=.10bba2b2-2dec-4861-aa87-2fb4a050495f@github.com>

On Tue, 11 Nov 2025 12:37:59 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I can see the argument for not having the user's method as the top frame. A user may get a quick hint (instead of looking at the line number) if they see something like setInt(...), but this doesn?t work as well with tooling when you want to group stack traces by top frame, for example in a tree view. You typically want to see the application frame and then expand the nodes. If setInt, setFloat, setLong, etc. appear as the top nodes, users have to click and expand every setter, instead of seeing an aggregated list directly of packages, classes, or methods where finals are modified.

@egahlin and I discussed this and agreed to have the top-frame of the stack trace recorded with the event be the caller's method. This allows the stack filter include j.l.r.Field with listing method names. We might revisit this later to add further fields to the event to indicate an unreflect op and/or the field type.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3518032863

From alanb at openjdk.org  Tue Nov 11 17:48:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:48:45 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
 <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>
 <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>
Message-ID: <qrd3tLUbQ68_OK8kno-rLI4guFMYtbWZarfglXPi3SY=.ccf5110a-3300-4609-aca0-ee6e2b9af2d1@github.com>

On Tue, 11 Nov 2025 15:01:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> we have plenty of time to restrict 2 and 3 together in future releases.

There isn't any proposal to change JNI. It has never done any access checking. The only change is to -Xcheck:jni warning and logging to catch JNI code that is mutating finals. Once we dial up to have mutating finals be denied by default then we might dial up -Xcheck:jni at the same time to make it fatal.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3518048959

From forax at openjdk.org  Tue Nov 11 17:49:02 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 11 Nov 2025 17:49:02 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v2]
In-Reply-To: <hMA3EPOMFlD4JKHktdABoBOXDQPkz5Wakx86l2fkovM=.7139475b-2219-4ec4-945b-5682d5de4236@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <NWxQlK3_BVl6Fy5YCSa2S5u4SAzVEWNi73iS_D3OuhU=.1a6c85eb-533e-4bad-8984-b313f0f26717@github.com>
 <p4lQ-B2UBHgzBLSQY3GQf1bCCRB01DWkIN_jLRiSwXY=.f890f186-7618-4bcb-89b4-997fa4a8edbd@github.com>
 <hMA3EPOMFlD4JKHktdABoBOXDQPkz5Wakx86l2fkovM=.7139475b-2219-4ec4-945b-5682d5de4236@github.com>
Message-ID: <cStkQ8SJOSKc9kn-M5BtOxJchYsS_I9_4amAZ0FqDog=.12f916d9-ba66-4aaa-a1b9-5cf3de2c39a5@github.com>

On Tue, 11 Nov 2025 17:10:34 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> That wouldn't help with the `stream().sorted(Comparator.naturalOrder())` case; the example I supplied is somewhat contrived, I originally ran into this in Guava (see the [issue](https://github.com/google/guava/issues/6187) I opened there); the library is null-hostile and so always supplies a comparator to its sorted collections. 

If you switch from Comparator.naturalOrder()) to null, you have to do it in stream.sorted() too (and also List.sort(Comparator), Collections.sort(Comparator), Array.sort(Comparator), Collections.reverseOrder(Comparator) etc)

> Note that this won't directly fix the issue there until they move away from their custom natural order comparator to the one from the JDK.

yes, comparing comparators with == is brittle anyway, but at least you can make it consistent for the JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3518051371

From alanb at openjdk.org  Tue Nov 11 17:48:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:48:49 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
Message-ID: <HFicJcbb0TWbdaiuH3biej0hbUE8lEmWwkvS5aco6zk=.5d3d6b50-b758-49c2-81af-a43315c9a52e@github.com>

On Mon, 10 Nov 2025 20:12:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - Merge branch 'master' into JDK-8353835
>>  - Fix typo in test comment
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Suppress warnings from some tests
>>  - Change -Xcheck:jni to be warning rather than fatal error
>>  - Merge branch 'master' into JDK-8353835
>>  - Simplify filter
>>  - Merge branch 'master' into JDK-8353835
>>  - Update Xcheck:jni description
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02
>
> src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 72:
> 
>> 70: <em>illegal</em>.
>> 71: 
>> 72: The command line option <code>--illegal-final-field-mutation</code> controls how illegal
> 
> Missing `<p>`?

Just a blank line, it's all the one paragraph.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2515095873

From henryjen at openjdk.org  Tue Nov 11 17:52:07 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 11 Nov 2025 17:52:07 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <bMfPBB44qiZYQFudEH6Anr7hYjHtehleU-B31K5C9yc=.8d6e1ce9-f074-43b5-95e4-cf827d2293a4@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
 <VpxU4VbRHEOB1lboXmxqgp-aMGqvJ3Do2Md_j3DKeBk=.4e073851-01d2-4145-bf8d-dbe5c43069ed@github.com>
 <HnoobwuLz2v674j1Md6-bGccJOOID-SPKk91Ot3MOS8=.2b72df9f-7de9-41f0-afc4-411b95d65178@github.com>
 <bMfPBB44qiZYQFudEH6Anr7hYjHtehleU-B31K5C9yc=.8d6e1ce9-f074-43b5-95e4-cf827d2293a4@github.com>
Message-ID: <rpFZEyo6gxOQ-Edt5hlZd9bCO4Dx8Tk7eUIHkt3mjJI=.23d08ced-51d3-4cf8-a878-1449b410adc1@github.com>

On Tue, 11 Nov 2025 17:16:40 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Sure we can. I do want to keep a message consistent and softer as this can happen to releases before this get merged. Thought 'missing' is a little better than 'N/A' which is more likely in a release.txt.
>
> Actually, if we just leave it blank, that message still works in all translation, I think.
> 
> 
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
> 81:err.jlink.version.mismatch=jlink?????{0}???????java.base?????{1}???????
> 
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
> 81:err.jlink.version.mismatch=jlink ?? {0} ??? java.base ?? {1} ???
> 
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
> 81:err.jlink.version.mismatch=jlink-Version {0} stimmt nicht mit Ziel-java.base-Version {1} ?berein
> 
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
> 133:err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1}

With the latest update, the message is like

Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515113606

From henryjen at openjdk.org  Tue Nov 11 17:52:09 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 11 Nov 2025 17:52:09 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <lnO3YRKbBD0NB0HwAcyYKKazWxhXGi7BBeqXbaGwXZg=.4a0bc86c-6f10-49d2-af5d-2b0e671b8e0a@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
 <gZCxrZvEIOLDUqJivktGsA96-y3Y0Tpdm_JAXaMQGPc=.03a10aaa-0d05-4362-91f5-5b0d2ccb6a8e@github.com>
 <GXDEo2GY0tUp0iCIw2i-vg1xRP1yAQ63jid_wj0oPbI=.81e2cb35-325f-4c80-bd1a-108b679bc015@github.com>
 <vuesPeNzcrp3R0vKDT8kqGqfyHiWxzpodjnmQ4w2wCI=.f3882a9c-2562-4ebd-a15b-808af4ea4bb6@github.com>
 <lnO3YRKbBD0NB0HwAcyYKKazWxhXGi7BBeqXbaGwXZg=.4a0bc86c-6f10-49d2-af5d-2b0e671b8e0a@github.com>
Message-ID: <QxarF4zJkezXeuurcTwKJplLjzuJEk201zl7RHVvw3s=.ce2d7369-d22d-47ae-8411-0b9093d3cbe7@github.com>

On Tue, 11 Nov 2025 17:27:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> IllegalArgumentException and most others are caught in run() and showing message as an Error.
>
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing
> 
> "java.base build missing" is a bit confusing as it suggests that java.base is missing when it trying to say that the release resource is missing. Have you tried creating a separate resource/message for this case?

@jerboaa suggested the same thing, I updated the message from "missing" to "". With latest update the message is,


Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build 


Let's use @jerboaa comment thread above to solve this message issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515111787

From duke at openjdk.org  Tue Nov 11 17:56:19 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 11 Nov 2025 17:56:19 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v4]
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <U1lkBfT6i8L3Tgj_nxz0XYY8Wh1GUB18JalHuZRdoyY=.f5474769-0603-4bb6-ae5e-0b52794e8b3d@github.com>

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Fix bad merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28226/files
  - new: https://git.openjdk.org/jdk/pull/28226/files/caeb8f37..4c48f937

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

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

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

From sgehwolf at openjdk.org  Tue Nov 11 17:59:05 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Nov 2025 17:59:05 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v5]
In-Reply-To: <O4Zm7TRWShmHC7f1BvS6sO-3Pc1Wl6x-qynZFTjcx8Q=.35306041-d424-40e2-8f74-b5b0bacef3c5@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <O4Zm7TRWShmHC7f1BvS6sO-3Pc1Wl6x-qynZFTjcx8Q=.35306041-d424-40e2-8f74-b5b0bacef3c5@github.com>
Message-ID: <EY8WtaiVxb1sL-eKmoX8PHClMhOdl21EKHXAhaW3V6g=.19d41a6a-e095-49a8-abbb-7f8327450425@github.com>

On Tue, 11 Nov 2025 17:25:43 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR include build changes from @magicus and jlink change to verify the build signature.
>> 
>> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
>> 
>> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>>                                                                                                                                                                  
>> ? java --version
>> openjdk 26-internal 2026-03-17
>> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
>> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>>                                                                                                                                                                  
>> ? jlink --version                                                                       
>> 26-internal
>>                                                                                                                                                                  
>> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>>                                                                                                                                                                  
>> ? jlink --add-modules java.base --output macos
>>                                                             
>> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>>                                                                                                                                                                  
>> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat missing release.txt as emptry release signature

I think this can be tested akin to `JLinkOptionsTest` by implementing a simple plugin that transforms the `release.txt` resource and uses `--keep-packaged-modules` and then attempts to perform a link on the resulting image. Similarly we could cover the case of `release.txt` missing by using the `--exclude-resources` plugin.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 620:

> 618:             // silently ignore and fall through to version mismatch
> 619:             targetRelease = "";
> 620:         }

You could avoid the NSEE and try/catch by handling that case explicitly:

Suggestion:

            targetRelease = getReleaseInfo(target).orElseThrow(()-> new IllegalArgumentException("handle missing release.txt file"));
            if (currentRelease.equals(targetRelease)) {
               return;
            }

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

PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3449192405
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515101026

From haraldei at openjdk.org  Tue Nov 11 18:01:08 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Tue, 11 Nov 2025 18:01:08 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <M8b27hvhTw4LY0ArUpPvJjo7md6lxeDYAX04Inf1oQk=.42b70a05-1bb8-43e1-9f99-6edb0592b8c4@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <M8b27hvhTw4LY0ArUpPvJjo7md6lxeDYAX04Inf1oQk=.42b70a05-1bb8-43e1-9f99-6edb0592b8c4@github.com>
Message-ID: <AsiNHnsk2P3IISfzyEymFV_yNTIEF1orcN6R-jG6_VE=.35d834c6-ec2a-44eb-ac37-ceb3a85645be@github.com>

On Tue, 11 Nov 2025 16:24:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Thanks, I think I get it. What happens if you try to allocate 4 bytes of memory and request 8 byte alignment? Won't the result only be 4 byte aligned?

No, it will still be 8 byte aligned. See the implementation notes in [the jemalloc man page](https://man.freebsd.org/cgi/man.cgi?query=malloc):

> Allocation requests that are no more than half the quantum (8 or 16, depending on architecture) are rounded up to the nearest power of two that is at least sizeof(double). All other object size classes are multiples of the quantum, (,,,)

> I think the assumption of the current optimization is wrong: that malloc always returns memory aligned to a _constant_ `MAX_MALLOC_ALIGN`, and instead it depends on the size of the allocation, and the underlying allocator.

Yes, that is the root of the problem.

> I think ideally we'd be able to ask the allocator what the alignment of the memory it will return of a certain size is (or ask it to do an aligned allocation). 

Having something like `os::posix_memalign()` could eliminate the problem completely, and probably simplify the code in `allocateNativeInternal` quite a bit.

> We could also use a helper method that returns the alignment for a certain allocation size:
> 
> ```
> private static final boolean IS_FREEBSD = System.getProperty("os.name").equals(...);
> 
> private long alignmentForSize(long size) {
>     if (IS_FREEBSD) {
>         ...
>     } else {
>         return Unsafe.ADDRESS_SIZE == 4 ? 8 : 16;
>     }
> }
> ```

Yeah, this would definitely make the code clearer! I spent quite some time trying to understand where this assumption around `MAX_MALLOC_ALIGN` came from :)

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3518105587

From prappo at openjdk.org  Tue Nov 11 18:03:25 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Nov 2025 18:03:25 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <Jg3MeJaiB4fV2KnK2C-6eQbKxetJcckkxlE9roMqpm8=.520e7041-3bdb-4d4d-b8e1-44ce1fa7ee29@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
 <FmJLEn9tj9G3xESdUzLlowxBH8sAWCKmr7phzEkaLAE=.911e6751-fde7-48cc-843c-322508adfca6@github.com>
 <Jg3MeJaiB4fV2KnK2C-6eQbKxetJcckkxlE9roMqpm8=.520e7041-3bdb-4d4d-b8e1-44ce1fa7ee29@github.com>
Message-ID: <iVuR7hwr8KaS-ZUGLAUxuEuclNSJ0AGjDE3Ug3sqrGA=.3c5bd867-137d-4754-beac-6b88c84e2777@github.com>

On Tue, 11 Nov 2025 17:33:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think that would be too much to try to put in the InterruptedException class description but we could potentially extend the sentence in the Thread Interruption section to include the case where someone chooses to add the InterruptedException as a suppressed exception.

Fair enough.
 
> I would prefer not get into further guidance for unwrapping, e.g. catch FooException, get the InterruptedException cause, clear the interrupted status before re-throwing the cause.

I agree. Besides, there's no cookie-cutter guidance for cases like that. For example, some exceptions in an exception graph can originate in another thread. It would be a mistake to interrupt one thread because it got an exception that is linked to InterruptedException from another thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2515140262

From acobbs at openjdk.org  Tue Nov 11 18:18:02 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 11 Nov 2025 18:18:02 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v4]
In-Reply-To: <U1lkBfT6i8L3Tgj_nxz0XYY8Wh1GUB18JalHuZRdoyY=.f5474769-0603-4bb6-ae5e-0b52794e8b3d@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <U1lkBfT6i8L3Tgj_nxz0XYY8Wh1GUB18JalHuZRdoyY=.f5474769-0603-4bb6-ae5e-0b52794e8b3d@github.com>
Message-ID: <WEJPKlG5zFWDt2ZPfNRM1FBH_-kS3TVNNNr4_IQrj0M=.bf31cd9e-dc71-40c2-85ca-acabb94c4d55@github.com>

On Tue, 11 Nov 2025 17:56:19 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bad merge

src/java.base/share/classes/java/util/stream/StreamOpFlag.java line 753:

> 751:         int characteristics = spliterator.characteristics();
> 752:         if ((characteristics & Spliterator.SORTED) != 0 &&
> 753:                 (spliterator.getComparator() instanceof Comparator c &&

Not sure if the performance of `instanceof` is meaningfully faster than `!=`, but the `instanceof` test could be replaced with a null test:

if ((characteristics & Spliterator.SORTED) != 0) {
    Comparator<?> c = spliterator.getComparator();
    if (c != null && !c.equals(Comparator.naturalOrder()) { ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28226#discussion_r2515182450

From alanb at openjdk.org  Tue Nov 11 18:32:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 18:32:20 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption [v2]
In-Reply-To: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
Message-ID: <FnBgbzpMtQOX020kAZUDQBhSjvfnKaJRpwdNU9bO_9M=.a51d65b1-449d-4415-a98f-924ff8b115ca@github.com>

> This is docs only change to a add a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.

Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:

 - interrupt status -> interrupted status
 - Word smithing, mention throwing with IE as suppressed exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28216/files
  - new: https://git.openjdk.org/jdk/pull/28216/files/cfba1f26..48a6f22a

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

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

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

From alanb at openjdk.org  Tue Nov 11 18:32:22 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 18:32:22 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption [v2]
In-Reply-To: <FmJLEn9tj9G3xESdUzLlowxBH8sAWCKmr7phzEkaLAE=.911e6751-fde7-48cc-843c-322508adfca6@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
 <FmJLEn9tj9G3xESdUzLlowxBH8sAWCKmr7phzEkaLAE=.911e6751-fde7-48cc-843c-322508adfca6@github.com>
Message-ID: <79hhP7x9xGrSAldHKWULmFItZs6tiCA8lQNbBTTN5H4=.df83c9a4-7ea0-48d5-9d99-d1b60c1aadc7@github.com>

On Tue, 11 Nov 2025 16:04:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - interrupt status -> interrupted status
>>  - Word smithing, mention throwing with IE as suppressed exception
>
> src/java.base/share/classes/java/lang/Thread.java line 202:
> 
>> 200:  *
>> 201:  * <p> Code that doesn't invoke any interruptible methods can still respond to interrupt
>> 202:  * by polling the current thread's interrupt status with
> 
> Suggestion:
> 
>  * by polling the current thread's interrupted status with

Well spotted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28216#discussion_r2515236880

From duke at openjdk.org  Tue Nov 11 18:33:29 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 11 Nov 2025 18:33:29 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v5]
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <zyR0--nUOrfXGt2fqM0MPz_dQfey_rhn9L7jLuvnI1w=.662f909e-0188-4d40-adbc-632376e290eb@github.com>

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Fix SortOps.OfRef logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28226/files
  - new: https://git.openjdk.org/jdk/pull/28226/files/4c48f937..ea73382c

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

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

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

From prappo at openjdk.org  Tue Nov 11 18:39:03 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Nov 2025 18:39:03 GMT
Subject: RFR: 8371226: Thread class description needs section on Thread
 Interruption [v2]
In-Reply-To: <FnBgbzpMtQOX020kAZUDQBhSjvfnKaJRpwdNU9bO_9M=.a51d65b1-449d-4415-a98f-924ff8b115ca@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
 <FnBgbzpMtQOX020kAZUDQBhSjvfnKaJRpwdNU9bO_9M=.a51d65b1-449d-4415-a98f-924ff8b115ca@github.com>
Message-ID: <C8hvpDWPRDVBuVW-cqnuQ06lr1FJlJvVlVzW4WWGmNc=.0a60d330-48d7-4348-bc1d-57ffd5f65981@github.com>

On Tue, 11 Nov 2025 18:32:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is docs only change to a add a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.
>
> Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - interrupt status -> interrupted status
>  - Word smithing, mention throwing with IE as suppressed exception

Looks good!

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28216#pullrequestreview-3449396249

From cstein at openjdk.org  Tue Nov 11 18:45:48 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Nov 2025 18:45:48 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v2]
In-Reply-To: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
Message-ID: <Yev1Ev38yMOCRDd8lrLshwbaQ7vCllcR4t2kzGnlgio=.7139e763-6c91-405f-adc5-66a033e2bcd8@github.com>

> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Split test steps

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28154/files
  - new: https://git.openjdk.org/jdk/pull/28154/files/2af59381..28068ea6

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

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

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

From cstein at openjdk.org  Tue Nov 11 18:51:02 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Nov 2025 18:51:02 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v2]
In-Reply-To: <0kXR9LUYkpot1AJkkAk659sl0To-INwK5nOwR9wxozI=.9c076fb1-04d9-4e54-89ef-28c48c30f3b1@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <0kXR9LUYkpot1AJkkAk659sl0To-INwK5nOwR9wxozI=.9c076fb1-04d9-4e54-89ef-28c48c30f3b1@github.com>
Message-ID: <wIGyCzSjc8vmeLfJ8Y-UkTqXom07zm2K6zD3fSS8Op8=.1a1b8ef5-3da2-46a0-9d29-4a72ecee8d2b@github.com>

On Mon, 10 Nov 2025 13:55:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Split test steps
>
> test/jdk/tools/jar/ValidatorTest.java line 354:
> 
>> 352:             jar("--validate --file " + path);
>> 353:             fail("Expecting non-zero exit code validating: " + path);
>> 354:         } catch (IOException e) {
> 
> It's just that `jar` method that throws the expected exception, right? Could you limit the length of the `try` block to not cover the nested try block? Otherwise, if `JarInputStream` starts throwing the same exception, this test would stop testing the `jar` method. (also I think it makes it a little clearer which line is expected to throw)

Applied in https://github.com/openjdk/jdk/pull/28154/commits/28068ea6bf7b95fa6427cf644102ba3df9c3fa32

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2515301732

From alanb at openjdk.org  Tue Nov 11 18:56:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 18:56:09 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <rpFZEyo6gxOQ-Edt5hlZd9bCO4Dx8Tk7eUIHkt3mjJI=.23d08ced-51d3-4cf8-a878-1449b410adc1@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
 <VpxU4VbRHEOB1lboXmxqgp-aMGqvJ3Do2Md_j3DKeBk=.4e073851-01d2-4145-bf8d-dbe5c43069ed@github.com>
 <HnoobwuLz2v674j1Md6-bGccJOOID-SPKk91Ot3MOS8=.2b72df9f-7de9-41f0-afc4-411b95d65178@github.com>
 <bMfPBB44qiZYQFudEH6Anr7hYjHtehleU-B31K5C9yc=.8d6e1ce9-f074-43b5-95e4-cf827d2293a4@github.com>
 <rpFZEyo6gxOQ-Edt5hlZd9bCO4Dx8Tk7eUIHkt3mjJI=.23d08ced-51d3-4cf8-a878-1449b410adc1@github.com>
Message-ID: <rQmuFmMFBE6bQPrfK1h5hzEoxGY1nmMnU_SCtan1RHU=.72790468-29c7-4f4d-9481-48642a744370@github.com>

On Tue, 11 Nov 2025 17:49:40 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Actually, if we just leave it blank, that message still works in all translation, I think.
>> 
>> 
>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
>> 81:err.jlink.version.mismatch=jlink?????{0}???????java.base?????{1}???????
>> 
>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
>> 81:err.jlink.version.mismatch=jlink ?? {0} ??? java.base ?? {1} ???
>> 
>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
>> 81:err.jlink.version.mismatch=jlink-Version {0} stimmt nicht mit Ziel-java.base-Version {1} ?berein
>> 
>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
>> 133:err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1}
>
> With the latest update, the message is like
> 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build

It kinda works but a different message to say that the release info from the java.base module is not present might be clearer. Maybe it can include something "older JDK release?" or something to give a clue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515315980

From lancea at openjdk.org  Tue Nov 11 19:01:03 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 11 Nov 2025 19:01:03 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v2]
In-Reply-To: <Yev1Ev38yMOCRDd8lrLshwbaQ7vCllcR4t2kzGnlgio=.7139e763-6c91-405f-adc5-66a033e2bcd8@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <Yev1Ev38yMOCRDd8lrLshwbaQ7vCllcR4t2kzGnlgio=.7139e763-6c91-405f-adc5-66a033e2bcd8@github.com>
Message-ID: <b-S4bE-Ny6BEt33IdRgOhToP8Y1hbT43R2ApwDfVsQg=.809638d8-e4b2-4446-ac51-a1c2c9b18876@github.com>

On Tue, 11 Nov 2025 18:45:48 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Split test steps

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 257:

> 255:                         errorAndInvalid(formatMsg("error.validator.wrong.position", firstName, "0"));
> 256:                     }
> 257:                 }

I would suggest to move this check to after the order mismatch  validation below as the checks also validate if the manifest is missing in the LOC or CEN or out of order

By doing so you will also guarantee that Manifest is at the same offset it both he LOC and CEN

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2511473421

From cstein at openjdk.org  Tue Nov 11 19:09:38 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Nov 2025 19:09:38 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v3]
In-Reply-To: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
Message-ID: <40najGNF67k5YUI2jmSPDijNRRSfdCwPCAfGwmivqFU=.3dd7e106-2452-4b0b-906e-63fa22377030@github.com>

> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Move manifest location check to after the order mismatch validation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28154/files
  - new: https://git.openjdk.org/jdk/pull/28154/files/28068ea6..9986cd87

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

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

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

From cstein at openjdk.org  Tue Nov 11 19:09:40 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Nov 2025 19:09:40 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v3]
In-Reply-To: <b-S4bE-Ny6BEt33IdRgOhToP8Y1hbT43R2ApwDfVsQg=.809638d8-e4b2-4446-ac51-a1c2c9b18876@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <Yev1Ev38yMOCRDd8lrLshwbaQ7vCllcR4t2kzGnlgio=.7139e763-6c91-405f-adc5-66a033e2bcd8@github.com>
 <b-S4bE-Ny6BEt33IdRgOhToP8Y1hbT43R2ApwDfVsQg=.809638d8-e4b2-4446-ac51-a1c2c9b18876@github.com>
Message-ID: <bS7VlpAZSy8PwC1SyCIXsTCj0YzdcWjD1ibKWjjalE8=.28e2f25a-6812-4d40-bcc3-3bd85dca847c@github.com>

On Mon, 10 Nov 2025 17:58:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move manifest location check to after the order mismatch validation
>
> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 257:
> 
>> 255:                         errorAndInvalid(formatMsg("error.validator.wrong.position", firstName, "0"));
>> 256:                     }
>> 257:                 }
> 
> I would suggest to move this check to after the order mismatch  validation below as the checks also validate if the manifest is missing in the LOC or CEN or out of order
> 
> By doing so you will also guarantee that Manifest is at the same offset it both he LOC and CEN

Applied by https://github.com/openjdk/jdk/commit/9986cd87d732ed899d9a6300951f6e65d6a12eeb

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2515365378

From lancea at openjdk.org  Tue Nov 11 19:21:03 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 11 Nov 2025 19:21:03 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v3]
In-Reply-To: <40najGNF67k5YUI2jmSPDijNRRSfdCwPCAfGwmivqFU=.3dd7e106-2452-4b0b-906e-63fa22377030@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <40najGNF67k5YUI2jmSPDijNRRSfdCwPCAfGwmivqFU=.3dd7e106-2452-4b0b-906e-63fa22377030@github.com>
Message-ID: <GkmumCk6Hm_kT-mb5Ymn20t6WhsU_JuG-oupKuXU8Ns=.addec769-be00-4815-bcb8-0ef2b849c45e@github.com>

On Tue, 11 Nov 2025 19:09:38 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move manifest location check to after the order mismatch validation

test/jdk/tools/jar/ValidatorTest.java line 342:

> 340:     }
> 341: 
> 342:     private void testWrongManifestPosition(

This new test only validates that  the LOC MANIFEST.MF entries are where they need to be.  It does not do a similar CEN check in the event that the LOC and CEN entries do not match.  

If you change your validation order so that Validator checks the MANIFEST location after it checks the order, then you should be covered.

I would also add a comment to the test to help future maintainers to the test ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2515410239

From duke at openjdk.org  Tue Nov 11 20:59:20 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 11 Nov 2025 20:59:20 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v4]
In-Reply-To: <WEJPKlG5zFWDt2ZPfNRM1FBH_-kS3TVNNNr4_IQrj0M=.bf31cd9e-dc71-40c2-85ca-acabb94c4d55@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <U1lkBfT6i8L3Tgj_nxz0XYY8Wh1GUB18JalHuZRdoyY=.f5474769-0603-4bb6-ae5e-0b52794e8b3d@github.com>
 <WEJPKlG5zFWDt2ZPfNRM1FBH_-kS3TVNNNr4_IQrj0M=.bf31cd9e-dc71-40c2-85ca-acabb94c4d55@github.com>
Message-ID: <b9dcIt1-gj41A-RoBYWB8EVgugfV-55IfvszDqdLptk=.23e3740c-93ae-432d-b888-73d464b89541@github.com>

On Tue, 11 Nov 2025 18:15:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bad merge
>
> src/java.base/share/classes/java/util/stream/StreamOpFlag.java line 753:
> 
>> 751:         int characteristics = spliterator.characteristics();
>> 752:         if ((characteristics & Spliterator.SORTED) != 0 &&
>> 753:                 (spliterator.getComparator() instanceof Comparator c &&
> 
> Not sure if the performance of `instanceof` is meaningfully faster than `!=`, but the `instanceof` test could be replaced with a null test:
> 
> if ((characteristics & Spliterator.SORTED) != 0) {
>     Comparator<?> c = spliterator.getComparator();
>     if (c != null && !c.equals(Comparator.naturalOrder()) { ...

I actually prefer this, seems a bit more readable to me. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28226#discussion_r2515785006

From duke at openjdk.org  Tue Nov 11 20:59:18 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 11 Nov 2025 20:59:18 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v6]
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <wFIOoKuYbiFUcRK1HMXvY_hUekLfVCUI3RebUSW8DiU=.cc49894b-306e-40b3-96dc-3aef0a39d033@github.com>

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Clean up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28226/files
  - new: https://git.openjdk.org/jdk/pull/28226/files/ea73382c..c5bf7d56

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

  Stats: 10 lines in 1 file changed: 1 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28226/head:pull/28226

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

From duke at openjdk.org  Tue Nov 11 22:00:24 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 11 Nov 2025 22:00:24 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations
Message-ID: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>

# HashMap.putAll() optimizations: Eliminating Megamorphic Call Site Bottlenecks

## Summary

This PR addresses performance bottlenecks in `HashMap.putMapEntries()` by implementing direct optimizations for specific input types: `j.u.HashMap` and `j.u.Collections$UnmodifiableMap`. The optimizations target `HashMap(Map)` constructor and `putAll()` operations based on the real-world megamorphic behavior identified in [JDK-8368292](https://bugs.openjdk.org/browse/JDK-8368292), delivering significant performance improvements when multiple `Map` subtypes are used.

## Problem Context

### Megamorphic Call Site Overhead in Map Iteration
`HashMap.putMapEntries()` currently uses a generic approach that suffers from megamorphic call site overhead when applications perform bulk creation or population of HashMaps from various source map types:

1. `m.entrySet()` becomes megamorphic across different map implementations
2. `entrySet().iterator()` creates different iterator types
3. `entry.getKey()` and `entry.getValue()` calls vary by map type
4. Individual `putVal()` calls for each entry

When the source is `Collections$UnmodifiableMap`, the problem is compounded by megamorphic wrappers around the already-megamorphic iteration methods. In cases where the unwrapped map is also a HashMap, both the wrapper overhead and the iteration overhead can be eliminated with a single optimization.

## Optimized Methods

### HashMap
- **`putMapEntries(Map<? extends K, ? extends V> m, boolean evict)`**: Added fast paths for UnmodifiableMap unwrapping and HashMap-to-HashMap copying
- **`putMapEntries(HashMap<? extends K, ? extends V> src, boolean evict)`**: copies HashMap-to-HashMap via direct Node processing.  Avoids polymorphic issues and eliminates redundant calls to HashMap.hash().

## Implementation Details

### HashMap-to-HashMap Fast Path
Directly iterates over `src.table` to eliminate entrySet() allocation and polymorphic iterator calls, using the internal Node structure for maximum efficiency.

### UnmodifiableMap Unwrapping
Detects UnmodifiableMap instances and accesses the underlying map directly via the `m` field, eliminating wrapper-induced megamorphic call sites. UnmodifiableMap visibility changed from `private` to package-private to enable this direct access.

## Performance Impact

| Source Type | Size | Poisoned | Baseline | Optimized | Improvement |
|-------------|------|----------|----------|-----------|-------------|
| HashMap | 0 | true | 9.429 ns/op | 8.875 ns/op | **6% faster** |
| HashMap | 5 | true | 181.645 ns/op | 80.012 ns/op | **56% faster** |
| HashMap | 25 | true | 796.415 ns/op | 283.643 ns/op | **64% faster** |
| TreeMap | 0 | true | 9.356 ns/op | 9.155 ns/op | **-** |
| TreeMap | 5 | true | 169.233 ns/op | 169.566 ns/op | **-** |
| TreeMap | 25 | true | 792.667 ns/op | 791.195 ns/op | **-** |
| ConcurrentHashMap | 0 | true | 9.275 ns/op | 9.156 ns/op | **-** |
| ConcurrentHashMap | 5 | true | 229.291 ns/op | 227.382 ns/op | **-** |
| ConcurrentHashMap | 25 | true | 1071.336 ns/op | 1105.111 ns/op | **-** |
| UnmodifiableMap(HashMap) | 0 | true | 13.563 ns/op | 9.253 ns/op | **32% faster** |
| UnmodifiableMap(HashMap) | 5 | true | 318.184 ns/op | 76.264 ns/op | **76% faster** |
| UnmodifiableMap(HashMap) | 25 | true | 1510.489 ns/op | 284.001 ns/op | **81% faster** |
| UnmodifiableMap(TreeMap) | 5 | true | 323.412 ns/op | 186.990 ns/op | **42% faster** |
| UnmodifiableMap(TreeMap) | 25 | true | 1529.959 ns/op | 809.125 ns/op | **47% faster** |

This shows substantial improvements (32-81%) for optimized paths while maintaining no significant regression for non-optimized paths.

### Call Site Poisoning Impact

| Source Type | Size | Unpoisoned | Poisoned | Degradation |
|-------------|------|------------|----------|-------------|
| HashMap | 0 | 4.949 ns/op | 9.429 ns/op | 91% slower |
| HashMap | 5 | 86.796 ns/op | 181.645 ns/op | 109% slower |
| HashMap | 25 | 322.196 ns/op | 796.415 ns/op | 147% slower |
| TreeMap | 0 | 5.043 ns/op | 9.356 ns/op | 86% slower |
| TreeMap | 5 | 102.329 ns/op | 169.233 ns/op | 65% slower |
| TreeMap | 25 | 433.668 ns/op | 792.667 ns/op | 83% slower |
| ConcurrentHashMap | 0 | 5.054 ns/op | 9.275 ns/op | 84% slower |
| ConcurrentHashMap | 5 | 135.616 ns/op | 229.291 ns/op | 69% slower |
| ConcurrentHashMap | 25 | 591.134 ns/op | 1071.336 ns/op | 81% slower |
| UnmodifiableMap(HashMap) | 0 | 5.319 ns/op | 13.563 ns/op | 155% slower |
| UnmodifiableMap(HashMap) | 5 | 146.471 ns/op | 318.184 ns/op | 117% slower |
| UnmodifiableMap(HashMap) | 25 | 393.053 ns/op | 1510.489 ns/op | 284% slower |
| UnmodifiableMap(TreeMap) | 0 | 5.331 ns/op | 13.539 ns/op | 154% slower |
| UnmodifiableMap(TreeMap) | 5 | 78.215 ns/op | 323.412 ns/op | 314% slower |
| UnmodifiableMap(TreeMap) | 25 | 332.189 ns/op | 1529.959 ns/op | 361% slower |

## FAQ

**Q: Why use exact class check instead of instanceof for HashMap?**
A: This prevents the fast path from becoming megamorphic if HashMap subclasses are common, ensuring the optimization remains effective. Also, subclasses might override behavior in ways that make direct table access incorrect.

**Q: Is it safe to make UnmodifiableMap package-private?**
A: Yes. The class remains non-public and is only accessible within java.util. The change enables internal optimizations without exposing implementation details to external code.

**Q: Are these optimizations safe?**
A: Yes. HashMap-to-HashMap copying maintains identical behavior, and UnmodifiableMap unwrapping accesses the exact same data through a more direct path.

**Q: What about other Map types?**
A: Profiling data shows these are the biggest opportunities. Others exist but are lower-priority.

**Q: How do these optimizations interact with existing code?**
A: These are internal implementation optimizations that maintain full API compatibility. No external code changes are required.

## Testing

Comprehensive unit tests added to MOAT.java covering:
- HashMap.putAll() with various source map types
- UnmodifiableMap handling in putAll operations  
- Correctness verification for all optimization paths

Tier-1 tests passed.

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

Commit messages:
 - Bug fix & unit test
 - fixing whitespace
 - Optimizing HashMap.putAll() and .<init> for HashMap and C$UM

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

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

From asemenyuk at openjdk.org  Tue Nov 11 22:39:19 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 11 Nov 2025 22:39:19 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v5]
In-Reply-To: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
Message-ID: <r8u5L0fySGlaC9-c6_Dh07LOuCIpPFN-8FfB3_Y7BEw=.d4adf13c-3867-472c-9612-11b8377110e2@github.com>

> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
> 
> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
> 
> ### Error reporting improved
> 
> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
> 
> Command line (Windows): 
> 
> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
> 
> Old error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> 
> 
> New error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> Error: Option [--mac-package-name] is not valid on this platform
> Error: Option [-p] is not valid with type [exe]
> Error: Option [--linux-menu-group] is not valid on this platform
> 
> 
>  2. Fix misleading error messages.
> 
> Command line (Windows): 
> 
> jpackage --input no --main-jar no.jar
> 
> Old error output:
> 
> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
> 
> 
> New error output:
> 
> The value "no" provided for parameter --input is not a directory
> 
> 
> 
> 
> ### Help output fixed
> 
> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
> 
> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
> 
> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
> 
> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
> 
> ### Functional changes
> 
> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
> 
> Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.
> 
> In addition to `--opt...

Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision:

 - Update cli-*.txt help output files
 - StandardOption, HelpResources.properties: split description of the "add-launcher" option by OS
 - OptionSpecBuilder: bugfix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28163/files
  - new: https://git.openjdk.org/jdk/pull/28163/files/da39bcc1..0448168a

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

  Stats: 40 lines in 6 files changed: 32 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28163/head:pull/28163

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

From sherman at openjdk.org  Wed Nov 12 01:40:11 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 12 Nov 2025 01:40:11 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: <NPPeE5V5So2nS47cMyWWG8k3RI_L2-ew_DmbiHBkBnM=.854c1ae0-7e76-4e9d-8f70-4c1181f183a2@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <AHtBR8KtQsMG9sup-cEEPY07xRW8aLMkooVJeWWV5sY=.adf6db85-cb73-4e38-a8b4-abc0d3108052@github.com>
 <NPPeE5V5So2nS47cMyWWG8k3RI_L2-ew_DmbiHBkBnM=.854c1ae0-7e76-4e9d-8f70-4c1181f183a2@github.com>
Message-ID: <yyegsEPTSxzHcPeTrbmF65k6fZevbf3Rqc-YmGQwAnI=.6d10318c-d17a-428f-b5bd-24e35f86af4e@github.com>

On Fri, 7 Nov 2025 22:11:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to use value long for folding
>
> src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 152:
> 
>> 150:                 }
>> 151:             }
>> 152:         }
> 
> If expanded_case_cps was sorted, Array.binarySearch could be used to find the index of the first character in the range.
> And the loop could break when cp reaches the end of the range.

This is the existing implementation. I will leave it to the next round when we are back to the regex.

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

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

From sherman at openjdk.org  Wed Nov 12 01:52:04 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 12 Nov 2025 01:52:04 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: <NPPeE5V5So2nS47cMyWWG8k3RI_L2-ew_DmbiHBkBnM=.854c1ae0-7e76-4e9d-8f70-4c1181f183a2@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <AHtBR8KtQsMG9sup-cEEPY07xRW8aLMkooVJeWWV5sY=.adf6db85-cb73-4e38-a8b4-abc0d3108052@github.com>
 <NPPeE5V5So2nS47cMyWWG8k3RI_L2-ew_DmbiHBkBnM=.854c1ae0-7e76-4e9d-8f70-4c1181f183a2@github.com>
Message-ID: <vjLPkcN38FaTiPY5ibGn1i3k7Q-Y_XFYPcazv9oMFkg=.737746af-f5b3-48f7-a2da-55e184572b69@github.com>

On Fri, 7 Nov 2025 22:14:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to use value long for folding
>
> src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 169:
> 
>> 167:     private static final int HASH_NEXT = 2;
>> 168: 
>> 169:     private static int[][] hashKeys(int[] keys) {
> 
> It may be worthwhile to round up the hash modulo to a prime number to avoid unfortunate hash collisions.

I did try several prime numbers. It doesn?t really help because the code points in the table are mostly sequential within one continuous category range; if there?s a hash collision, using a different prime will likely just move the collision to the next code point.

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

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

From sherman at openjdk.org  Wed Nov 12 03:24:42 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 12 Nov 2025 03:24:42 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v8]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <v6JcrxDxBY8c7EbWe4YVBTMD3JBd_x995V-yhMlQ-DU=.784962de-bb5d-4b36-845f-424249d1a8a5@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:

  update with new test cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/c21de111..6a01bf7c

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

  Stats: 8 lines in 3 files changed: 3 ins; 2 del; 3 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 duke at openjdk.org  Wed Nov 12 05:48:00 2025
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Wed, 12 Nov 2025 05:48:00 GMT
Subject: RFR: 8371339: Illegal pattern char 'B' with locale.providers as
 HOST on macOS for Taiwanese
In-Reply-To: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
References: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
Message-ID: <b9Jegq_HaxLjuQBypMjq0Oolh0lyE4OreI40Hx1bWsk=.b061ed7d-a10b-4577-827a-a3387c5efc15@github.com>

On Thu, 6 Nov 2025 19:35:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover when we introduced "dayperiods" in the JDK ([JDK-8247781](https://bugs.openjdk.org/browse/JDK-8247781)). The CLDR Converter was modified to generate patterns for SimpleDateFormat for dayperiods (simply replacing them with ampm), and the same processing should have been applied to Host provider on mac, which also uses LDML patterns. As in the bug report, macos recently started using dayperiods, thus the issue was revealed. Regression test is not provided as it would require the macos's default locale should be configured to zh_TW. I have manually confirmed that the proposed fix would work for the problem case.

@RogerRiggs Could you please review this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28181#issuecomment-3520129064

From cstein at openjdk.org  Wed Nov 12 07:09:03 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 12 Nov 2025 07:09:03 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v3]
In-Reply-To: <GkmumCk6Hm_kT-mb5Ymn20t6WhsU_JuG-oupKuXU8Ns=.addec769-be00-4815-bcb8-0ef2b849c45e@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <40najGNF67k5YUI2jmSPDijNRRSfdCwPCAfGwmivqFU=.3dd7e106-2452-4b0b-906e-63fa22377030@github.com>
 <GkmumCk6Hm_kT-mb5Ymn20t6WhsU_JuG-oupKuXU8Ns=.addec769-be00-4815-bcb8-0ef2b849c45e@github.com>
Message-ID: <5SVrnXXcVGQgTledYjujDGtcfsUccxoJH0ba1bUkzFA=.adfbbc3b-d779-4386-80cb-46d7055132f9@github.com>

On Tue, 11 Nov 2025 19:18:35 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move manifest location check to after the order mismatch validation
>
> test/jdk/tools/jar/ValidatorTest.java line 342:
> 
>> 340:     }
>> 341: 
>> 342:     private void testWrongManifestPosition(
> 
> This new test only validates that  the LOC MANIFEST.MF entries are where they need to be.  It does not do a similar CEN check in the event that the LOC and CEN entries do not match.  
> 
> If you change your validation order so that Validator checks the MANIFEST location after it checks the order, then you should be covered.
> 
> I would also add a comment to the test to help future maintainers to the test ...

I'll add such a comment.

The existing tests for LOC-CEN related mismatches should already cover those cases. In addition, the results of the checks in `Validator` are accumulated - so their order is not important, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2517154697

From cstein at openjdk.org  Wed Nov 12 07:20:44 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 12 Nov 2025 07:20:44 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v4]
In-Reply-To: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
Message-ID: <D5VGiXjk-i01BJy3oN8TbGmQQ3fpwSo0iE8GToF83NY=.c2419065-5f17-4007-926e-dbf3ee885ada@github.com>

> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Add comment to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28154/files
  - new: https://git.openjdk.org/jdk/pull/28154/files/9986cd87..b7389cb6

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

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

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

From jbhateja at openjdk.org  Wed Nov 12 08:03:02 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 12 Nov 2025 08:03:02 GMT
Subject: RFR: 8370691: Add new HalffloatVector type and enable
 intrinsification of float16 vector operations
In-Reply-To: <sarGywPvaDEM5GZdW_6tFu6RqpdYzsD-mpzPpgDETeo=.7f7d2de6-0631-493b-bbde-50c36cb624e0@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <_ryF0SNpSLahH4HkGqSnGKc_6d9P1fWrKYTS0jRPvtk=.ff2143aa-d3a5-4776-bdd0-95646dfd35e9@github.com>
 <sarGywPvaDEM5GZdW_6tFu6RqpdYzsD-mpzPpgDETeo=.7f7d2de6-0631-493b-bbde-50c36cb624e0@github.com>
Message-ID: <diXGgYU0jyAVgKuiCcv9hzGIQ7i8Mc7FSv113U1UdA0=.409690ea-cdcf-4512-8e61-89377248735c@github.com>

On Tue, 11 Nov 2025 16:28:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> We already have a lot of things in the codebase now from previous issues that use `HF` everywhere, for example some node names, and the type. Should we maybe rename all of them to `F16`, or something else? Open question, not sure of the answer yet.
>
>> We already have a lot of things in the codebase now from previous issues that use `HF` everywhere, for example some node names, and the type. Should we maybe rename all of them to `F16`, or something else? Open question, not sure of the answer yet.
> 
> I was only referring to the Java code, esp. the new public classes so they align with the `Float16` element type. I do think it worthwhile to align so we are consistent across the platform. Revisiting the names in HotSpot, and their internal connection in Java, could be done in a separate PR?

Hi @PaulSandoz , Thanks for your comments. Please find below my responses.

> When you generate the fallback code for unary/binary etc can you push the carrier type and conversations into the uOp/bOp implementations so you don't have to explicitly operate on the carrier type and do the conversions as you do now e.g.,:
> 
> ```
> v0.uOp(m, (i, a) -> float16ToShortBits(Float16.valueOf(-(shortBitsToFloat16(($type$)a).floatValue()))));
> ```

Currently, uOp and uOpTemplates are part of the scaffolding logic and are sacrosanct; they are shared by various abstracted vector classes, and their semantics are defined by the lambda expression. I agree that explicit conversion in lambdas looks verbose, but moving them to uOpTemplate may fracture the lambda expression such that part of its semantics, i.e,. conversions, will seep into uOpTemplate, while what will appear at the surface will be the expression operating over primitive float values; this may become very confusing. 

> 
> The transition of intrinsic arguments from `vsp.elementType()` to `vsp.carrierType(), vsp.operType()` is a little unfortunate. Is this because HotSpot cannot directly refer to the `Float16` class from the incubating module? 

Yes, the idea here was to clearly differentiate b/w elemType and carrierType and avoid passing Float16.class as an argument to intrinsic entry points. Unlike the VectorSupport class, Float16 is part of the incubating module and cannot be directly exposed to VM, i.e., we cannot create a vmSymbol for it during initialization. This would have made all the lane type checks in-line expand name-based rather than efficient symbol lookup.

> Requiring two arguments means they can get out of sync. Previously the class provided all the information needed, now 
> arguably the type does. 

Yes, from the compiler standpoint point all we care about is the carrier type, which determines the vector lane size. This is augmented with operation kind (PRIM / FP16) to differentiate a short vector lane from a float16 vector lane. Apart from this, we need to pass the VectorBox type to wrap the vector IR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3520530639

From jbhateja at openjdk.org  Wed Nov 12 08:03:04 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 12 Nov 2025 08:03:04 GMT
Subject: RFR: 8370691: Add new HalffloatVector type and enable
 intrinsification of float16 vector operations
In-Reply-To: <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
Message-ID: <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>

On Tue, 11 Nov 2025 00:59:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Some quick comments.
> > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
> 
> I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.

There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3520534564

From alanb at openjdk.org  Wed Nov 12 08:14:26 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Nov 2025 08:14:26 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <hhpTt97mJhKq1xoZ0iVQ7hQPjCzvyo_-hMgc0LsmiZo=.247d98e8-8c50-41ac-8ba5-d31914aab06c@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
 <hhpTt97mJhKq1xoZ0iVQ7hQPjCzvyo_-hMgc0LsmiZo=.247d98e8-8c50-41ac-8ba5-d31914aab06c@github.com>
Message-ID: <KS5whSwzltSPsIO_QoLmQsij-l2uv6zH_KR9E3u8krU=.5c8c3369-c72d-4f06-8b48-bbd62021dfc4@github.com>

On Tue, 11 Nov 2025 12:40:29 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lance's man page inputs
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 264:
> 
>> 262: \                             versions.
>> 263: main.help.opt.any=\
>> 264: \ Operation modifiers valid in any mode:\n\
> 
> This text _valid in any mode_ was present in earlier releases but does not seem to have been true for `-C` with `-x`.

Do we need to create a bug to check the help output?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/2752#discussion_r2517325560

From alanb at openjdk.org  Wed Nov 12 08:21:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Nov 2025 08:21:12 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
 <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>
 <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>
Message-ID: <t_h54JLqwtUPhfVq8gZSdua9Ad-6x8a00NwDq1Qu6y4=.9b25ed17-bfb4-4039-9c27-a43f6c0e1bdc@github.com>

On Tue, 11 Nov 2025 15:01:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> > It's aligned with setAccessible. It's corner case of course but if a JNI attached thread invokes setAccessible with no java frames on the stack, then it is specified to only succeed if the API element is public and declared in a public class in an exported package.
> 
> Consider setting the field `java.lang.constant.DirectMethodHandleDesc$Kind.refKind` (public final instance field in public class in exported, non-open package) in 3 ways:
> 
> 1. `Field.setAccessible` + `set` in Java code: Now `set` fails without `--add-opens` (not open)

There is a spec issue here. Field.set on final instance fields should align with setAccessible. So assuming setAccessible has succeeded, final field mutation for the caller module is enabled, then Field.set should be specified to succeed when the field is public and its declaring class is public and in a package that its module exports "statically" to the caller module.  Right now, we specify that the package must be statically open to the caller which is more than setAccessible requires for this case. I agree this may be surprising. I've drafted spec (and implementation) changes to align them but I want to check with Alex and Ron as it doing it now would require changing a line in the JEP too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3520598996

From swen at openjdk.org  Wed Nov 12 08:27:22 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 12 Nov 2025 08:27:22 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v14]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <j0CoISQQjbpB7n8cN8P3M9savhFZCy5sYbBEiRthDKw=.dc1994d0-32cf-405a-a46e-35d21b072edf@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use append string

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/271b1572..56661320

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=12-13

  Stats: 37 lines in 4 files changed: 2 ins; 30 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

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

From pminborg at openjdk.org  Wed Nov 12 08:30:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Nov 2025 08:30:03 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <Ut7NlZ9u8jDdeP5IjnXLDuFUfVYciRNuxOk8UXI7BLQ=.620f195e-c717-431d-96a0-740bb92f69ac@github.com>

On Tue, 11 Nov 2025 14:11:28 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Would it make sense to add `OperatingSystem.BSD` to consolidate any such predicates?

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3520634175

From swen at openjdk.org  Wed Nov 12 08:32:42 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 12 Nov 2025 08:32:42 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v15]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <MtYbIWVhLT_Q_E2I4N1JZhRdmvwSsGBPK2HYZdcpOL8=.17188294-647d-401c-835e-076517af6801@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - use append string
 - remove assert & newCapacity
 - fix assert
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - Fix JavaLangAccess.appendLatin1 javadoc to match method signature
   
   The previous javadoc incorrectly described the method as appending a two-digit
   integer representation, but the method actually appends two Latin-1 characters.
   Updated the documentation to accurately reflect the method's behavior.
   
   Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - Merge remote-tracking branch 'upstream/master' into appendPair_202508
 - appendPair instead of appendLatin1(char, char)
 - Revert "appendPair instead of append(char, char)"
   
   This reverts commit d969a235e54da4ac96b7205982624f52305cae31.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/76a0732b...4e77cc58

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

Changes: https://git.openjdk.org/jdk/pull/26911/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=14
  Stats: 156 lines in 7 files changed: 125 ins; 4 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

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

From pminborg at openjdk.org  Wed Nov 12 09:17:20 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Nov 2025 09:17:20 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
Message-ID: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>

This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 

All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.

It should be noted that with this change, the running time for the benchmarks would increase significantly.

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

Commit messages:
 - Fix copyright years
 - Improve BulkOp benchmarks

Changes: https://git.openjdk.org/jdk/pull/28260/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28260&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371571
  Stats: 572 lines in 5 files changed: 355 ins; 107 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/28260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28260/head:pull/28260

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

From pminborg at openjdk.org  Wed Nov 12 09:17:21 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Nov 2025 09:17:21 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
Message-ID: <ECaItgn93sYNj5Oq7sJrvQWhgp1v1V6zk4KE0c0EgH4=.b7e5bc46-b3b4-4c70-a33f-ed99a17b4c4e@github.com>

On Wed, 12 Nov 2025 09:08:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
> 
> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
> 
> It should be noted that with this change, the running time for the benchmarks would increase significantly.

Here are some examples of benchmark output:


Benchmark                                 (alignment)  (segmentType)  (size)  Mode  Cnt  Score   Error  Units
SegmentBulkHash.Array.array                       N/A            N/A       2  avgt   30  2.681 ? 0.137  ns/op
SegmentBulkHash.Segment.hash                  ALIGNED           HEAP       2  avgt   30  3.531 ? 0.343  ns/op
SegmentBulkHash.Segment.hash                  ALIGNED         NATIVE       2  avgt   30  5.070 ? 0.963  ns/op
SegmentBulkHash.Segment.hash                UNALIGNED           HEAP       2  avgt   30  3.498 ? 0.238  ns/op
SegmentBulkHash.Segment.hash                UNALIGNED         NATIVE       2  avgt   30  4.158 ? 0.154  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        ALIGNED           HEAP       2  avgt   30  4.470 ? 0.215  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        ALIGNED         NATIVE       2  avgt   30  3.906 ? 0.233  ns/op
SegmentBulkHash.Segment.hashLoopIntInt      UNALIGNED           HEAP       2  avgt   30  4.531 ? 0.246  ns/op
SegmentBulkHash.Segment.hashLoopIntInt      UNALIGNED         NATIVE       2  avgt   30  3.619 ? 0.095  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       ALIGNED           HEAP       2  avgt   30  4.226 ? 0.266  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       ALIGNED         NATIVE       2  avgt   30  3.223 ? 0.351  ns/op
SegmentBulkHash.Segment.hashLoopIntLong     UNALIGNED           HEAP       2  avgt   30  4.125 ? 0.293  ns/op
SegmentBulkHash.Segment.hashLoopIntLong     UNALIGNED         NATIVE       2  avgt   30  3.329 ? 0.221  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      ALIGNED           HEAP       2  avgt   30  3.603 ? 0.285  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      ALIGNED         NATIVE       2  avgt   30  3.048 ? 0.172  ns/op
SegmentBulkHash.Segment.hashLoopLongLong    UNALIGNED           HEAP       2  avgt   30  3.666 ? 0.180  ns/op
SegmentBulkHash.Segment.hashLoopLongLong    UNALIGNED         NATIVE       2  avgt   30  3.237 ? 0.257  ns/op



Benchmark                                 (alignment)  (segmentType)  (size)  Mode  Cnt  Score   Error  Units
SegmentBulkCopy.Array.arrayCopy                   N/A            N/A       2  avgt   30  5.654 ? 0.363  ns/op
SegmentBulkCopy.Array.arrayCopy                   N/A            N/A       3  avgt   30  4.704 ? 0.337  ns/op
SegmentBulkCopy.Array.bufferCopy                  N/A            N/A       2  avgt   30  6.964 ? 0.711  ns/op
SegmentBulkCopy.Array.bufferCopy                  N/A            N/A       3  avgt   30  7.033 ? 0.486  ns/op
SegmentBulkCopy.Segment.copy                  ALIGNED           HEAP       2  avgt   30  6.333 ? 0.513  ns/op
SegmentBulkCopy.Segment.copy                  ALIGNED           HEAP       3  avgt   30  6.181 ? 0.632  ns/op
SegmentBulkCopy.Segment.copy                  ALIGNED         NATIVE       2  avgt   30  4.552 ? 0.312  ns/op
SegmentBulkCopy.Segment.copy                  ALIGNED         NATIVE       3  avgt   30  4.680 ? 0.362  ns/op
SegmentBulkCopy.Segment.copy                UNALIGNED           HEAP       2  avgt   30  6.574 ? 0.568  ns/op
SegmentBulkCopy.Segment.copy                UNALIGNED           HEAP       3  avgt   30  6.516 ? 0.431  ns/op
SegmentBulkCopy.Segment.copy                UNALIGNED         NATIVE       2  avgt   30  4.503 ? 0.245  ns/op
SegmentBulkCopy.Segment.copy                UNALIGNED         NATIVE       3  avgt   30  4.584 ? 0.254  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        ALIGNED           HEAP       2  avgt   30  5.492 ? 0.242  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        ALIGNED           HEAP       3  avgt   30  7.173 ? 0.414  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        ALIGNED         NATIVE       2  avgt   30  4.743 ? 0.173  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        ALIGNED         NATIVE       3  avgt   30  5.651 ? 0.144  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt      UNALIGNED           HEAP       2  avgt   30  5.658 ? 0.281  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt      UNALIGNED           HEAP       3  avgt   30  6.853 ? 0.388  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt      UNALIGNED         NATIVE       2  avgt   30  4.807 ? 0.220  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt      UNALIGNED         NATIVE       3  avgt   30  5.765 ? 0.261  ns/op
SegmentBulkCopy.Segment.copyUnsafe            ALIGNED           HEAP       2  avgt   30  9.287 ? 0.410  ns/op
SegmentBulkCopy.Segment.copyUnsafe            ALIGNED           HEAP       3  avgt   30  9.258 ? 0.440  ns/op
SegmentBulkCopy.Segment.copyUnsafe            ALIGNED         NATIVE       2  avgt   30  8.188 ? 0.384  ns/op
SegmentBulkCopy.Segment.copyUnsafe            ALIGNED         NATIVE       3  avgt   30  7.348 ? 0.321  ns/op
SegmentBulkCopy.Segment.copyUnsafe          UNALIGNED           HEAP       2  avgt   30  8.741 ? 0.363  ns/op
SegmentBulkCopy.Segment.copyUnsafe          UNALIGNED           HEAP       3  avgt   30  8.788 ? 0.287  ns/op
SegmentBulkCopy.Segment.copyUnsafe          UNALIGNED         NATIVE       2  avgt   30  7.534 ? 0.241  ns/op
SegmentBulkCopy.Segment.copyUnsafe          UNALIGNED         NATIVE       3  avgt   30  7.238 ? 0.271  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       ALIGNED           HEAP       2  avgt   30  5.412 ? 0.182  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       ALIGNED           HEAP       3  avgt   30  6.545 ? 0.352  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       ALIGNED         NATIVE       2  avgt   30  5.402 ? 0.882  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       ALIGNED         NATIVE       3  avgt   30  5.396 ? 0.259  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong     UNALIGNED           HEAP       2  avgt   30  5.495 ? 0.268  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong     UNALIGNED           HEAP       3  avgt   30  6.354 ? 0.350  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong     UNALIGNED         NATIVE       2  avgt   30  4.439 ? 0.206  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong     UNALIGNED         NATIVE       3  avgt   30  5.586 ? 0.289  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      ALIGNED           HEAP       2  avgt   30  5.109 ? 0.213  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      ALIGNED           HEAP       3  avgt   30  7.341 ? 0.364  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      ALIGNED         NATIVE       2  avgt   30  4.486 ? 0.235  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      ALIGNED         NATIVE       3  avgt   30  6.911 ? 0.289  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong    UNALIGNED           HEAP       2  avgt   30  5.302 ? 0.138  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong    UNALIGNED           HEAP       3  avgt   30  7.409 ? 0.431  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong    UNALIGNED         NATIVE       2  avgt   30  4.524 ? 0.184  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong    UNALIGNED         NATIVE       3  avgt   30  6.463 ? 0.262  ns/op



Benchmark                                 (alignment)  (segmentType)  (size)  Mode  Cnt  Score   Error  Units
SegmentBulkFill.Array.arraysFill                  N/A            N/A       2  avgt   30  2.138 ? 0.086  ns/op
SegmentBulkFill.Array.arraysFill                  N/A            N/A       3  avgt   30  2.124 ? 0.056  ns/op
SegmentBulkFill.Array.arraysFillLoop              N/A            N/A       2  avgt   30  1.715 ? 0.092  ns/op
SegmentBulkFill.Array.arraysFillLoop              N/A            N/A       3  avgt   30  2.124 ? 0.052  ns/op
SegmentBulkFill.Array.bufferFillLoop              N/A            N/A       2  avgt   30  3.293 ? 0.077  ns/op
SegmentBulkFill.Array.bufferFillLoop              N/A            N/A       3  avgt   30  3.321 ? 0.090  ns/op
SegmentBulkFill.Segment.fill                  ALIGNED           HEAP       2  avgt   30  2.368 ? 0.073  ns/op
SegmentBulkFill.Segment.fill                  ALIGNED           HEAP       3  avgt   30  2.429 ? 0.060  ns/op
SegmentBulkFill.Segment.fill                  ALIGNED         NATIVE       2  avgt   30  1.974 ? 0.070  ns/op
SegmentBulkFill.Segment.fill                  ALIGNED         NATIVE       3  avgt   30  1.990 ? 0.047  ns/op
SegmentBulkFill.Segment.fill                UNALIGNED           HEAP       2  avgt   30  2.641 ? 0.270  ns/op
SegmentBulkFill.Segment.fill                UNALIGNED           HEAP       3  avgt   30  2.666 ? 0.077  ns/op
SegmentBulkFill.Segment.fill                UNALIGNED         NATIVE       2  avgt   30  2.157 ? 0.065  ns/op
SegmentBulkFill.Segment.fill                UNALIGNED         NATIVE       3  avgt   30  2.084 ? 0.026  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        ALIGNED           HEAP       2  avgt   30  3.409 ? 0.069  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        ALIGNED           HEAP       3  avgt   30  4.141 ? 0.114  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        ALIGNED         NATIVE       2  avgt   30  2.990 ? 0.088  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        ALIGNED         NATIVE       3  avgt   30  3.382 ? 0.059  ns/op
SegmentBulkFill.Segment.fillLoopIntInt      UNALIGNED           HEAP       2  avgt   30  3.288 ? 0.061  ns/op
SegmentBulkFill.Segment.fillLoopIntInt      UNALIGNED           HEAP       3  avgt   30  4.322 ? 0.228  ns/op
SegmentBulkFill.Segment.fillLoopIntInt      UNALIGNED         NATIVE       2  avgt   30  3.451 ? 0.085  ns/op
SegmentBulkFill.Segment.fillLoopIntInt      UNALIGNED         NATIVE       3  avgt   30  3.998 ? 0.133  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       ALIGNED           HEAP       2  avgt   30  3.512 ? 0.092  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       ALIGNED           HEAP       3  avgt   30  4.239 ? 0.136  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       ALIGNED         NATIVE       2  avgt   30  3.253 ? 0.133  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       ALIGNED         NATIVE       3  avgt   30  3.578 ? 0.158  ns/op
SegmentBulkFill.Segment.fillLoopIntLong     UNALIGNED           HEAP       2  avgt   30  3.082 ? 0.089  ns/op
SegmentBulkFill.Segment.fillLoopIntLong     UNALIGNED           HEAP       3  avgt   30  3.669 ? 0.086  ns/op
SegmentBulkFill.Segment.fillLoopIntLong     UNALIGNED         NATIVE       2  avgt   30  2.875 ? 0.091  ns/op
SegmentBulkFill.Segment.fillLoopIntLong     UNALIGNED         NATIVE       3  avgt   30  3.443 ? 0.075  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      ALIGNED           HEAP       2  avgt   30  2.717 ? 0.062  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      ALIGNED           HEAP       3  avgt   30  4.013 ? 0.105  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      ALIGNED         NATIVE       2  avgt   30  2.353 ? 0.049  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      ALIGNED         NATIVE       3  avgt   30  3.718 ? 0.098  ns/op
SegmentBulkFill.Segment.fillLoopLongLong    UNALIGNED           HEAP       2  avgt   30  2.769 ? 0.098  ns/op
SegmentBulkFill.Segment.fillLoopLongLong    UNALIGNED           HEAP       3  avgt   30  4.097 ? 0.131  ns/op
SegmentBulkFill.Segment.fillLoopLongLong    UNALIGNED         NATIVE       2  avgt   30  2.388 ? 0.068  ns/op
SegmentBulkFill.Segment.fillLoopLongLong    UNALIGNED         NATIVE       3  avgt   30  3.688 ? 0.069  ns/op
SegmentBulkFill.Segment.fillUnsafe            ALIGNED           HEAP       2  avgt   30  4.740 ? 0.118  ns/op
SegmentBulkFill.Segment.fillUnsafe            ALIGNED           HEAP       3  avgt   30  6.462 ? 0.292  ns/op
SegmentBulkFill.Segment.fillUnsafe            ALIGNED         NATIVE       2  avgt   30  4.376 ? 0.139  ns/op
SegmentBulkFill.Segment.fillUnsafe            ALIGNED         NATIVE       3  avgt   30  5.864 ? 0.342  ns/op
SegmentBulkFill.Segment.fillUnsafe          UNALIGNED           HEAP       2  avgt   30  6.642 ? 0.584  ns/op
SegmentBulkFill.Segment.fillUnsafe          UNALIGNED           HEAP       3  avgt   30  7.080 ? 0.337  ns/op
SegmentBulkFill.Segment.fillUnsafe          UNALIGNED         NATIVE       2  avgt   30  6.519 ? 0.330  ns/op
SegmentBulkFill.Segment.fillUnsafe          UNALIGNED         NATIVE       3  avgt   30  6.392 ? 0.229  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/28260#issuecomment-3520881115

From pminborg at openjdk.org  Wed Nov 12 10:07:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Nov 2025 10:07:39 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:

 - Clarify toString spec
 - Merge branch 'master' into lazy-constants
 - Add @AOTSafeClassInitializer
 - Address comments in PR
 - Fix merge mistake
 - Merge master
 - Rework toString implementations
 - Update after doc comments
 - Merge branch 'master' into lazy-constants
 - Revert the AbstractMap.keySet @Stable annotation
 - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

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

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=24
  Stats: 8445 lines in 60 files changed: 3836 ins; 4490 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From mcimadamore at openjdk.org  Wed Nov 12 11:24:09 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Nov 2025 11:24:09 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>

On Tue, 11 Nov 2025 14:11:28 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

>From a logical point of view, what we'd need would be a couple of extra constants:

* `MIN_ALIGN`, this is the minimum alignment provided by the allocator/OS/platform combo
* `MAX_ALIGN`, this is the maximum alignment provided by the allocator/OS/platform combo

Then, we have three cases:
* if the requested alignment `A` is `A <= MIN_ALIGN`, we can just allocate and don't adjust for alignment
* if the requested alignment `A` is `MIN_ALIGN < A <= MAX_ALIGN` and the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment
* otherwise, allocate a bigger segment and manually align the result

The problem is: how do we discover these constants?

> Having something like os::posix_memalign() could eliminate the problem completely, and probably simplify the code in allocateNativeInternal quite a bit.

Yeah, that would be nice -- but I noticed that `posix_memalign` is currently not allowed in hotspot code:

https://github.com/openjdk/jdk/blob/400a83da893f5fc285a175b63a266de21e93683c/src/hotspot/os/posix/forbiddenFunctions_posix.hpp#L45

So, allowing this would require some discussion. Also, going down this path will likely require its own `Unsafe` primitive, and intrinsics, plus potential tweaks to support NMT. So, not straightforward to pull off.

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3521432776

From mcimadamore at openjdk.org  Wed Nov 12 11:24:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Nov 2025 11:24:10 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>
Message-ID: <PYJzzCOqgz9T7kon0xrZEXlkUmmNDaKun58WUX0GDMY=.eb5713dc-82cb-439f-b433-c9d8c7b38423@github.com>

On Wed, 12 Nov 2025 11:19:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The problem is: how do we discover these constants?

Note: we can't just do a "trial allocation" of 4 bytes and see what comes out -- we might just be "lucky" and see an 8-byte aligned address, even though the underlying allocator is aligning at 4 bytes...

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3521438964

From duke at openjdk.org  Wed Nov 12 11:25:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 11:25:18 GMT
Subject: RFR: 8371645: BasicImageReader getEntryNames() is stateful and cannot
 be called more than once
Message-ID: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>

Stop entry name creation using a stateful read of underlying buffer (which moves the position and consumes it).

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

Commit messages:
 - Make entry name reading idempotent

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

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

From mcimadamore at openjdk.org  Wed Nov 12 11:30:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Nov 2025 11:30:06 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>
Message-ID: <yYXR8A0jq4BM2cfAG0xxA4n80ZpRIDgfGTSQnke_2Rg=.0a5a3b51-3be8-4c94-bc43-22fad469022e@github.com>

On Wed, 12 Nov 2025 11:19:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Then, we have three cases:
> 
>     * if the requested alignment `A` is `A <= MIN_ALIGN`, we can just allocate and don't adjust for alignment
> 
>     * if the requested alignment `A` is `MIN_ALIGN < A <= MAX_ALIGN` and the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment
> 
>     * otherwise, allocate a bigger segment and manually align the result

If we can't establish a min alignment, we could at least have some way to determine the max alignment (I'd say probably 16 is a good number because of system ABI?), and then just use two rules:

 * if the requested alignment `A` is `A <= MAX_ALIGN` **and** the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment
 * otherwise, allocate a bigger segment and manually align the result
 
 This should still deliver the kind of compaction we were aiming for with the optimization, but hopefully get there in a more portable way?

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3521457435

From alanb at openjdk.org  Wed Nov 12 11:47:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Nov 2025 11:47:19 GMT
Subject: RFR: 8371645: BasicImageReader getEntryNames() is stateful and
 cannot be called more than once
In-Reply-To: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
References: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
Message-ID: <42LDZXZPDw7wdMDEXMn98jOckaTVZBihEUwJ9732EDA=.4ad8ddd3-443f-4af8-8577-e8c996751aa0@github.com>

On Wed, 12 Nov 2025 11:17:21 GMT, David Beaumont <duke at openjdk.org> wrote:

> Stop entry name creation using a stateful read of underlying buffer (which moves the position and consumes it).

Can you confirm that the only usage is the jimage tool?

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

PR Comment: https://git.openjdk.org/jdk/pull/28263#issuecomment-3521519802

From duke at openjdk.org  Wed Nov 12 12:06:35 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 12:06:35 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure
Message-ID: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>

Rewrite of VerifyJimage test to fix several severe issues.

This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.

Issue 1: Broken file comparison

This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.

This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.

Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.

Issue 2: Use of BasicImageReader for class file reading

A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.

The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.

Issue 3: File comparison mode was never run by default

This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.

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

Depends on: https://git.openjdk.org/jdk/pull/28263

Commit messages:
 - Fix very broken test and make it compatible with preview mode

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

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

From haraldei at openjdk.org  Wed Nov 12 12:10:01 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Wed, 12 Nov 2025 12:10:01 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <yYXR8A0jq4BM2cfAG0xxA4n80ZpRIDgfGTSQnke_2Rg=.0a5a3b51-3be8-4c94-bc43-22fad469022e@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>
 <yYXR8A0jq4BM2cfAG0xxA4n80ZpRIDgfGTSQnke_2Rg=.0a5a3b51-3be8-4c94-bc43-22fad469022e@github.com>
Message-ID: <0ThHtq8WS_vBh593c4Rj-E33BFC-fh9xq8QMj3euQRc=.13ed680a-30eb-4a5c-9716-dd5c9f9e192e@github.com>

On Wed, 12 Nov 2025 11:27:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> From a logical point of view, what we'd need would be a couple of extra constants:
>> 
>> * `MIN_ALIGN`, this is the minimum alignment provided by the allocator/OS/platform combo
>> * `MAX_ALIGN`, this is the maximum alignment provided by the allocator/OS/platform combo
>> 
>> Then, we have three cases:
>> * if the requested alignment `A` is `A <= MIN_ALIGN`, we can just allocate and don't adjust for alignment
>> * if the requested alignment `A` is `MIN_ALIGN < A <= MAX_ALIGN` and the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment
>> * otherwise, allocate a bigger segment and manually align the result
>> 
>> The problem is: how do we discover these constants?
>> 
>>> Having something like os::posix_memalign() could eliminate the problem completely, and probably simplify the code in allocateNativeInternal quite a bit.
>> 
>> Yeah, that would be nice -- but I noticed that `posix_memalign` is currently not allowed in hotspot code:
>> 
>> https://github.com/openjdk/jdk/blob/400a83da893f5fc285a175b63a266de21e93683c/src/hotspot/os/posix/forbiddenFunctions_posix.hpp#L45
>> 
>> So, allowing this would require some discussion. Also, going down this path will likely require its own `Unsafe` primitive, and intrinsics, plus potential tweaks to support NMT. So, not straightforward to pull off.
>
>> Then, we have three cases:
>> 
>>     * if the requested alignment `A` is `A <= MIN_ALIGN`, we can just allocate and don't adjust for alignment
>> 
>>     * if the requested alignment `A` is `MIN_ALIGN < A <= MAX_ALIGN` and the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment
>> 
>>     * otherwise, allocate a bigger segment and manually align the result
> 
> If we can't establish a min alignment, we could at least have some way to determine the max alignment (I'd say probably 16 is a good number because of system ABI?), and then just use two rules:
> 
>  * if the requested alignment `A` is `A <= MAX_ALIGN` **and** the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment
>  * otherwise, allocate a bigger segment and manually align the result
>  
>  This should still deliver the kind of compaction we were aiming for with the optimization, but hopefully get there in a more portable way?

@mcimadamore Thanks for the input! I will have to think more about this to be sure I see it clearly.

I was made aware by @bsdkurt that my original proposal here is flawed. It will work the same for platforms with a constant `MAX_MALLOC_ALIGN` of 16, but for the FreeBSD/jemalloc case, it still allocates only 8 bytes, but may cause access outside of the allocated memory. The test pass because the out of bounds accessed memory is not allocated or overwritten by somebody else.

Currently I think @JornVernee's suggestion looks the most promising. It allows for flexibility in determining the underlying architecture's alignment preferences base on the size of the allocation.

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3521603834

From jvernee at openjdk.org  Wed Nov 12 12:18:04 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 12:18:04 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v4]
In-Reply-To: <D5VGiXjk-i01BJy3oN8TbGmQQ3fpwSo0iE8GToF83NY=.c2419065-5f17-4007-926e-dbf3ee885ada@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <D5VGiXjk-i01BJy3oN8TbGmQQ3fpwSo0iE8GToF83NY=.c2419065-5f17-4007-926e-dbf3ee885ada@github.com>
Message-ID: <647L2WUdlyyz_lCer-cWGhypEEjtv5CO5pFtpRwga3o=.13596e36-16dc-4688-bd11-b01d95ee5529@github.com>

On Wed, 12 Nov 2025 07:20:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to test

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28154#pullrequestreview-3453142623

From haraldei at openjdk.org  Wed Nov 12 12:19:01 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Wed, 12 Nov 2025 12:19:01 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <Ut7NlZ9u8jDdeP5IjnXLDuFUfVYciRNuxOk8UXI7BLQ=.620f195e-c717-431d-96a0-740bb92f69ac@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <Ut7NlZ9u8jDdeP5IjnXLDuFUfVYciRNuxOk8UXI7BLQ=.620f195e-c717-431d-96a0-740bb92f69ac@github.com>
Message-ID: <5uFt21WH-s4t91ia9q3ej3ajxwbYKyKCIN9-ul72JDM=.e69ca50e-3411-46e8-a5bc-b53806208c7f@github.com>

On Wed, 12 Nov 2025 08:27:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Would it make sense to add `OperatingSystem.BSD` to consolidate any such predicates?

I think so, but for this case we would also need `OperatingSystem.FreeBSD`, as I am uncerain if OpenBSD has the same issue. (NetBSD seems to also use jemalloc, and should behave like FreeBSD, though.)

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3521645508

From duke at openjdk.org  Wed Nov 12 12:24:39 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 12:24:39 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure [v2]
In-Reply-To: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
Message-ID: <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>

> Rewrite of VerifyJimage test to fix several severe issues.
> 
> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
> 
> Issue 1: Broken file comparison
> 
> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
> 
> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
> 
> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
> 
> Issue 2: Use of BasicImageReader for class file reading
> 
> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
> 
> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
> 
> Issue 3: File comparison mode was never run by default
> 
> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Tweaked path to class name handling for clarity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28265/files
  - new: https://git.openjdk.org/jdk/pull/28265/files/034af05e..1ad6e937

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

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

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

From duke at openjdk.org  Wed Nov 12 12:24:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 12:24:41 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure [v2]
In-Reply-To: <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
 <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>
Message-ID: <kq3BdsByyI8wZxz7y5wbwTOWVr4t51ZBGy_0lypkbwo=.64eeabef-9ddd-4592-ab69-10541cd5136d@github.com>

On Wed, 12 Nov 2025 12:19:58 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Rewrite of VerifyJimage test to fix several severe issues.
>> 
>> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
>> 
>> Issue 1: Broken file comparison
>> 
>> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
>> 
>> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
>> 
>> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
>> 
>> Issue 2: Use of BasicImageReader for class file reading
>> 
>> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
>> 
>> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
>> 
>> Issue 3: File comparison mode was never run by default
>> 
>> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaked path to class name handling for clarity

test/jdk/tools/jimage/VerifyJimage.java line 239:

> 237:                 // Use the entry name because we know it uses the '/' separator.
> 238:                 String entryName = getEntryName(path);
> 239:                 return Files.isRegularFile(path)

I have no idea if there's a better definition of "what is a marker file", but this logic was sufficient to prevent issues. Same for the other two predicates. I started by letting everything through and added sensible looking clauses until it passed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28265#discussion_r2518092836

From duke at openjdk.org  Wed Nov 12 12:36:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 12:36:08 GMT
Subject: RFR: 8371645: BasicImageReader getEntryNames() is stateful and
 cannot be called more than once
In-Reply-To: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
References: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
Message-ID: <UDV8_jUF0SQ0EDAlEdj_kBn0TCTq39J7AmXemJAzWzU=.18ca79cc-5ab7-4efb-8c05-f99776862c9f@github.com>

On Wed, 12 Nov 2025 11:17:21 GMT, David Beaumont <duke at openjdk.org> wrote:

> Stop entry name creation using a stateful read of underlying buffer (which moves the position and consumes it).

It is not, the VerifyJimage tool used it (how I discovered the issue).
My IDE shows 8 uses, but JImageTask looks to be the only non-test one.

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

PR Comment: https://git.openjdk.org/jdk/pull/28263#issuecomment-3521709857

From alanb at openjdk.org  Wed Nov 12 12:47:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Nov 2025 12:47:25 GMT
Subject: RFR: 8371645: BasicImageReader getEntryNames() is stateful and
 cannot be called more than once
In-Reply-To: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
References: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
Message-ID: <PqMGtVaKdlDb24dCpEi-Ob67kAwP6bjAcomaPcxugnU=.43147082-4eb9-496c-b445-40b7c12648bc@github.com>

On Wed, 12 Nov 2025 11:17:21 GMT, David Beaumont <duke at openjdk.org> wrote:

> Stop entry name creation using a stateful read of underlying buffer (which moves the position and consumes it).

VerifyJimage is a test. I checked the jimage tool and it uses it.  (I'm mostly trying to see if it gets used at compile, link or runtime but it seems not.)

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

PR Comment: https://git.openjdk.org/jdk/pull/28263#issuecomment-3521754015

From vklang at openjdk.org  Wed Nov 12 12:54:34 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 12 Nov 2025 12:54:34 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v11]
In-Reply-To: <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
Message-ID: <CbMHUboGTEm5WEWnHmGymb-rO9QVFU3c-QEsr0HeJlQ=.a711870b-91a3-4be0-8a78-814bfc649142@github.com>

On Tue, 11 Nov 2025 17:48:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
> 
>  - Remove dup end body tag
>  - Change FinalFieldMutationEvent so that caller is top frame in stack trace
>  - Merge branch 'master' into JDK-8353835
>  - Review feedback: Add tests for setting internal properties, improve links in Mutation methods page
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - ... and 40 more: https://git.openjdk.org/jdk/compare/2902436f...b22947c7

src/java.base/share/classes/java/lang/reflect/Field.java line 1543:

> 1541:      * the given possibly-null caller.
> 1542:      */
> 1543:     private String finalFieldMutationWarning(Class<?> caller, boolean unreflect) {

It may make sense to have this method return a StringBuilder instance (and use it internally before returning it) as that would cut down on extra String-instance creation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2518192839

From duke at openjdk.org  Wed Nov 12 13:25:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 13:25:03 GMT
Subject: RFR: 8371645: BasicImageReader getEntryNames() is stateful and
 cannot be called more than once
In-Reply-To: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
References: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
Message-ID: <t0QUjCSk1id9ogJmCxyUNYJ5Z5P_YtlwDDWMj4FUJ6k=.795955e4-bee3-4eed-a077-a7dc91945d0c@github.com>

On Wed, 12 Nov 2025 11:17:21 GMT, David Beaumont <duke at openjdk.org> wrote:

> Stop entry name creation using a stateful read of underlying buffer (which moves the position and consumes it).

I can't promise it's not used at runtime (I don't 100% trust that the IDE indexes everything), but if it were it would be remarkable that it hadn't caused issues since its impossible to call it twice without it throwing a buffer underflow exception.

I can confirm that (a) the fix works as well as the old code in JLinkTask and (b) it lets you call it multiple times successfully.
I didn't add a unit test case because I think that the fix is obviously (by inspection) good and it will be very thoroughly tested by its use in JLinkTask.

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

PR Comment: https://git.openjdk.org/jdk/pull/28263#issuecomment-3521916706

From mcimadamore at openjdk.org  Wed Nov 12 13:29:13 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Nov 2025 13:29:13 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
Message-ID: <YaemS3pEXZd3Aswn3m05QxiDtGZ9WId3B7pZ7L8x_U0=.6f5dde72-c521-4626-bfd3-bda7db0eb076@github.com>

On Wed, 12 Nov 2025 09:08:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
> 
> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
> 
> It should be noted that with this change, the running time for the benchmarks would increase significantly.

test/micro/org/openjdk/bench/java/lang/foreign/BulkOps.java line 1:

> 1: /*

I this can now be deleted, as it's covered by the other benchmarks?

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkCopy.java line 60:

> 58:     byte[] dstArray;
> 59: 
> 60:     public static class Array extends SegmentBulkCopy {

Should we use just one class for both arrays and byte buffers? Also, for those we don't test loops?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518301013
PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518306595

From mcimadamore at openjdk.org  Wed Nov 12 13:33:21 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Nov 2025 13:33:21 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <ECaItgn93sYNj5Oq7sJrvQWhgp1v1V6zk4KE0c0EgH4=.b7e5bc46-b3b4-4c70-a33f-ed99a17b4c4e@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <ECaItgn93sYNj5Oq7sJrvQWhgp1v1V6zk4KE0c0EgH4=.b7e5bc46-b3b4-4c70-a33f-ed99a17b4c4e@github.com>
Message-ID: <uctRSIYry8RooqrYUJk3fPAyP-KzC22IN-IQTN8lWC0=.ecfaf975-cf09-4570-946f-20880fbf2e42@github.com>

On Wed, 12 Nov 2025 09:14:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Here are some examples of benchmark output (only one or two sizes are shown for brevity):
> 
> ```
> Benchmark                                 (alignment)  (segmentType)  (size)  Mode  Cnt  Score   Error  Units
> SegmentBulkHash.Array.array                       N/A            N/A       2  avgt   30  2.681 ? 0.137  ns/op
> SegmentBulkHash.Segment.hash                  ALIGNED           HEAP       2  avgt   30  3.531 ? 0.343  ns/op
> SegmentBulkHash.Segment.hash                  ALIGNED         NATIVE       2  avgt   30  5.070 ? 0.963  ns/op
> SegmentBulkHash.Segment.hash                UNALIGNED           HEAP       2  avgt   30  3.498 ? 0.238  ns/op
> SegmentBulkHash.Segment.hash                UNALIGNED         NATIVE       2  avgt   30  4.158 ? 0.154  ns/op
> SegmentBulkHash.Segment.hashLoopIntInt        ALIGNED           HEAP       2  avgt   30  4.470 ? 0.215  ns/op
> SegmentBulkHash.Segment.hashLoopIntInt        ALIGNED         NATIVE       2  avgt   30  3.906 ? 0.233  ns/op
> SegmentBulkHash.Segment.hashLoopIntInt      UNALIGNED           HEAP       2  avgt   30  4.531 ? 0.246  ns/op
> SegmentBulkHash.Segment.hashLoopIntInt      UNALIGNED         NATIVE       2  avgt   30  3.619 ? 0.095  ns/op
> SegmentBulkHash.Segment.hashLoopIntLong       ALIGNED           HEAP       2  avgt   30  4.226 ? 0.266  ns/op
> SegmentBulkHash.Segment.hashLoopIntLong       ALIGNED         NATIVE       2  avgt   30  3.223 ? 0.351  ns/op
> SegmentBulkHash.Segment.hashLoopIntLong     UNALIGNED           HEAP       2  avgt   30  4.125 ? 0.293  ns/op
> SegmentBulkHash.Segment.hashLoopIntLong     UNALIGNED         NATIVE       2  avgt   30  3.329 ? 0.221  ns/op
> SegmentBulkHash.Segment.hashLoopLongLong      ALIGNED           HEAP       2  avgt   30  3.603 ? 0.285  ns/op
> SegmentBulkHash.Segment.hashLoopLongLong      ALIGNED         NATIVE       2  avgt   30  3.048 ? 0.172  ns/op
> SegmentBulkHash.Segment.hashLoopLongLong    UNALIGNED           HEAP       2  avgt   30  3.666 ? 0.180  ns/op
> SegmentBulkHash.Segment.hashLoopLongLong    UNALIGNED         NATIVE       2  avgt   30  3.237 ? 0.257  ns/op
> ```
> 

Interesting -- the base version is faster for heap than native.
But the loop versions are the opposite. I wonder why?

(the other benchmarks don't seem to have this trait)

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

PR Comment: https://git.openjdk.org/jdk/pull/28260#issuecomment-3521960689

From epeter at openjdk.org  Wed Nov 12 13:38:23 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Nov 2025 13:38:23 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
Message-ID: <Lr3gE0hBkkzYI0boQkISK74AlSmyOFbgIKW7q2PBvgE=.b8c6f141-a5ff-4a42-8d9f-ac2ec2e2eb20@github.com>

On Wed, 12 Nov 2025 09:08:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
> 
> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
> 
> It should be noted that with this change, the running time for the benchmarks would increase significantly.

Drive by comment for now. Nice effort, to unify the benchmarks :)

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkMismatch.java line 122:

> 120:                     srcSegment = srcSegment.asSlice(1, size);
> 121:                     dstSegment = dstSegment.asSlice(1, size);
> 122:                 }

What do you hope to acheive with this? I hope that the intrinsics automatically align the vectors, right? Or are you checking for exactly that?

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

PR Review: https://git.openjdk.org/jdk/pull/28260#pullrequestreview-3453489287
PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518338346

From mbaesken at openjdk.org  Wed Nov 12 13:49:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Nov 2025 13:49:38 GMT
Subject: RFR: 8371608: Jtreg test  jdk/internal/vm/Continuation/Fuzz.java
 sometimes fails with (fast)debug binaries
Message-ID: <nRBH7HkrI2R4VW0m0I4RdT1xBexRyBpC7TkGh1-SMMM=.79e4eb76-c3d0-461e-b837-24977b86d5f9@github.com>

When running the jtreg test jdk/internal/vm/Continuation/Fuzz.java with (fast)debug binaries, we see timeouts like these on multiple platforms :


jdk/internal/vm/Continuation/Fuzz_preserve-fp on Linux x86_64 :

java.lang.AssertionError: Failed to compile int Fuzz.com_int(int,int) in 45000ms
at Fuzz.waitForCompilation(Fuzz.java:323)
at Fuzz.compile(Fuzz.java:357)
at Fuzz.testTrace(Fuzz.java:214)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:186)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
at java.base/java.nio.file.FileChannelLinesSpliterator.forEachRemaining(FileChannelLinesSpliterator.java:130)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265)
at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:632)
at Fuzz.testStream(Fuzz.java:204)
at Fuzz.testFile(Fuzz.java:189)
at Fuzz.runTests(Fuzz.java:111)
at Fuzz.main(Fuzz.java:105)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:1474)


Probably it makes sense to increase the COMPILATION_TIMEOUT when running with (fast)debug binaries.

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

Commit messages:
 - JDK-8371608

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

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

From pminborg at openjdk.org  Wed Nov 12 13:51:04 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Nov 2025 13:51:04 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <Lr3gE0hBkkzYI0boQkISK74AlSmyOFbgIKW7q2PBvgE=.b8c6f141-a5ff-4a42-8d9f-ac2ec2e2eb20@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <Lr3gE0hBkkzYI0boQkISK74AlSmyOFbgIKW7q2PBvgE=.b8c6f141-a5ff-4a42-8d9f-ac2ec2e2eb20@github.com>
Message-ID: <S4Pj_ZriAeK1sjj9ewY2OrCXJ-JNMni0CyFxEjUZ8JQ=.0584e690-3f24-4a7b-b5a3-448af8256f8e@github.com>

On Wed, 12 Nov 2025 13:34:54 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkMismatch.java line 122:
> 
>> 120:                     srcSegment = srcSegment.asSlice(1, size);
>> 121:                     dstSegment = dstSegment.asSlice(1, size);
>> 122:                 }
> 
> What do you hope to acheive with this? I hope that the intrinsics automatically align the vectors, right? Or are you checking for exactly that?

Yepp. The idea was to test the impact of alignment, as the hand-rolled version uses unaligned access, and the intrinsics might align its bulk operations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518385504

From alanb at openjdk.org  Wed Nov 12 13:57:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Nov 2025 13:57:04 GMT
Subject: RFR: 8371645: BasicImageReader getEntryNames() is stateful and
 cannot be called more than once
In-Reply-To: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
References: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
Message-ID: <Cjkbp7dx7VusEjFmFeX7P81ck9JZOW86eFEAmCb9Gqw=.2ec907dd-3448-4bf6-a727-615974c39a09@github.com>

On Wed, 12 Nov 2025 11:17:21 GMT, David Beaumont <duke at openjdk.org> wrote:

> Stop entry name creation using a stateful read of underlying buffer (which moves the position and consumes it).

Marked as reviewed by alanb (Reviewer).

The change looks okay, the only usage I can find in the src tree if the jimage too.

Can you add the "noreg-hard" label to the JBS issue as it doesn't seem feasible to include a regression test.

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

PR Review: https://git.openjdk.org/jdk/pull/28263#pullrequestreview-3453574021
PR Comment: https://git.openjdk.org/jdk/pull/28263#issuecomment-3522066837

From mdoerr at openjdk.org  Wed Nov 12 14:06:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 12 Nov 2025 14:06:29 GMT
Subject: RFR: 8371608: Jtreg test jdk/internal/vm/Continuation/Fuzz.java
 sometimes fails with (fast)debug binaries
In-Reply-To: <nRBH7HkrI2R4VW0m0I4RdT1xBexRyBpC7TkGh1-SMMM=.79e4eb76-c3d0-461e-b837-24977b86d5f9@github.com>
References: <nRBH7HkrI2R4VW0m0I4RdT1xBexRyBpC7TkGh1-SMMM=.79e4eb76-c3d0-461e-b837-24977b86d5f9@github.com>
Message-ID: <A1XRXZ226nrBPDoaPKbrpsfoYv3dSRNG9mR-_-IBB-4=.899c881d-9b93-464a-ab32-788afec962d1@github.com>

On Wed, 12 Nov 2025 13:36:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test jdk/internal/vm/Continuation/Fuzz.java with (fast)debug binaries, we see timeouts like these on multiple platforms :
> 
> 
> jdk/internal/vm/Continuation/Fuzz_preserve-fp on Linux x86_64 :
> 
> java.lang.AssertionError: Failed to compile int Fuzz.com_int(int,int) in 45000ms
> at Fuzz.waitForCompilation(Fuzz.java:323)
> at Fuzz.compile(Fuzz.java:357)
> at Fuzz.testTrace(Fuzz.java:214)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:186)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
> at java.base/java.nio.file.FileChannelLinesSpliterator.forEachRemaining(FileChannelLinesSpliterator.java:130)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176)
> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265)
> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:632)
> at Fuzz.testStream(Fuzz.java:204)
> at Fuzz.testFile(Fuzz.java:189)
> at Fuzz.runTests(Fuzz.java:111)
> at Fuzz.main(Fuzz.java:105)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> Probably it makes sense to increase the COMPILATION_TIMEOUT when running with (fast)debug binaries.

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28267#pullrequestreview-3453622233

From jvernee at openjdk.org  Wed Nov 12 14:08:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 14:08:56 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <YaemS3pEXZd3Aswn3m05QxiDtGZ9WId3B7pZ7L8x_U0=.6f5dde72-c521-4626-bfd3-bda7db0eb076@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <YaemS3pEXZd3Aswn3m05QxiDtGZ9WId3B7pZ7L8x_U0=.6f5dde72-c521-4626-bfd3-bda7db0eb076@github.com>
Message-ID: <6w42ysf030Ytfj8vDQ_MfQN84x_PTJr6-ll7tX792k4=.3b8491e3-f307-482b-9337-f3a5620fb4f9@github.com>

On Wed, 12 Nov 2025 13:24:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> test/micro/org/openjdk/bench/java/lang/foreign/BulkOps.java line 1:
> 
>> 1: /*
> 
> I this can now be deleted, as it's covered by the other benchmarks?

Yeah, I was also expecting BulkOps to be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518445332

From jvernee at openjdk.org  Wed Nov 12 14:09:00 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 14:09:00 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
Message-ID: <bIgA1--t6tdOLLaxohGIrZMk014aNtjEp0nzMZPAVTg=.444e08a9-45df-4352-90e4-7c4e8fb9a24c@github.com>

On Wed, 12 Nov 2025 09:08:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
> 
> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
> 
> It should be noted that with this change, the running time for the benchmarks would increase significantly.

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkCopy.java line 160:

> 158:         public void copyUnsafe() {
> 159:             MemorySegment.copy(srcSegment, 0, dstSegment, 0, size);
> 160:         }

Shouldn't this method be using `Unsafe`? (similar for the other classes)

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkHash.java line 58:

> 56: 
> 57:     @Param({"2", /*"3", "4", "5", "6", "7", "8", "12", "16", "64", "512",
> 58:             "4096", "32768", "262144", "2097152", "16777216", "134217728"*/})

I think you forgot to uncomment this

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkHash.java line 113:

> 111:             }
> 112: 
> 113:             // Always use the same alignment regardless of size

Leftover comment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518436374
PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518437872
PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518441123

From epeter at openjdk.org  Wed Nov 12 14:09:03 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Nov 2025 14:09:03 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <S4Pj_ZriAeK1sjj9ewY2OrCXJ-JNMni0CyFxEjUZ8JQ=.0584e690-3f24-4a7b-b5a3-448af8256f8e@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <Lr3gE0hBkkzYI0boQkISK74AlSmyOFbgIKW7q2PBvgE=.b8c6f141-a5ff-4a42-8d9f-ac2ec2e2eb20@github.com>
 <S4Pj_ZriAeK1sjj9ewY2OrCXJ-JNMni0CyFxEjUZ8JQ=.0584e690-3f24-4a7b-b5a3-448af8256f8e@github.com>
Message-ID: <jNQ2SWgdbPZHi8mO0lLh4qPOCv1bjA0tz91ynyt6eQ0=.792b41cf-655e-43e9-a091-9b3f60de1136@github.com>

On Wed, 12 Nov 2025 13:48:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkMismatch.java line 122:
>> 
>>> 120:                     srcSegment = srcSegment.asSlice(1, size);
>>> 121:                     dstSegment = dstSegment.asSlice(1, size);
>>> 122:                 }
>> 
>> What do you hope to acheive with this? I hope that the intrinsics automatically align the vectors, right? Or are you checking for exactly that?
>
> Yepp. The idea was to test the impact of alignment, as the hand-rolled version uses unaligned access, and the intrinsics might align its bulk operations.

Ok. But what kind of guarantee do you think you are getting from the byte array? With Lilliput (and maybe without), it may only be a 4 byte alignment, it may actually be unaligned that way for your long accesses. Are you aware of that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518444080

From epeter at openjdk.org  Wed Nov 12 14:09:04 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Nov 2025 14:09:04 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <jNQ2SWgdbPZHi8mO0lLh4qPOCv1bjA0tz91ynyt6eQ0=.792b41cf-655e-43e9-a091-9b3f60de1136@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <Lr3gE0hBkkzYI0boQkISK74AlSmyOFbgIKW7q2PBvgE=.b8c6f141-a5ff-4a42-8d9f-ac2ec2e2eb20@github.com>
 <S4Pj_ZriAeK1sjj9ewY2OrCXJ-JNMni0CyFxEjUZ8JQ=.0584e690-3f24-4a7b-b5a3-448af8256f8e@github.com>
 <jNQ2SWgdbPZHi8mO0lLh4qPOCv1bjA0tz91ynyt6eQ0=.792b41cf-655e-43e9-a091-9b3f60de1136@github.com>
Message-ID: <BJytPxg7tC4KC_AJ3zquXDaalzxE_oryUZoxnHEFpbo=.9ab3fdb7-6a82-40fd-a966-cb20209b1a27@github.com>

On Wed, 12 Nov 2025 14:05:29 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Yepp. The idea was to test the impact of alignment, as the hand-rolled version uses unaligned access, and the intrinsics might align its bulk operations.
>
> Ok. But what kind of guarantee do you think you are getting from the byte array? With Lilliput (and maybe without), it may only be a 4 byte alignment, it may actually be unaligned that way for your long accesses. Are you aware of that?

Alternatively, you could just use a long array, that way you get at least the same 8-byte alignment that you have with native memory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2518446344

From rriggs at openjdk.org  Wed Nov 12 14:20:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Nov 2025 14:20:29 GMT
Subject: RFR: 8371645: BasicImageReader getEntryNames() is stateful and
 cannot be called more than once
In-Reply-To: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
References: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
Message-ID: <nEfrRG21G5rhiiHgakrqk4IuRaZorXoexOTy1bs69aQ=.54d35a2e-6bec-48e1-a2f7-f91874d990fe@github.com>

On Wed, 12 Nov 2025 11:17:21 GMT, David Beaumont <duke at openjdk.org> wrote:

> Stop entry name creation using a stateful read of underlying buffer (which moves the position and consumes it).

Looks ok.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28263#pullrequestreview-3453680588

From vklang at openjdk.org  Wed Nov 12 14:35:54 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 12 Nov 2025 14:35:54 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v11]
In-Reply-To: <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
Message-ID: <DlB7TLAa1cvtzrwptN3rNFbsFfqzRFGyNn074tnj2p4=.bc36884f-0a6a-4e6e-a957-7a7307eb8713@github.com>

On Tue, 11 Nov 2025 17:48:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
> 
>  - Remove dup end body tag
>  - Change FinalFieldMutationEvent so that caller is top frame in stack trace
>  - Merge branch 'master' into JDK-8353835
>  - Review feedback: Add tests for setting internal properties, improve links in Mutation methods page
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - ... and 40 more: https://git.openjdk.org/jdk/compare/2902436f...b22947c7

src/java.base/share/man/java.md line 482:

> 480: 
> 481:     -   `allow`: This mode allows illegal final field mutation in all modules,
> 482:         without any warings.

Suggestion:

        without any warnings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2518551065

From swen at openjdk.org  Wed Nov 12 14:39:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 12 Nov 2025 14:39:06 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v16]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <hww5TKWMoyEXaG0yB59ikjxoIL_sqjfnc6W1098N8cQ=.0b4ade8b-4854-4dde-b23e-7deffd30f9f6@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  appendQuad

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/4e77cc58..ae1fcb6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=14-15

  Stats: 32 lines in 3 files changed: 24 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

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

From duke at openjdk.org  Wed Nov 12 14:45:53 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Nov 2025 14:45:53 GMT
Subject: RFR: 8371645: BasicImageReader getEntryNames() is stateful and
 cannot be called more than once
In-Reply-To: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
References: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
Message-ID: <hUtY5o4_wABmD_hOcz8XDJ20J7ViJlN-iJl8auHZUcw=.27bd3674-acbc-43b5-bcb0-d264325cf4c3@github.com>

On Wed, 12 Nov 2025 11:17:21 GMT, David Beaumont <duke at openjdk.org> wrote:

> Stop entry name creation using a stateful read of underlying buffer (which moves the position and consumes it).

@david-beaumont 
Your change (at version 0d30902f3934453236da01eb0f75ee3b3b2e5446) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28263#issuecomment-3522300675

From swen at openjdk.org  Wed Nov 12 15:01:49 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 12 Nov 2025 15:01:49 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v17]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <WJeeAF8mUbfNMuRjvkHot-we7WoZXDY3iruMKiMPbRc=.74622925-401d-4e35-a5bd-064f2828ae6d@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  static field JLA

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/ae1fcb6b..9fbc9853

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=15-16

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

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

From duke at openjdk.org  Wed Nov 12 15:02:12 2025
From: duke at openjdk.org (Jesse Glick)
Date: Wed, 12 Nov 2025 15:02:12 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <KS5whSwzltSPsIO_QoLmQsij-l2uv6zH_KR9E3u8krU=.5c8c3369-c72d-4f06-8b48-bbd62021dfc4@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
 <hhpTt97mJhKq1xoZ0iVQ7hQPjCzvyo_-hMgc0LsmiZo=.247d98e8-8c50-41ac-8ba5-d31914aab06c@github.com>
 <KS5whSwzltSPsIO_QoLmQsij-l2uv6zH_KR9E3u8krU=.5c8c3369-c72d-4f06-8b48-bbd62021dfc4@github.com>
Message-ID: <u3g6m9KC-USpXhWGYAEF7B64o8sC048U5EXRDjMuA88=.d2acbf03-62da-473d-b53c-8a237e942856@github.com>

On Wed, 12 Nov 2025 08:11:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 264:
>> 
>>> 262: \                             versions.
>>> 263: main.help.opt.any=\
>>> 264: \ Operation modifiers valid in any mode:\n\
>> 
>> This text _valid in any mode_ was present in earlier releases but does not seem to have been true for `-C` with `-x`.
>
> Do we need to create a bug to check the help output?

Does not seem worth a backport, just noting this for the record.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/2752#discussion_r2518654756

From lancea at openjdk.org  Wed Nov 12 15:16:40 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 12 Nov 2025 15:16:40 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v4]
In-Reply-To: <D5VGiXjk-i01BJy3oN8TbGmQQ3fpwSo0iE8GToF83NY=.c2419065-5f17-4007-926e-dbf3ee885ada@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <D5VGiXjk-i01BJy3oN8TbGmQQ3fpwSo0iE8GToF83NY=.c2419065-5f17-4007-926e-dbf3ee885ada@github.com>
Message-ID: <Ku-m9S6wTDv-AN8tZ2aYMtFp0ak6kzcfoNIm8SoYROQ=.0b4768c1-001f-47c9-ac88-1558c15225b3@github.com>

On Wed, 12 Nov 2025 07:20:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to test

Thank you for moving the Manifest position checking as it helps improve the overall validation checking

WRT the new Resource: error.validator.wrong.position,  I believe this is only used by your new check and if so, perhaps consider making the message more specific indicating the Manifest was not found in either entry 1 or 2 (or something like that)

a couple of other responses below but all good

test/jdk/tools/jar/ValidatorTest.java line 315:

> 313:     /**
> 314:      * Validates that the LOC MANIFEST.MF entries are at the expected positions.
> 315:      *

Thank you for adding a comment.  I might suggest adding a little more clarity or point to JarInputStream docs as the  Manifest Location for JarFile is not an issue. 

The issue boils down to the fact that JarInputStream walks the LOC sequentially and because of this there is the limitation on the location of where  the Manifest can live.

Not a big deal overall and I will leave it to you.  It is just no obvious to someone who is working in this area the 1st time as this issue is not directly related to the Zip specification, but is a JarInputStream limitation

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28154#pullrequestreview-3453879848
PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2518637541

From lancea at openjdk.org  Wed Nov 12 15:16:45 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 12 Nov 2025 15:16:45 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v3]
In-Reply-To: <5SVrnXXcVGQgTledYjujDGtcfsUccxoJH0ba1bUkzFA=.adfbbc3b-d779-4386-80cb-46d7055132f9@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <40najGNF67k5YUI2jmSPDijNRRSfdCwPCAfGwmivqFU=.3dd7e106-2452-4b0b-906e-63fa22377030@github.com>
 <GkmumCk6Hm_kT-mb5Ymn20t6WhsU_JuG-oupKuXU8Ns=.addec769-be00-4815-bcb8-0ef2b849c45e@github.com>
 <5SVrnXXcVGQgTledYjujDGtcfsUccxoJH0ba1bUkzFA=.adfbbc3b-d779-4386-80cb-46d7055132f9@github.com>
Message-ID: <xjnrnUonkntFqD-MLBeiGIJVOvF6rafxcUuym8ZErHo=.a72afe88-d9df-47fd-acfd-84852e38d6ee@github.com>

On Wed, 12 Nov 2025 07:06:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> test/jdk/tools/jar/ValidatorTest.java line 342:
>> 
>>> 340:     }
>>> 341: 
>>> 342:     private void testWrongManifestPosition(
>> 
>> This new test only validates that  the LOC MANIFEST.MF entries are where they need to be.  It does not do a similar CEN check in the event that the LOC and CEN entries do not match.  
>> 
>> If you change your validation order so that Validator checks the MANIFEST location after it checks the order, then you should be covered.
>> 
>> I would also add a comment to the test to help future maintainers to the test ...
>
> I'll add such a comment.
> 
> The existing tests for LOC-CEN related mismatches should already cover those cases. In addition, the results of the checks in `Validator` are accumulated - so their order is not important, right?

With moving the location check for the Manifest in Validator to be the last check, we are in good shape

Would it have been nice to do the same type of check using the CEN(via JarFile::stream or JarFile::entries)? Sure, but not a must

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2518683457

From duke at openjdk.org  Wed Nov 12 15:27:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 15:27:54 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure [v2]
In-Reply-To: <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
 <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>
Message-ID: <CrrOsxIVn1edtkMfPlKYbBB9nPjXOD0nl4KRwhkOsjI=.abe11f93-30b8-40e7-9029-61572c829ca9@github.com>

On Wed, 12 Nov 2025 12:24:39 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Rewrite of VerifyJimage test to fix several severe issues.
>> 
>> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
>> 
>> Issue 1: Broken file comparison
>> 
>> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
>> 
>> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
>> 
>> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
>> 
>> Issue 2: Use of BasicImageReader for class file reading
>> 
>> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
>> 
>> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
>> 
>> Issue 3: File comparison mode was never run by default
>> 
>> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaked path to class name handling for clarity

test/jdk/tools/jimage/VerifyJimage.java line 218:

> 216:     }
> 217: 
> 218:     static class JImageReader extends BasicImageReader {

This being a subclass of BasicImageReader means it was reading the "raw" unmapped entries, meaning that in preview mode it will try and load the non-preview version of the class from the reader in a VM that's using preview mode classes. Using JRT file system, which is preview mode aware for the current runtime, always gives you the "right" choice of class bytes for class loading.

test/jdk/tools/jimage/VerifyJimage.java line 218:

> 216:     }
> 217: 
> 218:     static class JImageReader extends BasicImageReader {

This being a subclass of BasicImageReader means it was reading the "raw" unmapped entries, meaning that in preview mode it will try and load the non-preview version of the class from the reader in a VM that's using preview mode classes. Using JRT file system, which is preview mode aware for the current runtime, always gives you the "right" choice of class bytes for class loading.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28265#discussion_r2518744184
PR Review Comment: https://git.openjdk.org/jdk/pull/28265#discussion_r2518750863

From swen at openjdk.org  Wed Nov 12 15:41:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 12 Nov 2025 15:41:15 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v17]
In-Reply-To: <WJeeAF8mUbfNMuRjvkHot-we7WoZXDY3iruMKiMPbRc=.74622925-401d-4e35-a5bd-064f2828ae6d@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <WJeeAF8mUbfNMuRjvkHot-we7WoZXDY3iruMKiMPbRc=.74622925-401d-4e35-a5bd-064f2828ae6d@github.com>
Message-ID: <Otn8f-PWfKz32jKeczTTv_lDDYNi9f4Lr8JpZXEZ-kY=.8e5b0e0c-5cbe-4501-9d92-6d8ac2c49446@github.com>

On Wed, 12 Nov 2025 15:01:49 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   static field JLA

In the current version, the methods newly added to JLA have been removed, and a new approach has been adopted to still achieve a significant performance improvement.

Below are the performance data for a MacBook M1 Pro:

* shell

make test TEST="micro:java.time.ToStringBench.localDateToString"


* output

# baseline 76a0732ba5c0f3159ed0ebc5fcb2dfb7117b38cd 
Benchmark                             Mode  Cnt   Score   Error   Units
ToStringBench.instantToString        thrpt   15   9.736 ? 1.054  ops/ms
ToStringBench.localDateTimeToString  thrpt   15  16.034 ? 2.344  ops/ms
ToStringBench.localDateToString      thrpt   15  61.926 ? 1.877  ops/ms
ToStringBench.localTimeToString      thrpt   15  21.297 ? 1.686  ops/ms
ToStringBench.zonedDateTimeToString  thrpt   15  15.536 ? 2.785  ops/ms



# pr_26911 ae1fcb6b80fa6c153202f2c26fa459bb9ac08990
Benchmark                             Mode  Cnt    Score   Error   Units
ToStringBench.instantToString        thrpt   15   10.925 ? 1.160  ops/ms
ToStringBench.localDateTimeToString  thrpt   15   19.034 ? 2.861  ops/ms
ToStringBench.localDateToString      thrpt   15  103.126 ? 1.932  ops/ms
ToStringBench.localTimeToString      thrpt   15   29.642 ? 1.904  ops/ms
ToStringBench.zonedDateTimeToString  thrpt   15   30.409 ? 5.503  ops/ms


* compare

| Benchmark             | Baseline (ops/ms) | PR #26911 (ops/ms) | Improvement (%) |
|-----------------------|-------------------|--------------------|-----------------|
| instantToString       | 9.736 ? 1.054     | 10.925 ? 1.160     | +12.2%          |
| localDateTimeToString | 16.034 ? 2.344    | 19.034 ? 2.861     | +18.7%          |
| localDateToString     | 61.926 ? 1.877    | 103.126 ? 1.932    | +66.5%          |
| localTimeToString     | 21.297 ? 1.686    | 29.642 ? 1.904     | +39.2%          |
| zonedDateTimeToString | 15.536 ? 2.785    | 30.409 ? 5.503     | +95.7%          |


This primarily involves triggering Late Inline in the `appendPair`/`appendQuad` methods of `DecimalDigits`, and then optimizing `MergeStore` and `Elimate Allocation` accordingly. See below:


@ 38   java.lang.StringBuilder::append (8 bytes)   inline (hot)   late inline succeeded (string method)


And it can trigger the MergeStore optimization of DecimalDigits::appendPair:
* JVM Args

-XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=TraceMergeStores,jdk.internal.util.DecimalDigits::appendPair,SUCCESS


[TraceMergeStores]: Replace
 796  StoreB  === 818 761 788 35  [[ 801 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
 801  StoreB  === 818 796 799 92  [[ 810 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores]: with
  35  LoadS  === 5 7 33  [[ 92 488 570 808 796 470 258 604 644 836 ]]  @short[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; #short !jvms: DecimalDigits::appendPair @ bci:7 (line 463)
 836  StoreC  === 818 761 788 35  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
 ```


-XX:+UnlockDiagnosticVMOptions -XX:+PrintEliminateAllocations

The following log was observed:
 ```
 Scalar  169  CheckCastPP  === 160 158  [[ 570 488 470 258 ]]  #java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=146  Oop:java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=146 !jvms: String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465)
++++ Eliminated: 146 Allocate
Scalar   77  CheckCastPP  === 71 69  [[ 570 488 644 604 258 470 ]]  #byte[int:2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=57 !orig=[326] !jvms: DecimalDigits::appendPair @ bci:14 (line 464)
++++ Eliminated: 57 AllocateArray
NotScalar (Object is referenced by node) 1147  CheckCastPP  === 1141 1139  [[ 1271 1154 1154 1203 1159 1159 1685 1647 ]]  #byte[int:2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=1127 !orig=[1371] !jvms: DecimalDigits::appendPair @ bci:14 (line 464) DateTimeHelper::formatTo @ bci:68 (line 66)
  >>>>  1271  EncodeP  === _ 1147  [[ 1273 ]]  #narrowoop: byte[int:2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=1127 !orig=[1370] !jvms: String::<init> @ bci:6 (line 5012) String::newStringWithLatin1Bytes @ bci:22 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465) DateTimeHelper::formatTo @ bci:68 (line 66)
NotScalar (Object is referenced by node) 2071  CheckCastPP  === 2065 2063  [[ 2195 2078 2078 2127 2083 2083 2609 2571 ]]  #byte[int:2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=2051 !orig=[2295] !jvms: DecimalDigits::appendPair @ bci:14 (line 464) DateTimeHelper::formatTo @ bci:83 (line 68)
  >>>>  2195  EncodeP  === _ 2071  [[ 2197 ]]  #narrowoop: byte[int:2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=2051 !orig=[2294] !jvms: String::<init> @ bci:6 (line 5012) String::newStringWithLatin1Bytes @ bci:22 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465) DateTimeHelper::formatTo @ bci:83 (line 68)
Scalar  2150  CheckCastPP  === 2141 2139  [[ 2537 2455 2437 ]]  #java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=2127  Oop:java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=2127 !jvms: String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465) DateTimeHelper::formatTo @ bci:83 (line 68)
++++ Eliminated: 2127 Allocate
Scalar   286  CheckCastPP  === 277 275  [[ 681 599 581 371 ]]  #java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=263  Oop:java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=263 !jvms: String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendQuad @ bci:71 (line 487) DateTimeHelper::formatTo @ bci:30 (line 58)
++++ Eliminated: 263 Allocate
Scalar   182  CheckCastPP  === 176 174  [[ 681 191 191 198 198 205 205 599 216 216 755 715 371 581 ]]  #byte[int:4] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=162 !orig=[438] !jvms: DecimalDigits::appendQuad @ bci:36 (line 486) DateTimeHelper::formatTo @ bci:30 (line 58)
++++ Eliminated: 162 AllocateArray
Scalar  1226  CheckCastPP  === 1217 1215  [[ 1613 1531 1513 ]]  #java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=1203  Oop:java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=1203 !jvms: String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465) DateTimeHelper::formatTo @ bci:68 (line 66)
++++ Eliminated: 1203 Allocate
Scalar  1147  CheckCastPP  === 1141 1139  [[ 1613 1154 1154 1531 1159 1159 1685 1647 1513 ]]  #byte[int:2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=1127 !orig=[1371] !jvms: DecimalDigits::appendPair @ bci:14 (line 464) DateTimeHelper::formatTo @ bci:68 (line 66)
++++ Eliminated: 1127 AllocateArray
Scalar  2071  CheckCastPP  === 2065 2063  [[ 2537 2078 2078 2455 2083 2083 2609 2571 2437 ]]  #byte[int:2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=2051 !orig=[2295] !jvms: DecimalDigits::appendPair @ bci:14 (line 464) DateTimeHelper::formatTo @ bci:83 (line 68)
++++ Eliminated: 2051 AllocateArray
NotScalar (Object is referenced by node)  505  CheckCastPP  === 502 723  [[ 1027 227 ]]  #byte[int:2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=226 !orig=[2285] !jvms: DecimalDigits::appendPair @ bci:14 (line 464) DateTimeHelper::formatTo @ bci:68 (line 66) LocalDate::toString @ bci:12 (line 2150)
  >>>>  1027  EncodeP  === _ 505  [[ 973 ]]  #narrowoop: byte[int:2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=226 !orig=[2284] !jvms: String::<init> @ bci:6 (line 5012) String::newStringWithLatin1Bytes @ bci:22 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465) DateTimeHelper::formatTo @ bci:68 (line 66) LocalDate::toString @ bci:12 (line 2150)
Scalar   232  Allocate  === 513 514 515 41 1 (459 460 317 1 1 1 188 1 1 1 1 1 1 1 188 1 1 516 1 ) [[ 474 253 120 937 337 603 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top, bool ) allocationKlass:java/lang/String String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465) DateTimeHelper::formatTo @ bci:83 (line 68) LocalDate::toString @ bci:12 (line 2150) !jvms: String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465) DateTimeHelper::formatTo @ bci:83 (line 68) LocalDate::toString @ bci:12 (line 2150)
++++ Eliminated: 232 Allocate
Scalar   222  Allocate  === 491 492 493 41 1 (459 460 317 1 1 1 188 188 189 1 1 1 1 1 1 188 1 1 494 1 ) [[ 464 249 112 920 384 589 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top, bool ) allocationKlass:java/lang/String String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendQuad @ bci:71 (line 487) DateTimeHelper::formatTo @ bci:30 (line 58) LocalDate::toString @ bci:12 (line 2150) !jvms: String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendQuad @ bci:71 (line 487) DateTimeHelper::formatTo @ bci:30 (line 58) LocalDate::toString @ bci:12 (line 2150)
++++ Eliminated: 222 Allocate
Scalar   227  Allocate  === 502 503 504 41 1 (459 460 317 1 1 1 188 188 189 1 1 1 1 1 188 1 1 505 1 ) [[ 469 251 116 972 389 643 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top, bool ) allocationKlass:java/lang/String String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465) DateTimeHelper::formatTo @ bci:68 (line 66) LocalDate::toString @ bci:12 (line 2150) !jvms: String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendPair @ bci:33 (line 465) DateTimeHelper::formatTo @ bci:68 (line 66) LocalDate::toString @ bci:12 (line 2150)
++++ Eliminated: 227 Allocate
Scalar   494  CheckCastPP  === 491 714  [[ 555 1011 1011 903 903 764 764 555 ]]  #byte[int:4] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=221 !orig=[2966] !jvms: DecimalDigits::appendQuad @ bci:36 (line 486) DateTimeHelper::formatTo @ bci:30 (line 58) LocalDate::toString @ bci:12 (line 2150)
++++ Eliminated: 221 AllocateArray
Scalar   231  AllocateArray  === 502 503 511 41 1 (459 446 317 344 487 1 188 1 1 1 1 1 1 512 188 490 ) [[ 473 252 119 898 514 732 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int, bool ) allocationKlass:[B DecimalDigits::appendPair @ bci:14 (line 464) DateTimeHelper::formatTo @ bci:83 (line 68) LocalDate::toString @ bci:12 (line 2150) !jvms: DecimalDigits::appendPair @ bci:14 (line 464) DateTimeHelper::formatTo @ bci:83 (line 68) LocalDate::toString @ bci:12 (line 2150)
++++ Eliminated: 231 AllocateArray
Scalar   188  CheckCastPP  === 435 436  [[ 220 220 220 226 543 226 226 550 550 200 88 86 86 543 88 ]]  #java/lang/StringBuilder (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/Appendable):NotNull:exact *,iid=219  Oop:java/lang/StringBuilder (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/Appendable):NotNull:exact *,iid=219 !jvms: LocalDate::toString @ bci:0 (line 2149)
++++ Eliminated: 219 Allocate
Scalar   226  AllocateArray  === 488 185 500 41 1 (459 446 317 344 487 1 3142 3142 189 1 1 1 1 501 3142 490 759 317 317 671 ) [[ 468 250 115 894 503 723 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int, bool ) allocationKlass:[B DecimalDigits::appendPair @ bci:14 (line 464) DateTimeHelper::formatTo @ bci:68 (line 66) LocalDate::toString @ bci:12 (line 2150) !jvms: DecimalDigits::appendPair @ bci:14 (line 464) DateTimeHelper::formatTo @ bci:68 (line 66) LocalDate::toString @ bci:12 (line 2150)
++++ Eliminated: 226 AllocateArray
NotScalar (Object is passed as argument)  759  CheckCastPP  === 542 747  [[ 200 557 1601 1601 1597 1597 1571 1571 1605 1605 557 1665 558 1665 1650 1650 558 1635 197 1635 153 858 1620 1620 86 88 ]]  #byte[int:10] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=220 !orig=[386] !jvms: AbstractStringBuilder::<init> @ bci:12 (line 101) StringBuilder::<init> @ bci:2 (line 119) LocalDate::toString @ bci:6 (line 2149)
  >>>>   858  ArrayCopy  === 990 1 991 41 1 (759 769 989 769 1585 _ _ _ _ ) [[ 683 859 ]]  void ( java/lang/Object *, int, java/lang/Object *, int, int, int, int, BotPTR *+bot, BotPTR *+bot ) (oop array clone, tightly coupled allocation) !jvms: Arrays::copyOfRange @ bci:11 (line 3843) String::<init> @ bci:32 (line 4995) StringBuilder::toString @ bci:16 (line 478) LocalDate::toString @ bci:16 (line 2151)
NotScalar (Object is passed as argument)  759  CheckCastPP  === 542 747  [[ 200 557 1601 1601 1597 1597 1571 1571 1605 1605 557 1665 558 1665 1650 1650 558 1635 197 1635 153 858 1620 1620 86 88 ]]  #byte[int:10] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=220 !orig=[386] !jvms: AbstractStringBuilder::<init> @ bci:12 (line 101) StringBuilder::<init> @ bci:2 (line 119) LocalDate::toString @ bci:6 (line 2149)
  >>>>   858  ArrayCopy  === 990 1 991 41 1 (759 769 989 769 1585 _ _ _ _ ) [[ 683 859 ]]  void ( java/lang/Object *, int, java/lang/Object *, int, int, int, int, BotPTR *+bot, BotPTR *+bot ) (oop array clone, tightly coupled allocation) !jvms: Arrays::copyOfRange @ bci:11 (line 3843) String::<init> @ bci:32 (line 4995) StringBuilder::toString @ bci:16 (line 478) LocalDate::toString @ bci:16 (line 2151)
Scalar  211  CheckCastPP  === 202 200  [[ 610 528 510 298 ]]  #java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=188  Oop:java/lang/String (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/constant/Constable,java/lang/constant/ConstantDesc):NotNull:exact *,iid=188 !jvms: String::newStringWithLatin1Bytes @ bci:16 (line 782) System$1::uncheckedNewStringWithLatin1Bytes @ bci:1 (line 2133) DecimalDigits::appendQuad @ bci:71 (line 487)
++++ Eliminated: 188 Allocate
Scalar  107  CheckCastPP  === 101 99  [[ 610 116 116 123 123 130 130 528 141 141 644 684 298 510 ]]  #byte[int:4] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *,iid=87 !orig=[366] !jvms: DecimalDigits::appendQuad @ bci:36 (line 486)
++++ Eliminated: 87 AllocateArray

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

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3522578182

From cnorrbin at openjdk.org  Wed Nov 12 15:42:24 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 12 Nov 2025 15:42:24 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
Message-ID: <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>

On Tue, 11 Nov 2025 09:57:39 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Remove SkippedException import
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Fix include
>  - Add asserts/checks for input domain
>  - Add regression test for jdk-8370492
>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

Looks good! We are also starting to see tests failing. Some of the new tests fail on rootless cgroup v1 configurations, see comment.

test/hotspot/jtreg/containers/docker/TestMisc.java line 107:

> 105:         // Don't use 1024 exactly so as to avoid mapping to the unlimited/uset case.
> 106:         // Use a value > 100 post-mapping so as to hit the non-default branch: 1052 => 103
> 107:         printContainerInfo(1052, 1024, true);

These tests fail in rootless Podman containers using cgroup v1, because that configuration does not support resource limits. We get the following error to stderr:
`Resource limits are not supported and ignored on cgroups V1 rootless systems`
and the cpu shares value is reset to 1024. `cpu_shares: no shares` is then in the output, leading to the first test failing. Then, `1024 != 1052` which leads to the second test failing.

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

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3454095579
PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2518801888

From kurt at openjdk.org  Wed Nov 12 15:43:27 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Wed, 12 Nov 2025 15:43:27 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <5uFt21WH-s4t91ia9q3ej3ajxwbYKyKCIN9-ul72JDM=.e69ca50e-3411-46e8-a5bc-b53806208c7f@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <Ut7NlZ9u8jDdeP5IjnXLDuFUfVYciRNuxOk8UXI7BLQ=.620f195e-c717-431d-96a0-740bb92f69ac@github.com>
 <5uFt21WH-s4t91ia9q3ej3ajxwbYKyKCIN9-ul72JDM=.e69ca50e-3411-46e8-a5bc-b53806208c7f@github.com>
Message-ID: <23IzdmRbcaIvjdWHZ5LOCzoG1bLh4k53ah3t4_ApFt8=.07a970cc-30e9-4454-8e7d-82aae067bb9a@github.com>

On Wed, 12 Nov 2025 12:15:56 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

> > Would it make sense to add `OperatingSystem.BSD` to consolidate any such predicates?
> 
> I think so, but for this case we would also need `OperatingSystem.FreeBSD`, as I am uncerain if OpenBSD has the same issue. (NetBSD seems to also use jemalloc, and should behave like FreeBSD, though.)

OpenBSD's malloc smallest arena is 16 bytes so it matches the current assumption `MAX_MALLOC_ALIGN` makes and does not exhibit a problem with the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3522593168

From duke at openjdk.org  Wed Nov 12 15:44:53 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 15:44:53 GMT
Subject: Integrated: 8371645: BasicImageReader getEntryNames() is stateful and
 cannot be called more than once
In-Reply-To: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
References: <-Cj4YtgtR56RPjil-fcLuaY3UmhFtrg-QvbG_Nr0Vxc=.4f2da0d0-597d-4d15-b1de-750d3aca8008@github.com>
Message-ID: <izcVR-wSufoPAnrDp-MyHzRTkNZWmI6OpsKrQu0QPHg=.5a57b821-336c-4f92-9e2e-2c709fe1bd96@github.com>

On Wed, 12 Nov 2025 11:17:21 GMT, David Beaumont <duke at openjdk.org> wrote:

> Stop entry name creation using a stateful read of underlying buffer (which moves the position and consumes it).

This pull request has now been integrated.

Changeset: e5c72937
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5c72937af50433029b8d4b6b30a5318c31a9da4
Stats:     7 lines in 1 file changed: 0 ins; 1 del; 6 mod

8371645: BasicImageReader getEntryNames() is stateful and cannot be called more than once

Reviewed-by: alanb, rriggs

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

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

From kurt at openjdk.org  Wed Nov 12 16:08:12 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Wed, 12 Nov 2025 16:08:12 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>
Message-ID: <rmiLisK2PnBY1gwZJaHMZe8dHXmy8oya2j3h4LT2B0g=.1e484612-138c-41f8-b917-ce27aeb1f6c4@github.com>

On Wed, 12 Nov 2025 11:19:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> From a logical point of view, what we'd need would be a couple of extra constants:
> 
> * `MIN_ALIGN`, this is the minimum alignment provided by the allocator/OS/platform combo
> * `MAX_ALIGN`, this is the maximum alignment provided by the allocator/OS/platform combo
> 
> Then, we have three cases:
> 
> * if the requested alignment `A` is `A <= MIN_ALIGN`, we can just allocate and don't adjust for alignment

This seems reasonable to me. While the current code's constant is named `MAX_MALLOC_ALIGN`, I believe in practice it is really the `MIN_ALIGN` and probably should be renamed. It seems to me the current code is written as if it is the `MIN_ALIGN`. 

> * if the requested alignment `A` is `MIN_ALIGN < A <= MAX_ALIGN` and the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment

Doesn't this assume that all malloc implementations follow power of 2 pattern of arena sizes: 8, 16, 32, 64 and pointer alignments between min and max? malloc could also be implemented skipping some of those intermediate sizes. e.g. 16, 64, 256.

> * otherwise, allocate a bigger segment and manually align the result

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3522700151

From archie.cobbs at gmail.com  Wed Nov 12 16:17:38 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 12 Nov 2025 10:17:38 -0600
Subject: Bug in ClassFile API?
Message-ID: <CANSoFxtwv0vuOeEQx2uoSmyUBTGuqPTCbJVOAASheQDJLN3KLg@mail.gmail.com>

I think I found a bug in the ClassFile API but since I'm new to it, before
creating one in Jira, I wanted to double-check I'm not doing something
stupid... could someone please confirm?

Consider this simple test class:

import java.lang.annotation.*;
import java.lang.classfile.*;
import java.nio.file.Path;

public class Test {

    public static void main(String[] args) throws Exception {
        final String filename = args.length > 0 ? args[0] : "Example.class";
        final Path path = Path.of(filename);
        final ClassFile classFile = ClassFile.of();
        final ClassModel classModel = classFile.parse(path);
        classModel.forEach(classElement -> {
            switch (classElement) {
            case MethodModel method when
method.methodName().equalsString("<init>") ->
                System.out.println(String.format("%s: method \"%s\":
runtime visible type annotations: %s",
                  filename, method.methodName(),
method.findAttribute(Attributes.runtimeVisibleTypeAnnotations())));
            default -> { }
            }
        });
    }
}

class Example {
    Example(Object o) {
        String s = (@Anno String)o;
    }
}

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE_USE)
@interface Anno { }

If you compile and run this test it doesn't find any type annotation
attribute on the Example constructor:

$ javac Test.java && java Test
Example.class: method "<init>": runtime visible type annotations:
Optional.empty

Yet javap shows that there is one (as expected):

$  javap -verbose Example
...
  Example(java.lang.Object);
    descriptor: (Ljava/lang/Object;)V
    flags: (0x0000)
    Code:
      stack=1, locals=3, args_size=2
         0: aload_0
         1: invokespecial #1                  // Method
java/lang/Object."<init>":()V
         4: aload_1
         5: checkcast     #7                  // class java/lang/String
         8: astore_2
         9: return
      LineNumberTable:
        line 24: 0
        line 25: 4
        line 26: 9
      RuntimeVisibleTypeAnnotations:
        0: #15(): CAST, offset=5, type_index=0
          Anno

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251112/bb258cda/attachment-0001.htm>

From archie.cobbs at gmail.com  Wed Nov 12 16:20:14 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 12 Nov 2025 10:20:14 -0600
Subject: Bug in ClassFile API?
In-Reply-To: <CANSoFxtwv0vuOeEQx2uoSmyUBTGuqPTCbJVOAASheQDJLN3KLg@mail.gmail.com>
References: <CANSoFxtwv0vuOeEQx2uoSmyUBTGuqPTCbJVOAASheQDJLN3KLg@mail.gmail.com>
Message-ID: <CANSoFxuZJ+hsEh-v9s0_iKTSb2Kv28AUdwtguAQYmw=-SYwowA@mail.gmail.com>

Wait, I think I just figured this out... the annotation is on the code, not
the method...

Nevermind! Thanks.

On Wed, Nov 12, 2025 at 10:17?AM Archie Cobbs <archie.cobbs at gmail.com>
wrote:

> I think I found a bug in the ClassFile API but since I'm new to it, before
> creating one in Jira, I wanted to double-check I'm not doing something
> stupid... could someone please confirm?
>
> Consider this simple test class:
>
> import java.lang.annotation.*;
> import java.lang.classfile.*;
> import java.nio.file.Path;
>
> public class Test {
>
>     public static void main(String[] args) throws Exception {
>         final String filename = args.length > 0 ? args[0] :
> "Example.class";
>         final Path path = Path.of(filename);
>         final ClassFile classFile = ClassFile.of();
>         final ClassModel classModel = classFile.parse(path);
>         classModel.forEach(classElement -> {
>             switch (classElement) {
>             case MethodModel method when
> method.methodName().equalsString("<init>") ->
>                 System.out.println(String.format("%s: method \"%s\":
> runtime visible type annotations: %s",
>                   filename, method.methodName(),
> method.findAttribute(Attributes.runtimeVisibleTypeAnnotations())));
>             default -> { }
>             }
>         });
>     }
> }
>
> class Example {
>     Example(Object o) {
>         String s = (@Anno String)o;
>     }
> }
>
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.TYPE_USE)
> @interface Anno { }
>
> If you compile and run this test it doesn't find any type annotation
> attribute on the Example constructor:
>
> $ javac Test.java && java Test
> Example.class: method "<init>": runtime visible type annotations:
> Optional.empty
>
> Yet javap shows that there is one (as expected):
>
> $  javap -verbose Example
> ...
>   Example(java.lang.Object);
>     descriptor: (Ljava/lang/Object;)V
>     flags: (0x0000)
>     Code:
>       stack=1, locals=3, args_size=2
>          0: aload_0
>          1: invokespecial #1                  // Method
> java/lang/Object."<init>":()V
>          4: aload_1
>          5: checkcast     #7                  // class java/lang/String
>          8: astore_2
>          9: return
>       LineNumberTable:
>         line 24: 0
>         line 25: 4
>         line 26: 9
>       RuntimeVisibleTypeAnnotations:
>         0: #15(): CAST, offset=5, type_index=0
>           Anno
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251112/2496161c/attachment.htm>

From jvernee at openjdk.org  Wed Nov 12 16:39:57 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:39:57 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

Some initial comments on the spec and implementation. I still need to look at the tests.

src/java.base/share/classes/java/lang/LazyConstant.java line 48:

> 46:  * (provided at construction) will be invoked and the result will be used to initialize
> 47:  * the constant. Once a lazy constant is initialized, its contents can <em>never change</em>
> 48:  * and will be retrieved over and over again upon subsequent {@linkplain #get() get}

Are the above links to `#get()` also intended to have a the plain `get` text?

src/java.base/share/classes/java/lang/LazyConstant.java line 169:

> 167:  *          a lazy constant {@linkplain java.lang.ref##reachability strongly references}
> 168:  *          it contents. Hence, a lazy constant will hold its contents until
> 169:  *          the lazy constant itself is collected (if ever).

Maybe you could avoid the word 'collected' here, as there are no other references to the GC in this section, and no link to what GC is/does. i.e. I think 'collected' is not well-defined enough to be used here.

Suggestion:

 *          it contents. Hence, the contents of a lazy constant will be reachable as long
 *          as the lazy constant itself is reachable.

src/java.base/share/classes/java/lang/LazyConstant.java line 249:

> 247: 
> 248:     /**
> 249:      * {@return the {@linkplain System#identityHashCode(Object)} for this lazy constant}

How does this link render? It doesn't have any plain text. Maybe it's missing?

Suggestion:

     * {@return the {@linkplain System#identityHashCode(Object) identity hash code} for this lazy constant}

src/java.base/share/classes/java/lang/LazyConstant.java line 257:

> 255: 
> 256:     /**
> 257:      * {@return a non-initializing string suitable for debugging}

What is a 'non-initializing string'? ;) I think the second paragraph already covers this aspect, so you can leave it out here.

src/java.base/share/classes/java/lang/LazyConstant.java line 275:

> 273:     /**
> 274:      * {@return a lazy constant to be computed later via the provided
> 275:      *          {@code computingFunction}}

The function computes the contents, not the LC itself, so:

Suggestion:

     * {@return a lazy constant whose contents is to be computed later via the provided
     *          {@code computingFunction}}

src/java.base/share/classes/java/util/LazyCollections.java line 55:

> 53: 
> 54:     // Unsafe allows LazyCollection classes to be used early in the boot sequence
> 55:     static final Unsafe UNSAFE = Unsafe.getUnsafe();

Suggestion:

    private static final Unsafe UNSAFE = Unsafe.getUnsafe();

src/java.base/share/classes/java/util/LazyCollections.java line 66:

> 64:         // using `elements.length`.
> 65:         @Stable
> 66:         private final int size;

Is this really that important? What about the extra footprint added by the `int` field? We might have many instances of this class, but only one copy of the bytecode.

src/java.base/share/classes/java/util/LazyCollections.java line 199:

> 197:                 final int size = base.size();
> 198:                 subListRangeCheck(fromIndex, toIndex, size);
> 199:                 return new ReverseOrderLazyListView<>(base.subList(size - toIndex, size - fromIndex));

Why not this? (maybe add a comment?)
Suggestion:

                return new ReverseOrderLazyListView<>(base.subList(fromIndex, toIndex));

src/java.base/share/classes/java/util/LazyCollections.java line 264:

> 262: 
> 263:         @Stable
> 264:         private final Map<K, Integer> indexMapper;

This index mapper is a clever solution that avoids implementing a hashing function again. Lookups through this map can be folded because it is created using `Map.ofEntries`. I think you should put that in a comment here as well.

src/java.base/share/classes/java/util/LazyCollections.java line 433:

> 431:             @Override public V      getValue() {
> 432:                 final int index = map.indexFor(getKey);
> 433:                 final V v = map.getAcquire(getKey);

I suppose you could use `orElseCompute` here, since you already have the index

src/java.base/share/classes/java/util/LazyCollections.java line 488:

> 486:     static final class Mutexes {
> 487: 
> 488:         static final Object TOMB_STONE = new Object();

Suggestion:

        private static final Object TOMB_STONE = new Object();

src/java.base/share/classes/java/util/LazyCollections.java line 578:

> 576:             if (t == null) {
> 577:                 final T newValue = switch (functionHolder.function()) {
> 578:                     case Supplier<?> sup     -> (T) sup.get();

Is the held function ever a Supplier? I don't see a FunctionHolder being created with one.

src/java.base/share/classes/java/util/LazyCollections.java line 607:

> 605:         assert Thread.holdsLock(mutex) : index + "didn't hold " + mutex;
> 606:         // We know we hold the monitor here so plain semantic is enough
> 607:         if (array[index] == null) {

This should always be true when we get here, right?

src/java.base/share/classes/java/util/List.java line 1222:

> 1220:      * <p>
> 1221:      * Any {@link List#subList(int, int) subList()} or {@link List#reversed()} views
> 1222:      * of the returned list are also lazily computed.

Is this really about the views itself? Or about the elements? (AFAIK these views are typically lazily computed/created for others List impls as well)

Suggestion:

     * The elements of any {@link List#subList(int, int) subList()} or {@link List#reversed()} views
     * of the returned list are also lazily computed.

src/java.base/share/classes/java/util/Map.java line 1765:

> 1763:      * at most once per key, even in a multi-threaded environment. Competing
> 1764:      * threads accessing a value already under computation will block until an element
> 1765:      * is computed or an exception is thrown by the computing thread.

I think technically it's more correct to say something like '... or the computing function completes abnormally'. Since, if an exception is throw inside the computing function (by the computing thread), it may be caught and handled inside the computing function as well.

src/java.base/share/classes/java/util/Map.java line 1778:

> 1776:      * <p>
> 1777:      * Any {@link Map#values()} or {@link Map#entrySet()} views of the returned map are
> 1778:      * also lazily computed.

Suggestion:

     * The values of any {@link Map#values()} or {@link Map#entrySet()} views of the returned map are
     * also lazily computed.

src/java.base/share/classes/java/util/Map.java line 1817:

> 1815:         final Set<K> keyCopies = Set.copyOf(keys);
> 1816:         Objects.requireNonNull(computingFunction);
> 1817:         if (keys instanceof EnumSet<?> && !keys.isEmpty()) {

The fact that `keys` is being used here and not `keyCopies` looks a bit fishy. In general we should use the validated copy of our data in subsequent processing. Since `EnumSet` is mutable, it seems that these two could go out of sync.

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

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3448944313
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518699095
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518745565
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518765422
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518768972
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518779499
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518885149
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518897461
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518919343
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518968294
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518950708
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518970767
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2519007486
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2519002745
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518813240
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518832566
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518837814
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518880555

From jvernee at openjdk.org  Wed Nov 12 16:39:58 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:39:58 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <BPsL8gRBQYDTohQqPmBLVaEJ5NBxHEignbOmqf4YSVU=.30ee3776-265a-4966-860b-7f8ff7fc91a6@github.com>

On Wed, 12 Nov 2025 15:23:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 169:
> 
>> 167:  *          a lazy constant {@linkplain java.lang.ref##reachability strongly references}
>> 168:  *          it contents. Hence, a lazy constant will hold its contents until
>> 169:  *          the lazy constant itself is collected (if ever).
> 
> Maybe you could avoid the word 'collected' here, as there are no other references to the GC in this section, and no link to what GC is/does. i.e. I think 'collected' is not well-defined enough to be used here.
> 
> Suggestion:
> 
>  *          it contents. Hence, the contents of a lazy constant will be reachable as long
>  *          as the lazy constant itself is reachable.

Alternatively you could say something like 'becomes eligible for garbage collection', but I think defining the spec in terms of reachability is better, since that has a better definition in `java.lang.ref##reachability`.

> src/java.base/share/classes/java/util/Map.java line 1765:
> 
>> 1763:      * at most once per key, even in a multi-threaded environment. Competing
>> 1764:      * threads accessing a value already under computation will block until an element
>> 1765:      * is computed or an exception is thrown by the computing thread.
> 
> I think technically it's more correct to say something like '... or the computing function completes abnormally'. Since, if an exception is throw inside the computing function (by the computing thread), it may be caught and handled inside the computing function as well.

(Same for List)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518789003
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518834700

From jvernee at openjdk.org  Wed Nov 12 16:39:59 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:39:59 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>
 <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com>
 <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>
Message-ID: <dhFCSfTNXvOxuS2Qx41yPqplCUhXTq4IWT-7OWvhK8M=.fc1e937b-1fb2-4572-aa50-db9e1192a4ef@github.com>

On Mon, 13 Oct 2025 11:25:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Usually a null sentinel is used when null indicates something different. I think maybe to allow folding the empty case, we should probably add a new annotation or a new element-value to indicate this status and properly handle it in C1/C2 (similar to the field trusting in ciField)
>
> I've added two new benchmarks:
> 
> 
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42 = LazyConstant.of(() -> Optional.of(42));
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42_2 = LazyConstant.of(() -> Optional.of(42));
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY = LazyConstant.of(Optional::empty);
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY2 = LazyConstant.of(Optional::empty);
>     
>     ...
>     
>         @Benchmark
>     public int staticOptional42() {
>         return OPTIONAL_42.get().orElseThrow() + OPTIONAL_42_2.get().orElseThrow();
>     }
> 
>     @Benchmark
>     public boolean staticOptionalEmpty() {
>         return OPTIONAL_EMPTY.get().isEmpty() ^ OPTIONAL_EMPTY2.get().isEmpty();
>     }
> 
>     
> 
> 
> Which gives:
> 
> 
> Benchmark                              Mode  Cnt  Score   Error  Units
> StableValueBenchmark.staticOptional42  avgt   10  0.354 ? 0.045  ns/op
> 
> Benchmark                                 Mode  Cnt  Score   Error  Units
> StableValueBenchmark.staticOptionalEmpty  avgt   10  0.370 ? 0.030  ns/op
> 
> 
> So, both `Optional` variants appears to support constant folding.

I don't think we can drawn that conclusion just based on the speed. For the non-constant folded cases, this would be 2 loads and an xor.

I don't see how C2 would be allowed to constant fold the loads if the value is `null`, since that's explicitly forbidden by `@Stable` (and there's no easy way around that AFAIK, since the JIT thread may see a partially initialized object, so it conservatively ignores default values).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514951017

From jvernee at openjdk.org  Wed Nov 12 16:40:02 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:40:02 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v24]
In-Reply-To: <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
Message-ID: <fZvWSosJ0dpOekq5kMHya1CWSi5gEARpc_t-9KhX5qc=.203d607b-631d-46b3-a7fa-5def2552f15d@github.com>

On Mon, 10 Nov 2025 14:59:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @AOTSafeClassInitializer

src/java.base/share/classes/jdk/internal/lang/LazyConstantImpl.java line 47:

> 45: 
> 46:     // Unsafe allows `LazyConstant` instances to be used early in the boot sequence
> 47:     static final Unsafe UNSAFE = Unsafe.getUnsafe();

Suggestion:

    private static final Unsafe UNSAFE = Unsafe.getUnsafe();

test/jdk/java/lang/LazyConstant/LazyConstantSafePublicationTest.java line 117:

> 115:     @Test
> 116:     void mainTest() {
> 117:         CONSTANTS.set(constants());

Instead of passing this through a static field, why not just pass it through the constructor of Producer and Consumer? (which are created below)

test/micro/org/openjdk/bench/java/lang/stable/StableMapSingleBenchmark.java line 66:

> 64:     private static final Map<MyEnum, Integer> MAP_ENUM = Map.ofLazy(EnumSet.allOf(MyEnum.class), MyEnum::ordinal);
> 65:     private static final Map<MyEnum, Optional<Integer>> MAP_ENUM_OPTIONAL = Map.ofLazy(EnumSet.allOf(MyEnum.class), e -> Optional.of(e.ordinal()));
> 66:     private static final Function<Integer, Integer> FUNCTION = MAP::get;

I suppose the function variants are not very interesting to test, since they just delegate to Map::get, Maybe consider removing them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514957700
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514930623
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514913683

From sgehwolf at openjdk.org  Wed Nov 12 16:40:42 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Nov 2025 16:40:42 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
 <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>
Message-ID: <uuwGNXE09dUJswJZF04OEl3jhX5socgZ8GRjQROUprw=.eb396bb1-d2b6-401a-8a71-9b62589a716a@github.com>

On Wed, 12 Nov 2025 15:36:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Severin Gehwolf 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 seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>>  - Remove SkippedException import
>>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>>  - Fix include
>>  - Add asserts/checks for input domain
>>  - Add regression test for jdk-8370492
>>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function
>
> test/hotspot/jtreg/containers/docker/TestMisc.java line 107:
> 
>> 105:         // Don't use 1024 exactly so as to avoid mapping to the unlimited/uset case.
>> 106:         // Use a value > 100 post-mapping so as to hit the non-default branch: 1052 => 103
>> 107:         printContainerInfo(1052, 1024, true);
> 
> These tests fail in rootless Podman containers using cgroup v1, because that configuration does not support resource limits. We get the following error to stderr:
> `Resource limits are not supported and ignored on cgroups V1 rootless systems`
> and the cpu shares value is reset to 1024. `cpu_shares: no shares` is then in the output, leading to the first test failing. Then, `1024 != 1052` which leads to the second test failing.

OK. Thanks for the heads-up. I'll test it. We have infra to check for rootless and can skip it there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2519021505

From fweimer at redhat.com  Wed Nov 12 16:42:26 2025
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 12 Nov 2025 17:42:26 +0100
Subject: InputStream/OutputStream concurrency guarantees
In-Reply-To: <CANSoFxtHtYSYVMDukYuFWhCNs2pah_5QdSnSOf+d_G8q7=XjYA@mail.gmail.com>
 (Archie Cobbs's message of "Thu, 30 Oct 2025 21:33:18 -0500")
References: <lhupla8dbqz.fsf@oldenburg.str.redhat.com>
 <CAChcVunevSwUqNXrZZCy3-CEhA8=oqQ0qVvOHOkARCUgaeGmfg@mail.gmail.com>
 <c39ddec3-e12f-43ad-a6c8-5ed375f23ba3@oracle.com>
 <CAChcVum=RH-Z3fq1Q5x4MYirT3OfCW3xZZ_rcKn16srUPa9VzA@mail.gmail.com>
 <5848207d-a5f7-48c8-81c8-826de122af48@oracle.com>
 <lhuzf98joxy.fsf@oldenburg.str.redhat.com>
 <CANSoFxuJQyHZGfj7vv02Vnf1WAn2H6DCawtHS30xMxHODC4zbw@mail.gmail.com>
 <lhuv7jwjcgt.fsf@oldenburg.str.redhat.com>
 <CANSoFxtHtYSYVMDukYuFWhCNs2pah_5QdSnSOf+d_G8q7=XjYA@mail.gmail.com>
Message-ID: <lhuh5uzryml.fsf@oldenburg.str.redhat.com>

* Archie Cobbs:

> On Thu, Oct 30, 2025 at 4:39?PM Florian Weimer <fweimer at redhat.com> wrote:
>
>> I'm trying to image in a way to get rid of the double buffering in
>> FileInputStream/FileOutputStream: have the kernel access the heap
>> directly, instead of a copy.
>
> Wasn't that one of the goals of the NIO Channel API and direct
> ByteBuffers?

Code that allocates ByteBuffers cannot always determine whether they
should be direct or not.

> You've probably already considered that approach - if so I'm curious
> why it doesn't work.

It works, but if I recall there is lots of thorny code for the direct
buffer used for bouncing, to enable FileChannel etc. for heap buffers.
That could go away on platforms where the kernel can directly access
heap arrays.  But maybe that's not true on all platforms, so that code
will have to be maintained indefinitely.

Thanks,
Florian


From rriggs at openjdk.org  Wed Nov 12 18:37:07 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Nov 2025 18:37:07 GMT
Subject: RFR: 8371732: [redo] Change java.time month/day field types to 'byte'
Message-ID: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>

Redo change (8371732) that failed when the updated class objects were incompatible.
The fields of classes are changed to allow a more compact form of storage.

To ensure compatibility of the class objects, the fields are explicitly declared in SerialPersistentFields with the original field types.
The fields are marked `transient` to indicate the field declarations are not used for serialization.
The affected classes are java.time.LocalDate, MonthDay, and YearMonth.
Tests are added to verify the types and names of serialized fields of each class.

HijrahDate only changes the field types, the fields are transient and there is no change to the serialized from of the HijrahDate.class object.

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

Commit messages:
 - Change some java.time fields from int or short to byte to save on heap size.

Changes: https://git.openjdk.org/jdk/pull/28274/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28274&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371732
  Stats: 124 lines in 7 files changed: 100 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/28274.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28274/head:pull/28274

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

From psandoz at openjdk.org  Wed Nov 12 19:51:18 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 12 Nov 2025 19:51:18 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer
In-Reply-To: <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
Message-ID: <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>

On Wed, 12 Nov 2025 07:59:38 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > > Some quick comments.
> > > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
> > 
> > 
> > I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
> 
> There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.

Maybe we move the shape to the end e.g., `Float16Vector128`, `IntVector128`, `IntVectorMax`?

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3523631727

From rrich at openjdk.org  Wed Nov 12 19:58:59 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 12 Nov 2025 19:58:59 GMT
Subject: RFR: 8371608: Jtreg test jdk/internal/vm/Continuation/Fuzz.java
 sometimes fails with (fast)debug binaries
In-Reply-To: <nRBH7HkrI2R4VW0m0I4RdT1xBexRyBpC7TkGh1-SMMM=.79e4eb76-c3d0-461e-b837-24977b86d5f9@github.com>
References: <nRBH7HkrI2R4VW0m0I4RdT1xBexRyBpC7TkGh1-SMMM=.79e4eb76-c3d0-461e-b837-24977b86d5f9@github.com>
Message-ID: <sjmc96lZmxcNeGGmjBjn8OQzpGQvaJvmFOjRg8NQz6U=.041d2d16-8263-4e18-90a8-ba840b3bcfec@github.com>

On Wed, 12 Nov 2025 13:36:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test jdk/internal/vm/Continuation/Fuzz.java with (fast)debug binaries, we see timeouts like these on multiple platforms :
> 
> 
> jdk/internal/vm/Continuation/Fuzz_preserve-fp on Linux x86_64 :
> 
> java.lang.AssertionError: Failed to compile int Fuzz.com_int(int,int) in 45000ms
> at Fuzz.waitForCompilation(Fuzz.java:323)
> at Fuzz.compile(Fuzz.java:357)
> at Fuzz.testTrace(Fuzz.java:214)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:186)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
> at java.base/java.nio.file.FileChannelLinesSpliterator.forEachRemaining(FileChannelLinesSpliterator.java:130)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176)
> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265)
> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:632)
> at Fuzz.testStream(Fuzz.java:204)
> at Fuzz.testFile(Fuzz.java:189)
> at Fuzz.runTests(Fuzz.java:111)
> at Fuzz.main(Fuzz.java:105)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> Probably it makes sense to increase the COMPILATION_TIMEOUT when running with (fast)debug binaries.

Looks reasonable.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28267#pullrequestreview-3455212748

From alanb at openjdk.org  Wed Nov 12 20:03:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Nov 2025 20:03:31 GMT
Subject: RFR: 8371732: [redo] Change java.time month/day field types to
 'byte'
In-Reply-To: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
References: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
Message-ID: <C_-3yZ1Buen_pdQaYjMYtgchaPdM4utuFC8K7WsjKJI=.a2135fc4-9740-40b3-af09-defe2079f828@github.com>

On Wed, 12 Nov 2025 18:29:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Redo change (8371732) that failed when the updated class objects were incompatible.
> The fields of classes are changed to allow a more compact form of storage.
> 
> To ensure compatibility of the class objects, the fields are explicitly declared in SerialPersistentFields with the original field types.
> The fields are marked `transient` to indicate the field declarations are not used for serialization.
> The affected classes are java.time.LocalDate, MonthDay, and YearMonth.
> Tests are added to verify the types and names of serialized fields of each class.
> 
> HijrahDate only changes the field types, the fields are transient and there is no change to the serialized from of the HijrahDate.class object.

Good

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28274#pullrequestreview-3455240021

From psandoz at openjdk.org  Wed Nov 12 20:13:49 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 12 Nov 2025 20:13:49 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer
In-Reply-To: <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
Message-ID: <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>

On Wed, 12 Nov 2025 19:48:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> > Some quick comments.
>>> > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
>>> 
>>> I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
>> 
>> There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.
>
>> > > Some quick comments.
>> > > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
>> > 
>> > 
>> > I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
>> 
>> There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.
> 
> Maybe we move the shape to the end e.g., `Float16Vector128`, `IntVector128`, `IntVectorMax`?

> Hi @PaulSandoz , Thanks for your comments. Please find below my responses.
> 
> > When you generate the fallback code for unary/binary etc can you push the carrier type and conversations into the uOp/bOp implementations so you don't have to explicitly operate on the carrier type and do the conversions as you do now e.g.,:
> > ```
> > v0.uOp(m, (i, a) -> float16ToShortBits(Float16.valueOf(-(shortBitsToFloat16(($type$)a).floatValue()))));
> > ```
> 
> Currently, uOp and uOpTemplates are part of the scaffolding logic and are sacrosanct; they are shared by various abstracted vector classes, and their semantics are defined by the lambda expression. I agree that explicit conversion in lambdas looks verbose, but moving them to uOpTemplate may fracture the lambda expression such that part of its semantics, i.e,. conversions, will seep into uOpTemplate, while what will appear at the surface will be the expression operating over primitive float values; this may become very confusing.

Since the uOpTemplate etc are per element vector type it seems straightforward to adjust the template to perform the conversion before and after the function application, or add a default method to FUnOp etc that operates on the carrier value and performs the conversions and the template calls that default method. Later we will eventually be able to declare Float16![] and it should all collapse away. 

> 
> > Requiring two arguments means they can get out of sync. Previously the class provided all the information needed, now
> > arguably the type does.
> 
> Yes, from the compiler standpoint point all we care about is the carrier type, which determines the vector lane size. This is augmented with operation kind (PRIM / FP16) to differentiate a short vector lane from a float16 vector lane. Apart from this, we need to pass the VectorBox type to wrap the vector IR.

The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3523722566

From sgehwolf at openjdk.org  Wed Nov 12 20:28:41 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Nov 2025 20:28:41 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Fix TestMisc for podman on cg v1 in rootless mode.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/a2c6b160..9417bdbe

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

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

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

From sgehwolf at openjdk.org  Wed Nov 12 20:28:42 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Nov 2025 20:28:42 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <uuwGNXE09dUJswJZF04OEl3jhX5socgZ8GRjQROUprw=.eb396bb1-d2b6-401a-8a71-9b62589a716a@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
 <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>
 <uuwGNXE09dUJswJZF04OEl3jhX5socgZ8GRjQROUprw=.eb396bb1-d2b6-401a-8a71-9b62589a716a@github.com>
Message-ID: <F44-sGqpPOFeUpz7wsxljtDtFiDzBaYwQ93l6faWR6g=.15546430-d8be-4459-82bb-a41c5a16e82c@github.com>

On Wed, 12 Nov 2025 16:37:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/hotspot/jtreg/containers/docker/TestMisc.java line 107:
>> 
>>> 105:         // Don't use 1024 exactly so as to avoid mapping to the unlimited/uset case.
>>> 106:         // Use a value > 100 post-mapping so as to hit the non-default branch: 1052 => 103
>>> 107:         printContainerInfo(1052, 1024, true);
>> 
>> These tests fail in rootless Podman containers using cgroup v1, because that configuration does not support resource limits. We get the following error to stderr:
>> `Resource limits are not supported and ignored on cgroups V1 rootless systems`
>> and the cpu shares value is reset to 1024. `cpu_shares: no shares` is then in the output, leading to the first test failing. Then, `1024 != 1052` which leads to the second test failing.
>
> OK. Thanks for the heads-up. I'll test it. We have infra to check for rootless and can skip it there.

Should be fixed in the update with: https://github.com/openjdk/jdk/pull/28157/commits/9417bdbeb4d458489953a54d253e8f79dc678734

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2519710367

From duke at openjdk.org  Wed Nov 12 21:49:10 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 12 Nov 2025 21:49:10 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <ggdw6IJLb8vSl_FSPlfD6B-JOIQbaPXXetiZzK9r-SM=.e6340448-e798-4d81-a2d0-54e23a127f3c@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

src/java.base/share/classes/java/util/LazyCollections.java line 509:

> 507:                 return mutex;
> 508:             }
> 509:             // Protect against racy stores of mutexe candidates

Suggestion:

            // Protect against racy stores of mutex candidates

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518540555

From duke at openjdk.org  Wed Nov 12 21:49:12 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 12 Nov 2025 21:49:12 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <QOrBcIEhpsiMtBjYAIXYvE5gTFQDmQUUtNplF-uBTGU=.10d80411-1396-4e42-80d1-aa13749520f7@github.com>

On Wed, 12 Nov 2025 16:33:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 578:
> 
>> 576:             if (t == null) {
>> 577:                 final T newValue = switch (functionHolder.function()) {
>> 578:                     case Supplier<?> sup     -> (T) sup.get();
> 
> Is the held function ever a Supplier? I don't see a FunctionHolder being created with one.

This?is from?when `FunctionHolder` was?located in?the?`jdk.internal.lang.stable` package in?[GH?25878], and?was?used to?implement the?computing?function freeing?mechanism in?[`StableValue?::supplier(?)`].

[GH?25878]: https://github.com/openjdk/jdk/pull/25878
[`StableValue?::supplier(?)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/StableValue.html#supplier(java.util.function.Supplier)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2519902578

From asemenyuk at openjdk.org  Wed Nov 12 23:11:18 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 12 Nov 2025 23:11:18 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
Message-ID: <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>

> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
> 
> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
> 
> ### Error reporting improved
> 
> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
> 
> Command line (Windows): 
> 
> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
> 
> Old error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> 
> 
> New error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> Error: Option [--mac-package-name] is not valid on this platform
> Error: Option [-p] is not valid with type [exe]
> Error: Option [--linux-menu-group] is not valid on this platform
> 
> 
>  2. Fix misleading error messages.
> 
> Command line (Windows): 
> 
> jpackage --input no --main-jar no.jar
> 
> Old error output:
> 
> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
> 
> 
> New error output:
> 
> The value "no" provided for parameter --input is not a directory
> 
> 
> 
> 
> ### Help output fixed
> 
> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
> 
> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
> 
> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
> 
> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
> 
> ### Functional changes
> 
> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
> 
> Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.
> 
> In addition to `--opt...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  MainResources.properties: remove unreferenced L10N key

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28163/files
  - new: https://git.openjdk.org/jdk/pull/28163/files/0448168a..f7de2646

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

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

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

From rriggs at openjdk.org  Wed Nov 12 23:44:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Nov 2025 23:44:06 GMT
Subject: RFR: 8371339: Illegal pattern char 'B' with locale.providers as
 HOST on macOS for Taiwanese
In-Reply-To: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
References: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
Message-ID: <aslDwHYiHSeA41AWBGNXePrE-2w6fVXKGfhn3zjkgyc=.9fe7a467-98db-403c-af9d-ec00ed2d19c3@github.com>

On Thu, 6 Nov 2025 19:35:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover when we introduced "dayperiods" in the JDK ([JDK-8247781](https://bugs.openjdk.org/browse/JDK-8247781)). The CLDR Converter was modified to generate patterns for SimpleDateFormat for dayperiods (simply replacing them with ampm), and the same processing should have been applied to Host provider on mac, which also uses LDML patterns. As in the bug report, macos recently started using dayperiods, thus the issue was revealed. Regression test is not provided as it would require the macos's default locale should be configured to zh_TW. I have manually confirmed that the proposed fix would work for the problem case.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28181#pullrequestreview-3456048793

From rriggs at openjdk.org  Wed Nov 12 23:47:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Nov 2025 23:47:02 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <kXo_Gn9Q2z489_ETagoMTs_IjQIyTlq7j5Gmye7MGWc=.6bc8aae9-c269-4908-8fba-aa7a2f6e6b02@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

src/java.base/share/native/libjimage/imageFile.cpp line 335:

> 333:     _index_data = (u1*)osSupport::map_memory(_fd, _name, 0, (size_t)map_size());
> 334:     if (_index_data == nullptr) {
> 335:       return false;

Indentation in this file is 4 spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28087#discussion_r2520210679

From smarks at openjdk.org  Wed Nov 12 23:59:04 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 12 Nov 2025 23:59:04 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v2]
In-Reply-To: <cStkQ8SJOSKc9kn-M5BtOxJchYsS_I9_4amAZ0FqDog=.12f916d9-ba66-4aaa-a1b9-5cf3de2c39a5@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <NWxQlK3_BVl6Fy5YCSa2S5u4SAzVEWNi73iS_D3OuhU=.1a6c85eb-533e-4bad-8984-b313f0f26717@github.com>
 <p4lQ-B2UBHgzBLSQY3GQf1bCCRB01DWkIN_jLRiSwXY=.f890f186-7618-4bcb-89b4-997fa4a8edbd@github.com>
 <hMA3EPOMFlD4JKHktdABoBOXDQPkz5Wakx86l2fkovM=.7139475b-2219-4ec4-945b-5682d5de4236@github.com>
 <cStkQ8SJOSKc9kn-M5BtOxJchYsS_I9_4amAZ0FqDog=.12f916d9-ba66-4aaa-a1b9-5cf3de2c39a5@github.com>
Message-ID: <ccpwJ_xOijiF7vuVSlkDpJMzfK4ydlPPBZfMc2HVCX4=.5c2a4ad6-1120-4703-8429-1ab69daf2c92@github.com>

On Tue, 11 Nov 2025 17:46:11 GMT, R?mi Forax <forax at openjdk.org> wrote:

>>> I wonder if it's not better to replace Comparator.naturalOrder() by null in the constructor of TreeSet, given that TreeSet does not provide a getter for it so the only way to get the comparator is using treeSet.spliterator().getComparator().
>> 
>> That wouldn't help with the `stream().sorted(Comparator.naturalOrder())` case; the example I supplied is somewhat contrived, I originally ran into this in Guava (see the [issue](https://github.com/google/guava/issues/6187) I opened there); the library is null-hostile and so always supplies a comparator to its sorted collections. Note that this won't directly fix the issue there until they move away from their custom natural order comparator to the one from the JDK.
>
>> That wouldn't help with the `stream().sorted(Comparator.naturalOrder())` case; the example I supplied is somewhat contrived, I originally ran into this in Guava (see the [issue](https://github.com/google/guava/issues/6187) I opened there); the library is null-hostile and so always supplies a comparator to its sorted collections. 
> 
> If you switch from Comparator.naturalOrder()) to null, you have to do it in stream.sorted() too (and also List.sort(Comparator), Collections.sort(Comparator), Array.sort(Comparator), Collections.reverseOrder(Comparator) etc)
> 
>> Note that this won't directly fix the issue there until they move away from their custom natural order comparator to the one from the JDK.
> 
> yes, comparing comparators with == is brittle anyway, but at least you can make it consistent for the JDK.

@forax

> I wonder if it's not better to replace Comparator.naturalOrder() by null in the constructor of TreeSet, given that TreeSet does not provide a getter for it so the only way to get the comparator is using treeSet.spliterator().getComparator().

TreeSet does have a "getter" named `comparator()`. It's defined by SortedSet. Not sure this affects where the discussion is at the moment though.

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

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3524405700

From liach at openjdk.org  Thu Nov 13 00:14:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Nov 2025 00:14:28 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
 [v5]
In-Reply-To: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
References: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
Message-ID: <usMnDz0Y1oEQvmpPPhQPS1YA60pF5kM3vsvN2RGmErk=.38222a37-f315-497c-b8a3-36ff5310beb1@github.com>

> java.lang.reflect.Proxy has some surprising behaviors associated with protected methods in Object, covariant/contravariant overrides in interfaces, and package-private types in method signatures. Such behaviors should have tests, so that they are not accidentally perturbed in Proxy updates.

Chen Liang 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 nine additional commits since the last revision:

 - Better comments
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
 - Update test/jdk/java/lang/reflect/Proxy/BridgeMethodsTest.java
 - Consolidate duplicate tests
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
 - Tweaks
 - 8370839: Tests to verify peculiar Proxy dispatching behaviors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28023/files
  - new: https://git.openjdk.org/jdk/pull/28023/files/e8ed5fab..5cafdf2f

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

  Stats: 160628 lines in 819 files changed: 110305 ins; 22545 del; 27778 mod
  Patch: https://git.openjdk.org/jdk/pull/28023.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28023/head:pull/28023

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

From liach at openjdk.org  Thu Nov 13 00:14:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Nov 2025 00:14:30 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
 [v2]
In-Reply-To: <FZq6CBx_fyQx2YEpp2MsF6f6YRpPRwoIeVx1m_7FOjw=.ba1ed9a1-c37b-442a-b8c5-b8b489adfd3d@github.com>
References: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
 <IZXKtP1X-lxkJrUaRk61IDTKZG4D7cJJW31XtFtDjqo=.542f242c-db52-4ac7-bf22-3cf281c7dee8@github.com>
 <FZq6CBx_fyQx2YEpp2MsF6f6YRpPRwoIeVx1m_7FOjw=.ba1ed9a1-c37b-442a-b8c5-b8b489adfd3d@github.com>
Message-ID: <1ZceXMx9hxzUtjeMr-EgTeTg7O_0p5WfFfFU-9azrLo=.ea072a52-901c-4935-9e12-d4f20aed4b33@github.com>

On Tue, 4 Nov 2025 15:46:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>>  - Tweaks
>>  - 8370839: Tests to verify peculiar Proxy dispatching behaviors
>
> These look good, but I think it would help if you could add a short description (in a comment) for each/some test cases of what it is that you're trying to test. Especially since some of the test cases are targeting the invisible bridge methods.

@JornVernee I have added comments about the tests. Please help review again.

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

PR Comment: https://git.openjdk.org/jdk/pull/28023#issuecomment-3524445195

From liach at openjdk.org  Thu Nov 13 00:31:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Nov 2025 00:31:11 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v17]
In-Reply-To: <WJeeAF8mUbfNMuRjvkHot-we7WoZXDY3iruMKiMPbRc=.74622925-401d-4e35-a5bd-064f2828ae6d@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <WJeeAF8mUbfNMuRjvkHot-we7WoZXDY3iruMKiMPbRc=.74622925-401d-4e35-a5bd-064f2828ae6d@github.com>
Message-ID: <HydpYe9Mj2UmwKV4pHteSURyQqoWtvZM1eA-O341o-U=.c37b5ab0-5b13-4d86-adec-cb36c3975f31@github.com>

On Wed, 12 Nov 2025 15:01:49 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   static field JLA

src/java.base/share/classes/java/time/MonthDay.java line 753:

> 751:     @Override
> 752:     public String toString() {
> 753:         StringBuilder buf = new StringBuilder(10);

Why is this set to 10 instead of 7?

src/java.base/share/classes/java/time/YearMonth.java line 1201:

> 1199:     public String toString() {
> 1200:         int absYear = Math.abs(year);
> 1201:         StringBuilder buf = new StringBuilder(9);

I think 7 is better for most cases, right?

src/java.base/share/classes/java/time/ZoneOffset.java line 466:

> 464:         } else {
> 465:             int absTotalSeconds = Math.abs(totalSeconds);
> 466:             StringBuilder buf = new StringBuilder();

This can be pre-sized to 9 (or 7 if seconds is 0)

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 463:

> 461:      */
> 462:     public static void appendPair(StringBuilder buf, int v) {
> 463:         int packed = DIGITS[v & 0x7f];

We should assert v is in range so errors can be caught when we run tests. Same for appendQuad.

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 464:

> 462:     public static void appendPair(StringBuilder buf, int v) {
> 463:         int packed = DIGITS[v & 0x7f];
> 464:         buf.append(

Add a comment in the middle, that compiler should be able to eliminate the string and array allocation here. Same for appendQuad.

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 466:

> 464:         buf.append(
> 465:                 JLA.uncheckedNewStringWithLatin1Bytes(
> 466:                         new byte[] {(byte) (packed & 0xFF), (byte) (packed >> 8)}));

Suggestion:

                        new byte[] {(byte) packed, (byte) (packed >> 8)}));

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 484:

> 482:      */
> 483:     public static void appendQuad(StringBuilder buf, int v) {
> 484:         int y01 = v / 100;

Same assert bound check request

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 486:

> 484:         int y01 = v / 100;
> 485:         int packed = DIGITS[y01 & 0x7f] | (DIGITS[(v - y01 * 100) & 0x7f] << 16);
> 486:         buf.append(

Same comment about noting the compiler can eliminate array and string allocations.

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 488:

> 486:         buf.append(
> 487:                 JLA.uncheckedNewStringWithLatin1Bytes(
> 488:                         new byte[] {(byte) (packed & 0xFF), (byte) (packed >> 8), (byte) (packed >> 16), (byte) (packed >> 24)}));

Suggestion:

                        new byte[] {(byte) packed, (byte) (packed >> 8), (byte) (packed >> 16), (byte) (packed >> 24)}));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2520394779
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2520398192
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2520403542
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2520418117
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2520428744
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2520408664
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2520427212
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2520429334
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2520418300

From naoto at openjdk.org  Thu Nov 13 00:34:15 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Nov 2025 00:34:15 GMT
Subject: RFR: 8371339: Illegal pattern char 'B' with locale.providers as
 HOST on macOS for Taiwanese
In-Reply-To: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
References: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
Message-ID: <LAKGj1u86hones4qa0mfrsLo4YKPpvdhuwNMWnxJIVA=.00fb52ad-2552-4567-86b3-eadb9805e4ee@github.com>

On Thu, 6 Nov 2025 19:35:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover when we introduced "dayperiods" in the JDK ([JDK-8247781](https://bugs.openjdk.org/browse/JDK-8247781)). The CLDR Converter was modified to generate patterns for SimpleDateFormat for dayperiods (simply replacing them with ampm), and the same processing should have been applied to Host provider on mac, which also uses LDML patterns. As in the bug report, macos recently started using dayperiods, thus the issue was revealed. Regression test is not provided as it would require the macos's default locale should be configured to zh_TW. I have manually confirmed that the proposed fix would work for the problem case.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28181#issuecomment-3524517311

From naoto at openjdk.org  Thu Nov 13 00:34:15 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Nov 2025 00:34:15 GMT
Subject: Integrated: 8371339: Illegal pattern char 'B' with locale.providers as
 HOST on macOS for Taiwanese
In-Reply-To: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
References: <30ThkifrSqifpcv8THhqYLuq535cHggNmDFIGim8F0k=.e5ea6c2c-1704-4fb7-8296-9c5756cd4b6c@github.com>
Message-ID: <ICEGjFxsQFy8Q8tezl4LceDdvxoCJcXcUFPV_ttVKBo=.b19d3b52-ad44-4863-b057-867ff36170df@github.com>

On Thu, 6 Nov 2025 19:35:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover when we introduced "dayperiods" in the JDK ([JDK-8247781](https://bugs.openjdk.org/browse/JDK-8247781)). The CLDR Converter was modified to generate patterns for SimpleDateFormat for dayperiods (simply replacing them with ampm), and the same processing should have been applied to Host provider on mac, which also uses LDML patterns. As in the bug report, macos recently started using dayperiods, thus the issue was revealed. Regression test is not provided as it would require the macos's default locale should be configured to zh_TW. I have manually confirmed that the proposed fix would work for the problem case.

This pull request has now been integrated.

Changeset: d2571ea7
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2571ea76ae5a9ccb7053bfec24bf3aedd366084
Stats:     12 lines in 1 file changed: 11 ins; 0 del; 1 mod

8371339: Illegal pattern char 'B' with locale.providers as HOST on macOS for Taiwanese

Reviewed-by: jlu, rriggs

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

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

From smarks at openjdk.org  Thu Nov 13 00:52:06 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 13 Nov 2025 00:52:06 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v5]
In-Reply-To: <vSVVYdKkOvUOmmdFbICM87-yqIkBKShCnSUmt3sUsmo=.37a8728b-8e3a-4961-a84f-f179c93acec9@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <vSVVYdKkOvUOmmdFbICM87-yqIkBKShCnSUmt3sUsmo=.37a8728b-8e3a-4961-a84f-f179c93acec9@github.com>
Message-ID: <1M7QGkc_DoRJEGF4nQXShjdOfs-5rM0k4cnt5Ims73E=.156ea658-649b-4a20-88b6-6284eea3ef96@github.com>

On Mon, 10 Nov 2025 16:31:37 GMT, jengebr <duke at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace fixes

test/jdk/java/util/Collection/MOAT.java line 890:

> 888:     }
> 889: 
> 890:     private static void testAddAll(Collection<Integer> c) {

Thanks for moving this test into MOAT. Overall it seems like a large reduction in test bulk, which simplifies a lot of things. Great!

test/jdk/java/util/Collection/MOAT.java line 892:

> 890:     private static void testAddAll(Collection<Integer> c) {
> 891:         if (!supportsAdd(c))
> 892:             return;

There's already a check for `supportsAdd()` in the testCollection1() method, which is the only caller, so it doesn't seem necessary to have one here.

test/jdk/java/util/Collection/MOAT.java line 898:

> 896:         // Test empty ArrayList source
> 897:         ArrayList<Integer> emptySource = new ArrayList<>();
> 898:         check(!c.addAll(emptySource));

It seems like there's an assertion missing here. We check the return value from addAll(), but not the state of the collection after the operation. Maybe something like `check(c.isEmpty())` ?

test/jdk/java/util/Collection/MOAT.java line 905:

> 903:         arraySource.add(99);
> 904:         check(c.addAll(arraySource));
> 905:         equal(new ArrayList<Integer>(c), arraySource);

Here and at line 913 it seems a bit odd to copy `c` into a new ArrayList to compare equality. I think it's trying to assert that `c` contains only the expected elements. Unfortunately `c` can be any collection, not just a List, and to use List equality it needs to be copied into an actual List. Doubly unfortunately, the new List will capture the encounter order of whatever collection `c` is, which might not be well-defined -- for example if `c` is a HashSet. So I don't think this is the right assertion. Probably a size check and a containsAll() check, as is done in the bottom case, is sufficient.

test/jdk/java/util/Collection/MOAT.java line 922:

> 920:         check(c.addAll(arraySource));
> 921:         equal(c.size(), sizeBefore + arraySource.size());
> 922:         check(c.containsAll(arraySource));

As I said in another comment, this (size check and containsAll check) looks like a better set of assertions than using List equality as in the earlier test cases.

I'm confused about the scope of cases being covered here. It seems like there are potentially three different axes of cases that potentially could be tested:

1) source is ArrayList / other kind of List
2) source is empty / not empty
3) destination is empty / not empty

That would indicate having eight test cases. That's kind of at the outer limit for hand-coded cases. At this point or beyond, having some automated case generation would be preferable. And this is MOAT and not JUnit, so test generation would have to be done _ad hoc_. I could imagine doing it in about the same amount of code (say 30 or fewer lines). But if you're not up for doing this, it's probably sufficient for this change to test just the ArrayList and non-ArrayList sources, since that should be sufficient to test the code path you're changing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2520427236
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2520350910
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2520359830
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2520399855
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2520522638

From liach at openjdk.org  Thu Nov 13 00:52:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Nov 2025 00:52:09 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v6]
In-Reply-To: <wFIOoKuYbiFUcRK1HMXvY_hUekLfVCUI3RebUSW8DiU=.cc49894b-306e-40b3-96dc-3aef0a39d033@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <wFIOoKuYbiFUcRK1HMXvY_hUekLfVCUI3RebUSW8DiU=.cc49894b-306e-40b3-96dc-3aef0a39d033@github.com>
Message-ID: <l3YaQPL6ng5J6hwTNyLk30qugM7i3pREO5D_B0sTDTk=.bbc43250-370c-492b-8d40-9aca49249755@github.com>

On Tue, 11 Nov 2025 20:59:18 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up

src/java.base/share/classes/java/util/stream/SortedOps.java line 129:

> 127:                           (isNaturalSort ? StreamOpFlag.IS_SORTED : StreamOpFlag.NOT_SORTED));
> 128:             this.isNaturalSort = isNaturalSort;
> 129:             this.comparator = comparator;

Since we are calling super explicitly, we prefer putting field assignments before the super constructor call in anticipation for more robust object construction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28226#discussion_r2520520546

From serb at openjdk.org  Thu Nov 13 02:19:46 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 13 Nov 2025 02:19:46 GMT
Subject: RFR: 8371746: Some imports in Integer.java and Long.java became unused
 after JDK-8370503
Message-ID: <wwtlO_jYOA5VWK-jhLmVj1km86hzfAvei_PG_QvjYKw=.0757c681-ba75-41f3-a994-5fc107111582@github.com>

Trivial patch. Removes unused imports from `Integer.java` and `Long.java` following [JDK-8370503](https://bugs.openjdk.org/browse/JDK-8370503).

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

Commit messages:
 - 8371746: Some imports in Integer.java and Long.java became unused after JDK-8370503

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

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

From liach at openjdk.org  Thu Nov 13 02:27:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Nov 2025 02:27:00 GMT
Subject: RFR: 8371746: Some imports in Integer.java and Long.java became
 unused after JDK-8370503
In-Reply-To: <wwtlO_jYOA5VWK-jhLmVj1km86hzfAvei_PG_QvjYKw=.0757c681-ba75-41f3-a994-5fc107111582@github.com>
References: <wwtlO_jYOA5VWK-jhLmVj1km86hzfAvei_PG_QvjYKw=.0757c681-ba75-41f3-a994-5fc107111582@github.com>
Message-ID: <dnMsHf8wvnPYVjdhc0ghvIuos9dJ8dRNoenCKN0aljw=.c82883ac-3b04-4e69-aceb-16d0e2455689@github.com>

On Wed, 12 Nov 2025 22:25:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Trivial patch. Removes unused imports from `Integer.java` and `Long.java` following [JDK-8370503](https://bugs.openjdk.org/browse/JDK-8370503).

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28277#pullrequestreview-3456797844

From jvernee at openjdk.org  Thu Nov 13 02:32:03 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 13 Nov 2025 02:32:03 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
 [v5]
In-Reply-To: <usMnDz0Y1oEQvmpPPhQPS1YA60pF5kM3vsvN2RGmErk=.38222a37-f315-497c-b8a3-36ff5310beb1@github.com>
References: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
 <usMnDz0Y1oEQvmpPPhQPS1YA60pF5kM3vsvN2RGmErk=.38222a37-f315-497c-b8a3-36ff5310beb1@github.com>
Message-ID: <pkWgUZcfEcnODZfgW4e5_WuS7WeYu0bPmjOCBGcMN4A=.add8882a-ed61-467d-b8ba-7c4f53440ceb@github.com>

On Thu, 13 Nov 2025 00:14:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> java.lang.reflect.Proxy has some surprising behaviors associated with protected methods in Object, covariant/contravariant overrides in interfaces, and package-private types in method signatures. Such behaviors should have tests, so that they are not accidentally perturbed in Proxy updates.
>
> Chen Liang 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 nine additional commits since the last revision:
> 
>  - Better comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>  - Update test/jdk/java/lang/reflect/Proxy/BridgeMethodsTest.java
>  - Consolidate duplicate tests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>  - Tweaks
>  - 8370839: Tests to verify peculiar Proxy dispatching behaviors

Thanks for the updates!

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28023#pullrequestreview-3456817978

From syan at openjdk.org  Thu Nov 13 02:38:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Nov 2025 02:38:16 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java
Message-ID: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>

Hi all,

In JDK 11, ThreadPoolExecutor.finalize() was specified to do nothing, leaving the finalize() method empty by [JDK-8371748](https://bugs.openjdk.org/browse/JDK-8371748), so I think it's safety to remove finalize() in testFinalizeMethodCallsSuperFinalize for test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java.

This PR also remove unnecessary '@SuppressWarnings("removal")' in test/jdk/java/util/concurrent/tck/JSR166TestCase.java and test/jdk/java/util/concurrent/tck/ExecutorsTest.java.

Change has been verified locally on linux-x64 by run test ava/util/concurrent/tck/JSR166TestCase.java#default. Test-fix only, no risk,

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

Commit messages:
 - 8371682: Suppress javac warning from ThreadPoolExecutorSubclassTest.java

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

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

From duke at openjdk.org  Thu Nov 13 02:50:38 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Thu, 13 Nov 2025 02:50:38 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v7]
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <L5e98tCFibtD61ENDhoBfJ4Sn0ETLCt4Qvn86271lhA=.29d0c60f-290e-4d71-aa9c-a66baa87d472@github.com>

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Assign fields before super call

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28226/files
  - new: https://git.openjdk.org/jdk/pull/28226/files/c5bf7d56..3f339ad9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28226&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28226&range=05-06

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

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

From swen at openjdk.org  Thu Nov 13 04:07:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 13 Nov 2025 04:07:45 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v18]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <-aL1dZ7JL827EIaxfss_kcc_2aEb4DtxKNkmh5mzmeo=.b8cb47fb-32a2-42eb-a73a-2f5cbc74d52b@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - fix codestyle
 - digitQuad MergeStore & from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/9fbc9853..683e9483

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=16-17

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

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

From swen at openjdk.org  Thu Nov 13 04:07:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 13 Nov 2025 04:07:46 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v17]
In-Reply-To: <HydpYe9Mj2UmwKV4pHteSURyQqoWtvZM1eA-O341o-U=.c37b5ab0-5b13-4d86-adec-cb36c3975f31@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <WJeeAF8mUbfNMuRjvkHot-we7WoZXDY3iruMKiMPbRc=.74622925-401d-4e35-a5bd-064f2828ae6d@github.com>
 <HydpYe9Mj2UmwKV4pHteSURyQqoWtvZM1eA-O341o-U=.c37b5ab0-5b13-4d86-adec-cb36c3975f31@github.com>
Message-ID: <Nxo0gtsMqAxMhWWNAtpY6Dk69hRySJdMhUc2FoV4PEY=.ef6aed11-cab2-4afa-bee3-965df9ffa697@github.com>

On Thu, 13 Nov 2025 00:22:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   static field JLA
>
> src/java.base/share/classes/java/time/MonthDay.java line 753:
> 
>> 751:     @Override
>> 752:     public String toString() {
>> 753:         StringBuilder buf = new StringBuilder(10);
> 
> Why is this set to 10 instead of 7?

I suggest not making this change, as it is irrelevant to this PR.

> src/java.base/share/classes/java/time/YearMonth.java line 1201:
> 
>> 1199:     public String toString() {
>> 1200:         int absYear = Math.abs(year);
>> 1201:         StringBuilder buf = new StringBuilder(9);
> 
> I think 7 is better for most cases, right?

I suggest not making this change, as it is irrelevant to this PR.

> src/java.base/share/classes/java/time/ZoneOffset.java line 466:
> 
>> 464:         } else {
>> 465:             int absTotalSeconds = Math.abs(totalSeconds);
>> 466:             StringBuilder buf = new StringBuilder();
> 
> This can be pre-sized to 9 (or 7 if seconds is 0)

I suggest not making this change, as it is irrelevant to this PR.

> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 463:
> 
>> 461:      */
>> 462:     public static void appendPair(StringBuilder buf, int v) {
>> 463:         int packed = DIGITS[v & 0x7f];
> 
> We should assert v is in range so errors can be caught when we run tests. Same for appendQuad.

To maintain consistency with other putPair methods in DecimalDigits, trust the caller and do not perform assert checks, as assert checks can increase codeSize and potentially impact performance.

> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 484:
> 
>> 482:      */
>> 483:     public static void appendQuad(StringBuilder buf, int v) {
>> 484:         int y01 = v / 100;
> 
> Same assert bound check request

To maintain consistency with other putPair methods in DecimalDigits, trust the caller and do not perform assert checks, as assert checks can increase codeSize and potentially impact performance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2521259148
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2521259449
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2521259773
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2521265811
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2521266282

From liach at openjdk.org  Thu Nov 13 04:20:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Nov 2025 04:20:06 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v18]
In-Reply-To: <-aL1dZ7JL827EIaxfss_kcc_2aEb4DtxKNkmh5mzmeo=.b8cb47fb-32a2-42eb-a73a-2f5cbc74d52b@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <-aL1dZ7JL827EIaxfss_kcc_2aEb4DtxKNkmh5mzmeo=.b8cb47fb-32a2-42eb-a73a-2f5cbc74d52b@github.com>
Message-ID: <je6bMjE1Vp_FFIlnsWpXeBFMn6pJTfSkXyoLw1A9vvk=.df625b47-af73-411f-a5a1-af2fbaa84a24@github.com>

On Thu, 13 Nov 2025 04:07:45 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix codestyle
>  - digitQuad MergeStore & from @liach

test/jdk/jdk/internal/util/DecimalDigitsTest.java line 36:

> 34:  * @summary Test DecimalDigits.appendPair method with LATIN1 and UTF16 encoding
> 35:  * @modules java.base/jdk.internal.util
> 36:  * @run testng test.jdk.internal.util.DecimalDigitsTest

We recommend using junit for new tests.

test/jdk/jdk/internal/util/DecimalDigitsTest.java line 41:

> 39: 
> 40:     @Test
> 41:     public void testAppendPair() {

This duplicates testAppendPairWithLatin1Encoding and can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2521325209
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2521324512

From liach at openjdk.org  Thu Nov 13 04:36:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Nov 2025 04:36:17 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
 [v5]
In-Reply-To: <usMnDz0Y1oEQvmpPPhQPS1YA60pF5kM3vsvN2RGmErk=.38222a37-f315-497c-b8a3-36ff5310beb1@github.com>
References: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
 <usMnDz0Y1oEQvmpPPhQPS1YA60pF5kM3vsvN2RGmErk=.38222a37-f315-497c-b8a3-36ff5310beb1@github.com>
Message-ID: <nNRsT6_UI_dLAxWAgtlBwGoPk17fawZTatwblBv0rSA=.b73afab6-51ca-4250-8af4-ad22d0e5bab3@github.com>

On Thu, 13 Nov 2025 00:14:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> java.lang.reflect.Proxy has some surprising behaviors associated with protected methods in Object, covariant/contravariant overrides in interfaces, and package-private types in method signatures. Such behaviors should have tests, so that they are not accidentally perturbed in Proxy updates.
>
> Chen Liang 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 nine additional commits since the last revision:
> 
>  - Better comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>  - Update test/jdk/java/lang/reflect/Proxy/BridgeMethodsTest.java
>  - Consolidate duplicate tests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
>  - Tweaks
>  - 8370839: Tests to verify peculiar Proxy dispatching behaviors

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28023#issuecomment-3525293006

From liach at openjdk.org  Thu Nov 13 04:36:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Nov 2025 04:36:19 GMT
Subject: Integrated: 8370839: Tests to verify peculiar Proxy dispatching
 behaviors
In-Reply-To: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
References: <K7MBvTGqP5kFjrOez-SwIE7RGmYD3LmKEv-8i0GtWqE=.a4023631-42e4-419f-91d3-2c9d199a4386@github.com>
Message-ID: <Tm4IFWgVDXph04Tsx-ue4K1J3BF9ocMavz1Daj_0nrI=.94de8d0e-5b7a-4e09-8ed7-d1fba81d9583@github.com>

On Tue, 28 Oct 2025 16:53:26 GMT, Chen Liang <liach at openjdk.org> wrote:

> java.lang.reflect.Proxy has some surprising behaviors associated with protected methods in Object, covariant/contravariant overrides in interfaces, and package-private types in method signatures. Such behaviors should have tests, so that they are not accidentally perturbed in Proxy updates.

This pull request has now been integrated.

Changeset: 5f42c770
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f42c7708588db28f9c18bf63462001e99b35ec7
Stats:     348 lines in 3 files changed: 325 ins; 2 del; 21 mod

8370839: Tests to verify peculiar Proxy dispatching behaviors

Reviewed-by: jvernee

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

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

From swen at openjdk.org  Thu Nov 13 04:38:42 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 13 Nov 2025 04:38:42 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v19]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <cIB0UVq0YvYs_MdnoCW3Y3x3qKRSm5kSQqAD7fci6qo=.48aa8d85-6c17-4622-9eb8-b0e9ccf709bd@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove duplicates testAppendPairWithLatin1Encoding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/683e9483..70fc504e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=17-18

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

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

From duke at openjdk.org  Thu Nov 13 05:05:16 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Nov 2025 05:05:16 GMT
Subject: Withdrawn: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
Message-ID: <RB8Dc8Rxp9MPESxV7Y7-58YUz7Dd3sWdtoCoF0CWzs8=.59a522c0-e941-4ae0-9252-80d44a3336a3@github.com>

On Sun, 20 Jul 2025 22:19:07 GMT, simon <duke at openjdk.org> wrote:

> 8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/26406/head:pull/26406` \
> `$ git checkout pull/26406`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/26406` \
> `$ git pull https://git.openjdk.org/jdk.git pull/26406/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 26406`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 26406`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/26406.diff">https://git.openjdk.org/jdk/pull/26406.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/26406#issuecomment-3094832141)
> </details>

This pull request has been closed without being integrated.

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

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

From darcy at openjdk.org  Thu Nov 13 05:18:03 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 13 Nov 2025 05:18:03 GMT
Subject: RFR: 8371746: Some imports in Integer.java and Long.java became
 unused after JDK-8370503
In-Reply-To: <wwtlO_jYOA5VWK-jhLmVj1km86hzfAvei_PG_QvjYKw=.0757c681-ba75-41f3-a994-5fc107111582@github.com>
References: <wwtlO_jYOA5VWK-jhLmVj1km86hzfAvei_PG_QvjYKw=.0757c681-ba75-41f3-a994-5fc107111582@github.com>
Message-ID: <oLZoa5XwwbPFtRaKD2GgFOQ2_hZ2uoUBw5AhvqDXnS0=.c998c24c-7d82-4cda-a243-23369220773d@github.com>

On Wed, 12 Nov 2025 22:25:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Trivial patch. Removes unused imports from `Integer.java` and `Long.java` following [JDK-8370503](https://bugs.openjdk.org/browse/JDK-8370503).

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28277#pullrequestreview-3457460465

From iris at openjdk.org  Thu Nov 13 05:54:03 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 13 Nov 2025 05:54:03 GMT
Subject: RFR: 8371746: Some imports in Integer.java and Long.java became
 unused after JDK-8370503
In-Reply-To: <wwtlO_jYOA5VWK-jhLmVj1km86hzfAvei_PG_QvjYKw=.0757c681-ba75-41f3-a994-5fc107111582@github.com>
References: <wwtlO_jYOA5VWK-jhLmVj1km86hzfAvei_PG_QvjYKw=.0757c681-ba75-41f3-a994-5fc107111582@github.com>
Message-ID: <3J9rV0DlcRHwzAQKAXiVZgydkQ70pZF-PoVOjnR425Q=.79f7d20f-977c-4a0b-bc5e-f6cbe15b9e93@github.com>

On Wed, 12 Nov 2025 22:25:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Trivial patch. Removes unused imports from `Integer.java` and `Long.java` following [JDK-8370503](https://bugs.openjdk.org/browse/JDK-8370503).

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28277#pullrequestreview-3457611662

From swen at openjdk.org  Thu Nov 13 06:04:12 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 13 Nov 2025 06:04:12 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v18]
In-Reply-To: <je6bMjE1Vp_FFIlnsWpXeBFMn6pJTfSkXyoLw1A9vvk=.df625b47-af73-411f-a5a1-af2fbaa84a24@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <-aL1dZ7JL827EIaxfss_kcc_2aEb4DtxKNkmh5mzmeo=.b8cb47fb-32a2-42eb-a73a-2f5cbc74d52b@github.com>
 <je6bMjE1Vp_FFIlnsWpXeBFMn6pJTfSkXyoLw1A9vvk=.df625b47-af73-411f-a5a1-af2fbaa84a24@github.com>
Message-ID: <Y20qlyPJVQhMoFYIJ2kZ3sdrnRtVO-ODyu5x2PTvgOM=.eb91a68f-9dae-4181-acdf-86326b8d39c9@github.com>

On Thu, 13 Nov 2025 04:16:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix codestyle
>>  - digitQuad MergeStore & from @liach
>
> test/jdk/jdk/internal/util/DecimalDigitsTest.java line 36:
> 
>> 34:  * @summary Test DecimalDigits.appendPair method with LATIN1 and UTF16 encoding
>> 35:  * @modules java.base/jdk.internal.util
>> 36:  * @run testng test.jdk.internal.util.DecimalDigitsTest
> 
> We recommend using junit for new tests.

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;


Using JUnit 5 will cause an error:

/Users/wenshao/Work/git/jdk/test/jdk/jdk/internal/util/DecimalDigitsTest.java:27: error: package org.junit.jupiter.api does not exist
import static org.junit.jupiter.api.Assertions.assertEquals;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2521691404

From duke at openjdk.org  Thu Nov 13 06:46:51 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Thu, 13 Nov 2025 06:46:51 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v8]
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Fix StreamOpFlagsTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28226/files
  - new: https://git.openjdk.org/jdk/pull/28226/files/3f339ad9..9452d747

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28226&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28226&range=06-07

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

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

From alanb at openjdk.org  Thu Nov 13 07:09:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 07:09:03 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <yp9bE9rha3wVFpIbCFF12n7ZbqhPq053AROtCWCkQ48=.adb800fc-3807-45f1-93cd-9a1b395c3159@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
 <yp9bE9rha3wVFpIbCFF12n7ZbqhPq053AROtCWCkQ48=.adb800fc-3807-45f1-93cd-9a1b395c3159@github.com>
Message-ID: <jZbBEvmPeKvMMKgY-V9XzU9kqfYtJjpZOlLMGq-bOT4=.1e4c7eed-1c29-4a72-8a2f-da1cfcdf23e3@github.com>

On Tue, 11 Nov 2025 06:43:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.
>
> src/java.base/share/native/libjimage/imageFile.cpp line 334:
> 
>> 332:     // Memory map image (minimally the index.)
>> 333:     _index_data = (u1*)osSupport::map_memory(_fd, _name, 0, (size_t)map_size());
>> 334:     if (_index_data == nullptr) {
> 
> The rest of the code in the `libjimage` library uses `NULL`, including the return value in `osSupport::map_memory(...)`. So I think it would be better to use `NULL` here for consistency.

I agree, have a mix is annoying. In any case, changing the assert to have it fail looks right. The jimage file is opened during startup so less likely, but still possible, that this mmap fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28087#discussion_r2521919635

From alanb at openjdk.org  Thu Nov 13 07:21:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 07:21:03 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java
In-Reply-To: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
Message-ID: <_EaMoHXD1s157S3nVEF3wRG8Kv2gi08a540OAALaA4E=.4989ad67-c5a5-471d-8bbe-fe4c8fd9b5c7@github.com>

On Thu, 13 Nov 2025 02:31:31 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> In JDK 11, ThreadPoolExecutor.finalize() was specified to do nothing, leaving the finalize() method empty by [JDK-8371748](https://bugs.openjdk.org/browse/JDK-8371748), so I think it's safety to remove finalize() in testFinalizeMethodCallsSuperFinalize for test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java.
> 
> This PR also remove unnecessary '@SuppressWarnings("removal")' in test/jdk/java/util/concurrent/tck/JSR166TestCase.java and test/jdk/java/util/concurrent/tck/ExecutorsTest.java.
> 
> Change has been verified locally on linux-x64 by run test ava/util/concurrent/tck/JSR166TestCase.java#default. Test-fix only, no risk,

I think the changes in this PR are okay. I think it is time to remove TPE.finalize too (not this PR of course).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28278#issuecomment-3525980634

From hgreule at openjdk.org  Thu Nov 13 07:34:17 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 13 Nov 2025 07:34:17 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java
In-Reply-To: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
Message-ID: <40G2POBsmfbe-0dCfZ6XTAMEujQqeMx674_PXse8Bqc=.669ffe36-d5d2-4316-a105-b738424a14ec@github.com>

On Thu, 13 Nov 2025 02:31:31 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> In JDK 11, ThreadPoolExecutor.finalize() was specified to do nothing, leaving the finalize() method empty by [JDK-8371748](https://bugs.openjdk.org/browse/JDK-8371748), so I think it's safety to remove finalize() in testFinalizeMethodCallsSuperFinalize for test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java.
> 
> This PR also remove unnecessary '@SuppressWarnings("removal")' in test/jdk/java/util/concurrent/tck/JSR166TestCase.java and test/jdk/java/util/concurrent/tck/ExecutorsTest.java.
> 
> Change has been verified locally on linux-x64 by run test ava/util/concurrent/tck/JSR166TestCase.java#default. Test-fix only, no risk,

What does `testFinalizeMethodCallsSuperFinalize` test now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28278#issuecomment-3526053688

From syan at openjdk.org  Thu Nov 13 07:48:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Nov 2025 07:48:04 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java
In-Reply-To: <40G2POBsmfbe-0dCfZ6XTAMEujQqeMx674_PXse8Bqc=.669ffe36-d5d2-4316-a105-b738424a14ec@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
 <40G2POBsmfbe-0dCfZ6XTAMEujQqeMx674_PXse8Bqc=.669ffe36-d5d2-4316-a105-b738424a14ec@github.com>
Message-ID: <R2LxlJv4xEwkl_SOowCKaTA9klwxGZUHZOw6yr-Co9Y=.609db99d-f0e3-40fa-b6b3-51c9bb0858d5@github.com>

On Thu, 13 Nov 2025 07:31:13 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> What does `testFinalizeMethodCallsSuperFinalize` test now?

I have verified java/util/concurrent/tck/JSR166TestCase.java#default locally, test still run passed. Test java/util/concurrent/tck/JSR166TestCase.java#default will invoke all the junit tests in java/util/concurrent/tck directory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28278#issuecomment-3526125885

From cstein at openjdk.org  Thu Nov 13 08:39:37 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 13 Nov 2025 08:39:37 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v5]
In-Reply-To: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
Message-ID: <XfoQewk7-dEpabvrmUfS2X15_AW-qgCF7LHjL8cZJd4=.413cc204-6550-4eee-891b-0d3f591a3ff8@github.com>

> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Use dedicated error messages

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28154/files
  - new: https://git.openjdk.org/jdk/pull/28154/files/b7389cb6..99e8e320

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28154&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28154&range=03-04

  Stats: 19 lines in 3 files changed: 9 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28154/head:pull/28154

PR: https://git.openjdk.org/jdk/pull/28154

From cstein at openjdk.org  Thu Nov 13 08:45:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 13 Nov 2025 08:45:31 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v4]
In-Reply-To: <Ku-m9S6wTDv-AN8tZ2aYMtFp0ak6kzcfoNIm8SoYROQ=.0b4768c1-001f-47c9-ac88-1558c15225b3@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <D5VGiXjk-i01BJy3oN8TbGmQQ3fpwSo0iE8GToF83NY=.c2419065-5f17-4007-926e-dbf3ee885ada@github.com>
 <Ku-m9S6wTDv-AN8tZ2aYMtFp0ak6kzcfoNIm8SoYROQ=.0b4768c1-001f-47c9-ac88-1558c15225b3@github.com>
Message-ID: <jbbjLX0stYwwe9iOvIDPMuLxdJsuBzue6PvHUSxSrqo=.f701f84a-5d9f-4904-b59d-67285f7f16c3@github.com>

On Wed, 12 Nov 2025 14:55:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment to test
>
> test/jdk/tools/jar/ValidatorTest.java line 315:
> 
>> 313:     /**
>> 314:      * Validates that the LOC MANIFEST.MF entries are at the expected positions.
>> 315:      *
> 
> Thank you for adding a comment.  I might suggest adding a little more clarity or point to JarInputStream docs as the  Manifest Location for JarFile is not an issue. 
> 
> The issue boils down to the fact that JarInputStream walks the LOC sequentially and because of this there is the limitation on the location of where  the Manifest can live.
> 
> Not a big deal overall and I will leave it to you.  It is just no obvious to someone who is working in this area the 1st time as this issue is not directly related to the Zip specification, but is a JarInputStream limitation

Addressed both, better error messages and the test comment in https://github.com/openjdk/jdk/pull/28154/commits/99e8e3200beac1fea0d32df10d457416773283f3

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28154#discussion_r2522351147

From cnorrbin at openjdk.org  Thu Nov 13 09:05:32 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 13 Nov 2025 09:05:32 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <fF1hoR6uoYPtBN7Dy1V6wsoo3N6Yu69Ha_6qEOj9npI=.7a1c0dce-1c66-4a3a-936e-f134a45e7aae@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

LGTM

-------------

Marked as reviewed by cnorrbin (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3458531316

From jbhateja at openjdk.org  Thu Nov 13 09:31:03 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 13 Nov 2025 09:31:03 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer
In-Reply-To: <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
Message-ID: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>

On Wed, 12 Nov 2025 20:11:06 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.

Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3526715585

From jbhateja at openjdk.org  Thu Nov 13 09:31:04 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 13 Nov 2025 09:31:04 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer
In-Reply-To: <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
Message-ID: <15AReOBUAseO-BiCWHW7N-OSOcknDc0Box3c90cXRZU=.5d7341db-94ea-4cdf-b3cd-fabe414dd88d@github.com>

On Wed, 12 Nov 2025 19:48:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > > > Some quick comments.
> > > > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
> > > 
> > > 
> > > I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
> > 
> > 
> > There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.
> 
> Maybe we move the shape to the end e.g., `Float16Vector128`, `IntVector128`, `IntVectorMax`?

This looks good, since all these are concrete vector classes not exposed to users.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3526723445

From sgehwolf at openjdk.org  Thu Nov 13 10:05:25 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 13 Nov 2025 10:05:25 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <ho9I83ItEzD8807dKyFokWhJFoTGNAYL-iERqgO35lo=.2d687123-8174-4d01-a3f3-271e8b31b70e@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

Thanks for the review. I still need a review from a Reviewer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28157#issuecomment-3526909866

From duke at openjdk.org  Thu Nov 13 11:50:52 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Nov 2025 11:50:52 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <F6lKp85DrINoEMTbUJHY4jmexUwCBbubY1q79YetIIw=.420f05c4-88a1-492b-b894-e9a18aeefa16@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

Returning false here isn't an immediate hard-fail (unlike the assertion), so there is now a situation where `mmap()` failing will allow the VM startup code to continue running for longer than before.

In particular, having this return false means that `ClassLoader::lookup_vm_options()` returns false, and skips the parsing of options from the jimage file.

I'm not 100% clear if it would later fail, or just attempt to run in "exploded" mode, possibly yielding an unexpected/undefined state.

There are two methods in `ClassPathImageEntry` related to this:

`ClassPathImageEntry::jimage_non_null()` which will assert that the image was opened.
`ClassPathImageEntry::jimage()` which will not.

Depending on who calls these, and in what order, the JVM startup might now reach code it wouldn't have before when/if `mmap()` failed.

However this is no different to other ways in which the jimage open code can return false (esp. just not having the file there) so I don't think this, slight, change in possible behaviour incurs any more risk of getting into an odd state than was already present.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28087#pullrequestreview-3459404369

From jpai at openjdk.org  Thu Nov 13 12:08:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Nov 2025 12:08:46 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <u3g6m9KC-USpXhWGYAEF7B64o8sC048U5EXRDjMuA88=.d2acbf03-62da-473d-b53c-8a237e942856@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
 <hhpTt97mJhKq1xoZ0iVQ7hQPjCzvyo_-hMgc0LsmiZo=.247d98e8-8c50-41ac-8ba5-d31914aab06c@github.com>
 <KS5whSwzltSPsIO_QoLmQsij-l2uv6zH_KR9E3u8krU=.5c8c3369-c72d-4f06-8b48-bbd62021dfc4@github.com>
 <u3g6m9KC-USpXhWGYAEF7B64o8sC048U5EXRDjMuA88=.d2acbf03-62da-473d-b53c-8a237e942856@github.com>
Message-ID: <1VIe_2nVpu5ukGbis6X1kKk8Q7rq0C6rIJsPMvlNuFg=.cbdd73f1-bf34-42f9-b2ee-59da75252033@github.com>

On Wed, 12 Nov 2025 14:59:27 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> Do we need to create a bug to check the help output?
>
> Does not seem worth a backport, just noting this for the record.

I vaguely remember this text which says "-C" is valid in any mode was discussed (as an existing inaccuracy) when the changes in this PR were being discussed. But I can't find that discussion anywhere right now. I do think that we need to address this text issue for older releases since this text prominently shows up both in the help output as well as the man page for example https://docs.oracle.com/en/java/javase/21/docs/specs/man/jar.html#operation-modifiers-valid-in-any-mode. I'll file an issue shortly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/2752#discussion_r2523209954

From alanb at openjdk.org  Thu Nov 13 12:19:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 12:19:46 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <uBWv4fPeZCnDEdfvwSgAcACiC9oKD4Fe5mFGX7fh6sM=.8a9a6c11-3b27-4603-a638-a04f9baf20aa@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

In an images build, the VM has to fail during startup if the jimage file cannot be opened. Maybe @jcking could paste in the output from both release and fastdebug builds. It may be that it trips an assert earlier with debug builds.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28087#issuecomment-3527546988

From jpai at openjdk.org  Thu Nov 13 12:38:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Nov 2025 12:38:28 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <1VIe_2nVpu5ukGbis6X1kKk8Q7rq0C6rIJsPMvlNuFg=.cbdd73f1-bf34-42f9-b2ee-59da75252033@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
 <hhpTt97mJhKq1xoZ0iVQ7hQPjCzvyo_-hMgc0LsmiZo=.247d98e8-8c50-41ac-8ba5-d31914aab06c@github.com>
 <KS5whSwzltSPsIO_QoLmQsij-l2uv6zH_KR9E3u8krU=.5c8c3369-c72d-4f06-8b48-bbd62021dfc4@github.com>
 <u3g6m9KC-USpXhWGYAEF7B64o8sC048U5EXRDjMuA88=.d2acbf03-62da-473d-b53c-8a237e942856@github.com>
 <1VIe_2nVpu5ukGbis6X1kKk8Q7rq0C6rIJsPMvlNuFg=.cbdd73f1-bf34-42f9-b2ee-59da75252033@github.com>
Message-ID: <UzIzM1VDZU-IjHh3O3NCAWvlHclkZdjMnG88n5VYwTQ=.1598efb1-0b55-47af-9ab4-822e1ea46812@github.com>

On Thu, 13 Nov 2025 12:05:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Does not seem worth a backport, just noting this for the record.
>
> I vaguely remember this text which says "-C" is valid in any mode was discussed (as an existing inaccuracy) when the changes in this PR were being discussed. But I can't find that discussion anywhere right now. I do think that we need to address this text issue for older releases since this text prominently shows up both in the help output as well as the man page for example https://docs.oracle.com/en/java/javase/21/docs/specs/man/jar.html#operation-modifiers-valid-in-any-mode. I'll file an issue shortly.

I've filed https://bugs.openjdk.org/browse/JDK-8371796

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/2752#discussion_r2523298438

From lancea at openjdk.org  Thu Nov 13 12:41:04 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 13 Nov 2025 12:41:04 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v5]
In-Reply-To: <XfoQewk7-dEpabvrmUfS2X15_AW-qgCF7LHjL8cZJd4=.413cc204-6550-4eee-891b-0d3f591a3ff8@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <XfoQewk7-dEpabvrmUfS2X15_AW-qgCF7LHjL8cZJd4=.413cc204-6550-4eee-891b-0d3f591a3ff8@github.com>
Message-ID: <z6_Os6USFsGt4DIlWVDLAGulQfWQLuGa5URwGPTzaR8=.d086b2b0-ad69-4e88-a8e3-c211018a5e99@github.com>

On Thu, 13 Nov 2025 08:39:37 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dedicated error messages

thank you for the additional clarifications.  

I think we are in a good place

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28154#pullrequestreview-3459597265

From alanb at openjdk.org  Thu Nov 13 13:31:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 13:31:52 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v11]
In-Reply-To: <CbMHUboGTEm5WEWnHmGymb-rO9QVFU3c-QEsr0HeJlQ=.a711870b-91a3-4be0-8a78-814bfc649142@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
 <CbMHUboGTEm5WEWnHmGymb-rO9QVFU3c-QEsr0HeJlQ=.a711870b-91a3-4be0-8a78-814bfc649142@github.com>
Message-ID: <1QetBwPtcolO6_qPQSSRdSofa79BD4UNn9Ri68DGryo=.3dc36aee-0e70-4f88-a5e9-0ac0de3ed121@github.com>

On Wed, 12 Nov 2025 12:51:37 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
>> 
>>  - Remove dup end body tag
>>  - Change FinalFieldMutationEvent so that caller is top frame in stack trace
>>  - Merge branch 'master' into JDK-8353835
>>  - Review feedback: Add tests for setting internal properties, improve links in Mutation methods page
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Fix typo in test comment
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Suppress warnings from some tests
>>  - ... and 40 more: https://git.openjdk.org/jdk/compare/2902436f...b22947c7
>
> src/java.base/share/classes/java/lang/reflect/Field.java line 1543:
> 
>> 1541:      * the given possibly-null caller.
>> 1542:      */
>> 1543:     private String finalFieldMutationWarning(Class<?> caller, boolean unreflect) {
> 
> It may make sense to have this method return a StringBuilder instance (and use it internally before returning it) as that would cut down on extra String-instance creation.

We could but this is the slow path that prints the warning on the first final field mutation. So I think I'll keep it as simple as possible.

> src/java.base/share/man/java.md line 482:
> 
>> 480: 
>> 481:     -   `allow`: This mode allows illegal final field mutation in all modules,
>> 482:         without any warings.
> 
> Suggestion:
> 
>         without any warnings.

Well spotted, this text was copied down `--illegal-native-access` so I'll fix the typo in both places.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2523476042
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2523469262

From duke at openjdk.org  Thu Nov 13 14:03:09 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Nov 2025 14:03:09 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <30va--sx1H0YORpDccz1-rcaBpHX8znPZxuuMOhVc88=.758667f5-a4e4-4404-a539-053c95350cf3@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

If it must fail if the jimage file cannot be opened, that should mean it must fail when the file is not present, unless the existence of the file is what defines "an images build".

If "is an images build" is meant to be a synonym for "the jimage file exists on disk", then this change might create a case where one observer decides "the is an images build" (by looking for the file) but the JVM behaves as if it's an "exploded" build and loads classes from elsewhere (though equally, this might not be possible based on other code paths).

The jimage file existing on disk is something that the JVM build/installation controls, but whether mmap works is something the underlying system controls. This change conflates the two things in terms of subsequent behaviour, and I'm not 100% sure that's what we want.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28087#issuecomment-3527950696

From alanb at openjdk.org  Thu Nov 13 14:34:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 14:34:28 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <C3sfP53Os4AjDSJwxLZySSC9bkUeuR1Lc2_LjUEi1I0=.ee446ab6-0110-4330-9ef8-927a4d1b6df0@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

ClassLoader::setup_bootstrap_search_path_impl, and first use of ModuleFinder.ofSystem in early startup, attempt to stat lib/modules to determine if this is an images build. An images build is what jlink produces and always has a lib/modules file. When developers download a JDK it is an images build. In the JDK build itself there is an immediate "exploded" build but that isn't really used after the JDK is fully built. 

It would be good to exercise this code to see how VM startup behaves when JIMAGE_Open returns NULL. It's possible that the fastdebug build will trip on an assert early. For the exercise then it would be good to check both release and fastdebug builds.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28087#issuecomment-3528098276

From pminborg at openjdk.org  Thu Nov 13 14:53:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Nov 2025 14:53:55 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <YaemS3pEXZd3Aswn3m05QxiDtGZ9WId3B7pZ7L8x_U0=.6f5dde72-c521-4626-bfd3-bda7db0eb076@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <YaemS3pEXZd3Aswn3m05QxiDtGZ9WId3B7pZ7L8x_U0=.6f5dde72-c521-4626-bfd3-bda7db0eb076@github.com>
Message-ID: <3El5xX6_IHc9wF76OZZmrodvkHHDu2d50CZHbgAq49A=.8f035397-3566-496b-9ca3-46b8905238c0@github.com>

On Wed, 12 Nov 2025 13:26:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkCopy.java line 60:
> 
>> 58:     byte[] dstArray;
>> 59: 
>> 60:     public static class Array extends SegmentBulkCopy {
> 
> Should we use just one class for both arrays and byte buffers? Also, for those we don't test loops?

I think we have the Array variants there so that we can compare the speed against the other variants.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2523770365

From jvernee at openjdk.org  Thu Nov 13 15:02:42 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 13 Nov 2025 15:02:42 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <bLo02X4tAuKX9tAMsHFk1xw2dQGJ5PXFIb8FDtkUcbs=.e8f3267a-e3ef-4bcf-bfa0-5a21aaa0d3a8@github.com>

On Tue, 11 Nov 2025 14:11:28 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

I think what Maurizio is suggesting is probably the most flexible. We can assume that e.g. a 4 byte allocation is at least 4 byte aligned, and an 8 byte allocation is also at least 8 bytes aligned (which implies 4 byte alignment as well), up to a value equal to `alignof(max_align_t)`, which we currently assume to be 16 (though, we could have a native method that actually returns `alignof(max_align_t)`).

> Doesn't this assume that all malloc implementations follow power of 2 pattern of arena sizes: 8, 16, 32, 64 and pointer alignments between min and max? malloc could also be implemented skipping some of those intermediate sizes. e.g. 16, 64, 256.

If an 8 byte value is allocated in a 16 byte arena, I assume it is 16 byte aligned, which implies 8 byte alignment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3528212611

From duke at openjdk.org  Thu Nov 13 15:10:15 2025
From: duke at openjdk.org (jengebr)
Date: Thu, 13 Nov 2025 15:10:15 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v5]
In-Reply-To: <1M7QGkc_DoRJEGF4nQXShjdOfs-5rM0k4cnt5Ims73E=.156ea658-649b-4a20-88b6-6284eea3ef96@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <vSVVYdKkOvUOmmdFbICM87-yqIkBKShCnSUmt3sUsmo=.37a8728b-8e3a-4961-a84f-f179c93acec9@github.com>
 <1M7QGkc_DoRJEGF4nQXShjdOfs-5rM0k4cnt5Ims73E=.156ea658-649b-4a20-88b6-6284eea3ef96@github.com>
Message-ID: <ZqcCwk9brd7A2xxfqDFMr9ytkjRptAugh54Oe3R7OS8=.10843f8f-752b-4ff6-9b79-d601d5ca21f6@github.com>

On Thu, 13 Nov 2025 00:27:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> jengebr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace fixes
>
> test/jdk/java/util/Collection/MOAT.java line 890:
> 
>> 888:     }
>> 889: 
>> 890:     private static void testAddAll(Collection<Integer> c) {
> 
> Thanks for moving this test into MOAT. Overall it seems like a large reduction in test bulk, which simplifies a lot of things. Great!

Yes, thank you for pointing it out!  I overlooked its existence until you pointed me to it, I agree it's a a much better option.

> test/jdk/java/util/Collection/MOAT.java line 905:
> 
>> 903:         arraySource.add(99);
>> 904:         check(c.addAll(arraySource));
>> 905:         equal(new ArrayList<Integer>(c), arraySource);
> 
> Here and at line 913 it seems a bit odd to copy `c` into a new ArrayList to compare equality. I think it's trying to assert that `c` contains only the expected elements. Unfortunately `c` can be any collection, not just a List, and to use List equality it needs to be copied into an actual List. Doubly unfortunately, the new List will capture the encounter order of whatever collection `c` is, which might not be well-defined -- for example if `c` is a HashSet. So I don't think this is the right assertion. Probably a size check and a containsAll() check, as is done in the bottom case, is sufficient.

I'm curious, why not .equals() when we know the input is a List?  That is a stricter assertion because it ensures ordering remains unchanged.

Happy to make the change, though.

> test/jdk/java/util/Collection/MOAT.java line 922:
> 
>> 920:         check(c.addAll(arraySource));
>> 921:         equal(c.size(), sizeBefore + arraySource.size());
>> 922:         check(c.containsAll(arraySource));
> 
> As I said in another comment, this (size check and containsAll check) looks like a better set of assertions than using List equality as in the earlier test cases.
> 
> I'm confused about the scope of cases being covered here. It seems like there are potentially three different axes of cases that potentially could be tested:
> 
> 1) source is ArrayList / other kind of List
> 2) source is empty / not empty
> 3) destination is empty / not empty
> 
> That would indicate having eight test cases. That's kind of at the outer limit for hand-coded cases. At this point or beyond, having some automated case generation would be preferable. And this is MOAT and not JUnit, so test generation would have to be done _ad hoc_. I could imagine doing it in about the same amount of code (say 30 or fewer lines). But if you're not up for doing this, it's probably sufficient for this change to test just the ArrayList and non-ArrayList sources, since that should be sufficient to test the code path you're changing.

> At this point or beyond, having some automated case generation would be preferable. And this is MOAT and not JUnit, so test generation would have to be done ad hoc

Thank you!  I will reduce the testing to the dimension #1.  Your suggestion of a JUnit-based equivalent is excellent, I'll work it in sometime in the future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2523821114
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2523814719
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2523810534

From swen at openjdk.org  Thu Nov 13 15:12:03 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 13 Nov 2025 15:12:03 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v20]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <w6FwWosIcKTsC5cXLsoP1I804te0wFEIDUJq8olLJOA=.eef6670b-ed88-492c-b172-223836cf9def@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use JLA

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/70fc504e..458cfcdb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=18-19

  Stats: 62 lines in 4 files changed: 40 ins; 13 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

PR: https://git.openjdk.org/jdk/pull/26911

From pminborg at openjdk.org  Thu Nov 13 15:31:20 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Nov 2025 15:31:20 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <bIgA1--t6tdOLLaxohGIrZMk014aNtjEp0nzMZPAVTg=.444e08a9-45df-4352-90e4-7c4e8fb9a24c@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <bIgA1--t6tdOLLaxohGIrZMk014aNtjEp0nzMZPAVTg=.444e08a9-45df-4352-90e4-7c4e8fb9a24c@github.com>
Message-ID: <7QxTOeN3P7yhBzgg2U9T0MjHU4q6qBUCVTW-7HbeUJE=.bda3e9db-7acf-4af7-8b6a-b11496d7b76c@github.com>

On Wed, 12 Nov 2025 14:03:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkCopy.java line 160:
> 
>> 158:         public void copyUnsafe() {
>> 159:             MemorySegment.copy(srcSegment, 0, dstSegment, 0, size);
>> 160:         }
> 
> Shouldn't this method be using `Unsafe`? (similar for the other classes)

By setting the JVM-parameter to zero, the Unsafe variant is _always_ invoked.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2523907110

From duke at openjdk.org  Thu Nov 13 15:31:41 2025
From: duke at openjdk.org (jengebr)
Date: Thu, 13 Nov 2025 15:31:41 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations [v2]
In-Reply-To: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
Message-ID: <wdcyLaa8Y4Fb3FglCB9E3FiJRSQoQ8zCR2oHWBElzyw=.5f6b2d5d-4676-43cd-be68-586f4398f938@github.com>

> # HashMap.putAll() optimizations: Eliminating Megamorphic Call Site Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in `HashMap.putMapEntries()` by implementing direct optimizations for specific input types: `j.u.HashMap` and `j.u.Collections$UnmodifiableMap`. The optimizations target `HashMap(Map)` constructor and `putAll()` operations based on the real-world megamorphic behavior identified in [JDK-8368292](https://bugs.openjdk.org/browse/JDK-8368292), delivering significant performance improvements when multiple `Map` subtypes are used.
> 
> ## Problem Context
> 
> ### Megamorphic Call Site Overhead in Map Iteration
> `HashMap.putMapEntries()` currently uses a generic approach that suffers from megamorphic call site overhead when applications perform bulk creation or population of HashMaps from various source map types:
> 
> 1. `m.entrySet()` becomes megamorphic across different map implementations
> 2. `entrySet().iterator()` creates different iterator types
> 3. `entry.getKey()` and `entry.getValue()` calls vary by map type
> 4. Individual `putVal()` calls for each entry
> 
> When the source is `Collections$UnmodifiableMap`, the problem is compounded by megamorphic wrappers around the already-megamorphic iteration methods. In cases where the unwrapped map is also a HashMap, both the wrapper overhead and the iteration overhead can be eliminated with a single optimization.
> 
> ## Optimized Methods
> 
> ### HashMap
> - **`putMapEntries(Map<? extends K, ? extends V> m, boolean evict)`**: Added fast paths for UnmodifiableMap unwrapping and HashMap-to-HashMap copying
> - **`putMapEntries(HashMap<? extends K, ? extends V> src, boolean evict)`**: copies HashMap-to-HashMap via direct Node processing.  Avoids polymorphic issues and eliminates redundant calls to HashMap.hash().
> 
> ## Implementation Details
> 
> ### HashMap-to-HashMap Fast Path
> Directly iterates over `src.table` to eliminate entrySet() allocation and polymorphic iterator calls, using the internal Node structure for maximum efficiency.
> 
> ### UnmodifiableMap Unwrapping
> Detects UnmodifiableMap instances and accesses the underlying map directly via the `m` field, eliminating wrapper-induced megamorphic call sites. UnmodifiableMap visibility changed from `private` to package-private to enable this direct access.
> 
> ## Performance Impact
> 
> | Source Type | Size | Poisoned | Baseline | Optimized | Improvement |
> |-------------|------|----------|----------|-----------|-------------|
> | HashMap | 0 | true | 9.429 ns/op | 8.875 ns/op |...

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Unit test revisions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28243/files
  - new: https://git.openjdk.org/jdk/pull/28243/files/05891484..edfc6a2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28243&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28243&range=00-01

  Stats: 27 lines in 2 files changed: 7 ins; 11 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28243/head:pull/28243

PR: https://git.openjdk.org/jdk/pull/28243

From duke at openjdk.org  Thu Nov 13 15:32:07 2025
From: duke at openjdk.org (jengebr)
Date: Thu, 13 Nov 2025 15:32:07 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v6]
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <mQwxR0OSb6i3goJN42FBX8wFBO-DpDsYmB46finyZew=.6e993328-1833-4994-86a3-3515d2928f38@github.com>

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Unit test revisions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28116/files
  - new: https://git.openjdk.org/jdk/pull/28116/files/dd713ae0..49b43473

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28116&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28116&range=04-05

  Stats: 26 lines in 1 file changed: 0 ins; 13 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28116/head:pull/28116

PR: https://git.openjdk.org/jdk/pull/28116

From henryjen at openjdk.org  Thu Nov 13 15:42:16 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 13 Nov 2025 15:42:16 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v6]
In-Reply-To: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
Message-ID: <Fqz-O49viidm3VtmuD4mAq6WRyh4scFpK76IwIiUP6c=.06ce4cf7-7c37-42fd-977f-d227d737d84a@github.com>

> This PR include build changes from @magicus and jlink change to verify the build signature.
> 
> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
> 
> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>                                                                                                                                                                  
> ? java --version
> openjdk 26-internal 2026-03-17
> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>                                                                                                                                                                  
> ? jlink --version                                                                       
> 26-internal
>                                                                                                                                                                  
> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>                                                                                                                                                                  
> ? jlink --add-modules java.base --output macos
>                                                             
> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>                                                                                                                                                                  
> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Update the error message when not finding release signature

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28155/files
  - new: https://git.openjdk.org/jdk/pull/28155/files/0f1c9351..fa30f2c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=04-05

  Stats: 20 lines in 2 files changed: 5 ins; 7 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155

PR: https://git.openjdk.org/jdk/pull/28155

From asemenyuk at openjdk.org  Thu Nov 13 16:16:25 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 13 Nov 2025 16:16:25 GMT
Subject: RFR: 8364560: The default value of --linux-menu-group option is
 invalid
In-Reply-To: <omkPvg49OSxKbMngN3yrBo6DPHHEb9A6AozyYz3Y_dw=.d5588ec5-42ac-43e2-ac32-ceaadf6f7af8@github.com>
References: <omkPvg49OSxKbMngN3yrBo6DPHHEb9A6AozyYz3Y_dw=.d5588ec5-42ac-43e2-ac32-ceaadf6f7af8@github.com>
Message-ID: <ZjczBX-lxSq10ikaM9rHe29dR0FlsaNmwrghgJ-yQoc=.74587535-bae8-4657-8c08-bef53122f026@github.com>

On Thu, 13 Nov 2025 15:58:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Set the default value of the "Categories" key in .desktop files to "Utility".
>   - The value of the "Categories" key is an ID, not a localizable string. This is why the "param.menu-group.default" localization key was removed.
> - Add a test for the "--linux-menu-group" option.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28298#issuecomment-3528545201

From asemenyuk at openjdk.org  Thu Nov 13 16:16:24 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 13 Nov 2025 16:16:24 GMT
Subject: RFR: 8364560: The default value of --linux-menu-group option is
 invalid
Message-ID: <omkPvg49OSxKbMngN3yrBo6DPHHEb9A6AozyYz3Y_dw=.d5588ec5-42ac-43e2-ac32-ceaadf6f7af8@github.com>

- Set the default value of the "Categories" key in .desktop files to "Utility".
  - The value of the "Categories" key is an ID, not a localizable string. This is why the "param.menu-group.default" localization key was removed.
- Add a test for the "--linux-menu-group" option.

-------------

Commit messages:
 - 8364560: The default value of --linux-menu-group option is invalid

Changes: https://git.openjdk.org/jdk/pull/28298/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364560
  Stats: 45 lines in 5 files changed: 33 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28298/head:pull/28298

PR: https://git.openjdk.org/jdk/pull/28298

From swen at openjdk.org  Thu Nov 13 16:08:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 13 Nov 2025 16:08:15 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v21]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <yjwd5h_QiaXwr-Y0A_kzrAIpthTt7KJapLMj4XoYhzI=.0fb0a41f-d960-4c36-962c-0c7486d03334@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/458cfcdb..57ef68f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=19-20

  Stats: 26 lines in 2 files changed: 26 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

PR: https://git.openjdk.org/jdk/pull/26911

From lmesnik at openjdk.org  Thu Nov 13 16:23:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Nov 2025 16:23:43 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <gKV9TIOUce_DKfwYB8-NOBT9dpTicD1cvTgHbDFv1IM=.7d75578d-96fe-4879-9041-6a3994b9f0c4@github.com>

On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3460609576

From mbaesken at openjdk.org  Thu Nov 13 16:29:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Nov 2025 16:29:11 GMT
Subject: RFR: 8371608: Jtreg test jdk/internal/vm/Continuation/Fuzz.java
 sometimes fails with (fast)debug binaries
In-Reply-To: <nRBH7HkrI2R4VW0m0I4RdT1xBexRyBpC7TkGh1-SMMM=.79e4eb76-c3d0-461e-b837-24977b86d5f9@github.com>
References: <nRBH7HkrI2R4VW0m0I4RdT1xBexRyBpC7TkGh1-SMMM=.79e4eb76-c3d0-461e-b837-24977b86d5f9@github.com>
Message-ID: <LWInlKoETTW67ZoYyfLkuDYquqK8SzrymiJTmxyhclg=.808f65de-e92d-4d91-91f6-a1230df5685a@github.com>

On Wed, 12 Nov 2025 13:36:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test jdk/internal/vm/Continuation/Fuzz.java with (fast)debug binaries, we see timeouts like these on multiple platforms :
> 
> 
> jdk/internal/vm/Continuation/Fuzz_preserve-fp on Linux x86_64 :
> 
> java.lang.AssertionError: Failed to compile int Fuzz.com_int(int,int) in 45000ms
> at Fuzz.waitForCompilation(Fuzz.java:323)
> at Fuzz.compile(Fuzz.java:357)
> at Fuzz.testTrace(Fuzz.java:214)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:186)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
> at java.base/java.nio.file.FileChannelLinesSpliterator.forEachRemaining(FileChannelLinesSpliterator.java:130)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176)
> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265)
> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:632)
> at Fuzz.testStream(Fuzz.java:204)
> at Fuzz.testFile(Fuzz.java:189)
> at Fuzz.runTests(Fuzz.java:111)
> at Fuzz.main(Fuzz.java:105)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> Probably it makes sense to increase the COMPILATION_TIMEOUT when running with (fast)debug binaries.

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28267#issuecomment-3528607453

From mbaesken at openjdk.org  Thu Nov 13 16:29:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Nov 2025 16:29:12 GMT
Subject: Integrated: 8371608: Jtreg test jdk/internal/vm/Continuation/Fuzz.java
 sometimes fails with (fast)debug binaries
In-Reply-To: <nRBH7HkrI2R4VW0m0I4RdT1xBexRyBpC7TkGh1-SMMM=.79e4eb76-c3d0-461e-b837-24977b86d5f9@github.com>
References: <nRBH7HkrI2R4VW0m0I4RdT1xBexRyBpC7TkGh1-SMMM=.79e4eb76-c3d0-461e-b837-24977b86d5f9@github.com>
Message-ID: <YPxEmNKhWyjjkH9d1Izl8pwvrSKQB4Wsne62OYEy6As=.fd1bb50f-dec4-4ad9-a9f5-de7e9449cf34@github.com>

On Wed, 12 Nov 2025 13:36:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test jdk/internal/vm/Continuation/Fuzz.java with (fast)debug binaries, we see timeouts like these on multiple platforms :
> 
> 
> jdk/internal/vm/Continuation/Fuzz_preserve-fp on Linux x86_64 :
> 
> java.lang.AssertionError: Failed to compile int Fuzz.com_int(int,int) in 45000ms
> at Fuzz.waitForCompilation(Fuzz.java:323)
> at Fuzz.compile(Fuzz.java:357)
> at Fuzz.testTrace(Fuzz.java:214)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:186)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
> at java.base/java.nio.file.FileChannelLinesSpliterator.forEachRemaining(FileChannelLinesSpliterator.java:130)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176)
> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265)
> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:632)
> at Fuzz.testStream(Fuzz.java:204)
> at Fuzz.testFile(Fuzz.java:189)
> at Fuzz.runTests(Fuzz.java:111)
> at Fuzz.main(Fuzz.java:105)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> Probably it makes sense to increase the COMPILATION_TIMEOUT when running with (fast)debug binaries.

This pull request has now been integrated.

Changeset: bfc048ab
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfc048aba6391d52c07d9a5146466b47d2f6fed8
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8371608: Jtreg test  jdk/internal/vm/Continuation/Fuzz.java sometimes fails with (fast)debug binaries

Reviewed-by: mdoerr, rrich

-------------

PR: https://git.openjdk.org/jdk/pull/28267

From duke at openjdk.org  Thu Nov 13 16:43:49 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 13 Nov 2025 16:43:49 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v21]
In-Reply-To: <yjwd5h_QiaXwr-Y0A_kzrAIpthTt7KJapLMj4XoYhzI=.0fb0a41f-d960-4c36-962c-0c7486d03334@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <yjwd5h_QiaXwr-Y0A_kzrAIpthTt7KJapLMj4XoYhzI=.0fb0a41f-d960-4c36-962c-0c7486d03334@github.com>
Message-ID: <rM7l2dHpqGhodam52Ud5DDK_Wuu3bEgVkmjN0t9REo4=.10a0ec00-70f9-4815-a4c5-c6d6bb2901ee@github.com>

On Thu, 13 Nov 2025 16:08:15 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

src/java.base/share/classes/java/time/MonthDay.java line 758:

> 756:         buf.append('-');
> 757:         DecimalDigits.appendPair(buf, day);
> 758:         return buf.toString();

Why not

    byte[] bytes = new byte[7];
	bytes[0] = (byte)'-';
	bytes[1] = (byte)'-';
	DecimalDigits.appendPair(bytes, 2, month); // TBD
	bytes[4] = (byte)'-';
	DecimalDigits.appendPair(bytes, 5, month);
	return JLA.uncheckedNewStringWithLatin1Bytes(bytes);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2524176126

From kurt at openjdk.org  Thu Nov 13 17:05:25 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Thu, 13 Nov 2025 17:05:25 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <bLo02X4tAuKX9tAMsHFk1xw2dQGJ5PXFIb8FDtkUcbs=.e8f3267a-e3ef-4bcf-bfa0-5a21aaa0d3a8@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <bLo02X4tAuKX9tAMsHFk1xw2dQGJ5PXFIb8FDtkUcbs=.e8f3267a-e3ef-4bcf-bfa0-5a21aaa0d3a8@github.com>
Message-ID: <a3ZZS5ivq3jGwBtoxJiKEvFWJdnNXNBVcw5WKFwijvw=.5abeec4d-4db5-44a3-86e2-4ac64c7fe283@github.com>

On Thu, 13 Nov 2025 14:59:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I think what Maurizio is suggesting is probably the most flexible. We can assume that e.g. a 4 byte allocation is at least 4 byte aligned, and an 8 byte allocation is also at least 8 bytes aligned (which implies 4 byte alignment as well), up to a value equal to `alignof(max_align_t)`, which we currently assume to be 16 (though, we could have a native method that actually returns `alignof(max_align_t)`).

I see now. This makes sense to me. Thank you for explaining it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3528802206

From rriggs at openjdk.org  Thu Nov 13 17:11:18 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Nov 2025 17:11:18 GMT
Subject: RFR: 8371821: Duplicate export of jdk.internal.util to java.net.http
Message-ID: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>

Remove duplicate export of jdk.internal.util to java.net.http.

-------------

Commit messages:
 - 8371821: Duplicate export of jdk.internal.util to java.net.http

Changes: https://git.openjdk.org/jdk/pull/28301/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28301&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371821
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28301/head:pull/28301

PR: https://git.openjdk.org/jdk/pull/28301

From naoto at openjdk.org  Thu Nov 13 17:17:14 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Nov 2025 17:17:14 GMT
Subject: RFR: 8371821: Duplicate export of jdk.internal.util to
 java.net.http
In-Reply-To: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
References: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
Message-ID: <qrD3uE6MqIZTqPfjAtkMNw29d0gXV3lNzGv55tS2wLM=.4c8c6184-a61b-4072-99f1-0fdf69d447c1@github.com>

On Thu, 13 Nov 2025 17:04:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove duplicate export of jdk.internal.util to java.net.http.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28301#pullrequestreview-3460838897

From alanb at openjdk.org  Thu Nov 13 17:17:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 17:17:15 GMT
Subject: RFR: 8371821: Duplicate export of jdk.internal.util to
 java.net.http
In-Reply-To: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
References: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
Message-ID: <edzrwTO_9sNnceHFqLdDXW1fJT0vT94MmD3KnTDpTbQ=.8658fbc7-7478-48ba-9635-35210b7ca3da@github.com>

On Thu, 13 Nov 2025 17:04:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove duplicate export of jdk.internal.util to java.net.http.

Looks fine.

Do you mind digging into if we have a javac issue or is the GenModuleInfoSource tool in the build masking this as it generates the module-info.java that is compiled.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28301#pullrequestreview-3460839070
PR Comment: https://git.openjdk.org/jdk/pull/28301#issuecomment-3528860948

From dfuchs at openjdk.org  Thu Nov 13 17:35:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 17:35:40 GMT
Subject: RFR: 8371821: Duplicate export of jdk.internal.util to
 java.net.http
In-Reply-To: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
References: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
Message-ID: <qYNw6SPKGW8XZrEmdLgzRI2mV_bsaywORxRSFmJjkNs=.a423a53d-2240-4d20-8d62-19e233a1a4fa@github.com>

On Thu, 13 Nov 2025 17:04:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove duplicate export of jdk.internal.util to java.net.http.

LGTM.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28301#pullrequestreview-3460918328

From rriggs at openjdk.org  Thu Nov 13 18:38:21 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Nov 2025 18:38:21 GMT
Subject: RFR: 8371821: Duplicate export of jdk.internal.util to
 java.net.http
In-Reply-To: <edzrwTO_9sNnceHFqLdDXW1fJT0vT94MmD3KnTDpTbQ=.8658fbc7-7478-48ba-9635-35210b7ca3da@github.com>
References: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
 <edzrwTO_9sNnceHFqLdDXW1fJT0vT94MmD3KnTDpTbQ=.8658fbc7-7478-48ba-9635-35210b7ca3da@github.com>
Message-ID: <9c0IkPnDoQ0SqIbliRa08xnd1Q3oIAfzpupO1FMrxnQ=.b8098797-ed59-4237-a68f-02aea33741a6@github.com>

On Thu, 13 Nov 2025 17:14:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do you mind digging into if we have a javac issue or is the GenModuleInfoSource tool in the build masking this as it generates the module-info.java that is compiled.

It appears that GenModuleInfoSource does not check for duplicates. 
Targets are accumulated to a Set<String> and duplicates are ignored.
Created [JDK-8371851](https://bugs.openjdk.org/browse/JDK-8371851) to track any followup.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28301#issuecomment-3529166483

From pminborg at openjdk.org  Thu Nov 13 18:42:36 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Nov 2025 18:42:36 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v2]
In-Reply-To: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
Message-ID: <V55raivd_O60gWUqkcnE9OKZbRU9Ie63ckJRQJKDF4A=.ddbe3874-9038-44ec-8b00-6fa6fa8eab78@github.com>

> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
> 
> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
> 
> It should be noted that with this change, the running time for the benchmarks would increase significantly.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Remove lingering comment
 - Refactor and use long arrays
 - Remove BulkOps

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28260/files
  - new: https://git.openjdk.org/jdk/pull/28260/files/faaedb93..ab303deb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28260&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28260&range=00-01

  Stats: 441 lines in 5 files changed: 46 ins; 353 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/28260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28260/head:pull/28260

PR: https://git.openjdk.org/jdk/pull/28260

From serb at openjdk.org  Thu Nov 13 18:44:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 13 Nov 2025 18:44:13 GMT
Subject: Integrated: 8371746: Some imports in Integer.java and Long.java became
 unused after JDK-8370503
In-Reply-To: <wwtlO_jYOA5VWK-jhLmVj1km86hzfAvei_PG_QvjYKw=.0757c681-ba75-41f3-a994-5fc107111582@github.com>
References: <wwtlO_jYOA5VWK-jhLmVj1km86hzfAvei_PG_QvjYKw=.0757c681-ba75-41f3-a994-5fc107111582@github.com>
Message-ID: <YUu8Sri3gMiHm2ZxNel-vzCq5iN4MIelHsRwlIidFGk=.d91a4656-fd00-4cd6-8c48-af68353b9ca5@github.com>

On Wed, 12 Nov 2025 22:25:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Trivial patch. Removes unused imports from `Integer.java` and `Long.java` following [JDK-8370503](https://bugs.openjdk.org/browse/JDK-8370503).

This pull request has now been integrated.

Changeset: d09a8cb8
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d09a8cb81b70a6c51ef5599bee04f1445a48e63f
Stats:     4 lines in 2 files changed: 0 ins; 4 del; 0 mod

8371746: Some imports in Integer.java and Long.java became unused after JDK-8370503

Reviewed-by: liach, darcy, iris

-------------

PR: https://git.openjdk.org/jdk/pull/28277

From jvernee at openjdk.org  Thu Nov 13 19:02:32 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 13 Nov 2025 19:02:32 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v2]
In-Reply-To: <V55raivd_O60gWUqkcnE9OKZbRU9Ie63ckJRQJKDF4A=.ddbe3874-9038-44ec-8b00-6fa6fa8eab78@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <V55raivd_O60gWUqkcnE9OKZbRU9Ie63ckJRQJKDF4A=.ddbe3874-9038-44ec-8b00-6fa6fa8eab78@github.com>
Message-ID: <k1gJzhoN-8ThPyPjHtAgq7TgqhSfC15fa4pLRJccIH8=.0010e016-560b-4201-99a5-2f1ebbb3aa83@github.com>

On Thu, 13 Nov 2025 18:42:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove lingering comment
>  - Refactor and use long arrays
>  - Remove BulkOps

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkCopy.java line 122:

> 120:                     var s = MemorySegment.ofArray(baseArray);
> 121:                     srcSegment = Arena.ofAuto().allocateFrom(JAVA_LONG, s, JAVA_LONG, 0L, baseArray.length);
> 122:                     dstSegment = Arena.ofAuto().allocateFrom(JAVA_LONG, s, JAVA_LONG, 0L, baseArray.length);

You can use the other overload that accepts a long[]:

Suggestion:

                    srcSegment = Arena.ofAuto().allocateFrom(JAVA_LONG, baseArray);
                    dstSegment = Arena.ofAuto().allocateFrom(JAVA_LONG, baseArray);

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java line 114:

> 112:             segment = switch (SegmentType.valueOf(segmentType)) {
> 113:                 case HEAP   -> heapSegment;
> 114:                 case NATIVE -> Arena.ofAuto().allocateFrom(JAVA_LONG, heapSegment, JAVA_LONG, 0L, baseArray.length);

Suggestion:

                case NATIVE -> Arena.ofAuto().allocateFrom(JAVA_LONG, baseArray);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2524593943
PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2524598903

From jvernee at openjdk.org  Thu Nov 13 19:02:32 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 13 Nov 2025 19:02:32 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v2]
In-Reply-To: <k1gJzhoN-8ThPyPjHtAgq7TgqhSfC15fa4pLRJccIH8=.0010e016-560b-4201-99a5-2f1ebbb3aa83@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <V55raivd_O60gWUqkcnE9OKZbRU9Ie63ckJRQJKDF4A=.ddbe3874-9038-44ec-8b00-6fa6fa8eab78@github.com>
 <k1gJzhoN-8ThPyPjHtAgq7TgqhSfC15fa4pLRJccIH8=.0010e016-560b-4201-99a5-2f1ebbb3aa83@github.com>
Message-ID: <GSllEt_QEGRWRue4X-Brb652IWkw-WBquYWnyuvLMxg=.d72e8806-1da0-47b2-a4e1-9912f3ff14ef@github.com>

On Thu, 13 Nov 2025 18:58:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove lingering comment
>>  - Refactor and use long arrays
>>  - Remove BulkOps
>
> test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java line 114:
> 
>> 112:             segment = switch (SegmentType.valueOf(segmentType)) {
>> 113:                 case HEAP   -> heapSegment;
>> 114:                 case NATIVE -> Arena.ofAuto().allocateFrom(JAVA_LONG, heapSegment, JAVA_LONG, 0L, baseArray.length);
> 
> Suggestion:
> 
>                 case NATIVE -> Arena.ofAuto().allocateFrom(JAVA_LONG, baseArray);

(and same for the other 2)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2524601213

From rriggs at openjdk.org  Thu Nov 13 19:11:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Nov 2025 19:11:16 GMT
Subject: Integrated: 8371821: Duplicate export of jdk.internal.util to
 java.net.http
In-Reply-To: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
References: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
Message-ID: <M-FZYp8xivTSEjXwb5LrIK6_wEBEHIbUG-2fjM2wBiw=.ecd56cbf-81ad-44c0-ad3b-816ea4f3baa3@github.com>

On Thu, 13 Nov 2025 17:04:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove duplicate export of jdk.internal.util to java.net.http.

This pull request has now been integrated.

Changeset: 6322aaba
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6322aaba63b235cb6c73d23a932210af318404ec
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8371821: Duplicate export of jdk.internal.util to java.net.http

Reviewed-by: naoto, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/28301

From haraldei at openjdk.org  Thu Nov 13 19:12:41 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Thu, 13 Nov 2025 19:12:41 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Harald Eilertsen has updated the pull request incrementally with two additional commits since the last revision:

 - Second try to fix alignment for native segments
   
   Introducing a helper function as suggested by JornVernee to decide on
   the proper alignment based on the segment size.
   
   This work was sponsored by: The FreeBSD Foundation
   
   Co-authored-by: JornVernee
 - Test that native segments don't overlap
   
   This work was sponsored by: The FreeBSD Foundation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28235/files
  - new: https://git.openjdk.org/jdk/pull/28235/files/0d1bb665..2b8266f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=00-01

  Stats: 24 lines in 2 files changed: 17 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28235/head:pull/28235

PR: https://git.openjdk.org/jdk/pull/28235

From haraldei at openjdk.org  Thu Nov 13 19:21:17 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Thu, 13 Nov 2025 19:21:17 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <bLo02X4tAuKX9tAMsHFk1xw2dQGJ5PXFIb8FDtkUcbs=.e8f3267a-e3ef-4bcf-bfa0-5a21aaa0d3a8@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <bLo02X4tAuKX9tAMsHFk1xw2dQGJ5PXFIb8FDtkUcbs=.e8f3267a-e3ef-4bcf-bfa0-5a21aaa0d3a8@github.com>
Message-ID: <h276onyWjMAP9iXk1ovbjhJRb2ckjmGTBAmSYFCUp6k=.2a026cfa-1679-4c25-ad4b-078dde9e0f40@github.com>

On Thu, 13 Nov 2025 14:59:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> I think what Maurizio is suggesting is probably the most flexible. We can assume that e.g. a 4 byte allocation is at least 4 byte aligned, and an 8 byte allocation is also at least 8 bytes aligned (which implies 4 byte alignment as well), up to a value equal to `alignof(max_align_t)`, which we currently assume to be 16 (though, we could have a native method that actually returns `alignof(max_align_t)`).
> 
>> Doesn't this assume that all malloc implementations follow power of 2 pattern of arena sizes: 8, 16, 32, 64 and pointer alignments between min and max? malloc could also be implemented skipping some of those intermediate sizes. e.g. 16, 64, 256.
> 
> If an 8 byte value is allocated in a 16 byte arena, I assume it is 16 byte aligned, which implies 8 byte alignment.

I've pushed a new version now, by adding a helper function as suggested by @JornVernee, but if you want I can have another go with @mcimadamore's suggestion as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3529336594

From rriggs at openjdk.org  Thu Nov 13 19:43:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Nov 2025 19:43:06 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v21]
In-Reply-To: <yjwd5h_QiaXwr-Y0A_kzrAIpthTt7KJapLMj4XoYhzI=.0fb0a41f-d960-4c36-962c-0c7486d03334@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <yjwd5h_QiaXwr-Y0A_kzrAIpthTt7KJapLMj4XoYhzI=.0fb0a41f-d960-4c36-962c-0c7486d03334@github.com>
Message-ID: <Nd6o45yQAG362WDI_b_P6oLqztU7YqF4cDdwKjhFEXA=.4bfd6592-4c88-403d-8199-e06d9c8cad1e@github.com>

On Thu, 13 Nov 2025 16:08:15 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Up until the introduction of new JLA methods, this PR was looking good.
Do not add new JavaLangAccess methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3529425850

From psandoz at openjdk.org  Thu Nov 13 19:51:03 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 13 Nov 2025 19:51:03 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer
In-Reply-To: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
Message-ID: <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>

On Thu, 13 Nov 2025 09:25:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
> 
> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable

I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3529452461

From henryjen at openjdk.org  Thu Nov 13 19:59:47 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 13 Nov 2025 19:59:47 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v7]
In-Reply-To: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
Message-ID: <corgjVt6hvXqeusBDA6U-1QURvQieTjwwB3wzyhcvRY=.00ad2ed8-415c-4dbf-a9a1-eda4cd357f39@github.com>

> This PR include build changes from @magicus and jlink change to verify the build signature.
> 
> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
> 
> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>                                                                                                                                                                  
> ? java --version
> openjdk 26-internal 2026-03-17
> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>                                                                                                                                                                  
> ? jlink --version                                                                       
> 26-internal
>                                                                                                                                                                  
> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>                                                                                                                                                                  
> ? jlink --add-modules java.base --output macos
>                                                             
> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>                                                                                                                                                                  
> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  remove the extra space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28155/files
  - new: https://git.openjdk.org/jdk/pull/28155/files/fa30f2c2..5fb443b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155

PR: https://git.openjdk.org/jdk/pull/28155

From henryjen at openjdk.org  Thu Nov 13 19:59:48 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 13 Nov 2025 19:59:48 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v4]
In-Reply-To: <rQmuFmMFBE6bQPrfK1h5hzEoxGY1nmMnU_SCtan1RHU=.72790468-29c7-4f4d-9481-48642a744370@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <KqfDGq0VD6tVxm6hsjzaYkP2fTaHkehw394ZAq2qJG8=.f38f4e73-9cfe-4581-8016-ae2bb3b4662f@github.com>
 <VpxU4VbRHEOB1lboXmxqgp-aMGqvJ3Do2Md_j3DKeBk=.4e073851-01d2-4145-bf8d-dbe5c43069ed@github.com>
 <HnoobwuLz2v674j1Md6-bGccJOOID-SPKk91Ot3MOS8=.2b72df9f-7de9-41f0-afc4-411b95d65178@github.com>
 <bMfPBB44qiZYQFudEH6Anr7hYjHtehleU-B31K5C9yc=.8d6e1ce9-f074-43b5-95e4-cf827d2293a4@github.com>
 <rpFZEyo6gxOQ-Edt5hlZd9bCO4Dx8Tk7eUIHkt3mjJI=.23d08ced-51d3-4cf8-a878-1449b410adc1@github.com>
 <rQmuFmMFBE6bQPrfK1h5hzEoxGY1nmMnU_SCtan1RHU=.72790468-29c7-4f4d-9481-48642a744370@github.com>
Message-ID: <M2YHGUKQFkUadgElN8SnNrbnhtzMhXQaMqVlqXsgI7c=.e5a4172d-527a-497b-b74a-1024f509e9d8@github.com>

On Tue, 11 Nov 2025 18:52:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the latest update, the message is like
>> 
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build
>
> It kinda works but a different message to say that the release info from the java.base module is not present might be clearer. Maybe it can include something "older JDK release?" or something to give a clue.

Message updated with latest commit as proposed in the CSR.

$ jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25
Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 cannot find the build signature in the java.base specified on module path, likely from an earlier build.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2524746666

From rriggs at openjdk.org  Thu Nov 13 20:19:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Nov 2025 20:19:04 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure [v2]
In-Reply-To: <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
 <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>
Message-ID: <uqNcE0HWXoJIrGVcLa7cyp7qcUxYu5bD6DJd6j9itwI=.598ba078-b90d-42cd-9e0f-4ec8bf7ed7c2@github.com>

On Wed, 12 Nov 2025 12:24:39 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Rewrite of VerifyJimage test to fix several severe issues.
>> 
>> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
>> 
>> Issue 1: Broken file comparison
>> 
>> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
>> 
>> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
>> 
>> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
>> 
>> Issue 2: Use of BasicImageReader for class file reading
>> 
>> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
>> 
>> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
>> 
>> Issue 3: File comparison mode was never run by default
>> 
>> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaked path to class name handling for clarity

test/jdk/tools/jimage/VerifyJimage.java line 311:

> 309:         private void loadClass(String cn, ClassLoader loader) {
> 310:             try {
> 311:                 System.out.println("Loading " + cn);

Printing the successful class names isn't very useful, (even if it was previously).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28265#discussion_r2524812610

From asemenyuk at openjdk.org  Thu Nov 13 20:31:45 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 13 Nov 2025 20:31:45 GMT
Subject: RFR: 8369206: jpackage should not set R/O permission on app launchers
Message-ID: <mMYLwg4kM8nmxEKP3mwkJEpt3N-jUR8ycBgGO2QfkRU=.fd19f6e3-d2c1-490a-922b-fde4bcf412a1@github.com>

- Remove redundant `setWritable(true, true)` / `setReadOnly()` pair in the code updating resources of launchers on Windows

-------------

Commit messages:
 - 8369206: jpackage should not set R/O permission on app launchers

Changes: https://git.openjdk.org/jdk/pull/28305/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28305&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369206
  Stats: 38 lines in 1 file changed: 4 ins; 9 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/28305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28305/head:pull/28305

PR: https://git.openjdk.org/jdk/pull/28305

From duke at openjdk.org  Thu Nov 13 21:10:49 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Nov 2025 21:10:49 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure [v2]
In-Reply-To: <uqNcE0HWXoJIrGVcLa7cyp7qcUxYu5bD6DJd6j9itwI=.598ba078-b90d-42cd-9e0f-4ec8bf7ed7c2@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
 <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>
 <uqNcE0HWXoJIrGVcLa7cyp7qcUxYu5bD6DJd6j9itwI=.598ba078-b90d-42cd-9e0f-4ec8bf7ed7c2@github.com>
Message-ID: <2hWAz3FQ234dfmFLviwQAiuwyewhh0Y2PPGJy4Hb0OQ=.3731e640-c253-42cb-99b0-e17dc4d52c0b@github.com>

On Thu, 13 Nov 2025 20:15:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweaked path to class name handling for clarity
>
> test/jdk/tools/jimage/VerifyJimage.java line 311:
> 
>> 309:         private void loadClass(String cn, ClassLoader loader) {
>> 310:             try {
>> 311:                 System.out.println("Loading " + cn);
> 
> Printing the successful class names isn't very useful, (even if it was previously).

Fair point, will remove that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28265#discussion_r2524942363

From rriggs at openjdk.org  Thu Nov 13 21:16:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Nov 2025 21:16:29 GMT
Subject: RFR: 8371732: [redo] Change java.time month/day field types to
 'byte'
In-Reply-To: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
References: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
Message-ID: <PngSU4vZCsLebhkv0h1wHTS7XCMItZnBF5un7qkXjKo=.4a849d5d-df82-4e4b-b40f-089659c25399@github.com>

On Wed, 12 Nov 2025 18:29:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Redo change (8371732) that failed when the updated class objects were incompatible.
> The fields of classes are changed to allow a more compact form of storage.
> 
> To ensure compatibility of the class objects, the fields are explicitly declared in SerialPersistentFields with the original field types.
> The fields are marked `transient` to indicate the field declarations are not used for serialization.
> The affected classes are java.time.LocalDate, MonthDay, and YearMonth.
> Tests are added to verify the types and names of serialized fields of each class.
> 
> HijrahDate only changes the field types, the fields are transient and there is no change to the serialized from of the HijrahDate.class object.

Please also review the CSR [JDK-8371816](https://bugs.openjdk.org/browse/JDK-8371816)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28274#issuecomment-3529734697

From kbarrett at openjdk.org  Thu Nov 13 21:22:15 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 13 Nov 2025 21:22:15 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
Message-ID: <raGWDYJJ4f-LNkUZUR9Xro6k_qpiqJSmHGRdloYjU6o=.11b96d2b-aefc-4d19-a81a-caa3596202f2@github.com>

On Thu, 13 Nov 2025 19:12:41 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Second try to fix alignment for native segments
>    
>    Introducing a helper function as suggested by JornVernee to decide on
>    the proper alignment based on the segment size.
>    
>    This work was sponsored by: The FreeBSD Foundation
>    
>    Co-authored-by: JornVernee
>  - Test that native segments don't overlap
>    
>    This work was sponsored by: The FreeBSD Foundation

> However, this assumption does not hold for all allocators. Specifically
> jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte
> boundaries, respectively.

For what it's worth, I think the described behavior is non-conforming to the C
standards before C23. Before C23, the description of the allocation functions
all say

"The pointer returned if the allocation succeeds is suitably aligned so that
it may be assigned to a pointer to any type of object with a fundamental
alignment requirement and then used to access such an object or an array of
such objects in the space allocated ... "

(That's from C11 7.22.3/1. C99 and C17 have the same wording. I can't find my
copy of C89 right now, but expect it's pretty much the same.)

DR75 reiterated that the malloc result must be suitably aligned for _any_
(emphasis in the DR) type.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_075.html

A consequence of the pre-C23 behavior is that

max_align_t* p = malloc(1);

is always valid. C23 permits that to be UB. (You aren't allowed to create
misaligned pointers.)

C23 added the phrase "and size less than or equal to the size requested" after
"fundamental alignment requirement". I think that's sufficient to permit the
described behavior. But we're not using C23 (yet), we're using C11.

I would not be surprised if HotSpot also has code that assumes the result from
malloc and friends is always aligned to at least max_align_t's alignment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3529751947

From duke at openjdk.org  Thu Nov 13 21:28:58 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Nov 2025 21:28:58 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure [v3]
In-Reply-To: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
Message-ID: <J5LGDzb7xzhy1qdduW8ZqwZqJaCPrgVQNckDUXxtoSs=.a7c4e40d-7396-4cb6-a2bf-f06f229693ec@github.com>

> Rewrite of VerifyJimage test to fix several severe issues.
> 
> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
> 
> Issue 1: Broken file comparison
> 
> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
> 
> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
> 
> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
> 
> Issue 2: Use of BasicImageReader for class file reading
> 
> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
> 
> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
> 
> Issue 3: File comparison mode was never run by default
> 
> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.

David Beaumont 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 branch 'master' into jdk_8371591_verify/squashed
 - Remove unhelpful output
 - Tweaked path to class name handling for clarity
 - Fix very broken test and make it compatible with preview mode
 - Make entry name reading idempotent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28265/files
  - new: https://git.openjdk.org/jdk/pull/28265/files/1ad6e937..6a4cb625

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28265&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28265&range=01-02

  Stats: 9850 lines in 135 files changed: 5733 ins; 3521 del; 596 mod
  Patch: https://git.openjdk.org/jdk/pull/28265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28265/head:pull/28265

PR: https://git.openjdk.org/jdk/pull/28265

From mli at openjdk.org  Thu Nov 13 21:42:18 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 13 Nov 2025 21:42:18 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization
Message-ID: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>

Hi,

This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.

This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.

Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.

# Test
## Jtreg

in progress...

## Performance

Column names meanings:
* p: with patch
* p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
* m: without patch
* m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on

#### Average improvement

NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.

For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
<google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
-- | -- | -- | --
1.022782609 | 2.198717391 | 2.162673913 | 2.199

</google-sheets-html-origin>

-------------

Commit messages:
 - remove unused test code
 - revert unrelated test change
 - revert unrelated vmaskcmp change
 - typo
 - typo
 - disable vectorization of CMoveFD by removing share code change
 - remove Zicond code for CMoveFD
 - clean stop
 - Merge branch 'vectorize-CMove-Bool' into vectorize-CMove-Bool-riscv-CMoveF-D
 - Merge branch 'master' into vectorize-CMove-Bool
 - ... and 38 more: https://git.openjdk.org/jdk/compare/405d5f7a...ec0d8cc4

Changes: https://git.openjdk.org/jdk/pull/28309/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357551
  Stats: 4581 lines in 13 files changed: 4446 ins; 50 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/28309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28309/head:pull/28309

PR: https://git.openjdk.org/jdk/pull/28309

From naoto at openjdk.org  Thu Nov 13 22:05:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Nov 2025 22:05:55 GMT
Subject: RFR: 8346944: Update Unicode Data Files to 17.0.0
Message-ID: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>

Updates the JDK to use the latest Unicode 17.0.0, which also updates the ICU4J along with it ([8346947](https://bugs.openjdk.org/browse/JDK-8346947)
Update ICU4J to Version 78.1). The corresponding CSR has already been approved.

-------------

Commit messages:
 - icudata path fix
 - Update versions
 - icu4j final
 - .md file changes
 - 17.0 final
 - icudata78b(binary)
 - CaseFolding.text -> 17, copyright symbol as is
 - icudt78b
 - 17-beta
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/28093/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28093&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346944
  Stats: 2977 lines in 35 files changed: 1345 ins; 650 del; 982 mod
  Patch: https://git.openjdk.org/jdk/pull/28093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28093/head:pull/28093

PR: https://git.openjdk.org/jdk/pull/28093

From almatvee at openjdk.org  Thu Nov 13 22:42:11 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 13 Nov 2025 22:42:11 GMT
Subject: RFR: 8364560: The default value of --linux-menu-group option is
 invalid
In-Reply-To: <omkPvg49OSxKbMngN3yrBo6DPHHEb9A6AozyYz3Y_dw=.d5588ec5-42ac-43e2-ac32-ceaadf6f7af8@github.com>
References: <omkPvg49OSxKbMngN3yrBo6DPHHEb9A6AozyYz3Y_dw=.d5588ec5-42ac-43e2-ac32-ceaadf6f7af8@github.com>
Message-ID: <KbDTUWoFv6x8dAhAIKL-Z6MIosPOdi3TRGAU5bo0w8g=.1a62747e-acd9-4d24-912b-f0eaa5f14835@github.com>

On Thu, 13 Nov 2025 15:58:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Set the default value of the "Categories" key in .desktop files to "Utility".
>   - The value of the "Categories" key is an ID, not a localizable string. This is why the "param.menu-group.default" localization key was removed.
> - Add a test for the "--linux-menu-group" option.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28298#pullrequestreview-3461980477

From bchristi at openjdk.org  Thu Nov 13 23:19:52 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 13 Nov 2025 23:19:52 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize() method
Message-ID: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>

>From the bug report:
Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to
"[invoke] shutdown() when this executor is no longer referenced and it has no threads."

In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)).

In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)).

The finalize() method can safely be removed from ThreadPoolExecutor.

-------------

Commit messages:
 - Remove ThreadPoolExecutor.finalize()

Changes: https://git.openjdk.org/jdk/pull/28311/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28311&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371748
  Stats: 17 lines in 1 file changed: 0 ins; 17 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28311/head:pull/28311

PR: https://git.openjdk.org/jdk/pull/28311

From bchristi at openjdk.org  Thu Nov 13 23:26:08 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 13 Nov 2025 23:26:08 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java
In-Reply-To: <_EaMoHXD1s157S3nVEF3wRG8Kv2gi08a540OAALaA4E=.4989ad67-c5a5-471d-8bbe-fe4c8fd9b5c7@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
 <_EaMoHXD1s157S3nVEF3wRG8Kv2gi08a540OAALaA4E=.4989ad67-c5a5-471d-8bbe-fe4c8fd9b5c7@github.com>
Message-ID: <fp1tfB-AXfmSMKxE1k90uRlvB97x9fDqPd55wQJFy4U=.b297bbec-2076-4e2d-99d8-66bf69829ba6@github.com>

On Thu, 13 Nov 2025 07:18:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think it is time to remove TPE.finalize too

FYI, I've submitted a PR to do this:
https://git.openjdk.org/jdk/pull/28311

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28278#issuecomment-3530152512

From almatvee at openjdk.org  Thu Nov 13 23:48:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 13 Nov 2025 23:48:05 GMT
Subject: RFR: 8369206: jpackage should not set R/O permission on app
 launchers
In-Reply-To: <mMYLwg4kM8nmxEKP3mwkJEpt3N-jUR8ycBgGO2QfkRU=.fd19f6e3-d2c1-490a-922b-fde4bcf412a1@github.com>
References: <mMYLwg4kM8nmxEKP3mwkJEpt3N-jUR8ycBgGO2QfkRU=.fd19f6e3-d2c1-490a-922b-fde4bcf412a1@github.com>
Message-ID: <KHB9-xvVoM-aYROIsDnPqNmzvFgkMsrdh21nYX1Dk3g=.559ca6f8-bb75-4d02-8bdb-5c50b959368d@github.com>

On Thu, 13 Nov 2025 20:25:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Remove redundant `setWritable(true, true)` / `setReadOnly()` pair in the code updating resources of launchers on Windows

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28305#pullrequestreview-3462180759

From smarks at openjdk.org  Fri Nov 14 00:45:11 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 14 Nov 2025 00:45:11 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v5]
In-Reply-To: <ZqcCwk9brd7A2xxfqDFMr9ytkjRptAugh54Oe3R7OS8=.10843f8f-752b-4ff6-9b79-d601d5ca21f6@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <vSVVYdKkOvUOmmdFbICM87-yqIkBKShCnSUmt3sUsmo=.37a8728b-8e3a-4961-a84f-f179c93acec9@github.com>
 <1M7QGkc_DoRJEGF4nQXShjdOfs-5rM0k4cnt5Ims73E=.156ea658-649b-4a20-88b6-6284eea3ef96@github.com>
 <ZqcCwk9brd7A2xxfqDFMr9ytkjRptAugh54Oe3R7OS8=.10843f8f-752b-4ff6-9b79-d601d5ca21f6@github.com>
Message-ID: <vAwW9ViTV5JYiIhZzbRBn_LnrvRTk93H3jbvVBPn9vk=.d353c0ee-9a62-42db-a3e0-0b9d13efc863@github.com>

On Thu, 13 Nov 2025 15:05:28 GMT, jengebr <duke at openjdk.org> wrote:

>> test/jdk/java/util/Collection/MOAT.java line 905:
>> 
>>> 903:         arraySource.add(99);
>>> 904:         check(c.addAll(arraySource));
>>> 905:         equal(new ArrayList<Integer>(c), arraySource);
>> 
>> Here and at line 913 it seems a bit odd to copy `c` into a new ArrayList to compare equality. I think it's trying to assert that `c` contains only the expected elements. Unfortunately `c` can be any collection, not just a List, and to use List equality it needs to be copied into an actual List. Doubly unfortunately, the new List will capture the encounter order of whatever collection `c` is, which might not be well-defined -- for example if `c` is a HashSet. So I don't think this is the right assertion. Probably a size check and a containsAll() check, as is done in the bottom case, is sufficient.
>
> I'm curious, why not .equals() when we know the input is a List?  That is a stricter assertion because it ensures ordering remains unchanged.
> 
> Happy to make the change, though.

The testCollection1() method gets called with a bunch of different collections, including a HashSet, which arrives at this code in the `c` parameter. When `c` is copied into a new ArrayList, it gets whatever order is presented by `c`, which is unspecified when `c` is a HashSet. The resulting order might differ from the order in the source list, and equals() over Lists compares order, so it might result in a spurious failure.

I note that creating a HashSet of capacity 8 and adding 42 and then 99 results in [42, 99] but doing the same with a HashSet of capacity 16 results in [99, 42]. The test might actually pass, but if it does, it seems like it's pretty brittle.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2525367497

From asemenyuk at openjdk.org  Fri Nov 14 01:10:20 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 01:10:20 GMT
Subject: Integrated: 8364560: The default value of --linux-menu-group option is
 invalid
In-Reply-To: <omkPvg49OSxKbMngN3yrBo6DPHHEb9A6AozyYz3Y_dw=.d5588ec5-42ac-43e2-ac32-ceaadf6f7af8@github.com>
References: <omkPvg49OSxKbMngN3yrBo6DPHHEb9A6AozyYz3Y_dw=.d5588ec5-42ac-43e2-ac32-ceaadf6f7af8@github.com>
Message-ID: <auJkylQi3mo3nGvbLRWP0Su6yre4zV0ZpjQKWnsOT0Q=.33f22f92-f854-4314-be85-f06cf44c9ef3@github.com>

On Thu, 13 Nov 2025 15:58:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Set the default value of the "Categories" key in .desktop files to "Utility".
>   - The value of the "Categories" key is an ID, not a localizable string. This is why the "param.menu-group.default" localization key was removed.
> - Add a test for the "--linux-menu-group" option.

This pull request has now been integrated.

Changeset: 0d8b5188
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d8b5188bb4315be3c63898a2ce4e68dd2bd4481
Stats:     45 lines in 5 files changed: 33 ins; 4 del; 8 mod

8364560: The default value of --linux-menu-group option is invalid
8356574: Test --linux-menu-group option

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28298

From duke at openjdk.org  Fri Nov 14 01:26:03 2025
From: duke at openjdk.org (erifan)
Date: Fri, 14 Nov 2025 01:26:03 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific
 patterns
Message-ID: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>

`VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.

If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.

In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.

The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.

The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.

Current optimizations related to `VectorMaskCastNode` include:
1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.

This PR does the following optimizations:
1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as the vector length remains the same, and this is guranteed in the api level.

I conducted some simple research on different mask generation methods and mask operations, and obtained the following table, which includes some potential optimization opportunities that may use this `uncast_mask` function.

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 15">
<link id=Main-File rel=Main-File
href="file:////Users/erfang/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip.htm">
<link rel=File-List
href="file:////Users/erfang/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip_filelist.xml">


</head>

<body link="#467886" vlink="#96607D">


mask_gen/op | toLong | anyTrue | allTrue | trueCount | firstTrue | lastTrue | and | or | xor | andNot | not | laneIsSet
-- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
compare | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | TBI | N/A
maskAll | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI
fromLong | TBI | TBI | N/A | TBI | TBI | TBI | N/A | N/A | N/A | N/A | TBI | TBI



</body>

</html>

`TBI` indicated that there may be potential optimizations here that require further investigation.

Benchmarks:

On a Nvidia Grace machine with 128-bit SVE2:

Benchmark			            Unit	Before	Error	After	Error	Uplift
microMaskLoadCastStoreByte64	ops/us	59.23	0.21	148.12	0.07	2.50
microMaskLoadCastStoreDouble128	ops/us	2.43	0.00	38.31	0.01	15.73
microMaskLoadCastStoreFloat128	ops/us	6.19	0.00	75.67	0.11	12.22
microMaskLoadCastStoreInt128	ops/us	6.19	0.00	75.67	0.03	12.22
microMaskLoadCastStoreLong128	ops/us	2.43	0.00	38.32	0.01	15.74
microMaskLoadCastStoreShort64	ops/us	28.89	0.02	75.60	0.09	2.62


On a Nvidia Grace machine with 128-bit NEON:

Benchmark			            Unit	Before	Error	After	Error	Uplift
microMaskLoadCastStoreByte64	ops/us	75.75	0.19	149.74	0.08	1.98
microMaskLoadCastStoreDouble128	ops/us	8.71	0.03	38.71	0.05	4.44
microMaskLoadCastStoreFloat128	ops/us	24.05	0.03	76.49	0.05	3.18
microMaskLoadCastStoreInt128	ops/us	24.06	0.02	76.51	0.05	3.18
microMaskLoadCastStoreLong128	ops/us	8.72	0.01	38.71	0.02	4.44
microMaskLoadCastStoreShort64	ops/us	24.64	0.01	76.43	0.06	3.10


On an AMD EPYC 9124 16-Core Processor with AVX3:

Benchmark			            Unit	Before	Error	After	Error	Uplift
microMaskLoadCastStoreByte64	ops/us	82.13	0.31	115.14	0.08	1.40
microMaskLoadCastStoreDouble128	ops/us	0.32	0.00	0.32	0.00	1.01
microMaskLoadCastStoreFloat128	ops/us	42.18	0.05	57.56	0.07	1.36
microMaskLoadCastStoreInt128	ops/us	42.19	0.01	57.53	0.08	1.36
microMaskLoadCastStoreLong128	ops/us	0.30	0.01	0.32	0.00	1.05
microMaskLoadCastStoreShort64	ops/us	42.18	0.05	57.59	0.01	1.37


On an AMD EPYC 9124 16-Core Processor with AVX2:

Benchmark			            Unit	Before	Error	After	Error	Uplift
microMaskLoadCastStoreByte64	ops/us	73.53	0.20	114.98	0.03	1.56
microMaskLoadCastStoreDouble128	ops/us	0.29	0.01	0.30	0.00	1.00
microMaskLoadCastStoreFloat128	ops/us	30.78	0.14	57.50	0.01	1.87
microMaskLoadCastStoreInt128	ops/us	30.65	0.26	57.50	0.01	1.88
microMaskLoadCastStoreLong128	ops/us	0.30	0.00	0.30	0.00	0.99
microMaskLoadCastStoreShort64	ops/us	24.92	0.00	57.49	0.01	2.31


On an AMD EPYC 9124 16-Core Processor with AVX1:

Benchmark			            Unit	Before	Error	After	Error	Uplift
microMaskLoadCastStoreByte64	ops/us	79.68	0.01	248.49	0.91	3.12
microMaskLoadCastStoreDouble128	ops/us	0.28	0.00	0.28	0.00	1.00
microMaskLoadCastStoreFloat128	ops/us	31.11	0.04	95.48	2.27	3.07
microMaskLoadCastStoreInt128	ops/us	31.10	0.03	99.94	1.87	3.21
microMaskLoadCastStoreLong128	ops/us	0.28	0.00	0.28	0.00	0.99
microMaskLoadCastStoreShort64	ops/us	31.11	0.02	94.97	2.30	3.05


This PR was tested on 128-bit, 256-bit, and 512-bit (QEMU) aarch64 environments, and two 512-bit x64 machines. With various configurations, including sve2, sve1, neon, avx3, avx2, avx1, sse4 and sse3, all tests passed.

-------------

Commit messages:
 - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns

Changes: https://git.openjdk.org/jdk/pull/28313/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370863
  Stats: 582 lines in 7 files changed: 498 ins; 0 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/28313.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28313/head:pull/28313

PR: https://git.openjdk.org/jdk/pull/28313

From asemenyuk at openjdk.org  Fri Nov 14 01:39:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 01:39:53 GMT
Subject: RFR: 8369206: jpackage should not set R/O permission on app
 launchers [v2]
In-Reply-To: <mMYLwg4kM8nmxEKP3mwkJEpt3N-jUR8ycBgGO2QfkRU=.fd19f6e3-d2c1-490a-922b-fde4bcf412a1@github.com>
References: <mMYLwg4kM8nmxEKP3mwkJEpt3N-jUR8ycBgGO2QfkRU=.fd19f6e3-d2c1-490a-922b-fde4bcf412a1@github.com>
Message-ID: <AWny1VNvmTRjjPxtbdvKojBzL7u8vBPc4aWN_UqRleQ=.55aff1cd-c716-4b3c-8de3-47a5a9eee087@github.com>

> - Remove redundant `setWritable(true, true)` / `setReadOnly()` pair in the code updating resources of launchers on Windows

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  ExecutableRebrander: fix a typo in the comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28305/files
  - new: https://git.openjdk.org/jdk/pull/28305/files/012c70c0..305b00ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28305&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28305&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28305/head:pull/28305

PR: https://git.openjdk.org/jdk/pull/28305

From almatvee at openjdk.org  Fri Nov 14 01:49:03 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 14 Nov 2025 01:49:03 GMT
Subject: RFR: 8369206: jpackage should not set R/O permission on app
 launchers [v2]
In-Reply-To: <AWny1VNvmTRjjPxtbdvKojBzL7u8vBPc4aWN_UqRleQ=.55aff1cd-c716-4b3c-8de3-47a5a9eee087@github.com>
References: <mMYLwg4kM8nmxEKP3mwkJEpt3N-jUR8ycBgGO2QfkRU=.fd19f6e3-d2c1-490a-922b-fde4bcf412a1@github.com>
 <AWny1VNvmTRjjPxtbdvKojBzL7u8vBPc4aWN_UqRleQ=.55aff1cd-c716-4b3c-8de3-47a5a9eee087@github.com>
Message-ID: <ddNgrXzpP7aLFJNeiDGJ_sR4HD0ew4BWr_DEvat3uJE=.3ecbde5e-2625-42ba-a1e2-b35c1da5e978@github.com>

On Fri, 14 Nov 2025 01:39:53 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Remove redundant `setWritable(true, true)` / `setReadOnly()` pair in the code updating resources of launchers on Windows
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ExecutableRebrander: fix a typo in the comment

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28305#pullrequestreview-3462423687

From asemenyuk at openjdk.org  Fri Nov 14 01:49:05 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 01:49:05 GMT
Subject: RFR: 8369206: jpackage should not set R/O permission on app
 launchers [v2]
In-Reply-To: <KHB9-xvVoM-aYROIsDnPqNmzvFgkMsrdh21nYX1Dk3g=.559ca6f8-bb75-4d02-8bdb-5c50b959368d@github.com>
References: <mMYLwg4kM8nmxEKP3mwkJEpt3N-jUR8ycBgGO2QfkRU=.fd19f6e3-d2c1-490a-922b-fde4bcf412a1@github.com>
 <KHB9-xvVoM-aYROIsDnPqNmzvFgkMsrdh21nYX1Dk3g=.559ca6f8-bb75-4d02-8bdb-5c50b959368d@github.com>
Message-ID: <HbWN0iJvGiIXEDc4E-PZjt-Xt4i0vIAA-Ik3X60Bgb8=.f12c53ed-98b8-407b-87b4-4aa92437dcdd@github.com>

On Thu, 13 Nov 2025 23:45:52 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ExecutableRebrander: fix a typo in the comment
>
> Looks good.

@sashamatveev I pushed a minor change. Please review again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28305#issuecomment-3530462101

From asemenyuk at openjdk.org  Fri Nov 14 02:13:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 02:13:15 GMT
Subject: Integrated: 8369206: jpackage should not set R/O permission on app
 launchers
In-Reply-To: <mMYLwg4kM8nmxEKP3mwkJEpt3N-jUR8ycBgGO2QfkRU=.fd19f6e3-d2c1-490a-922b-fde4bcf412a1@github.com>
References: <mMYLwg4kM8nmxEKP3mwkJEpt3N-jUR8ycBgGO2QfkRU=.fd19f6e3-d2c1-490a-922b-fde4bcf412a1@github.com>
Message-ID: <EE2mgSlWYs6n0nXEbwTp13pF1I7tU9Bg2NzrZaEztME=.05c5f925-1877-4009-b3de-33d446527cf4@github.com>

On Thu, 13 Nov 2025 20:25:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Remove redundant `setWritable(true, true)` / `setReadOnly()` pair in the code updating resources of launchers on Windows

This pull request has now been integrated.

Changeset: 7733632f
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7733632f90a17ec848c4c9259c1aa58fded8c15a
Stats:     38 lines in 1 file changed: 4 ins; 9 del; 25 mod

8369206: jpackage should not set R/O permission on app launchers

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28305

From smarks at openjdk.org  Fri Nov 14 02:54:05 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 14 Nov 2025 02:54:05 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v6]
In-Reply-To: <mQwxR0OSb6i3goJN42FBX8wFBO-DpDsYmB46finyZew=.6e993328-1833-4994-86a3-3515d2928f38@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <mQwxR0OSb6i3goJN42FBX8wFBO-DpDsYmB46finyZew=.6e993328-1833-4994-86a3-3515d2928f38@github.com>
Message-ID: <ERo6FCHIo_hyvARdQJmVwWvprCGBZHLYVvKWaBg97eQ=.edef15f9-f4e6-4d56-8776-fa8e75db8656@github.com>

On Thu, 13 Nov 2025 15:32:07 GMT, jengebr <duke at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unit test revisions

Test update to MOAT looks good! Please add 8371164 to the `@bugs` section at the top of the file.

test/micro/org/openjdk/bench/java/util/ArrayListBulkOpsBenchmark.java line 128:

> 126:         }
> 127:     }
> 128: }

Missing EOL here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3530592655
PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2525584884

From almatvee at openjdk.org  Fri Nov 14 03:21:15 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 14 Nov 2025 03:21:15 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
Message-ID: <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>

On Wed, 12 Nov 2025 23:11:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
>> 
>> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
>> 
>> ### Error reporting improved
>> 
>> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
>> 
>> Command line (Windows): 
>> 
>> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
>> 
>> Old error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> 
>> 
>> New error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> Error: Option [--mac-package-name] is not valid on this platform
>> Error: Option [-p] is not valid with type [exe]
>> Error: Option [--linux-menu-group] is not valid on this platform
>> 
>> 
>>  2. Fix misleading error messages.
>> 
>> Command line (Windows): 
>> 
>> jpackage --input no --main-jar no.jar
>> 
>> Old error output:
>> 
>> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
>> 
>> 
>> New error output:
>> 
>> The value "no" provided for parameter --input is not a directory
>> 
>> 
>> 
>> 
>> ### Help output fixed
>> 
>> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
>> 
>> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
>> 
>> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
>> 
>> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
>> 
>> ### Functional changes
>> 
>> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
>> 
>> Like other JD...
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MainResources.properties: remove unreferenced L10N key

Looks good with some comments.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java line 49:

> 47:                 .bundler(CREATE_MAC_APP_IMAGE, MacBundlingEnvironment::createAppImage)
> 48:                 .bundler(CREATE_MAC_DMG, LazyLoad::dmgSysEnv, MacBundlingEnvironment::createDmdPackage)
> 49:                 .bundler(CREATE_MAC_PKG, MacBundlingEnvironment::createPkgPackage));

Do you know why `CREATE_MAC_PKG` does not need/use environment like `CREATE_MAC_DMG`?

src/jdk.jpackage/macosx/classes/module-info.java.extra line 27:

> 25: 
> 26: provides jdk.jpackage.internal.cli.CliBundlingEnvironment with
> 27:     jdk.jpackage.internal.MacBundlingEnvironment;

Missing new line at the end of the file.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/HelpFormatter.java line 46:

> 44:         this.optionGroups = Objects.requireNonNull(optionGroups);
> 45:         this.formatter = Objects.requireNonNull(formatter);
> 46: 

Extra new line.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/JOptSimpleOptionsBuilder.java line 184:

> 182:             try {
> 183:                 initializer.run();
> 184:                 throw new AssertionError();

Can you put a comment on why we need `throw new AssertionError()`? I assume that `initializer.run()` never exits.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpec.java line 126:

> 124:      * <p>
> 125:      * If the option has three names "a", "b", and "c", the stream will have three
> 126:      * option spec objects each with a single name. The firt will have name "a", the

`firt` -> `first`

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardAppImageFileOption.java line 227:

> 225:         }).map(option -> {
> 226:             var spec = context.mapOptionSpec(option.spec());
> 227:             var strValue = Optional.ofNullable(properties.get(spec.name().name()));

`name().name()` why we need name of the name and what it means?

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 328:

> 326:     public static final OptionValue<List<Path>> MAC_DMG_CONTENT = pathOption("mac-dmg-content")
> 327:             .valuePattern("additional content path")
> 328:             //.toArray(pathSeparator())

Remove if not needed.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 335:

> 333: 
> 334:     public static final OptionValue<Boolean> MAC_APP_STORE = booleanOption("mac-app-store")
> 335:             //.scope(MAC_SIGNING) // TODO: --mac-app-store should be applicable to app image signing operation because it redefines signing key

I do not like any TODO comments. They usually never got fixed. Bug needs to be filed if follow up is required.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 492:

> 490:                 context.asFileSource().ifPresent(propertyFile -> {
> 491:                     b.converterExceptionFactory(forMessageWithOptionValueAndName(propertyFile));
> 492:                     b.converterExceptionFormatString("error.properties-paramater-not-path");

`paramater` -> `parameter`. Below as well.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 544:

> 542:             }))
> 543:             .converterExceptionFactory(ERROR_WITH_VALUE_AND_OPTION_NAME)
> 544: //            .converterExceptionFormatString("error.paramater-not-launcher-shortcut-dir")

Remove if not needed.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 644:

> 642:                     final var theCause = cause.orElseThrow();
> 643:                     if (theCause instanceof AddLauncherSyntaxException) {
> 644: //                        return ERROR_WITH_VALUE_AND_OPTION_NAME.create(optionName,

Remove if not needed.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardValidator.java line 48:

> 46:     static final Predicate<Path> IS_DIRECTORY = Files::isDirectory;
> 47: 
> 48:     static final Predicate<Path> IS_EXISTENT_NOT_DIRECTORY = path -> {

`IS_EXISTENT_NOT_DIRECTORY` will be same as `IS_REGULAR_FILE`? And just do `return Files. isRegularFile(path)`.

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java line 403:

> 401:             }
> 402: 
> 403: //            Builder expectMalformedError(String v) {

Remove if not needed.

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java line 544:

> 542:                 buildLauncherShortcutTest().optionValue("false"),
> 543:                 buildLauncherShortcutTest().optionValue(""),
> 544: //                buildLauncherShortcutTest().optionValue("").propertyFile(true),

Remove and line 547.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28163#pullrequestreview-3455666852
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2520495679
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2520589934
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2521119607
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2521215259
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2521320407
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2521373482
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2525413799
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2525418201
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2525490887
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2521406263
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2521408337
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2525506624
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2525610819
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2525612889

From almatvee at openjdk.org  Fri Nov 14 03:21:17 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 14 Nov 2025 03:21:17 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v5]
In-Reply-To: <r8u5L0fySGlaC9-c6_Dh07LOuCIpPFN-8FfB3_Y7BEw=.d4adf13c-3867-472c-9612-11b8377110e2@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <r8u5L0fySGlaC9-c6_Dh07LOuCIpPFN-8FfB3_Y7BEw=.d4adf13c-3867-472c-9612-11b8377110e2@github.com>
Message-ID: <lMP86wJo79yRwf7U2KliAsXc3WnXArp8ookZYuz9Dvo=.084bff47-57b9-4b42-a536-42d0dd9c886e@github.com>

On Tue, 11 Nov 2025 22:39:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
>> 
>> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
>> 
>> ### Error reporting improved
>> 
>> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
>> 
>> Command line (Windows): 
>> 
>> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
>> 
>> Old error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> 
>> 
>> New error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> Error: Option [--mac-package-name] is not valid on this platform
>> Error: Option [-p] is not valid with type [exe]
>> Error: Option [--linux-menu-group] is not valid on this platform
>> 
>> 
>>  2. Fix misleading error messages.
>> 
>> Command line (Windows): 
>> 
>> jpackage --input no --main-jar no.jar
>> 
>> Old error output:
>> 
>> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
>> 
>> 
>> New error output:
>> 
>> The value "no" provided for parameter --input is not a directory
>> 
>> 
>> 
>> 
>> ### Help output fixed
>> 
>> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
>> 
>> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
>> 
>> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
>> 
>> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
>> 
>> ### Functional changes
>> 
>> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
>> 
>> Like other JD...
>
> Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update cli-*.txt help output files
>  - StandardOption, HelpResources.properties: split description of the "add-launcher" option by OS
>  - OptionSpecBuilder: bugfix

src/jdk.internal.opt/share/classes/module-info.java line 1:

> 1: /*

Copyright year needs to be updated to 2025.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2519930005

From almatvee at openjdk.org  Fri Nov 14 03:24:03 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 14 Nov 2025 03:24:03 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
Message-ID: <8PqEZ559QX0Cu7wbgHVZ42u75UwSasGf2SF-D3rn2R8=.fe0e46fa-4279-48c9-a50a-1b31bfc0f81d@github.com>

On Wed, 12 Nov 2025 23:11:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
>> 
>> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
>> 
>> ### Error reporting improved
>> 
>> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
>> 
>> Command line (Windows): 
>> 
>> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
>> 
>> Old error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> 
>> 
>> New error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> Error: Option [--mac-package-name] is not valid on this platform
>> Error: Option [-p] is not valid with type [exe]
>> Error: Option [--linux-menu-group] is not valid on this platform
>> 
>> 
>>  2. Fix misleading error messages.
>> 
>> Command line (Windows): 
>> 
>> jpackage --input no --main-jar no.jar
>> 
>> Old error output:
>> 
>> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
>> 
>> 
>> New error output:
>> 
>> The value "no" provided for parameter --input is not a directory
>> 
>> 
>> 
>> 
>> ### Help output fixed
>> 
>> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
>> 
>> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
>> 
>> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
>> 
>> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
>> 
>> ### Functional changes
>> 
>> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
>> 
>> Like other JD...
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MainResources.properties: remove unreferenced L10N key

> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.

Can you explain more on this one? I did not figure out how synchronization issue was fixed and what was issue with original implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28163#issuecomment-3530650746

From rriggs at openjdk.org  Fri Nov 14 03:39:14 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Nov 2025 03:39:14 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure [v2]
In-Reply-To: <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
 <x9WJE3Fb-_DCEfEbGMHT68HYDIDmytymkqeCsf7ZtZ4=.4c28bc0f-324f-4ec3-85b4-c8063c1eb17b@github.com>
Message-ID: <CPBuXfT0R4sFGfpgPVnM7lNAHtatPvBEpcyc5F998CI=.c0a71d76-3e2e-4079-bac5-08dcc24ffdfe@github.com>

On Wed, 12 Nov 2025 12:24:39 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Rewrite of VerifyJimage test to fix several severe issues.
>> 
>> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
>> 
>> Issue 1: Broken file comparison
>> 
>> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
>> 
>> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
>> 
>> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
>> 
>> Issue 2: Use of BasicImageReader for class file reading
>> 
>> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
>> 
>> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
>> 
>> Issue 3: File comparison mode was never run by default
>> 
>> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaked path to class name handling for clarity

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28265#pullrequestreview-3462632180

From swen at openjdk.org  Fri Nov 14 04:46:26 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 14 Nov 2025 04:46:26 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v22]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <gOqebHyurDwwkxa0E8WzV4cL9_e9so0K8Gd_xGnPDXo=.12a703a3-ebfb-45ed-b9d2-dc09d7362fa1@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove JLA

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/57ef68f4..35b98cb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=20-21

  Stats: 88 lines in 4 files changed: 13 ins; 66 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

PR: https://git.openjdk.org/jdk/pull/26911

From swen at openjdk.org  Fri Nov 14 05:20:14 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 14 Nov 2025 05:20:14 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v22]
In-Reply-To: <gOqebHyurDwwkxa0E8WzV4cL9_e9so0K8Gd_xGnPDXo=.12a703a3-ebfb-45ed-b9d2-dc09d7362fa1@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <gOqebHyurDwwkxa0E8WzV4cL9_e9so0K8Gd_xGnPDXo=.12a703a3-ebfb-45ed-b9d2-dc09d7362fa1@github.com>
Message-ID: <K80tmdWf1znR4WcwQAHAcZVEFa0YK-2g1SLwgVlA0_g=.08b08905-92ca-4786-878e-a3948febd43c@github.com>

On Fri, 14 Nov 2025 04:46:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove JLA

In the current version 35b98cb891207af7eaaa42503c0c872ec68771c6, run the following test:


make test TEST="micro:java.time.ToStringBench.localDateToString" MICRO="VM_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=TraceMergeStores,jdk.internal.util.DecimalDigits::appendQuad,SUCCESS" 


The output is as follows:


[TraceMergeStores]: Replace
 841  StoreB  === 881 806 833 53  [[ 846 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
 846  StoreB  === 881 841 844 129  [[ 851 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores]: with
  53  LoadS  === 5 7 51  [[ 129 615 533 871 841 515 303 649 689 902 ]]  @short[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; #short !jvms: DecimalDigits::appendQuad @ bci:10 (line 491)
 902  StoreC  === 881 806 833 53  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores]: Replace
 851  StoreB  === 881 902 849 78  [[ 856 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
 856  StoreB  === 881 851 854 142  [[ 873 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores]: with
  78  LoadS  === 5 7 76  [[ 142 533 615 865 851 515 303 649 689 903 ]]  @short[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; #short !jvms: DecimalDigits::appendQuad @ bci:22 (line 492)
 903  StoreC  === 881 902 849 78  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;


We can see there are two `SotreC` instructions here. Is it possible to merge these into OrI + StoreI, writing 4 bytes at a time?
@eme64 

In version 57ef68f4e49561423131287556cd592e29f05ba8, which uses JLA.appendLantin1, it can be optimized to OrI + StoreI.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3530872741

From epeter at openjdk.org  Fri Nov 14 07:09:28 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 14 Nov 2025 07:09:28 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v22]
In-Reply-To: <K80tmdWf1znR4WcwQAHAcZVEFa0YK-2g1SLwgVlA0_g=.08b08905-92ca-4786-878e-a3948febd43c@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <gOqebHyurDwwkxa0E8WzV4cL9_e9so0K8Gd_xGnPDXo=.12a703a3-ebfb-45ed-b9d2-dc09d7362fa1@github.com>
 <K80tmdWf1znR4WcwQAHAcZVEFa0YK-2g1SLwgVlA0_g=.08b08905-92ca-4786-878e-a3948febd43c@github.com>
Message-ID: <IpMOzne3fZocnf2ci4-taQdC8KQSOKuXSca3HgqDcQc=.fa321e8b-bfc8-4464-8297-cefc1f058467@github.com>

On Fri, 14 Nov 2025 05:17:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> We can see there are two SotreC instructions here. Is it possible to merge these into OrI + StoreI, writing 4 bytes at a time?

Can you describe the pattern in a bit more detail here?

Currently, we only merge stores where the inputs are either:
- All constants -> merge to a new constant
- All extracts of the same larger value -> when merging we just get the larger value. Example: Integer value is split into its 4 bytes, and each byte is stored separately -> we can merge the byte stores to an integer store, and just store the original integer value.

What you seem to ask for is a third category:
You have two consecutive stores, with two unrelated values. You could merge the two values with shift/or, and then store it with a larger store. Example:

a[i+0] = x; // StoreI
a[i+1] = y; // StoreI

Turns into `StoreL`, with value `x | ((long)(y) << 32)`.

One would also have to prove that this is in general profitable:
- Before: 2 stores
- After: 1 store + shift + or

It's not immediately clear that there are not cases where this could not lead to regressions, though they would probably be quite rare and hard to find.

Is that what you are asking for? I suppose that is in theory possible. I personally don't have time for it, but maybe someone volunteers for it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3531215264

From pminborg at openjdk.org  Fri Nov 14 07:11:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 07:11:12 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v2]
In-Reply-To: <V55raivd_O60gWUqkcnE9OKZbRU9Ie63ckJRQJKDF4A=.ddbe3874-9038-44ec-8b00-6fa6fa8eab78@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <V55raivd_O60gWUqkcnE9OKZbRU9Ie63ckJRQJKDF4A=.ddbe3874-9038-44ec-8b00-6fa6fa8eab78@github.com>
Message-ID: <4a1QagXAZgcpcDDdfLE6udgxq1PxH7fqKdTrFboBL_k=.ec0ef5ea-98da-4c5b-89c7-ad8fae223935@github.com>

On Thu, 13 Nov 2025 18:42:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove lingering comment
>  - Refactor and use long arrays
>  - Remove BulkOps

The benchmarks take about 6 hours to complete. Here is the output from my old Mac (2019, Intel):


Benchmark                                   (alignment)  (segmentType)     (size)  Mode  Cnt          Score          Error  Units
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A          2  avgt   30          4.975 ?        0.195  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A          4  avgt   30          4.139 ?        0.072  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A          8  avgt   30          4.243 ?        0.285  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A         12  avgt   30          4.472 ?        0.061  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A         16  avgt   30          5.241 ?        0.203  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A         64  avgt   30          4.634 ?        0.270  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A        512  avgt   30          8.536 ?        0.310  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A       4096  avgt   30         96.092 ?        6.595  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A      32768  avgt   30        804.326 ?       17.612  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A     262144  avgt   30       9887.394 ?      360.848  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A    2097152  avgt   30      77172.196 ?     2005.950  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A   16777216  avgt   30    1569903.233 ?    44054.449  ns/op
SegmentBulkCopy.Array.arrayCopy                     N/A            N/A  134217728  avgt   30   15666374.762 ?   593515.032  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A          2  avgt   30          5.806 ?        0.133  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A          4  avgt   30          5.705 ?        0.102  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A          8  avgt   30          5.813 ?        0.325  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A         12  avgt   30          5.817 ?        0.376  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A         16  avgt   30          5.837 ?        0.343  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A         64  avgt   30          5.771 ?        0.528  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A        512  avgt   30          5.674 ?        0.091  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A       4096  avgt   30          5.775 ?        0.371  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A      32768  avgt   30          5.785 ?        0.141  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A     262144  avgt   30          5.765 ?        0.140  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A    2097152  avgt   30          5.858 ?        0.212  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A   16777216  avgt   30          5.782 ?        0.111  ns/op
SegmentBulkCopy.Array.bufferCopy                    N/A            N/A  134217728  avgt   30          6.130 ?        0.350  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP          2  avgt   30          6.080 ?        0.350  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP          4  avgt   30          6.391 ?        0.531  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP          8  avgt   30          8.378 ?        0.752  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP         12  avgt   30          7.195 ?        0.139  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP         16  avgt   30          6.703 ?        0.463  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP         64  avgt   30         11.327 ?        1.023  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP        512  avgt   30         17.727 ?        1.163  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP       4096  avgt   30         44.226 ?        3.801  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP      32768  avgt   30        694.006 ?       82.675  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP     262144  avgt   30      10302.068 ?      777.341  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP    2097152  avgt   30      76710.526 ?     1663.377  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP   16777216  avgt   30    1564716.398 ?    17170.039  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED           HEAP  134217728  avgt   30   16546494.118 ?   995676.046  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE          2  avgt   30          4.342 ?        0.191  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE          4  avgt   30          3.935 ?        0.079  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE          8  avgt   30          5.300 ?        0.078  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE         12  avgt   30          6.465 ?        0.209  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE         16  avgt   30          5.781 ?        0.385  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE         64  avgt   30         10.669 ?        0.303  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE        512  avgt   30         15.059 ?        0.772  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE       4096  avgt   30         42.143 ?        2.533  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE      32768  avgt   30        608.449 ?       41.685  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE     262144  avgt   30      10914.654 ?      588.754  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE    2097152  avgt   30      78152.246 ?     5338.790  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE   16777216  avgt   30    1604537.416 ?    57291.246  ns/op
SegmentBulkCopy.Segment.copy                    ALIGNED         NATIVE  134217728  avgt   30   16537082.459 ?  1283384.399  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP          2  avgt   30          5.671 ?        0.109  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP          4  avgt   30          5.959 ?        0.240  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP          8  avgt   30          7.334 ?        0.134  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP         12  avgt   30          7.176 ?        0.327  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP         16  avgt   30          6.420 ?        0.133  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP         64  avgt   30         11.031 ?        0.318  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP        512  avgt   30         16.059 ?        0.737  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP       4096  avgt   30         55.730 ?        2.347  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP      32768  avgt   30        682.845 ?       12.703  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP     262144  avgt   30       9872.891 ?      238.840  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP    2097152  avgt   30      77427.463 ?     2191.678  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP   16777216  avgt   30    1568566.110 ?    73129.104  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED           HEAP  134217728  avgt   30   16833940.150 ?  1445170.439  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE          2  avgt   30          4.176 ?        0.127  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE          4  avgt   30          3.933 ?        0.248  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE          8  avgt   30          5.314 ?        0.112  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE         12  avgt   30          6.527 ?        0.373  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE         16  avgt   30          5.629 ?        0.075  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE         64  avgt   30         10.730 ?        0.461  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE        512  avgt   30         15.439 ?        0.967  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE       4096  avgt   30         58.961 ?        3.813  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE      32768  avgt   30        681.148 ?       13.207  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE     262144  avgt   30      11276.595 ?      288.753  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE    2097152  avgt   30      76322.647 ?     3023.455  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE   16777216  avgt   30    1534092.143 ?    19000.226  ns/op
SegmentBulkCopy.Segment.copy                  UNALIGNED         NATIVE  134217728  avgt   30   15840085.040 ?   757425.229  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP          2  avgt   30          5.275 ?        0.289  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP          4  avgt   30          8.601 ?        0.380  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP          8  avgt   30          9.888 ?        0.216  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP         12  avgt   30         10.115 ?        0.208  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP         16  avgt   30         11.282 ?        0.173  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP         64  avgt   30         15.441 ?        1.464  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP        512  avgt   30         34.518 ?        1.765  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP       4096  avgt   30         52.918 ?        3.657  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP      32768  avgt   30        616.877 ?       38.807  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP     262144  avgt   30       9702.343 ?      561.472  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP    2097152  avgt   30     107970.150 ?    17612.768  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP   16777216  avgt   30    2603409.528 ?   272235.690  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED           HEAP  134217728  avgt   30   22525344.383 ?   654636.341  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE          2  avgt   30          5.158 ?        0.200  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE          4  avgt   30          7.920 ?        0.174  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE          8  avgt   30          9.378 ?        0.474  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE         12  avgt   30          9.433 ?        0.234  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE         16  avgt   30         10.794 ?        0.358  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE         64  avgt   30         15.370 ?        0.689  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE        512  avgt   30         31.999 ?        2.441  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE       4096  avgt   30         60.044 ?        1.832  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE      32768  avgt   30        742.416 ?       35.974  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE     262144  avgt   30      10750.345 ?      335.206  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE    2097152  avgt   30      92444.491 ?    11504.122  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE   16777216  avgt   30    2578083.652 ?   161776.127  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt          ALIGNED         NATIVE  134217728  avgt   30   21709709.293 ?   558934.833  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP          2  avgt   30          5.907 ?        0.360  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP          4  avgt   30          9.539 ?        0.544  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP          8  avgt   30         11.119 ?        0.473  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP         12  avgt   30         10.939 ?        0.317  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP         16  avgt   30         12.255 ?        0.343  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP         64  avgt   30         16.786 ?        0.329  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP        512  avgt   30         36.047 ?        2.079  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP       4096  avgt   30         60.961 ?        1.123  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP      32768  avgt   30        732.320 ?       15.805  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP     262144  avgt   30      11261.486 ?      177.118  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP    2097152  avgt   30      98485.207 ?     4815.330  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP   16777216  avgt   30    2562857.821 ?   169517.171  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED           HEAP  134217728  avgt   30   21564431.500 ?  1764465.483  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE          2  avgt   30          5.195 ?        0.303  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE          4  avgt   30          7.887 ?        0.241  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE          8  avgt   30          9.125 ?        0.437  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE         12  avgt   30          9.299 ?        0.639  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE         16  avgt   30         10.739 ?        0.142  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE         64  avgt   30         15.525 ?        1.185  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE        512  avgt   30         30.721 ?        1.281  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE       4096  avgt   30         57.902 ?        1.739  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE      32768  avgt   30        750.100 ?       30.238  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE     262144  avgt   30      11082.966 ?      131.064  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE    2097152  avgt   30     108269.048 ?    10137.532  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE   16777216  avgt   30    2391256.771 ?   152764.171  ns/op
SegmentBulkCopy.Segment.copyLoopIntInt        UNALIGNED         NATIVE  134217728  avgt   30   22490219.570 ?  1867068.545  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP          2  avgt   30          5.942 ?        0.064  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP          4  avgt   30          7.553 ?        0.133  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP          8  avgt   30         11.441 ?        0.099  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP         12  avgt   30         15.248 ?        0.163  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP         16  avgt   30         18.985 ?        0.207  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP         64  avgt   30         69.596 ?        2.793  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP        512  avgt   30        578.897 ?       30.437  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP       4096  avgt   30       3680.643 ?       17.208  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP      32768  avgt   30      27259.230 ?      490.991  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP     262144  avgt   30     215314.619 ?     3798.978  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP    2097152  avgt   30    1785642.395 ?    30964.204  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP   16777216  avgt   30   14974386.141 ?   380979.165  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED           HEAP  134217728  avgt   30  121886928.850 ?  3447787.595  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE          2  avgt   30          4.876 ?        0.426  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE          4  avgt   30          6.680 ?        0.115  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE          8  avgt   30         10.049 ?        0.104  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE         12  avgt   30         13.763 ?        0.100  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE         16  avgt   30         17.424 ?        0.365  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE         64  avgt   30         59.446 ?        1.185  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE        512  avgt   30        456.871 ?        8.085  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE       4096  avgt   30       5839.656 ?      109.635  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE      32768  avgt   30      44992.784 ?     6373.239  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE     262144  avgt   30     222213.789 ?     2376.293  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE    2097152  avgt   30    1929682.814 ?    80406.720  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE   16777216  avgt   30   14774112.436 ?   147606.361  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong         ALIGNED         NATIVE  134217728  avgt   30  117046865.138 ?  1903956.584  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP          2  avgt   30          5.957 ?        0.070  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP          4  avgt   30          7.621 ?        0.257  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP          8  avgt   30         11.595 ?        0.851  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP         12  avgt   30         15.208 ?        0.164  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP         16  avgt   30         18.964 ?        0.212  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP         64  avgt   30         68.661 ?        1.050  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP        512  avgt   30        564.410 ?       17.365  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP       4096  avgt   30       3667.054 ?       48.854  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP      32768  avgt   30      27031.388 ?      515.769  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP     262144  avgt   30     226926.263 ?    18571.088  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP    2097152  avgt   30    1855857.367 ?   112908.583  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP   16777216  avgt   30   15176688.732 ?  1422955.167  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED           HEAP  134217728  avgt   30  115802892.293 ?  1647900.732  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE          2  avgt   30          4.742 ?        0.145  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE          4  avgt   30          6.612 ?        0.136  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE          8  avgt   30         10.095 ?        0.369  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE         12  avgt   30         13.428 ?        0.192  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE         16  avgt   30         17.250 ?        0.648  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE         64  avgt   30         59.399 ?        0.663  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE        512  avgt   30        468.083 ?       37.496  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE       4096  avgt   30       5752.354 ?      241.016  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE      32768  avgt   30      44653.549 ?     5344.853  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE     262144  avgt   30     220653.102 ?     6711.829  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE    2097152  avgt   30    1765091.999 ?    30236.094  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE   16777216  avgt   30   14588387.804 ?  1289250.748  ns/op
SegmentBulkCopy.Segment.copyLoopIntLong       UNALIGNED         NATIVE  134217728  avgt   30  113336420.393 ?  2293056.169  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP          2  avgt   30          5.146 ?        0.073  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP          4  avgt   30          9.430 ?        0.168  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP          8  avgt   30         10.872 ?        0.335  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP         12  avgt   30         10.942 ?        0.179  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP         16  avgt   30         12.398 ?        0.622  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP         64  avgt   30         16.884 ?        0.479  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP        512  avgt   30         33.928 ?        0.483  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP       4096  avgt   30         63.269 ?        3.536  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP      32768  avgt   30        770.760 ?        7.034  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP     262144  avgt   30      11382.922 ?      104.957  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP    2097152  avgt   30      99318.948 ?     8215.597  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP   16777216  avgt   30    2429329.527 ?   150265.335  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED           HEAP  134217728  avgt   30   20546635.488 ?  1218074.543  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE          2  avgt   30          4.390 ?        0.039  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE          4  avgt   30          8.760 ?        0.186  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE          8  avgt   30          9.594 ?        0.436  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE         12  avgt   30          9.770 ?        0.244  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE         16  avgt   30         11.200 ?        0.592  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE         64  avgt   30         16.344 ?        0.517  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE        512  avgt   30         34.287 ?        3.514  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE       4096  avgt   30         60.660 ?        1.724  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE      32768  avgt   30        750.561 ?       17.396  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE     262144  avgt   30      11670.596 ?      343.869  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE    2097152  avgt   30     137006.846 ?     6150.119  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE   16777216  avgt   30    2607338.374 ?   101259.992  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong        ALIGNED         NATIVE  134217728  avgt   30   22927871.742 ?   777191.247  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP          2  avgt   30          5.761 ?        0.065  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP          4  avgt   30         10.525 ?        0.680  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP          8  avgt   30         12.936 ?        0.661  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP         12  avgt   30         13.616 ?        1.285  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP         16  avgt   30         14.179 ?        0.787  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP         64  avgt   30         20.598 ?        1.262  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP        512  avgt   30         43.612 ?        2.221  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP       4096  avgt   30         71.669 ?        2.926  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP      32768  avgt   30        919.142 ?       25.319  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP     262144  avgt   30      13890.391 ?      477.231  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP    2097152  avgt   30     112268.994 ?     4224.930  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP   16777216  avgt   30    2773941.251 ?   199768.100  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED           HEAP  134217728  avgt   30   24552493.319 ?  3621074.337  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE          2  avgt   30          5.260 ?        0.202  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE          4  avgt   30          9.457 ?        0.156  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE          8  avgt   30         10.889 ?        0.355  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE         12  avgt   30         11.520 ?        0.292  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE         16  avgt   30         12.918 ?        0.246  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE         64  avgt   30         17.092 ?        0.372  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE        512  avgt   30         34.789 ?        2.570  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE       4096  avgt   30         67.835 ?        1.805  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE      32768  avgt   30        860.056 ?       12.553  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE     262144  avgt   30      12700.414 ?      390.168  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE    2097152  avgt   30     110532.822 ?     9128.368  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE   16777216  avgt   30    2660177.270 ?   135536.673  ns/op
SegmentBulkCopy.Segment.copyLoopLongLong      UNALIGNED         NATIVE  134217728  avgt   30   23897449.938 ?  2714769.406  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP          2  avgt   30         10.582 ?        0.392  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP          4  avgt   30         10.246 ?        0.483  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP          8  avgt   30          8.916 ?        0.143  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP         12  avgt   30          9.795 ?        0.367  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP         16  avgt   30          8.643 ?        0.142  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP         64  avgt   30          8.890 ?        0.179  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP        512  avgt   30         15.946 ?        0.226  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP       4096  avgt   30         67.112 ?        1.375  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP      32768  avgt   30        936.862 ?       19.557  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP     262144  avgt   30      13286.402 ?      285.636  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP    2097152  avgt   30     115039.272 ?     4222.166  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP   16777216  avgt   30    2550367.562 ?   118621.968  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED           HEAP  134217728  avgt   30   22209497.425 ?   977533.043  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE          2  avgt   30          9.346 ?        0.166  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE          4  avgt   30          8.328 ?        0.181  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE          8  avgt   30          8.517 ?        0.644  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE         12  avgt   30          8.491 ?        0.402  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE         16  avgt   30          8.432 ?        0.637  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE         64  avgt   30          7.749 ?        0.164  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE        512  avgt   30         13.562 ?        0.703  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE       4096  avgt   30         53.759 ?        3.484  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE      32768  avgt   30        875.670 ?       14.180  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE     262144  avgt   30      12746.529 ?      182.944  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE    2097152  avgt   30     128383.846 ?     4404.690  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE   16777216  avgt   30    2704314.291 ?   241631.983  ns/op
SegmentBulkCopy.Segment.copyUnsafe              ALIGNED         NATIVE  134217728  avgt   30   22771347.545 ?   658342.089  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP          2  avgt   30         12.293 ?        0.482  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP          4  avgt   30         11.810 ?        0.233  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP          8  avgt   30         11.345 ?        0.206  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP         12  avgt   30         11.832 ?        0.262  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP         16  avgt   30         11.938 ?        0.261  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP         64  avgt   30         12.038 ?        0.497  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP        512  avgt   30         17.747 ?        0.243  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP       4096  avgt   30         68.936 ?        2.162  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP      32768  avgt   30        952.171 ?       46.044  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP     262144  avgt   30      13860.608 ?      666.311  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP    2097152  avgt   30     121784.338 ?     6010.538  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP   16777216  avgt   30    2758023.712 ?   175517.371  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED           HEAP  134217728  avgt   30   23649594.683 ?  1972925.852  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE          2  avgt   30         10.147 ?        0.174  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE          4  avgt   30         10.302 ?        0.158  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE          8  avgt   30         10.101 ?        0.453  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE         12  avgt   30         10.651 ?        0.494  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE         16  avgt   30         11.192 ?        0.171  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE         64  avgt   30         10.616 ?        0.233  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE        512  avgt   30         17.586 ?        1.561  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE       4096  avgt   30         77.260 ?        3.505  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE      32768  avgt   30        931.910 ?       11.294  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE     262144  avgt   30      12780.945 ?      240.646  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE    2097152  avgt   30     115060.899 ?     8672.538  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE   16777216  avgt   30    2813329.611 ?   297819.618  ns/op
SegmentBulkCopy.Segment.copyUnsafe            UNALIGNED         NATIVE  134217728  avgt   30   22303045.077 ?   875937.220  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A          2  avgt   30          2.521 ?        0.042  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A          4  avgt   30          4.852 ?        0.063  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A          8  avgt   30          5.998 ?        0.199  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A         12  avgt   30          4.865 ?        0.072  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A         16  avgt   30          6.066 ?        0.162  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A         64  avgt   30          8.701 ?        0.271  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A        512  avgt   30         25.048 ?        0.412  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A       4096  avgt   30         56.409 ?        3.604  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A      32768  avgt   30        441.250 ?       22.357  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A     262144  avgt   30       5267.392 ?      429.547  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A    2097152  avgt   30      68314.550 ?     1918.564  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A   16777216  avgt   30    1371735.466 ?    84284.773  ns/op
SegmentBulkFill.Array.arraysFill                    N/A            N/A  134217728  avgt   30   13669724.771 ?   281394.365  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A          2  avgt   30          2.605 ?        0.056  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A          4  avgt   30          4.950 ?        0.271  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A          8  avgt   30          6.208 ?        0.143  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A         12  avgt   30          5.377 ?        0.239  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A         16  avgt   30          6.488 ?        0.123  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A         64  avgt   30         10.482 ?        0.370  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A        512  avgt   30         24.510 ?        4.586  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A       4096  avgt   30         48.521 ?        0.956  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A      32768  avgt   30        374.985 ?       19.047  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A     262144  avgt   30       4033.984 ?      280.488  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A    2097152  avgt   30      57462.641 ?     2235.699  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A   16777216  avgt   30    1171310.245 ?    76183.222  ns/op
SegmentBulkFill.Array.arraysFillLoop                N/A            N/A  134217728  avgt   30   12947567.600 ?   781527.989  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A          2  avgt   30          3.943 ?        0.070  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A          4  avgt   30          5.426 ?        0.170  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A          8  avgt   30          7.193 ?        0.599  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A         12  avgt   30          6.894 ?        0.236  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A         16  avgt   30          8.565 ?        0.160  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A         64  avgt   30         11.809 ?        0.453  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A        512  avgt   30         24.810 ?        1.155  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A       4096  avgt   30         51.998 ?        1.164  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A      32768  avgt   30        412.519 ?       17.135  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A     262144  avgt   30       4082.585 ?      227.410  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A    2097152  avgt   30      57716.233 ?     2702.127  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A   16777216  avgt   30    1140453.412 ?    90968.659  ns/op
SegmentBulkFill.Array.bufferFillLoop                N/A            N/A  134217728  avgt   30   12943176.334 ?  1046000.775  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP          2  avgt   30          2.756 ?        0.044  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP          4  avgt   30          2.677 ?        0.036  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP          8  avgt   30          3.996 ?        0.157  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP         12  avgt   30          5.032 ?        0.132  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP         16  avgt   30          4.578 ?        0.119  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP         64  avgt   30          7.952 ?        0.360  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP        512  avgt   30         11.243 ?        0.590  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP       4096  avgt   30         37.895 ?        0.500  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP      32768  avgt   30        405.947 ?       10.153  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP     262144  avgt   30       5332.738 ?      167.826  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP    2097152  avgt   30      58767.311 ?     5738.350  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP   16777216  avgt   30    1127931.502 ?    41006.916  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED           HEAP  134217728  avgt   30   12863038.809 ?   591834.479  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE          2  avgt   30          2.249 ?        0.034  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE          4  avgt   30          2.417 ?        0.073  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE          8  avgt   30          3.585 ?        0.144  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE         12  avgt   30          4.212 ?        0.089  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE         16  avgt   30          4.110 ?        0.135  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE         64  avgt   30          6.624 ?        0.113  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE        512  avgt   30         11.364 ?        0.642  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE       4096  avgt   30         37.917 ?        0.789  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE      32768  avgt   30        377.618 ?       25.495  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE     262144  avgt   30       6177.906 ?      352.228  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE    2097152  avgt   30      57378.200 ?     4766.598  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE   16777216  avgt   30    1164544.873 ?   102543.385  ns/op
SegmentBulkFill.Segment.fill                    ALIGNED         NATIVE  134217728  avgt   30   12665348.310 ?   176557.440  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP          2  avgt   30          2.725 ?        0.053  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP          4  avgt   30          2.689 ?        0.080  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP          8  avgt   30          3.966 ?        0.074  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP         12  avgt   30          5.079 ?        0.268  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP         16  avgt   30          4.595 ?        0.090  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP         64  avgt   30          8.154 ?        0.148  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP        512  avgt   30         12.213 ?        0.547  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP       4096  avgt   30         60.842 ?        2.209  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP      32768  avgt   30        550.950 ?       35.440  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP     262144  avgt   30       7141.146 ?      239.577  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP    2097152  avgt   30      65733.409 ?     3791.686  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP   16777216  avgt   30    1157433.794 ?    58691.589  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED           HEAP  134217728  avgt   30   13064794.269 ?   250020.512  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE          2  avgt   30          2.300 ?        0.042  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE          4  avgt   30          2.339 ?        0.040  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE          8  avgt   30          3.612 ?        0.084  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE         12  avgt   30          4.334 ?        0.142  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE         16  avgt   30          4.071 ?        0.180  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE         64  avgt   30          7.019 ?        0.111  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE        512  avgt   30         11.311 ?        0.607  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE       4096  avgt   30         57.471 ?        1.627  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE      32768  avgt   30        565.736 ?       48.133  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE     262144  avgt   30       6892.307 ?      312.206  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE    2097152  avgt   30      64365.408 ?     6443.033  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE   16777216  avgt   30    1174477.842 ?    38236.265  ns/op
SegmentBulkFill.Segment.fill                  UNALIGNED         NATIVE  134217728  avgt   30   13143443.609 ?   413401.360  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP          2  avgt   30          3.856 ?        0.064  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP          4  avgt   30          5.953 ?        0.152  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP          8  avgt   30          7.213 ?        0.325  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP         12  avgt   30          7.119 ?        0.139  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP         16  avgt   30          8.379 ?        0.370  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP         64  avgt   30         11.182 ?        0.241  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP        512  avgt   30         21.396 ?        0.944  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP       4096  avgt   30         52.136 ?        1.111  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP      32768  avgt   30        388.426 ?       29.256  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP     262144  avgt   30       3827.285 ?      133.255  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP    2097152  avgt   30      55762.090 ?     2488.630  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP   16777216  avgt   30    1554247.183 ?   940916.591  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED           HEAP  134217728  avgt   30    8964120.409 ?   558792.392  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE          2  avgt   30          3.001 ?        0.165  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE          4  avgt   30          4.948 ?        0.074  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE          8  avgt   30          5.630 ?        0.060  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE         12  avgt   30          5.785 ?        0.231  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE         16  avgt   30          6.521 ?        0.140  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE         64  avgt   30          9.519 ?        0.183  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE        512  avgt   30         24.401 ?        1.875  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE       4096  avgt   30         46.221 ?        2.476  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE      32768  avgt   30        347.152 ?       12.014  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE     262144  avgt   30       3429.537 ?      276.275  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE    2097152  avgt   30      49877.892 ?     1209.352  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE   16777216  avgt   30     596199.711 ?    30106.370  ns/op
SegmentBulkFill.Segment.fillLoopIntInt          ALIGNED         NATIVE  134217728  avgt   30    8777367.948 ?   293586.250  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP          2  avgt   30          3.298 ?        0.059  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP          4  avgt   30          4.930 ?        0.073  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP          8  avgt   30          6.140 ?        0.110  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP         12  avgt   30          6.189 ?        0.186  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP         16  avgt   30          6.941 ?        0.103  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP         64  avgt   30          9.419 ?        0.125  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP        512  avgt   30         18.482 ?        0.886  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP       4096  avgt   30         44.719 ?        1.705  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP      32768  avgt   30        343.314 ?       10.257  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP     262144  avgt   30       3347.846 ?       65.455  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP    2097152  avgt   30      49798.594 ?     1208.708  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP   16777216  avgt   30     595551.290 ?    26461.410  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED           HEAP  134217728  avgt   30    8687759.138 ?   151702.242  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE          2  avgt   30          3.035 ?        0.208  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE          4  avgt   30          4.799 ?        0.187  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE          8  avgt   30          5.460 ?        0.086  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE         12  avgt   30          5.474 ?        0.107  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE         16  avgt   30          6.387 ?        0.133  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE         64  avgt   30          9.560 ?        0.147  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE        512  avgt   30         23.269 ?        0.758  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE       4096  avgt   30         46.290 ?        0.973  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE      32768  avgt   30        341.239 ?        9.452  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE     262144  avgt   30       3629.545 ?      216.319  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE    2097152  avgt   30      49184.048 ?      757.276  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE   16777216  avgt   30     603341.049 ?    40715.473  ns/op
SegmentBulkFill.Segment.fillLoopIntInt        UNALIGNED         NATIVE  134217728  avgt   30    8761624.892 ?   168238.639  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP          2  avgt   30          3.153 ?        0.086  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP          4  avgt   30          4.252 ?        0.066  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP          8  avgt   30          6.681 ?        0.170  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP         12  avgt   30          9.091 ?        0.605  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP         16  avgt   30         11.256 ?        0.148  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP         64  avgt   30         45.952 ?        0.671  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP        512  avgt   30        313.569 ?       20.998  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP       4096  avgt   30       2454.926 ?       71.937  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP      32768  avgt   30      22526.439 ?     1366.339  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP     262144  avgt   30     173333.188 ?     5908.844  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP    2097152  avgt   30    1414814.178 ?    60803.270  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP   16777216  avgt   30   11485170.083 ?   363416.078  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED           HEAP  134217728  avgt   30   92595416.142 ?  5842945.762  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE          2  avgt   30          3.123 ?        0.073  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE          4  avgt   30          4.469 ?        0.176  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE          8  avgt   30          7.036 ?        0.166  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE         12  avgt   30          9.496 ?        0.202  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE         16  avgt   30         12.602 ?        0.459  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE         64  avgt   30         44.806 ?        3.424  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE        512  avgt   30        355.322 ?       23.344  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE       4096  avgt   30       2795.966 ?      126.485  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE      32768  avgt   30      21717.330 ?      868.518  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE     262144  avgt   30     176938.107 ?     5102.623  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE    2097152  avgt   30    1478073.243 ?   115315.137  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE   16777216  avgt   30   11869947.378 ?   829571.723  ns/op
SegmentBulkFill.Segment.fillLoopIntLong         ALIGNED         NATIVE  134217728  avgt   30   89816857.561 ?  2399773.905  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP          2  avgt   30          3.492 ?        0.179  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP          4  avgt   30          4.771 ?        0.193  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP          8  avgt   30          7.638 ?        0.766  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP         12  avgt   30          9.999 ?        0.337  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP         16  avgt   30         12.534 ?        0.347  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP         64  avgt   30         51.920 ?        1.637  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP        512  avgt   30        348.660 ?       18.903  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP       4096  avgt   30       2866.939 ?      252.666  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP      32768  avgt   30      22321.789 ?      643.336  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP     262144  avgt   30     176291.846 ?     8845.324  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP    2097152  avgt   30    1473804.228 ?   145882.061  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP   16777216  avgt   30   11750648.595 ?   769423.546  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED           HEAP  134217728  avgt   30   94109390.411 ?  4973749.859  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE          2  avgt   30          3.147 ?        0.085  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE          4  avgt   30          4.558 ?        0.186  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE          8  avgt   30          7.222 ?        0.262  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE         12  avgt   30          9.668 ?        0.263  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE         16  avgt   30         13.085 ?        0.100  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE         64  avgt   30         47.101 ?        1.990  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE        512  avgt   30        360.414 ?        9.968  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE       4096  avgt   30       2786.959 ?       85.607  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE      32768  avgt   30      23162.108 ?     1284.829  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE     262144  avgt   30     192940.139 ?    10496.283  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE    2097152  avgt   30    1460919.226 ?    12668.955  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE   16777216  avgt   30   11789089.779 ?   290992.568  ns/op
SegmentBulkFill.Segment.fillLoopIntLong       UNALIGNED         NATIVE  134217728  avgt   30   92727621.528 ?  1509157.607  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP          2  avgt   30          2.979 ?        0.053  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP          4  avgt   30          5.716 ?        0.123  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP          8  avgt   30          6.926 ?        0.219  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP         12  avgt   30          7.036 ?        0.202  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP         16  avgt   30          8.078 ?        0.504  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP         64  avgt   30         10.921 ?        0.288  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP        512  avgt   30         21.441 ?        0.568  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP       4096  avgt   30         51.188 ?        1.466  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP      32768  avgt   30        400.859 ?       19.988  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP     262144  avgt   30       3987.152 ?       98.156  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP    2097152  avgt   30      56335.624 ?     1719.755  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP   16777216  avgt   30    1135735.748 ?    49077.855  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED           HEAP  134217728  avgt   30   13060409.782 ?  1122635.466  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE          2  avgt   30          2.815 ?        0.069  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE          4  avgt   30          5.686 ?        0.285  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE          8  avgt   30          7.049 ?        0.285  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE         12  avgt   30          6.544 ?        0.339  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE         16  avgt   30          7.758 ?        0.174  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE         64  avgt   30         10.612 ?        0.514  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE        512  avgt   30         23.739 ?        2.458  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE       4096  avgt   30         55.276 ?        5.769  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE      32768  avgt   30        422.432 ?       20.117  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE     262144  avgt   30       4485.003 ?      315.418  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE    2097152  avgt   30      59755.061 ?     5166.429  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE   16777216  avgt   30    1232851.429 ?   145164.467  ns/op
SegmentBulkFill.Segment.fillLoopLongLong        ALIGNED         NATIVE  134217728  avgt   30   12759905.968 ?   331036.442  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP          2  avgt   30          3.240 ?        0.091  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP          4  avgt   30          5.348 ?        0.236  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP          8  avgt   30          6.710 ?        0.427  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP         12  avgt   30          6.794 ?        0.159  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP         16  avgt   30          7.965 ?        0.380  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP         64  avgt   30         10.785 ?        0.178  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP        512  avgt   30         22.685 ?        0.671  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP       4096  avgt   30         52.457 ?        0.629  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP      32768  avgt   30        411.368 ?       40.300  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP     262144  avgt   30       4018.323 ?      106.854  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP    2097152  avgt   30      56672.821 ?     3216.737  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP   16777216  avgt   30    1160619.879 ?    63601.665  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED           HEAP  134217728  avgt   30   13073144.328 ?   878206.096  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE          2  avgt   30          2.778 ?        0.046  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE          4  avgt   30          5.294 ?        0.123  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE          8  avgt   30          6.530 ?        0.150  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE         12  avgt   30          6.257 ?        0.481  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE         16  avgt   30          7.436 ?        0.161  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE         64  avgt   30         10.501 ?        0.629  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE        512  avgt   30         24.646 ?        1.884  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE       4096  avgt   30         51.028 ?        0.654  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE      32768  avgt   30        413.980 ?       37.104  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE     262144  avgt   30       4055.084 ?      216.524  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE    2097152  avgt   30      57270.811 ?     2232.847  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE   16777216  avgt   30    1140870.951 ?    57134.743  ns/op
SegmentBulkFill.Segment.fillLoopLongLong      UNALIGNED         NATIVE  134217728  avgt   30   12628578.069 ?   236192.786  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP          2  avgt   30          5.598 ?        0.241  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP          4  avgt   30          4.794 ?        0.072  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP          8  avgt   30          4.279 ?        0.105  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP         12  avgt   30          5.232 ?        0.410  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP         16  avgt   30          4.311 ?        0.066  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP         64  avgt   30          5.543 ?        0.240  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP        512  avgt   30         18.023 ?        0.350  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP       4096  avgt   30        136.178 ?        6.362  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP      32768  avgt   30       1198.318 ?       37.850  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP     262144  avgt   30      11085.452 ?      906.724  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP    2097152  avgt   30      91914.903 ?     5074.303  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP   16777216  avgt   30    1263137.568 ?    39016.298  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED           HEAP  134217728  avgt   30   12866053.630 ?   581664.548  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE          2  avgt   30          4.978 ?        0.057  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE          4  avgt   30          4.575 ?        0.087  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE          8  avgt   30          3.880 ?        0.102  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE         12  avgt   30          4.951 ?        0.200  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE         16  avgt   30          4.146 ?        0.239  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE         64  avgt   30          5.847 ?        0.248  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE        512  avgt   30         22.373 ?        1.025  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE       4096  avgt   30        163.615 ?        4.005  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE      32768  avgt   30       1406.803 ?       30.126  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE     262144  avgt   30      11930.156 ?      246.601  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE    2097152  avgt   30     107398.708 ?     2787.772  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE   16777216  avgt   30    1491074.142 ?    43116.735  ns/op
SegmentBulkFill.Segment.fillUnsafe              ALIGNED         NATIVE  134217728  avgt   30   14252786.576 ?   453715.979  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP          2  avgt   30          8.846 ?        0.180  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP          4  avgt   30          9.013 ?        0.171  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP          8  avgt   30          9.400 ?        0.310  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP         12  avgt   30          9.901 ?        0.279  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP         16  avgt   30         10.172 ?        0.142  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP         64  avgt   30          9.463 ?        0.315  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP        512  avgt   30         11.753 ?        0.160  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP       4096  avgt   30         66.819 ?        1.200  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP      32768  avgt   30        654.098 ?       36.482  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP     262144  avgt   30       6788.187 ?      200.604  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP    2097152  avgt   30      76146.809 ?     4422.446  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP   16777216  avgt   30    1432904.148 ?    42147.324  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED           HEAP  134217728  avgt   30   15508887.036 ?  1224423.815  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE          2  avgt   30          8.165 ?        0.233  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE          4  avgt   30          8.382 ?        0.405  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE          8  avgt   30          8.965 ?        0.198  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE         12  avgt   30          9.443 ?        0.411  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE         16  avgt   30          9.898 ?        0.128  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE         64  avgt   30          8.701 ?        0.139  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE        512  avgt   30         11.719 ?        0.921  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE       4096  avgt   30         68.990 ?        0.870  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE      32768  avgt   30        677.396 ?       23.859  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE     262144  avgt   30       7021.868 ?      145.703  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE    2097152  avgt   30      75492.188 ?     4682.203  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE   16777216  avgt   30    1446093.339 ?    54079.719  ns/op
SegmentBulkFill.Segment.fillUnsafe            UNALIGNED         NATIVE  134217728  avgt   30   14862352.444 ?   406730.811  ns/op
SegmentBulkHash.Array.array                         N/A            N/A          2  avgt   30          3.052 ?        0.073  ns/op
SegmentBulkHash.Array.array                         N/A            N/A          4  avgt   30          3.775 ?        0.064  ns/op
SegmentBulkHash.Array.array                         N/A            N/A          8  avgt   30          4.882 ?        0.077  ns/op
SegmentBulkHash.Array.array                         N/A            N/A         12  avgt   30          6.495 ?        0.133  ns/op
SegmentBulkHash.Array.array                         N/A            N/A         16  avgt   30          8.801 ?        0.389  ns/op
SegmentBulkHash.Array.array                         N/A            N/A         64  avgt   30         19.767 ?        0.311  ns/op
SegmentBulkHash.Array.array                         N/A            N/A        512  avgt   30         72.175 ?        1.000  ns/op
SegmentBulkHash.Array.array                         N/A            N/A       4096  avgt   30        501.395 ?        6.561  ns/op
SegmentBulkHash.Array.array                         N/A            N/A      32768  avgt   30       3929.496 ?       84.002  ns/op
SegmentBulkHash.Array.array                         N/A            N/A     262144  avgt   30      34902.830 ?     4701.980  ns/op
SegmentBulkHash.Array.array                         N/A            N/A    2097152  avgt   30    2019938.327 ?    40435.482  ns/op
SegmentBulkHash.Array.array                         N/A            N/A   16777216  avgt   30   16066908.487 ?   272793.694  ns/op
SegmentBulkHash.Array.array                         N/A            N/A  134217728  avgt   30  126584818.785 ?  4031437.144  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP          2  avgt   30          4.091 ?        0.143  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP          4  avgt   30          7.392 ?        0.290  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP          8  avgt   30         13.304 ?        0.283  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP         12  avgt   30         15.126 ?        0.267  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP         16  avgt   30         15.597 ?        0.292  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP         64  avgt   30         47.543 ?        9.674  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP        512  avgt   30        303.184 ?        5.162  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP       4096  avgt   30       2327.241 ?       45.114  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP      32768  avgt   30      18947.118 ?      424.749  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP     262144  avgt   30     154832.873 ?    12186.696  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP    2097152  avgt   30    1266417.521 ?    27077.922  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP   16777216  avgt   30   10591942.734 ?   654278.036  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED           HEAP  134217728  avgt   30   86635695.591 ?  1616951.849  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE          2  avgt   30          5.283 ?        0.153  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE          4  avgt   30          4.411 ?        0.250  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE          8  avgt   30         11.674 ?        0.171  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE         12  avgt   30         13.819 ?        0.227  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE         16  avgt   30         16.083 ?        0.809  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE         64  avgt   30         47.437 ?        0.681  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE        512  avgt   30        335.044 ?       15.056  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE       4096  avgt   30       2588.463 ?       69.043  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE      32768  avgt   30      20510.255 ?      449.978  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE     262144  avgt   30     179188.480 ?     4034.207  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE    2097152  avgt   30    1418511.735 ?   147213.033  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE   16777216  avgt   30   11560988.594 ?   579584.272  ns/op
SegmentBulkHash.Segment.hash                    ALIGNED         NATIVE  134217728  avgt   30   90755967.028 ?  1099511.306  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP          2  avgt   30          4.205 ?        0.325  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP          4  avgt   30          6.859 ?        0.140  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP          8  avgt   30         13.153 ?        1.050  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP         12  avgt   30         15.755 ?        0.758  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP         16  avgt   30         16.535 ?        0.382  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP         64  avgt   30         45.125 ?        0.905  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP        512  avgt   30        306.289 ?        5.401  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP       4096  avgt   30       2371.146 ?       65.929  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP      32768  avgt   30      20674.436 ?     1736.187  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP     262144  avgt   30     158443.373 ?     5769.276  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP    2097152  avgt   30    1345564.113 ?    68361.380  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP   16777216  avgt   30   10380406.319 ?   185474.601  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED           HEAP  134217728  avgt   30   83178106.626 ?  2480277.374  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE          2  avgt   30          5.253 ?        0.163  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE          4  avgt   30          4.600 ?        0.070  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE          8  avgt   30         12.277 ?        0.215  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE         12  avgt   30         14.304 ?        0.703  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE         16  avgt   30         15.929 ?        0.278  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE         64  avgt   30         44.941 ?        0.835  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE        512  avgt   30        324.829 ?        6.347  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE       4096  avgt   30       2529.040 ?       39.184  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE      32768  avgt   30      20554.561 ?      443.045  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE     262144  avgt   30     181531.537 ?     8689.609  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE    2097152  avgt   30    1388093.212 ?    45796.893  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE   16777216  avgt   30   10784789.521 ?   178897.169  ns/op
SegmentBulkHash.Segment.hash                  UNALIGNED         NATIVE  134217728  avgt   30   88034069.719 ?  2172037.337  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP          2  avgt   30          5.295 ?        0.082  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP          4  avgt   30          6.315 ?        0.095  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP          8  avgt   30          9.539 ?        0.178  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP         12  avgt   30         11.381 ?        0.178  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP         16  avgt   30         13.957 ?        1.125  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP         64  avgt   30         54.664 ?        1.040  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP        512  avgt   30        464.357 ?        6.281  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP       4096  avgt   30       3833.414 ?       54.682  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP      32768  avgt   30      29866.700 ?      605.533  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP     262144  avgt   30     237251.512 ?     9012.938  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP    2097152  avgt   30    1920687.928 ?    55677.219  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP   16777216  avgt   30   16041668.724 ?  1078432.415  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED           HEAP  134217728  avgt   30  132116094.756 ?  7557126.595  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE          2  avgt   30          4.735 ?        0.167  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE          4  avgt   30          5.501 ?        0.079  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE          8  avgt   30          9.164 ?        0.461  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE         12  avgt   30         10.908 ?        0.211  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE         16  avgt   30         13.127 ?        0.561  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE         64  avgt   30         55.078 ?        0.729  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE        512  avgt   30        463.711 ?       19.495  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE       4096  avgt   30       3690.981 ?      116.852  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE      32768  avgt   30      30095.124 ?     1099.632  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE     262144  avgt   30     236215.102 ?     3880.274  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE    2097152  avgt   30    1958083.325 ?    43109.881  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE   16777216  avgt   30   15914096.222 ?   267012.365  ns/op
SegmentBulkHash.Segment.hashLoopIntInt          ALIGNED         NATIVE  134217728  avgt   30  129208503.707 ?  7177406.123  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP          2  avgt   30          5.135 ?        0.102  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP          4  avgt   30          6.159 ?        0.087  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP          8  avgt   30          9.617 ?        0.134  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP         12  avgt   30         11.819 ?        0.624  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP         16  avgt   30         13.451 ?        0.202  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP         64  avgt   30         58.634 ?        3.831  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP        512  avgt   30        484.861 ?       18.138  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP       4096  avgt   30       3703.402 ?      225.221  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP      32768  avgt   30      28717.652 ?      622.694  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP     262144  avgt   30     239102.113 ?     6977.171  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP    2097152  avgt   30    1981403.319 ?    43954.872  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP   16777216  avgt   30   15951221.198 ?   293043.625  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED           HEAP  134217728  avgt   30  125346439.372 ?  3362020.105  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE          2  avgt   30          4.684 ?        0.137  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE          4  avgt   30          5.714 ?        0.303  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE          8  avgt   30          9.223 ?        0.121  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE         12  avgt   30         10.925 ?        0.193  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE         16  avgt   30         13.069 ?        0.464  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE         64  avgt   30         50.319 ?        1.591  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE        512  avgt   30        414.633 ?        9.396  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE       4096  avgt   30       3294.024 ?      165.441  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE      32768  avgt   30      27169.404 ?      602.143  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE     262144  avgt   30     217684.995 ?     4206.871  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE    2097152  avgt   30    1846702.853 ?    89997.725  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE   16777216  avgt   30   14514508.876 ?   375205.121  ns/op
SegmentBulkHash.Segment.hashLoopIntInt        UNALIGNED         NATIVE  134217728  avgt   30  112580356.427 ?  2914292.280  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP          2  avgt   30          4.006 ?        0.113  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP          4  avgt   30          6.028 ?        0.124  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP          8  avgt   30         10.783 ?        0.233  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP         12  avgt   30         15.612 ?        0.133  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP         16  avgt   30         19.682 ?        0.739  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP         64  avgt   30         70.314 ?        1.087  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP        512  avgt   30        558.909 ?        9.113  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP       4096  avgt   30       4480.011 ?       94.518  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP      32768  avgt   30      34188.185 ?     2313.115  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP     262144  avgt   30     294829.556 ?    10266.511  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP    2097152  avgt   30    2452939.965 ?   157456.584  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP   16777216  avgt   30   18913892.896 ?   615819.913  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED           HEAP  134217728  avgt   30  149760257.733 ?  6996009.704  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE          2  avgt   30          3.525 ?        0.090  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE          4  avgt   30          5.614 ?        0.193  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE          8  avgt   30          9.778 ?        0.147  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE         12  avgt   30         13.743 ?        0.309  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE         16  avgt   30         17.534 ?        0.432  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE         64  avgt   30         65.434 ?        2.455  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE        512  avgt   30        513.824 ?       11.062  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE       4096  avgt   30       4144.101 ?      116.974  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE      32768  avgt   30      33135.608 ?     1495.217  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE     262144  avgt   30     250953.002 ?    14725.362  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE    2097152  avgt   30    2048169.400 ?    52345.100  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE   16777216  avgt   30   16664138.815 ?   461299.518  ns/op
SegmentBulkHash.Segment.hashLoopIntLong         ALIGNED         NATIVE  134217728  avgt   30  129126878.548 ?  3024481.009  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP          2  avgt   30          4.356 ?        0.227  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP          4  avgt   30          6.197 ?        0.130  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP          8  avgt   30         10.662 ?        0.646  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP         12  avgt   30         14.349 ?        0.316  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP         16  avgt   30         19.093 ?        0.494  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP         64  avgt   30         70.106 ?        1.884  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP        512  avgt   30        544.297 ?       12.833  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP       4096  avgt   30       4372.754 ?      193.958  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP      32768  avgt   30      34757.320 ?     1008.118  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP     262144  avgt   30     281163.668 ?     8733.767  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP    2097152  avgt   30    2275227.467 ?    66365.311  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP   16777216  avgt   30   18616901.123 ?   763503.681  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED           HEAP  134217728  avgt   30  150196423.475 ?  3775137.479  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE          2  avgt   30          3.597 ?        0.097  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE          4  avgt   30          5.781 ?        0.116  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE          8  avgt   30          9.613 ?        0.473  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE         12  avgt   30         13.479 ?        0.367  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE         16  avgt   30         17.690 ?        0.473  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE         64  avgt   30         64.367 ?        1.823  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE        512  avgt   30        533.592 ?       25.148  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE       4096  avgt   30       4137.472 ?       81.658  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE      32768  avgt   30      32835.333 ?      941.310  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE     262144  avgt   30     250465.594 ?     6009.723  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE    2097152  avgt   30    2060451.538 ?    47109.585  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE   16777216  avgt   30   16499345.369 ?   456107.693  ns/op
SegmentBulkHash.Segment.hashLoopIntLong       UNALIGNED         NATIVE  134217728  avgt   30  132985049.782 ?  3829087.858  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP          2  avgt   30          3.850 ?        0.119  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP          4  avgt   30          5.349 ?        0.136  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP          8  avgt   30          8.303 ?        0.249  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP         12  avgt   30          9.933 ?        0.277  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP         16  avgt   30         11.857 ?        0.314  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP         64  avgt   30         49.017 ?        0.680  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP        512  avgt   30        413.991 ?       22.002  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP       4096  avgt   30       3312.720 ?      113.281  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP      32768  avgt   30      26523.251 ?     1451.185  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP     262144  avgt   30     210134.671 ?     8574.475  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP    2097152  avgt   30    1791219.800 ?   201769.996  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP   16777216  avgt   30   14596628.891 ?   967811.964  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED           HEAP  134217728  avgt   30  112525842.722 ?  4155179.656  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE          2  avgt   30          2.948 ?        0.113  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE          4  avgt   30          4.638 ?        0.107  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE          8  avgt   30          7.691 ?        0.151  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE         12  avgt   30          9.623 ?        0.645  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE         16  avgt   30         11.552 ?        0.522  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE         64  avgt   30         46.218 ?        1.255  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE        512  avgt   30        403.379 ?       22.356  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE       4096  avgt   30       3198.038 ?       91.503  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE      32768  avgt   30      26164.119 ?      920.916  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE     262144  avgt   30     212842.173 ?    22187.390  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE    2097152  avgt   30    1675198.860 ?    40245.667  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE   16777216  avgt   30   14834005.950 ?  1261213.575  ns/op
SegmentBulkHash.Segment.hashLoopLongLong        ALIGNED         NATIVE  134217728  avgt   30  111573019.160 ?  2921742.637  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP          2  avgt   30          3.872 ?        0.117  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP          4  avgt   30          5.267 ?        0.105  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP          8  avgt   30          8.763 ?        0.272  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP         12  avgt   30         10.124 ?        0.243  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP         16  avgt   30         11.581 ?        0.313  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP         64  avgt   30         45.962 ?        1.750  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP        512  avgt   30        405.016 ?       13.564  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP       4096  avgt   30       3287.824 ?      172.100  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP      32768  avgt   30      25475.386 ?      441.917  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP     262144  avgt   30     209870.657 ?     5216.265  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP    2097152  avgt   30    1769129.725 ?    58241.406  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP   16777216  avgt   30   13707478.676 ?   266393.309  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED           HEAP  134217728  avgt   30  112739727.453 ?  7769604.822  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE          2  avgt   30          2.886 ?        0.079  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE          4  avgt   30          4.667 ?        0.270  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE          8  avgt   30          8.015 ?        0.315  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE         12  avgt   30          9.239 ?        0.220  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE         16  avgt   30         11.215 ?        0.434  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE         64  avgt   30         46.295 ?        1.090  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE        512  avgt   30        399.351 ?       11.091  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE       4096  avgt   30       3256.777 ?      163.581  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE      32768  avgt   30      26413.393 ?     1134.787  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE     262144  avgt   30     206927.246 ?     6953.168  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE    2097152  avgt   30    1725673.656 ?   125464.741  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE   16777216  avgt   30   14256690.063 ?   702152.919  ns/op
SegmentBulkHash.Segment.hashLoopLongLong      UNALIGNED         NATIVE  134217728  avgt   30  113607895.883 ?  5447605.701  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A          2  avgt   30          3.939 ?        0.108  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A          4  avgt   30          6.178 ?        0.134  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A          8  avgt   30          5.528 ?        0.064  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A         12  avgt   30          6.855 ?        0.189  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A         16  avgt   30          5.908 ?        0.148  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A         64  avgt   30          7.831 ?        0.422  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A        512  avgt   30         16.293 ?        0.101  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A       4096  avgt   30         87.389 ?        1.550  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A      32768  avgt   30       1080.677 ?       10.171  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A     262144  avgt   30      11717.150 ?      156.616  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A    2097152  avgt   30     111850.756 ?     7448.346  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A   16777216  avgt   30    2167848.824 ?   151850.669  ns/op
SegmentBulkMismatch.Array.array                     N/A            N/A  134217728  avgt   30   18565333.636 ?  1132998.214  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP          2  avgt   30          4.290 ?        0.496  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP          4  avgt   30         11.161 ?        6.106  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP          8  avgt   30          7.226 ?        0.100  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP         12  avgt   30         10.082 ?        7.990  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP         16  avgt   30         14.751 ?        8.379  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP         64  avgt   30         10.213 ?        0.136  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP        512  avgt   30         53.631 ?       37.178  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP       4096  avgt   30        713.728 ?        5.858  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP      32768  avgt   30      15164.751 ?    31489.111  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP     262144  avgt   30      69135.635 ?    19709.732  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP    2097152  avgt   30     766200.949 ?    15096.957  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP   16777216  avgt   30    7915336.495 ? 11913179.591  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED           HEAP  134217728  avgt   30   58005435.115 ?   457212.450  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE          2  avgt   30         18.449 ?       23.255  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE          4  avgt   30         18.945 ?        0.076  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE          8  avgt   30         25.379 ?        0.257  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE         12  avgt   30         32.151 ?        0.828  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE         16  avgt   30         28.853 ?        0.911  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE         64  avgt   30         49.209 ?        0.304  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE        512  avgt   30        136.104 ?       10.041  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE       4096  avgt   30        687.266 ?       11.130  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE      32768  avgt   30       8587.788 ?      117.831  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE     262144  avgt   30      78358.540 ?     1208.940  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE    2097152  avgt   30     662386.121 ?    34962.960  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE   16777216  avgt   30    6720416.372 ?   114003.333  ns/op
SegmentBulkMismatch.Segment.mismatch            ALIGNED         NATIVE  134217728  avgt   30   57084945.524 ?   850139.934  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP          2  avgt   30         14.919 ?        5.386  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP          4  avgt   30         23.321 ?        0.772  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP          8  avgt   30         39.943 ?        0.716  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP         12  avgt   30         42.268 ?        0.529  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP         16  avgt   30         32.148 ?        0.416  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP         64  avgt   30         56.173 ?        0.821  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP        512  avgt   30        142.538 ?        4.219  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP       4096  avgt   30        774.853 ?       13.546  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP      32768  avgt   30       9167.731 ?       78.903  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP     262144  avgt   30      91597.241 ?     4900.530  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP    2097152  avgt   30     842782.906 ?    15747.147  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP   16777216  avgt   30    7277156.100 ?   101085.254  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED           HEAP  134217728  avgt   30   61493285.865 ?  1019638.868  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE          2  avgt   30         19.535 ?        0.922  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE          4  avgt   30         19.230 ?        0.384  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE          8  avgt   30         25.504 ?        0.312  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE         12  avgt   30         31.900 ?        0.419  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE         16  avgt   30         28.714 ?        0.370  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE         64  avgt   30         49.879 ?        0.797  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE        512  avgt   30        136.397 ?        4.808  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE       4096  avgt   30        764.847 ?       12.174  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE      32768  avgt   30       9253.348 ?       98.881  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE     262144  avgt   30      83163.957 ?      900.401  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE    2097152  avgt   30     710950.023 ?    39960.368  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE   16777216  avgt   30    7221306.721 ?   137023.489  ns/op
SegmentBulkMismatch.Segment.mismatch          UNALIGNED         NATIVE  134217728  avgt   30   59890191.233 ?   870684.086  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP          2  avgt   30         25.830 ?        0.393  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP          4  avgt   30         26.301 ?        0.519  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP          8  avgt   30         71.545 ?        1.097  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP         12  avgt   30         77.977 ?        1.713  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP         16  avgt   30         73.786 ?        0.626  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP         64  avgt   30         81.581 ?        1.675  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP        512  avgt   30        119.228 ?        1.844  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP       4096  avgt   30        456.995 ?       24.367  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP      32768  avgt   30       4481.308 ?       35.648  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP     262144  avgt   30      45589.165 ?     1716.776  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP    2097152  avgt   30     403169.474 ?    17076.681  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP   16777216  avgt   30    4642090.517 ?   121575.584  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED           HEAP  134217728  avgt   30   48013194.619 ?   929404.849  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE          2  avgt   30         22.930 ?        0.299  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE          4  avgt   30         25.148 ?        1.315  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE          8  avgt   30         44.011 ?        0.515  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE         12  avgt   30         61.016 ?        0.556  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE         16  avgt   30         56.859 ?       10.639  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE         64  avgt   30         60.748 ?        1.314  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE        512  avgt   30        137.795 ?        1.650  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE       4096  avgt   30        716.042 ?       16.302  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE      32768  avgt   30       8623.405 ?      101.389  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE     262144  avgt   30      78277.430 ?     1110.730  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE    2097152  avgt   30     626247.241 ?     5525.070  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE   16777216  avgt   30    4425153.445 ?   170061.993  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe      ALIGNED         NATIVE  134217728  avgt   30   48238452.400 ?   525455.147  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP          2  avgt   30         25.799 ?        0.440  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP          4  avgt   30         26.336 ?        0.379  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP          8  avgt   30         72.386 ?        1.922  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP         12  avgt   30         77.652 ?        0.988  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP         16  avgt   30         74.450 ?        1.895  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP         64  avgt   30         81.869 ?        1.229  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP        512  avgt   30        119.479 ?        2.070  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP       4096  avgt   30        452.108 ?        9.962  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP      32768  avgt   30       4719.002 ?       37.613  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP     262144  avgt   30      49001.490 ?      949.062  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP    2097152  avgt   30     406695.022 ?    10264.106  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP   16777216  avgt   30    4628509.780 ?   145190.807  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED           HEAP  134217728  avgt   30   51253002.341 ?   503920.110  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE          2  avgt   30         23.056 ?        0.388  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE          4  avgt   30         24.274 ?        0.434  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE          8  avgt   30         44.712 ?        2.130  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE         12  avgt   30         61.078 ?        0.650  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE         16  avgt   30         49.399 ?        3.390  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE         64  avgt   30         60.305 ?        0.958  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE        512  avgt   30        147.382 ?        5.807  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE       4096  avgt   30        783.496 ?        9.190  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE      32768  avgt   30       9257.377 ?      115.583  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE     262144  avgt   30      83902.943 ?      696.899  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE    2097152  avgt   30     668607.217 ?     9861.555  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE   16777216  avgt   30    4604291.659 ?   173468.211  ns/op
SegmentBulkMismatch.Segment.mismatchUnsafe    UNALIGNED         NATIVE  134217728  avgt   30   50673549.745 ?   500571.775  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28260#issuecomment-3531221623

From pminborg at openjdk.org  Fri Nov 14 07:17:26 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 07:17:26 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v2]
In-Reply-To: <V55raivd_O60gWUqkcnE9OKZbRU9Ie63ckJRQJKDF4A=.ddbe3874-9038-44ec-8b00-6fa6fa8eab78@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <V55raivd_O60gWUqkcnE9OKZbRU9Ie63ckJRQJKDF4A=.ddbe3874-9038-44ec-8b00-6fa6fa8eab78@github.com>
Message-ID: <9OoMaG-ys_WRQrnshbzEasKA1QAMHSe2oqvkOSvSwyM=.6b50c215-0b39-4b23-bfd7-213ed076bc41@github.com>

On Thu, 13 Nov 2025 18:42:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove lingering comment
>  - Refactor and use long arrays
>  - Remove BulkOps

Would it be interesting to use loop-based mismatch benchmarks as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28260#issuecomment-3531236812

From swen at openjdk.org  Fri Nov 14 08:03:20 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 14 Nov 2025 08:03:20 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v22]
In-Reply-To: <gOqebHyurDwwkxa0E8WzV4cL9_e9so0K8Gd_xGnPDXo=.12a703a3-ebfb-45ed-b9d2-dc09d7362fa1@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <gOqebHyurDwwkxa0E8WzV4cL9_e9so0K8Gd_xGnPDXo=.12a703a3-ebfb-45ed-b9d2-dc09d7362fa1@github.com>
Message-ID: <DbzfVLQH3BzCnAh-4hMf-uBa1hVDDdJ2NpWEawXfQz0=.250b2327-27e3-41c2-af3e-72461de21644@github.com>

On Fri, 14 Nov 2025 04:46:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove JLA

I wanted to modify the DecimalDigits.appendQuad method as follows, but this caused `MergeStore` to not work.

    public static void appendQuad(StringBuilder buf, int v) {
        // The & 0x7f operation keeps the index within the safe range [0, 127] for the DIGITS array,
        // which allows the JIT compiler to eliminate array bounds checks for performance.
        int packed = DIGITS[(v / 100) & 0x7f] | (DIGITS[(v % 100) & 0x7f] << 16);
        // The temporary String and byte[] objects created here are typically eliminated
        // by the JVM's escape analysis and scalar replacement optimizations during
        // runtime compilation, avoiding actual heap allocations in optimized code.
        buf.append(
                JLA.uncheckedNewStringWithLatin1Bytes(
                        new byte[] {(byte) packed,         (byte) (packed >> 8),
                                    (byte) (packed >> 16), (byte) (packed  >> 24)}));
    }


The output is as follows:

[TraceMergeStores] MergePrimitiveStores::run:  868  StoreB  === 887 813 861 145  [[ 872 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None
[TraceMergeStores] MergePrimitiveStores::run:  848  StoreB  === 888 813 840 81  [[ 853 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None
[TraceMergeStores] MergePrimitiveStores::run:  559  StoreB  === 548 543 351 352  [[ 562 ]]  @java/lang/AbstractStringBuilder (java/lang/CharSequence,java/lang/Appendable)+16 *, name=coder, idx=13;  Memory: @java/lang/StringBuilder (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/Appendable):NotNull:exact+16 *, name=coder, idx=13; !jvms: AbstractStringBuilder::append @ bci:78 (line 651) StringBuilder::append @ bci:2 (line 179) DecimalDigits::appendQuad @ bci:68 (line 496)
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None
[TraceMergeStores] MergePrimitiveStores::run:  739  StoreI  === 879 813 354 456  [[ 17 ]]  @java/lang/AbstractStringBuilder (java/lang/CharSequence,java/lang/Appendable)+12 *, name=count, idx=14;  Memory: @java/lang/StringBuilder (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/Appendable):NotNull:exact+12 *, name=count, idx=14; !jvms: AbstractStringBuilder::append @ bci:95 (line 654) StringBuilder::append @ bci:2 (line 179) DecimalDigits::appendQuad @ bci:68 (line 496)
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None
[TraceMergeStores] MergePrimitiveStores::run:  872  StoreB  === 887 868 856 912  [[ 876 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None
[TraceMergeStores] MergePrimitiveStores::run:  853  StoreB  === 888 848 851 906  [[ 858 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None
[TraceMergeStores] MergePrimitiveStores::run:  858  StoreB  === 888 853 856 912  [[ 863 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None
[TraceMergeStores] MergePrimitiveStores::run:  863  StoreB  === 888 858 861 145  [[ 880 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None
[TraceMergeStores] MergePrimitiveStores::run:  876  StoreB  === 887 872 851 906  [[ 878 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None
[TraceMergeStores] MergePrimitiveStores::run:  878  StoreB  === 887 876 840 81  [[ 880 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
[TraceMergeStores] expect no use: None
[TraceMergeStores] expect def: None

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3531435995

From jsjolen at openjdk.org  Fri Nov 14 08:15:03 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 14 Nov 2025 08:15:03 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory
In-Reply-To: <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <yLZbmcbjk47PQGcrS8MUXJsbcbAFxwUO2zut-7DNuTo=.55d2c6c7-b195-489f-b16d-9bc31a2e7899@github.com>
Message-ID: <WR6ZjFJ0qdIz8Pjvi4s50Q_G7eGpvsgjI9iX6DYw2bA=.94419b07-3376-45eb-9311-340b1eea3f88@github.com>

On Wed, 12 Nov 2025 11:19:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Yeah, that would be nice -- but I noticed that posix_memalign is currently not allowed in hotspot code:

That is because NMT doesn't support allocations with alignment `>16` bytes at the moment. In Hotspot, we've been working with the assumption of 16 byte alignment, due to the C standard (as per Kim's comment).

Supporting `posix_memalign` isn't impossible, it's simply not been a priority.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3531492676

From pminborg at openjdk.org  Fri Nov 14 09:08:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 09:08:58 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v3]
In-Reply-To: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
Message-ID: <l1o8YHINy5EBfwuaDYBi4W_lnri1iZ-Uenu-L2UZH94=.9e7d3389-acd3-43d4-896f-f9e2e9c8474c@github.com>

> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
> 
> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
> 
> It should be noted that with this change, the running time for the benchmarks would increase significantly.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Use other allocateFrom overload

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28260/files
  - new: https://git.openjdk.org/jdk/pull/28260/files/ab303deb..f0d633d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28260&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28260&range=01-02

  Stats: 8 lines in 4 files changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28260/head:pull/28260

PR: https://git.openjdk.org/jdk/pull/28260

From epeter at openjdk.org  Fri Nov 14 09:39:06 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 14 Nov 2025 09:39:06 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v22]
In-Reply-To: <DbzfVLQH3BzCnAh-4hMf-uBa1hVDDdJ2NpWEawXfQz0=.250b2327-27e3-41c2-af3e-72461de21644@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <gOqebHyurDwwkxa0E8WzV4cL9_e9so0K8Gd_xGnPDXo=.12a703a3-ebfb-45ed-b9d2-dc09d7362fa1@github.com>
 <DbzfVLQH3BzCnAh-4hMf-uBa1hVDDdJ2NpWEawXfQz0=.250b2327-27e3-41c2-af3e-72461de21644@github.com>
Message-ID: <6fUVNpVtE02hzyMyGDnYTOI4IkrtlD3rqQIxtU5-ahY=.84d4b4cd-6b2f-48ba-a69f-22318b3301d0@github.com>

On Fri, 14 Nov 2025 07:59:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove JLA
>
> I wanted to modify the DecimalDigits.appendQuad method as follows, but this caused `MergeStore` to not work.
> 
>     public static void appendQuad(StringBuilder buf, int v) {
>         // The & 0x7f operation keeps the index within the safe range [0, 127] for the DIGITS array,
>         // which allows the JIT compiler to eliminate array bounds checks for performance.
>         int packed = DIGITS[(v / 100) & 0x7f] | (DIGITS[(v % 100) & 0x7f] << 16);
>         // The temporary String and byte[] objects created here are typically eliminated
>         // by the JVM's escape analysis and scalar replacement optimizations during
>         // runtime compilation, avoiding actual heap allocations in optimized code.
>         buf.append(
>                 JLA.uncheckedNewStringWithLatin1Bytes(
>                         new byte[] {(byte) packed,         (byte) (packed >> 8),
>                                     (byte) (packed >> 16), (byte) (packed  >> 24)}));
>     }
> 
> 
> The output is as follows:
> 
> [TraceMergeStores] MergePrimitiveStores::run:  868  StoreB  === 887 813 861 145  [[ 872 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
> [TraceMergeStores] expect no use: None
> [TraceMergeStores] expect def: None
> [TraceMergeStores] MergePrimitiveStores::run:  848  StoreB  === 888 813 840 81  [[ 853 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
> [TraceMergeStores] expect no use: None
> [TraceMergeStores] expect def: None
> [TraceMergeStores] MergePrimitiveStores::run:  559  StoreB  === 548 543 351 352  [[ 562 ]]  @java/lang/AbstractStringBuilder (java/lang/CharSequence,java/lang/Appendable)+16 *, name=coder, idx=13;  Memory: @java/lang/StringBuilder (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/Appendable):NotNull:exact+16 *, name=coder, idx=13; !jvms: AbstractStringBuilder::append @ bci:78 (line 651) StringBuilder::append @ bci:2 (line 179) DecimalDigits::appendQuad @ bci:68 (line 496)
> [TraceMergeStores] expect no use: None
> [TraceMergeStores] expect def: None
> [TraceMergeStores] MergePrimitiveStores::run:  739  StoreI  === 879 813 354 456  [[ 17 ]]  @java/lang/AbstractStringBuilder (java/lang/CharSequence,java/lang/Appendable)+12 *, name=count, idx=14;  Memory: @java/lang/StringBuilder (java/io/Serializ...

@wenshao I see. I suspect that your `packed` is deconstructed into byte parts by C2 optimizations.

What happens if you route the `packed` value through some non-inlined method?


        int packed = DIGITS[(v / 100) & 0x7f] | (DIGITS[(v % 100) & 0x7f] << 16);
        packed = dontinline(packed); // prevents optimizations
        // The temporary String and byte[] objects created here are typically eliminated
        // by the JVM's escape analysis and scalar replacement optimizations during
        // runtime compilation, avoiding actual heap allocations in optimized code.
        buf.append(
                JLA.uncheckedNewStringWithLatin1Bytes(
                        new byte[] {(byte) packed,         (byte) (packed >> 8),
                                    (byte) (packed >> 16), (byte) (packed  >> 24)}));

The issue is probably that `packed >> 16)` in the lower part sees that it only requires the values from `DIGITS[(v % 100) & 0x7f] << 16`, and just redirects things, and folds away the shifts. C2 does a lot of smart things like that.

Feel free to debug this myself, and look at the C2 IR. I unfortunately have no time to dig deeper here at this time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3531817491

From haraldei at openjdk.org  Fri Nov 14 09:47:19 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Fri, 14 Nov 2025 09:47:19 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <raGWDYJJ4f-LNkUZUR9Xro6k_qpiqJSmHGRdloYjU6o=.11b96d2b-aefc-4d19-a81a-caa3596202f2@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
 <raGWDYJJ4f-LNkUZUR9Xro6k_qpiqJSmHGRdloYjU6o=.11b96d2b-aefc-4d19-a81a-caa3596202f2@github.com>
Message-ID: <GCkEtnccjjGHrGFDnlB3t0iums36AVXlET0MUkWJuCc=.7a8424d4-4b25-4236-a6b1-729a6c58cee4@github.com>

On Thu, 13 Nov 2025 21:18:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Harald Eilertsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Second try to fix alignment for native segments
>>    
>>    Introducing a helper function as suggested by JornVernee to decide on
>>    the proper alignment based on the segment size.
>>    
>>    This work was sponsored by: The FreeBSD Foundation
>>    
>>    Co-authored-by: JornVernee
>>  - Test that native segments don't overlap
>>    
>>    This work was sponsored by: The FreeBSD Foundation
>
>> However, this assumption does not hold for all allocators. Specifically
>> jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte
>> boundaries, respectively.
> 
> For what it's worth, I think the described behavior is non-conforming to the C
> standards before C23. Before C23, the description of the allocation functions
> all say
> 
> "The pointer returned if the allocation succeeds is suitably aligned so that
> it may be assigned to a pointer to any type of object with a fundamental
> alignment requirement and then used to access such an object or an array of
> such objects in the space allocated ... "
> 
> (That's from C11 7.22.3/1. C99 and C17 have the same wording. I can't find my
> copy of C89 right now, but expect it's pretty much the same.)
> 
> DR75 reiterated that the malloc result must be suitably aligned for _any_
> (emphasis in the DR) type.
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_075.html
> 
> A consequence of the pre-C23 behavior is that
> 
> max_align_t* p = malloc(1);
> 
> is always valid. C23 permits that to be UB. (You aren't allowed to create
> misaligned pointers.)
> 
> C23 added the phrase "and size less than or equal to the size requested" after
> "fundamental alignment requirement". I think that's sufficient to permit the
> described behavior. But we're not using C23 (yet), we're using C11.
> 
> I would not be surprised if HotSpot also has code that assumes the result from
> malloc and friends is always aligned to at least max_align_t's alignment.

@kimbarrett 
> For what it's worth, I think the described behavior is non-conforming to the C standards before C23

That may be, but it's nevertheless the behaviour of the allocator used by libc on FreeBSD. It's also something that will only affect very small allocations (8 bytes or less on a 64bit system.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3531853568

From nbenalla at openjdk.org  Fri Nov 14 09:47:49 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 14 Nov 2025 09:47:49 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v5]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <bXAj8GvbPQ59D2rYGXaM4lLTonXCT8OpR5Qw4h1p_6Y=.3650db88-2f42-422e-af89-0ae9b3db348b@github.com>

> Get JDK 27 underway.

Nizar Benalla 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 seven additional commits since the last revision:

 - Merge branch 'master' into start-of-release-27
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Merge branch 'master' into start-of-release-27
 - update links to JVMS 26 and 27
 - add missing enum
 - initial commit start-of-JDK-27

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/0652d5d3..3d9eb308

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=03-04

  Stats: 14293 lines in 184 files changed: 9629 ins; 3659 del; 1005 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

PR: https://git.openjdk.org/jdk/pull/28130

From mcimadamore at openjdk.org  Fri Nov 14 09:48:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 09:48:28 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <_twwdOdK3jZMnAaDPFubJhbEbR_FEK99I4obbpttveU=.21e193fa-067e-4df1-8cff-4cd0fc704e4f@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

src/java.base/share/classes/java/lang/LazyConstant.java line 241:

> 239: 
> 240:     /**
> 241:      * {@return if this lazy constant is the same as the provided {@code obj}}

maybe add (either in this PR or as follow up) a clarification saying that two different lazy constant that point to the same contents are **not** equals

src/java.base/share/classes/java/lang/LazyConstant.java line 280:

> 278:      * {@code computingFunction} at least until initialization completes successfully.
> 279:      * <p>
> 280:      * If the provided computing function is already an instance of

Not sure how I feel about that -- it seems to soft-break equals...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2526752889
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2526762818

From vklang at openjdk.org  Fri Nov 14 09:55:04 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 14 Nov 2025 09:55:04 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
Message-ID: <jzRS-3RT0o_nG2V3-gxFu0L7T0UMRBUkaSPKDsas0U0=.a662572b-da3a-4783-ad52-e7278634301f@github.com>

On Thu, 13 Nov 2025 23:10:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug report:
> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to
> "[invoke] shutdown() when this executor is no longer referenced and it has no threads."
> 
> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)).
> 
> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)).
> 
> The finalize() method can safely be removed from ThreadPoolExecutor.

Thanks @bchristi-git!

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28311#pullrequestreview-3464050407

From mcimadamore at openjdk.org  Fri Nov 14 09:55:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 09:55:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <dlCmKBiCeip7juDtJLwy9oYLpsGRTUMVStcF9mDyLV8=.1ab12a3c-32e6-45d5-b02d-6766fae68287@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

Looks great -- just a couple more javadoc tweaks ;-)

src/java.base/share/classes/java/util/List.java line 1233:

> 1231:      * The returned list's {@linkplain Object#equals(Object) equals()} and
> 1232:      * {@linkplain Object#hashCode() hashCode()} methods may trigger initialization of one
> 1233:      * or more lazy elements. The returned list's {@linkplain Object#toString() toString()}

I thought we have concluded that all Object methods should behave as those in any other list, to maximize migration opportunities.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3464050345
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2526787780

From jpai at openjdk.org  Fri Nov 14 10:01:25 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Nov 2025 10:01:25 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
Message-ID: <pUC2CsOOeN2fmLlHuqNHcTO5fZYPLIDwAmZRJEGd2ZY=.3e0a1615-873f-41b2-bd9a-807d8e80a364@github.com>

On Thu, 13 Nov 2025 23:10:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug report:
> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to
> "[invoke] shutdown() when this executor is no longer referenced and it has no threads."
> 
> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)).
> 
> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)).
> 
> The finalize() method can safely be removed from ThreadPoolExecutor.

Marked as reviewed by jpai (Reviewer).

The failures in the GitHub actions job appear related:


/home/runner/work/jdk/jdk/test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java:2011: error: unreported exception Throwable; must be caught or declared to be thrown
                super.finalize();
                              ^

-------------

PR Review: https://git.openjdk.org/jdk/pull/28311#pullrequestreview-3464063996
PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3531920120

From mcimadamore at openjdk.org  Fri Nov 14 10:14:04 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 10:14:04 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
Message-ID: <pG4aAiN3-QSE1saEjQXMWOjgA66ENSYkmpoMfVLpYQQ=.1300fd75-57f8-4dbc-8558-410032b6a2f6@github.com>

On Thu, 13 Nov 2025 19:12:41 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Second try to fix alignment for native segments
>    
>    Introducing a helper function as suggested by JornVernee to decide on
>    the proper alignment based on the segment size.
>    
>    This work was sponsored by: The FreeBSD Foundation
>    
>    Co-authored-by: JornVernee
>  - Test that native segments don't overlap
>    
>    This work was sponsored by: The FreeBSD Foundation

My 0.02$ -- regardless of what Hotspot code might do _today_, I think it would be preferrable to make the FFM allocation code a bit more flexible (along the lines described above). Whether fully supported by the Java runtime or not, to my eyes it just seem that, at least in some configurations, the API doesn't do what it says on the tin.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3531975731

From sgehwolf at openjdk.org  Fri Nov 14 10:18:19 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Nov 2025 10:18:19 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v7]
In-Reply-To: <corgjVt6hvXqeusBDA6U-1QURvQieTjwwB3wzyhcvRY=.00ad2ed8-415c-4dbf-a9a1-eda4cd357f39@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <corgjVt6hvXqeusBDA6U-1QURvQieTjwwB3wzyhcvRY=.00ad2ed8-415c-4dbf-a9a1-eda4cd357f39@github.com>
Message-ID: <0-JPrDhiMtDA6duzh8iGjTYImz1AqCIXy9U-HSjEVR0=.9bcd2751-d97b-4e11-a584-3527c46925f2@github.com>

On Thu, 13 Nov 2025 19:59:47 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR include build changes from @magicus and jlink change to verify the build signature.
>> 
>> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
>> 
>> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>>                                                                                                                                                                  
>> ? java --version
>> openjdk 26-internal 2026-03-17
>> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
>> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>>                                                                                                                                                                  
>> ? jlink --version                                                                       
>> 26-internal
>>                                                                                                                                                                  
>> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>>                                                                                                                                                                  
>> ? jlink --add-modules java.base --output macos
>>                                                             
>> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>>                                                                                                                                                                  
>> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove the extra space

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 604:

> 602:      *
> 603:      * @throws IllegalArgumentException This jlink cannot be used to create
> 604:      * the target runtime image.

Suggestion:

     * @throws IllegalArgumentException If  the `java.base` module reference `target` is not compatible with this jlink.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 615:

> 613:         }
> 614: 
> 615:         var targetRelease = releaseInfo.get();

This can be simplified:


String targetRelease = getReleaseInfo(target).orElseThrow(() -> new IllegalArgumentException(taskHelper...));

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 133:

> 131: err.empty.module.path=No module found in module path ''{0}'' with --add-modules ALL-MODULE-PATH
> 132: err.limit.modules=--limit-modules not allowed with --add-modules ALL-MODULE-PATH
> 133: err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1}

It would be good if the build info in the error is quoted. It's otherwise hard to discern where the build info starts/ends in the message:

Suggestion:

err.jlink.version.mismatch=jlink build ''{0}'' does not match target java.base build ''{1}''

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 134:

> 132: err.limit.modules=--limit-modules not allowed with --add-modules ALL-MODULE-PATH
> 133: err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1}
> 134: err.jlink.version.missing=jlink build {0} cannot find the build signature\

Suggestion:

err.jlink.version.missing=jlink build ''{0}'' cannot find the build signature\

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2526889972
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2526868718
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2526873977
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2526875224

From mcimadamore at openjdk.org  Fri Nov 14 10:22:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 10:22:06 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
Message-ID: <J4CiQYEor-I_72ZbM-DegzYDHzLEblFqgxU8h3z0SFs=.1ef99f3e-8a60-4658-8451-6e40fde7746b@github.com>

On Thu, 13 Nov 2025 19:12:41 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Second try to fix alignment for native segments
>    
>    Introducing a helper function as suggested by JornVernee to decide on
>    the proper alignment based on the segment size.
>    
>    This work was sponsored by: The FreeBSD Foundation
>    
>    Co-authored-by: JornVernee
>  - Test that native segments don't overlap
>    
>    This work was sponsored by: The FreeBSD Foundation

The fix is simple and pragmatic. The main difference between this and what I described is that by singling out FreeBSD, we won't be able to support cases where e.g. a developer runs on Linux, but using LD_PRELOAD to use a different allocator like jemalloc? It's a cornery case, but one I've seen from time to time to take advantage of some of the "hardening" features provided by jemalloc (and diagnose memory issues). Of course, we can also keep this PR as is, and then address other (more cornery cases) in separate PRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3532013857

From mbaesken at openjdk.org  Fri Nov 14 10:40:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Nov 2025 10:40:46 GMT
Subject: RFR: 8333871: check sysinfo return values
Message-ID: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>

In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
However we miss checking the return values at some places, this might need adjustment.

-------------

Commit messages:
 - JDK-8333871

Changes: https://git.openjdk.org/jdk/pull/28317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333871
  Stats: 23 lines in 2 files changed: 15 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28317/head:pull/28317

PR: https://git.openjdk.org/jdk/pull/28317

From forax at univ-mlv.fr  Fri Nov 14 10:42:18 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 14 Nov 2025 11:42:18 +0100 (CET)
Subject: Difficulties of recursion with Streams
In-Reply-To: <CAA9v-_OMFfDGHCOgqDe1jA7LgFZ6hT4owtkd5d5+sxhHOQvCQQ@mail.gmail.com>
References: <CAA9v-_OMFfDGHCOgqDe1jA7LgFZ6hT4owtkd5d5+sxhHOQvCQQ@mail.gmail.com>
Message-ID: <1156691217.39585641.1763116938967.JavaMail.zimbra@univ-eiffel.fr>

Hi David, 
You can always transform an imperative code to a stream by pushing the element through a consumer. 
Internally, a stream uses a push iterator (see Spliterator.tryAdvance(consumer)). 

As a silly example, this is a way to write fibonacci (the recursive form) with a stream right in the middle. 

static void fibo ( int n , IntConsumer consumer ) { 
if ( n < 2 ) { 
consumer .accept( n ); 
return ; 
} 
var result = Stream . of ( "" ) 
.mapMultiToInt(( _ , consumer2 ) -> { 
fibo ( n - 1 , consumer2 ); 
fibo ( n - 2 , consumer2 ); 
}) 
.sum(); 
consumer .accept( result ); 
} 

static void main () { 
fibo ( 7 , IO :: println ); 
} 

Here, I use mapMulti() to convert the imperative code to a Stream 
(there is no factory method on Stream that takes a consumer of consumer). 

If you also want to short-circuit, you can use a gatherer instead of mapMulti but short-circuiting the recursive code will require to use an exception as control flow (it will not be pretty). 

regards, 
R?mi 

> From: "David Alayachew" <davidalayachew at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Tuesday, November 11, 2025 4:36:29 AM
> Subject: Difficulties of recursion with Streams

> Hello [ mailto:core-libs-dev at openjdk.org | @core-libs-dev ] ,

> When working with streams, I often run into situations where I have to "demote"
> back to imperative code because I am trying to solve a problem best solved by
> recursion.

> Consider the common use case of cycling through permutations to find all
> permutations that satisfy some condition. With recursion, the answer is
> incredibly simple -- just grab an element from the set, then call the recursive
> method with a copy of the set minus the grabbed element. Once you reach the
> empty set, you've reached your terminal condition.

> Use cases like that are not only incredibly common, but usually, embarrassingly
> parallel. The example above of cycling through permutations is only a few lines
> of imperative code, but I struggle to imagine how I would do this with Streams.

> I guess let me start by asking -- are there any good ways currently to
> accomplish the above permutation example with Streams? And if not, should there
> be?

> Thank you for your time and consideration.
> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251114/55e02c11/attachment-0001.htm>

From haraldei at openjdk.org  Fri Nov 14 10:49:14 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Fri, 14 Nov 2025 10:49:14 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <J4CiQYEor-I_72ZbM-DegzYDHzLEblFqgxU8h3z0SFs=.1ef99f3e-8a60-4658-8451-6e40fde7746b@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
 <J4CiQYEor-I_72ZbM-DegzYDHzLEblFqgxU8h3z0SFs=.1ef99f3e-8a60-4658-8451-6e40fde7746b@github.com>
Message-ID: <BLvTYj0QNC7t4D_Yga1gA6SFY7EMIzYCSu2PEb09-XI=.0de4d205-bda3-40b6-9db8-b91058664cc3@github.com>

On Fri, 14 Nov 2025 10:19:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Harald Eilertsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Second try to fix alignment for native segments
>>    
>>    Introducing a helper function as suggested by JornVernee to decide on
>>    the proper alignment based on the segment size.
>>    
>>    This work was sponsored by: The FreeBSD Foundation
>>    
>>    Co-authored-by: JornVernee
>>  - Test that native segments don't overlap
>>    
>>    This work was sponsored by: The FreeBSD Foundation
>
> The fix is simple and pragmatic. The main difference between this and what I described is that by singling out FreeBSD, we won't be able to support cases where e.g. a developer runs on Linux, but using LD_PRELOAD to use a different allocator like jemalloc? It's a cornery case, but one I've seen from time to time to take advantage of some of the "hardening" features provided by jemalloc (and diagnose memory issues). Of course, we can also keep this PR as is, and then address other (more cornery cases) in separate PRs.

@mcimadamore That's a very good point! I'll try to update the patch, and see how it works out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3532137468

From jpai at openjdk.org  Fri Nov 14 10:55:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Nov 2025 10:55:10 GMT
Subject: RFR: 8333871: check sysinfo return values
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <JjvDS8FMBKXRIcbEdRUVM4buJDbvY8YGBciY6SlRda4=.776093c2-c71b-460c-87b7-a083df84b11b@github.com>

On Fri, 14 Nov 2025 10:33:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

src/java.base/unix/native/libjava/java_props_md.c line 394:

> 392:         if (ret == 0) {
> 393:             sprops.cpu_isalist = strdup(list);
> 394:             list[sizeof(list) - 1] = '\0';

Hello Matthias, is this a typo? The assignment to `list` which is no longer used after the previous line where it is duplicated, seems odd. Furthermore, is this explicit null termination needed? In `man strdup` I don't see any such expectations:

> The strdup() function returns a pointer to a new string which is a duplicate of the string s.  Memory for the new string is obtained with malloc(3), and can be freed with free(3).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2527051473

From jsjolen at openjdk.org  Fri Nov 14 10:57:19 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 14 Nov 2025 10:57:19 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
Message-ID: <GCd3RPOLqfaY1osbUMt3b-UI4DPJ_1TbWp5Y_Gtg7CA=.1cf1edcf-c29e-4750-8dcd-b87c96a87210@github.com>

On Thu, 13 Nov 2025 19:12:41 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Second try to fix alignment for native segments
>    
>    Introducing a helper function as suggested by JornVernee to decide on
>    the proper alignment based on the segment size.
>    
>    This work was sponsored by: The FreeBSD Foundation
>    
>    Co-authored-by: JornVernee
>  - Test that native segments don't overlap
>    
>    This work was sponsored by: The FreeBSD Foundation

The VM (which the JDK interfaces with malloc through) guarantees at-most 16 byte alignment from `malloc`, so any alignment less than that is also going to be fine. We should, as always, test this, but I don't think that anything will break on the VM side with this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3532178966

From mbaesken at openjdk.org  Fri Nov 14 11:07:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Nov 2025 11:07:20 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  0 - terminate not needed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28317/files
  - new: https://git.openjdk.org/jdk/pull/28317/files/2d574f7c..e9d2b1b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28317/head:pull/28317

PR: https://git.openjdk.org/jdk/pull/28317

From mbaesken at openjdk.org  Fri Nov 14 11:07:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Nov 2025 11:07:22 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <JjvDS8FMBKXRIcbEdRUVM4buJDbvY8YGBciY6SlRda4=.776093c2-c71b-460c-87b7-a083df84b11b@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <JjvDS8FMBKXRIcbEdRUVM4buJDbvY8YGBciY6SlRda4=.776093c2-c71b-460c-87b7-a083df84b11b@github.com>
Message-ID: <Ag3Gn6fC_CIpWvMdO28JD3eUVRR-W7ytxz3alLwAe_0=.0c132c7d-7feb-459f-a521-b3d903e8df9d@github.com>

On Fri, 14 Nov 2025 10:51:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   0 - terminate not needed
>
> src/java.base/unix/native/libjava/java_props_md.c line 394:
> 
>> 392:         if (ret == 0) {
>> 393:             sprops.cpu_isalist = strdup(list);
>> 394:             list[sizeof(list) - 1] = '\0';
> 
> Hello Matthias, is this a typo? The assignment to `list` which is no longer used after the previous line where it is duplicated, seems odd. Furthermore, is this explicit null termination needed? In `man strdup` I don't see any such expectations:
> 
>> The strdup() function returns a pointer to a new string which is a duplicate of the string s.  Memory for the new string is obtained with malloc(3), and can be freed with free(3).

Hi , I removed the 0 - termination. Seems it is not needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2527094141

From ayang at openjdk.org  Fri Nov 14 11:54:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 14 Nov 2025 11:54:12 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <G0xVQpc_FSma3WnGWCHVJMdprWwW86IKyICAFeQJ29k=.cd4cff1c-b67f-4616-8c19-260435956bf1@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3464591706

From alanb at openjdk.org  Fri Nov 14 12:05:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 12:05:51 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v12]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge branch 'master' into JDK-8353835
 - Cleanup
 - More cleanup of Field.set API docs, including some restructure from Alex
 - Cleanup
 - Merge branch 'master' into JDK-8353835
 - Update mutateFinals/modules test to exercise exports and opens cases
 - Update Field.set spec to better align with setAccessible for public final field in public class in exported package
 - Fix typo in java man page
 - Add method to test if package exported
 - Remove dup end body tag
 - ... and 49 more: https://git.openjdk.org/jdk/compare/9eaa364a...7693e8fa

-------------

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=11
  Stats: 5347 lines in 76 files changed: 5152 ins; 55 del; 140 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

PR: https://git.openjdk.org/jdk/pull/25115

From alanb at openjdk.org  Fri Nov 14 12:11:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 12:11:01 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <ZT4iXoqROEqXtP7Tm_bdWzYsrCk_Hk1nt4Yyd8LzJ1Q=.79b0cbac-5ceb-46a0-bf49-b5c6dbdd0dc7@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

src/java.base/unix/native/libjava/java_props_md.c line 395:

> 393:             sprops.cpu_isalist = strdup(list);
> 394:         } else {
> 395:             sprops.cpu_isalist = NULL;

Would you mind checking the code that puts this in a system property can tolerate NULL? I don't suppose sysinfo will fail here (unless you found a case?) but it would be good to confirm that it won't blow up somewhere else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2527272162

From alanb at openjdk.org  Fri Nov 14 12:35:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 12:35:49 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v12]
In-Reply-To: <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
Message-ID: <O79QRtXKdYOkhJK7oFljv-apKZV1b_GGW-UdinPaVMw=.df1d905d-7a85-486a-b674-3192d006be68@github.com>

On Fri, 14 Nov 2025 12:05:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Cleanup
>  - More cleanup of Field.set API docs, including some restructure from Alex
>  - Cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Update mutateFinals/modules test to exercise exports and opens cases
>  - Update Field.set spec to better align with setAccessible for public final field in public class in exported package
>  - Fix typo in java man page
>  - Add method to test if package exported
>  - Remove dup end body tag
>  - ... and 49 more: https://git.openjdk.org/jdk/compare/9eaa364a...7693e8fa

Just to follow-up on this discussion. The checks done by Field.set on a final field need to the same as, or more restrictive, than the checks done by setAccessible, this is important to preserve traceability. A caller of setAccessible can suppress access checks on a public final in a public class in a package that is exported to at least the caller. So your observation that it is "surprising" to require the package be opened to the caller in order to mutate the field when it is final is a good observation. It's not wrong, it's just more draconian that it should be. I discussed with Alex and Ron and we agreed to adjust the spec for this. We will need to re-submit the CSR with the (small) update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3532526777

From alanb at openjdk.org  Fri Nov 14 12:36:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 12:36:49 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
Message-ID: <CNiKMmOjf3N59_ZHvf_AgMb5J0zGpf-oaXFJgHvlBwQ=.c523e565-5d34-479b-a219-cdad1f00aae6@github.com>

On Thu, 13 Nov 2025 23:10:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug report:
> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to
> "[invoke] shutdown() when this executor is no longer referenced and it has no threads."
> 
> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)).
> 
> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)).
> 
> The finalize() method can safely be removed from ThreadPoolExecutor.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28311#pullrequestreview-3464732495

From pminborg at openjdk.org  Fri Nov 14 12:47:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 12:47:16 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v4]
In-Reply-To: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
Message-ID: <GcvvycqD2ndZ6ZIGKQYI7QPalpsu4k6A8a2-t3ysqUc=.b01257b0-e866-4470-aa10-501aabaad590@github.com>

> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
> 
> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
> 
> It should be noted that with this change, the running time for the benchmarks would increase significantly.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add loop variant for mismatch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28260/files
  - new: https://git.openjdk.org/jdk/pull/28260/files/f0d633d1..7f40672e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28260&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28260&range=02-03

  Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28260/head:pull/28260

PR: https://git.openjdk.org/jdk/pull/28260

From duke at openjdk.org  Fri Nov 14 12:59:42 2025
From: duke at openjdk.org (duke)
Date: Fri, 14 Nov 2025 12:59:42 GMT
Subject: Withdrawn: 8359424: Eliminate table lookup in Integer/Long toHexString
In-Reply-To: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
Message-ID: <dyskOneHpAoYN3P2sFcPeDiuzw--TimiBS60MffPPBU=.0fe30b6f-834d-4d0e-ae66-3144da2dfe04@github.com>

On Tue, 7 Jan 2025 10:39:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/22942

From haraldei at openjdk.org  Fri Nov 14 13:13:00 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Fri, 14 Nov 2025 13:13:00 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v3]
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <MqO3_Inf57nyfJtl0bEqKL1U0gtA-je3hfg6pxBz-Z8=.9631e5e3-7029-4311-947c-e105f34d8fdc@github.com>

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:

  OS agnostic fix for alignment of native segments
  
  Only align up the requested memory if the requested alignment is larget
  than max alignment provided by malloc, or if the requested size is not a
  multiple of the alignment size.
  
  This work was sponsored by: The FreeBSD Foundation
  
  Co-authored-by: mcimadamore

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28235/files
  - new: https://git.openjdk.org/jdk/pull/28235/files/2b8266f6..15daa51b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=01-02

  Stats: 17 lines in 1 file changed: 4 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28235/head:pull/28235

PR: https://git.openjdk.org/jdk/pull/28235

From sgehwolf at openjdk.org  Fri Nov 14 13:15:18 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Nov 2025 13:15:18 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <gX0-1gsNi4RVPLEOaYS6FyXXa6L4TLi_LDS2IWyokE8=.5edb1a53-ce95-407c-b957-31fe82408847@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28157#issuecomment-3532678185

From sgehwolf at openjdk.org  Fri Nov 14 13:15:19 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Nov 2025 13:15:19 GMT
Subject: Integrated: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <QLvbFlQI8t3MageG8gHw4_Sh7mGkUgIjDwiE44A3Ups=.f48a5d7c-cfeb-450d-bcd1-b43da0255568@github.com>

On Wed, 5 Nov 2025 18:13:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

This pull request has now been integrated.

Changeset: 5d65c23c
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d65c23cd99b72527dcfab9eb6da9510e7dc6330
Stats:     107 lines in 4 files changed: 90 ins; 0 del; 17 mod

8370492: [Linux] Update cpu shares to cpu.weight mapping function

Reviewed-by: cnorrbin, ayang, syan

-------------

PR: https://git.openjdk.org/jdk/pull/28157

From pminborg at openjdk.org  Fri Nov 14 13:35:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 13:35:17 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <dhFCSfTNXvOxuS2Qx41yPqplCUhXTq4IWT-7OWvhK8M=.fc1e937b-1fb2-4572-aa50-db9e1192a4ef@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>
 <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com>
 <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>
 <dhFCSfTNXvOxuS2Qx41yPqplCUhXTq4IWT-7OWvhK8M=.fc1e937b-1fb2-4572-aa50-db9e1192a4ef@github.com>
Message-ID: <ScfYyTv6C7xkXpvHpTblrpnDZPVDn2LjYQHtjPjoevI=.ae9fbf73-afb3-48ff-87ee-c48ca1603ea1@github.com>

On Tue, 11 Nov 2025 16:48:58 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I've added two new benchmarks:
>> 
>> 
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42 = LazyConstant.of(() -> Optional.of(42));
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42_2 = LazyConstant.of(() -> Optional.of(42));
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY = LazyConstant.of(Optional::empty);
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY2 = LazyConstant.of(Optional::empty);
>>     
>>     ...
>>     
>>         @Benchmark
>>     public int staticOptional42() {
>>         return OPTIONAL_42.get().orElseThrow() + OPTIONAL_42_2.get().orElseThrow();
>>     }
>> 
>>     @Benchmark
>>     public boolean staticOptionalEmpty() {
>>         return OPTIONAL_EMPTY.get().isEmpty() ^ OPTIONAL_EMPTY2.get().isEmpty();
>>     }
>> 
>>     
>> 
>> 
>> Which gives:
>> 
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> StableValueBenchmark.staticOptional42  avgt   10  0.354 ? 0.045  ns/op
>> 
>> Benchmark                                 Mode  Cnt  Score   Error  Units
>> StableValueBenchmark.staticOptionalEmpty  avgt   10  0.370 ? 0.030  ns/op
>> 
>> 
>> So, both `Optional` variants appears to support constant folding.
>
> I don't think we can drawn that conclusion just based on the speed. For the non-constant folded cases, this would be 2 loads and an xor.
> 
> I don't see how C2 would be allowed to constant fold the loads if the value is `null`, since that's explicitly forbidden by `@Stable` (and there's no easy way around that AFAIK, since the JIT thread may see a partially initialized object, so it conservatively ignores default values).

Yes. I think you are right @JornVernee. I've explored several ways to fix this and the simplest one might be to have a sentinel value instead of `null` to flag emptiness. Splitting the class into a bimorphic implementation would not be good for `value` classes (at least not for now), even though the C2 might otherwise be able to optimize the two variants.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527523848

From alanb at openjdk.org  Fri Nov 14 13:43:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 13:43:41 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v7]
In-Reply-To: <0-JPrDhiMtDA6duzh8iGjTYImz1AqCIXy9U-HSjEVR0=.9bcd2751-d97b-4e11-a584-3527c46925f2@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <corgjVt6hvXqeusBDA6U-1QURvQieTjwwB3wzyhcvRY=.00ad2ed8-415c-4dbf-a9a1-eda4cd357f39@github.com>
 <0-JPrDhiMtDA6duzh8iGjTYImz1AqCIXy9U-HSjEVR0=.9bcd2751-d97b-4e11-a584-3527c46925f2@github.com>
Message-ID: <jewrvB49CClRLPpxsbEICiHGGhoZJSR856I9G-q2Q90=.8a9f46c9-60d8-4318-bebb-831a5bf97a79@github.com>

On Fri, 14 Nov 2025 10:10:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove the extra space
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 133:
> 
>> 131: err.empty.module.path=No module found in module path ''{0}'' with --add-modules ALL-MODULE-PATH
>> 132: err.limit.modules=--limit-modules not allowed with --add-modules ALL-MODULE-PATH
>> 133: err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1}
> 
> It would be good if the build info in the error is quoted. It's otherwise hard to discern where the build info starts/ends in the message:
> 
> Suggestion:
> 
> err.jlink.version.mismatch=jlink build ''{0}'' does not match target java.base build ''{1}''

I agree as there are several sub-components in this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2527545554

From duke at openjdk.org  Fri Nov 14 13:46:26 2025
From: duke at openjdk.org (Almaz)
Date: Fri, 14 Nov 2025 13:46:26 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <GCkEtnccjjGHrGFDnlB3t0iums36AVXlET0MUkWJuCc=.7a8424d4-4b25-4236-a6b1-729a6c58cee4@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
 <raGWDYJJ4f-LNkUZUR9Xro6k_qpiqJSmHGRdloYjU6o=.11b96d2b-aefc-4d19-a81a-caa3596202f2@github.com>
 <GCkEtnccjjGHrGFDnlB3t0iums36AVXlET0MUkWJuCc=.7a8424d4-4b25-4236-a6b1-729a6c58cee4@github.com>
Message-ID: <kDWVCOPeXUFu_GbuOtP6qDoD52TpsY0_uN94PhUDrzs=.88933b41-77e1-4645-9a0a-7f70e4bffc9e@github.com>

On Fri, 14 Nov 2025 09:44:19 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

> For what it's worth, I think the described behavior is non-conforming to the C standards before C23

The standard was ambiguous prior to that and https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm is a good read on that topic.

Modified test works with initialized segments and there [allocated size](https://github.com/openjdk/jdk/blob/0671309de530822cc261e8251fc425c8aa3cc487/src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java#L194) is at least 8 bytes. Allocating non-initialized segments of smaller sizes might also help to reveal alignment related bugs. Does it worth adding test like


        int[] alignments = {2, 4, 8, 16};

        try (Arena arena = Arena.ofConfined()) {
            for (int alignment : alignments) {
                var seg = arena.allocateFrom(JAVA_BYTE.withByteAlignment(alignment), (byte) 0);
                assertTrue(seg.address() % alignment == 0);
            }
        }


in this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3532821794

From swen at openjdk.org  Fri Nov 14 14:05:14 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 14 Nov 2025 14:05:14 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v22]
In-Reply-To: <DbzfVLQH3BzCnAh-4hMf-uBa1hVDDdJ2NpWEawXfQz0=.250b2327-27e3-41c2-af3e-72461de21644@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <gOqebHyurDwwkxa0E8WzV4cL9_e9so0K8Gd_xGnPDXo=.12a703a3-ebfb-45ed-b9d2-dc09d7362fa1@github.com>
 <DbzfVLQH3BzCnAh-4hMf-uBa1hVDDdJ2NpWEawXfQz0=.250b2327-27e3-41c2-af3e-72461de21644@github.com>
Message-ID: <nErFmZIGF6leblALYcnCP-s2-AGVMEaA4DFVTIz6c5I=.7537f29a-9400-4e36-8ca0-d9af62be2ec8@github.com>

On Fri, 14 Nov 2025 07:59:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove JLA
>
> I wanted to modify the DecimalDigits.appendQuad method as follows, but this caused `MergeStore` to not work.
> 
>     public static void appendQuad(StringBuilder buf, int v) {
>         // The & 0x7f operation keeps the index within the safe range [0, 127] for the DIGITS array,
>         // which allows the JIT compiler to eliminate array bounds checks for performance.
>         int packed = DIGITS[(v / 100) & 0x7f] | (DIGITS[(v % 100) & 0x7f] << 16);
>         // The temporary String and byte[] objects created here are typically eliminated
>         // by the JVM's escape analysis and scalar replacement optimizations during
>         // runtime compilation, avoiding actual heap allocations in optimized code.
>         buf.append(
>                 JLA.uncheckedNewStringWithLatin1Bytes(
>                         new byte[] {(byte) packed,         (byte) (packed >> 8),
>                                     (byte) (packed >> 16), (byte) (packed  >> 24)}));
>     }
> 
> 
> The output is as follows:
> 
> [TraceMergeStores] MergePrimitiveStores::run:  868  StoreB  === 887 813 861 145  [[ 872 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
> [TraceMergeStores] expect no use: None
> [TraceMergeStores] expect def: None
> [TraceMergeStores] MergePrimitiveStores::run:  848  StoreB  === 888 813 840 81  [[ 853 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7;
> [TraceMergeStores] expect no use: None
> [TraceMergeStores] expect def: None
> [TraceMergeStores] MergePrimitiveStores::run:  559  StoreB  === 548 543 351 352  [[ 562 ]]  @java/lang/AbstractStringBuilder (java/lang/CharSequence,java/lang/Appendable)+16 *, name=coder, idx=13;  Memory: @java/lang/StringBuilder (java/io/Serializable,java/lang/Comparable,java/lang/CharSequence,java/lang/Appendable):NotNull:exact+16 *, name=coder, idx=13; !jvms: AbstractStringBuilder::append @ bci:78 (line 651) StringBuilder::append @ bci:2 (line 179) DecimalDigits::appendQuad @ bci:68 (line 496)
> [TraceMergeStores] expect no use: None
> [TraceMergeStores] expect def: None
> [TraceMergeStores] MergePrimitiveStores::run:  739  StoreI  === 879 813 354 456  [[ 17 ]]  @java/lang/AbstractStringBuilder (java/lang/CharSequence,java/lang/Appendable)+12 *, name=count, idx=14;  Memory: @java/lang/StringBuilder (java/io/Serializ...

> @wenshao I see. I suspect that your `packed` is deconstructed into byte parts by C2 optimizations.
> 
> What happens if you route the `packed` value through some non-inlined method?
> 
> ```
>         int packed = DIGITS[(v / 100) & 0x7f] | (DIGITS[(v % 100) & 0x7f] << 16);
>         packed = dontinline(packed); // prevents optimizations
>         // The temporary String and byte[] objects created here are typically eliminated
>         // by the JVM's escape analysis and scalar replacement optimizations during
>         // runtime compilation, avoiding actual heap allocations in optimized code.
>         buf.append(
>                 JLA.uncheckedNewStringWithLatin1Bytes(
>                         new byte[] {(byte) packed,         (byte) (packed >> 8),
>                                     (byte) (packed >> 16), (byte) (packed  >> 24)}));
> ```
> 
> The issue is probably that `packed >> 16)` in the lower part sees that it only requires the values from `DIGITS[(v % 100) & 0x7f] << 16`, and just redirects things, and folds away the shifts. C2 does a lot of smart things like that.
> 
> Feel free to debug this myself, and look at the C2 IR. I unfortunately have no time to dig deeper here at this time.

If `packed` is a constant, then `MergeStore` works here, so your guess is correct.

Let's leave it at that for now. Two `StoreC` instances are good enough; there's no need to try merging them into `StoreI`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3532952110

From mbaesken at openjdk.org  Fri Nov 14 14:07:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Nov 2025 14:07:21 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <ZT4iXoqROEqXtP7Tm_bdWzYsrCk_Hk1nt4Yyd8LzJ1Q=.79b0cbac-5ceb-46a0-bf49-b5c6dbdd0dc7@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <ZT4iXoqROEqXtP7Tm_bdWzYsrCk_Hk1nt4Yyd8LzJ1Q=.79b0cbac-5ceb-46a0-bf49-b5c6dbdd0dc7@github.com>
Message-ID: <hu7w2txJg16ZHHSnCL8YzApH_X8GEvlUI_eFpUTti-Y=.515a7b24-3b05-4dc5-887f-a4a47ba5019c@github.com>

On Fri, 14 Nov 2025 12:08:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   0 - terminate not needed
>
> src/java.base/unix/native/libjava/java_props_md.c line 395:
> 
>> 393:             sprops.cpu_isalist = strdup(list);
>> 394:         } else {
>> 395:             sprops.cpu_isalist = NULL;
> 
> Would you mind checking the code that puts this in a system property can tolerate NULL? I don't suppose sysinfo will fail here (unless you found a case?) but it would be good to confirm that it won't blow up somewhere else.

We do  PUTPROP here
https://github.com/openjdk/jdk/blob/5d65c23cd99b72527dcfab9eb6da9510e7dc6330/src/java.base/share/native/libjava/System.c#L164
with 3rd parameter == NULL in this case.
PUTPROP checks for this so I do not see issues with this
https://github.com/openjdk/jdk/blob/5d65c23cd99b72527dcfab9eb6da9510e7dc6330/src/java.base/share/native/libjava/System.c#L68

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2527633331

From swen at openjdk.org  Fri Nov 14 14:11:22 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 14 Nov 2025 14:11:22 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v21]
In-Reply-To: <rM7l2dHpqGhodam52Ud5DDK_Wuu3bEgVkmjN0t9REo4=.10a0ec00-70f9-4815-a4c5-c6d6bb2901ee@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <yjwd5h_QiaXwr-Y0A_kzrAIpthTt7KJapLMj4XoYhzI=.0fb0a41f-d960-4c36-962c-0c7486d03334@github.com>
 <rM7l2dHpqGhodam52Ud5DDK_Wuu3bEgVkmjN0t9REo4=.10a0ec00-70f9-4815-a4c5-c6d6bb2901ee@github.com>
Message-ID: <Phn_QT7fMsmnSeBpq6lBBmcksivf2bzKaV-gUoIOuck=.ce516575-5fc1-4f8d-8092-1547a83797dd@github.com>

On Thu, 13 Nov 2025 16:40:45 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comments
>
> src/java.base/share/classes/java/time/MonthDay.java line 758:
> 
>> 756:         buf.append('-');
>> 757:         DecimalDigits.appendPair(buf, day);
>> 758:         return buf.toString();
> 
> Why not
> 
>     byte[] bytes = new byte[7];
> 	bytes[0] = (byte)'-';
> 	bytes[1] = (byte)'-';
> 	DecimalDigits.appendPair(bytes, 2, month); // TBD
> 	bytes[4] = (byte)'-';
> 	DecimalDigits.appendPair(bytes, 5, month);
> 	return JLA.uncheckedNewStringWithLatin1Bytes(bytes);

That's a good suggestion, but such optimization is irrelevant to this PR, or it should be done in a separate PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2527645555

From swen at openjdk.org  Fri Nov 14 14:18:12 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 14 Nov 2025 14:18:12 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v23]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <z2gjVmz1tGoDqwO0VSbx__O8w6OwMqRJomtMk3Wcg0s=.34851f1e-a2de-4068-a492-6cbec7d8ed6a@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use junit, from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/35b98cb8..0abf226b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=21-22

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

PR: https://git.openjdk.org/jdk/pull/26911

From rriggs at openjdk.org  Fri Nov 14 14:36:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Nov 2025 14:36:53 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure [v3]
In-Reply-To: <J5LGDzb7xzhy1qdduW8ZqwZqJaCPrgVQNckDUXxtoSs=.a7c4e40d-7396-4cb6-a2bf-f06f229693ec@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
 <J5LGDzb7xzhy1qdduW8ZqwZqJaCPrgVQNckDUXxtoSs=.a7c4e40d-7396-4cb6-a2bf-f06f229693ec@github.com>
Message-ID: <cULfVk8rnGgTQFXkZ6XwG8pUal8xexlPO9yEu6cFfLc=.4db1fb1e-76cb-45c6-941f-221c97e9b488@github.com>

On Thu, 13 Nov 2025 21:28:58 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Rewrite of VerifyJimage test to fix several severe issues.
>> 
>> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
>> 
>> Issue 1: Broken file comparison
>> 
>> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
>> 
>> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
>> 
>> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
>> 
>> Issue 2: Use of BasicImageReader for class file reading
>> 
>> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
>> 
>> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
>> 
>> Issue 3: File comparison mode was never run by default
>> 
>> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
>
> David Beaumont 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 branch 'master' into jdk_8371591_verify/squashed
>  - Remove unhelpful output
>  - Tweaked path to class name handling for clarity
>  - Fix very broken test and make it compatible with preview mode
>  - Make entry name reading idempotent

Still looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28265#pullrequestreview-3465237397

From pminborg at openjdk.org  Fri Nov 14 14:44:49 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 14:44:49 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <Wd007lKJSjzYhyuz3x2mNThGNk32iP9Mmh0ouOQc48Q=.98fb1ae5-ae22-458d-a2da-3ac3c4f7c2fe@github.com>

On Wed, 12 Nov 2025 16:02:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 66:
> 
>> 64:         // using `elements.length`.
>> 65:         @Stable
>> 66:         private final int size;
> 
> Is this really that important? What about the extra footprint added by the `int` field? We might have many instances of this class, but only one copy of the bytecode.

Hrrm. I wonder if the C2 compiler will end up producing equivalent code for the two variants? But there are merits to your argument.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527753354

From mcimadamore at openjdk.org  Fri Nov 14 14:52:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 14:52:14 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <GCd3RPOLqfaY1osbUMt3b-UI4DPJ_1TbWp5Y_Gtg7CA=.1cf1edcf-c29e-4750-8dcd-b87c96a87210@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
 <GCd3RPOLqfaY1osbUMt3b-UI4DPJ_1TbWp5Y_Gtg7CA=.1cf1edcf-c29e-4750-8dcd-b87c96a87210@github.com>
Message-ID: <Zrsjge-vEahelAWXzsfu1WLArAUKJB2G6wUIYBMrsUg=.8f03975b-68cc-42f7-bc31-a91d074b817d@github.com>

On Fri, 14 Nov 2025 10:54:39 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> The VM (which the JDK interfaces with malloc through) guarantees at-most 16 byte alignment from `malloc`, so any alignment less than that is also going to be fine. We should, as always, test this, but I don't think that anything will break on the VM side with this change.

Note that, since this is just a change on a Java API, I don't think should affect the VM? Then of course if someone runs java in an environment with LD_PRELOAD where jemalloc is used instead of malloc, and _all_ allocation (even ones from native code) aligns differently, I can't speak on how that would impact the JVM.

But this change, alone, should not impact the VM in any way?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3533130463

From mcimadamore at openjdk.org  Fri Nov 14 14:52:17 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 14:52:17 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v3]
In-Reply-To: <MqO3_Inf57nyfJtl0bEqKL1U0gtA-je3hfg6pxBz-Z8=.9631e5e3-7029-4311-947c-e105f34d8fdc@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <MqO3_Inf57nyfJtl0bEqKL1U0gtA-je3hfg6pxBz-Z8=.9631e5e3-7029-4311-947c-e105f34d8fdc@github.com>
Message-ID: <3dgK7zQRIF-cwMTaXttOlW8m9d10kjJYnlwIsny_rd8=.458d6690-53c1-4acc-8e4c-f7cd59336553@github.com>

On Fri, 14 Nov 2025 13:13:00 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   OS agnostic fix for alignment of native segments
>   
>   Only align up the requested memory if the requested alignment is larget
>   than max alignment provided by malloc, or if the requested size is not a
>   multiple of the alignment size.
>   
>   This work was sponsored by: The FreeBSD Foundation
>   
>   Co-authored-by: mcimadamore

The latest changes look good -- but there seem to be failures in the test pipelines.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3533136853

From mcimadamore at openjdk.org  Fri Nov 14 14:52:12 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 14:52:12 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <kDWVCOPeXUFu_GbuOtP6qDoD52TpsY0_uN94PhUDrzs=.88933b41-77e1-4645-9a0a-7f70e4bffc9e@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
 <raGWDYJJ4f-LNkUZUR9Xro6k_qpiqJSmHGRdloYjU6o=.11b96d2b-aefc-4d19-a81a-caa3596202f2@github.com>
 <GCkEtnccjjGHrGFDnlB3t0iums36AVXlET0MUkWJuCc=.7a8424d4-4b25-4236-a6b1-729a6c58cee4@github.com>
 <kDWVCOPeXUFu_GbuOtP6qDoD52TpsY0_uN94PhUDrzs=.88933b41-77e1-4645-9a0a-7f70e4bffc9e@github.com>
Message-ID: <O8UY1Avn7TB6KX_wIZOL6vQ4meS2BhQKWq-gSWEBpV4=.da66c1fb-a8bb-4170-b400-925ae8c929ea@github.com>

On Fri, 14 Nov 2025 13:31:15 GMT, Almaz <duke at openjdk.org> wrote:

> > For what it's worth, I think the described behavior is non-conforming to the C standards before C23
> 
> The standard was ambiguous prior to that and https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm is a good read on that topic.
> 
> Modified test works with initialized segments and there [allocated size](https://github.com/openjdk/jdk/blob/0671309de530822cc261e8251fc425c8aa3cc487/src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java#L194) is at least 8 bytes. Allocating non-initialized segments of smaller sizes might also help to reveal alignment related bugs. Does it worth adding test like
> 
> ```
>         int[] alignments = {2, 4, 8, 16};
> 
>         try (Arena arena = Arena.ofConfined()) {
>             for (int alignment : alignments) {
>                 var seg = arena.allocateFrom(JAVA_BYTE.withByteAlignment(alignment), (byte) 0);
>                 assertTrue(seg.address() % alignment == 0);
>             }
>         }
> ```
> 
> in this PR?

I think it might be a good idea, yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3533120342

From haraldei at openjdk.org  Fri Nov 14 15:09:15 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Fri, 14 Nov 2025 15:09:15 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v3]
In-Reply-To: <3dgK7zQRIF-cwMTaXttOlW8m9d10kjJYnlwIsny_rd8=.458d6690-53c1-4acc-8e4c-f7cd59336553@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <MqO3_Inf57nyfJtl0bEqKL1U0gtA-je3hfg6pxBz-Z8=.9631e5e3-7029-4311-947c-e105f34d8fdc@github.com>
 <3dgK7zQRIF-cwMTaXttOlW8m9d10kjJYnlwIsny_rd8=.458d6690-53c1-4acc-8e4c-f7cd59336553@github.com>
Message-ID: <qrSfY7KZZ-nzy8qmsFcc1HJnV_ZXUiN_sgrorEtGW3U=.c0f139c7-0148-48fc-8927-ff0accb464ae@github.com>

On Fri, 14 Nov 2025 14:49:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The latest changes look good -- but there seem to be failures in the test pipelines.

I'm looking at the test failures now. At least it seems they fail consistently across all platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3533194754

From pminborg at openjdk.org  Fri Nov 14 15:15:51 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 15:15:51 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <7emI0lI9l1ZnKE89i3hDeQl4KiaE_GutmkDoIu772Ik=.276d7422-4102-425a-a92f-439134945f60@github.com>

On Wed, 12 Nov 2025 16:08:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 199:
> 
>> 197:                 final int size = base.size();
>> 198:                 subListRangeCheck(fromIndex, toIndex, size);
>> 199:                 return new ReverseOrderLazyListView<>(base.subList(size - toIndex, size - fromIndex));
> 
> Why not this? (maybe add a comment?)
> Suggestion:
> 
>                 return new ReverseOrderLazyListView<>(base.subList(fromIndex, toIndex));

Actually, now that toString() evaluates, we could just get rid of these classes and use the ones in the base class. Great!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527855543

From duke at openjdk.org  Fri Nov 14 15:25:14 2025
From: duke at openjdk.org (jengebr)
Date: Fri, 14 Nov 2025 15:25:14 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v5]
In-Reply-To: <vAwW9ViTV5JYiIhZzbRBn_LnrvRTk93H3jbvVBPn9vk=.d353c0ee-9a62-42db-a3e0-0b9d13efc863@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <vSVVYdKkOvUOmmdFbICM87-yqIkBKShCnSUmt3sUsmo=.37a8728b-8e3a-4961-a84f-f179c93acec9@github.com>
 <1M7QGkc_DoRJEGF4nQXShjdOfs-5rM0k4cnt5Ims73E=.156ea658-649b-4a20-88b6-6284eea3ef96@github.com>
 <ZqcCwk9brd7A2xxfqDFMr9ytkjRptAugh54Oe3R7OS8=.10843f8f-752b-4ff6-9b79-d601d5ca21f6@github.com>
 <vAwW9ViTV5JYiIhZzbRBn_LnrvRTk93H3jbvVBPn9vk=.d353c0ee-9a62-42db-a3e0-0b9d13efc863@github.com>
Message-ID: <zSgV8MS3wLC51A_sdeznLpxz5PKEJIM_QvGGrwD_8UQ=.f69f17ff-d402-4caf-a41f-02bf7fa0bd61@github.com>

On Fri, 14 Nov 2025 00:42:55 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I'm curious, why not .equals() when we know the input is a List?  That is a stricter assertion because it ensures ordering remains unchanged.
>> 
>> Happy to make the change, though.
>
> The testCollection1() method gets called with a bunch of different collections, including a HashSet, which arrives at this code in the `c` parameter. When `c` is copied into a new ArrayList, it gets whatever order is presented by `c`, which is unspecified when `c` is a HashSet. The resulting order might differ from the order in the source list, and equals() over Lists compares order, so it might result in a spurious failure.
> 
> I note that creating a HashSet of capacity 8 and adding 42 and then 99 results in [42, 99] but doing the same with a HashSet of capacity 16 results in [99, 42]. The test might actually pass, but if it does, it seems like it's pretty brittle.
> 
> EDIT: oh, looks like the latest change renders this issue moot. But that was the issue behind my comment.

Thank you!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2527884895

From rriggs at openjdk.org  Fri Nov 14 15:26:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Nov 2025 15:26:25 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v17]
In-Reply-To: <WJeeAF8mUbfNMuRjvkHot-we7WoZXDY3iruMKiMPbRc=.74622925-401d-4e35-a5bd-064f2828ae6d@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <WJeeAF8mUbfNMuRjvkHot-we7WoZXDY3iruMKiMPbRc=.74622925-401d-4e35-a5bd-064f2828ae6d@github.com>
Message-ID: <2qlyJpxr9DhFUx0HtzUPnvNQloqFPmff_Xw-hNPp05g=.2f0398a6-dbe8-4975-873c-2f94e7c85617@github.com>

On Wed, 12 Nov 2025 15:01:49 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   static field JLA

test/jdk/jdk/internal/util/DecimalDigitsTest.java line 49:

> 47:             assertEquals(sb.toString(), expected, "Failed for value: " + i);
> 48:         }
> 49:     }

This test is the same as the latin1 test below.  This one can be removed.

test/jdk/jdk/internal/util/DecimalDigitsTest.java line 81:

> 79:             // Check that the pair was appended correctly
> 80:             String appended = sb.substring(currentLength);
> 81:             assertEquals(appended, expected, "Failed for value: " + i + " with UTF16 encoding");

I'd include the '?' in the expected string and compare the whole string.
The substring will be converted back to latin1 when it is extracted.
So much of the code involved has already been extensively tested, its not clear its worth the test run time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2519103551
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2519128136

From rriggs at openjdk.org  Fri Nov 14 15:26:22 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Nov 2025 15:26:22 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v18]
In-Reply-To: <Y20qlyPJVQhMoFYIJ2kZ3sdrnRtVO-ODyu5x2PTvgOM=.eb91a68f-9dae-4181-acdf-86326b8d39c9@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <-aL1dZ7JL827EIaxfss_kcc_2aEb4DtxKNkmh5mzmeo=.b8cb47fb-32a2-42eb-a73a-2f5cbc74d52b@github.com>
 <je6bMjE1Vp_FFIlnsWpXeBFMn6pJTfSkXyoLw1A9vvk=.df625b47-af73-411f-a5a1-af2fbaa84a24@github.com>
 <Y20qlyPJVQhMoFYIJ2kZ3sdrnRtVO-ODyu5x2PTvgOM=.eb91a68f-9dae-4181-acdf-86326b8d39c9@github.com>
Message-ID: <qsER-upNXA21irrqFWa4q8E2xIuxcbg21qSWdrSdp1Q=.13dd1a21-ef80-4e48-994c-54a583ababe9@github.com>

On Thu, 13 Nov 2025 06:01:05 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> test/jdk/jdk/internal/util/DecimalDigitsTest.java line 36:
>> 
>>> 34:  * @summary Test DecimalDigits.appendPair method with LATIN1 and UTF16 encoding
>>> 35:  * @modules java.base/jdk.internal.util
>>> 36:  * @run testng test.jdk.internal.util.DecimalDigitsTest
>> 
>> We recommend using junit for new tests.
>
> import org.junit.jupiter.api.Test;
> import static org.junit.jupiter.api.Assertions.assertEquals;
> 
> 
> Using JUnit 5 will cause an error:
> 
> /Users/wenshao/Work/git/jdk/test/jdk/jdk/internal/util/DecimalDigitsTest.java:27: error: package org.junit.jupiter.api does not exist
> import static org.junit.jupiter.api.Assertions.assertEquals;

testng is fine, for consistency within the java.time tests, all of which use testng.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2524705231

From pminborg at openjdk.org  Fri Nov 14 15:35:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 15:35:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <sNjO1swdzNxW2L5GbPoiKqOMlTDoFlfr3SVhz3HHNgY=.4ee45512-ed3b-4ffb-bd00-580ea3844cf9@github.com>

On Wed, 12 Nov 2025 16:17:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 433:
> 
>> 431:             @Override public V      getValue() {
>> 432:                 final int index = map.indexFor(getKey);
>> 433:                 final V v = map.getAcquire(getKey);
> 
> I suppose you could use `orElseCompute` here, since you already have the index

Nice. Then we can get rid of the getAquire() method as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527915904

From pminborg at openjdk.org  Fri Nov 14 15:41:36 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 15:41:36 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <6zrll105lMejyo1PAG6cfBFzYt3N2-_9lIK6uP-Wl8A=.3e7908a7-71da-452e-8703-c4b7b5d661c3@github.com>

On Wed, 12 Nov 2025 16:32:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 607:
> 
>> 605:         assert Thread.holdsLock(mutex) : index + "didn't hold " + mutex;
>> 606:         // We know we hold the monitor here so plain semantic is enough
>> 607:         if (array[index] == null) {
> 
> This should always be true when we get here, right?

This is just an extra safety net to emulate a CAS op (while we are holding the monitor).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527936851

From swen at openjdk.org  Fri Nov 14 15:48:16 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 14 Nov 2025 15:48:16 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v24]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <9wkLz_EcOnSMn-PwvZVYvwEbh3j0BqPqR_PgMvKwDkM=.f709c870-e48f-4be7-b3e5-f02edadfdc29@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add test and from @RogerRiggs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/0abf226b..0070e7b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=22-23

  Stats: 37 lines in 1 file changed: 29 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

PR: https://git.openjdk.org/jdk/pull/26911

From swen at openjdk.org  Fri Nov 14 15:52:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 14 Nov 2025 15:52:46 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v24]
In-Reply-To: <9wkLz_EcOnSMn-PwvZVYvwEbh3j0BqPqR_PgMvKwDkM=.f709c870-e48f-4be7-b3e5-f02edadfdc29@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <9wkLz_EcOnSMn-PwvZVYvwEbh3j0BqPqR_PgMvKwDkM=.f709c870-e48f-4be7-b3e5-f02edadfdc29@github.com>
Message-ID: <-YApwwtJ8DmPFiKl28zZcP6HUG3fHpV-Llaw0j-nUS0=.84263959-31f1-4fa7-af02-54830d3060d2@github.com>

On Fri, 14 Nov 2025 15:48:16 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test and from @RogerRiggs

The `DecimalDigits.appendPair` and `appendQuad` methods will experience performance degradation if a `StringBuilder` with `Encoding UTF16` is passed to them. This occurs when `DecimalDigits.appendPair` or `appendQuad` is used in `DateTimeFormatter::formatTo`.

For example:

LocalDateTime localDateTime = ...;
StringBuilder sb = new StringBuilder();
sb.append('?');
DateTimeFormatter.ISO_DATE_TIME.formatTo(localDateTime, sb);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3533393414

From duke at openjdk.org  Fri Nov 14 15:56:47 2025
From: duke at openjdk.org (jengebr)
Date: Fri, 14 Nov 2025 15:56:47 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v7]
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <QqC8K6j2oXplESNqslXh1QUiOoIsOq4AfiU8fvXewwc=.8d4526e7-7070-4b7d-94d1-0e707fb162eb@github.com>

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Polishing test and benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28116/files
  - new: https://git.openjdk.org/jdk/pull/28116/files/49b43473..1fc9e9e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28116&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28116&range=05-06

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28116/head:pull/28116

PR: https://git.openjdk.org/jdk/pull/28116

From henryjen at openjdk.org  Fri Nov 14 16:00:43 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 14 Nov 2025 16:00:43 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v8]
In-Reply-To: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
Message-ID: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com>

> This PR include build changes from @magicus and jlink change to verify the build signature.
> 
> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
> 
> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>                                                                                                                                                                  
> ? java --version
> openjdk 26-internal 2026-03-17
> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>                                                                                                                                                                  
> ? jlink --version                                                                       
> 26-internal
>                                                                                                                                                                  
> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>                                                                                                                                                                  
> ? jlink --add-modules java.base --output macos
>                                                             
> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>                                                                                                                                                                  
> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  adapt review feedbacks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28155/files
  - new: https://git.openjdk.org/jdk/pull/28155/files/5fb443b2..a3edf9ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=06-07

  Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155

PR: https://git.openjdk.org/jdk/pull/28155

From epeter at openjdk.org  Fri Nov 14 16:07:06 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 14 Nov 2025 16:07:06 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization
In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
Message-ID: <ck9qtvcIKfxaa47UNuAa2Vqu98FzFZoLDIsNIdsCthM=.14fca2ef-a4f2-48b0-9ae7-8492a02d6f46@github.com>

On Thu, 13 Nov 2025 21:34:30 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> 
> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
> 
> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
> 
> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
> 
> # Test
> ## Jtreg
> 
> in progress...
> 
> ## Performance
> 
> Column names meanings:
> * p: with patch
> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> * m: without patch
> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> 
> #### Average improvement
> 
> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
> 
> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
> -- | -- | -- | --
> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
> 
> </google-sheets-html-origin>

I won't be able to review the RISCV part, so you'll have to find someone else there. I just dropped 2 drive-by comments about the tests :)

test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMove.java line 36:

> 34:  * @test
> 35:  * @summary Test conditional move.
> 36:  * @requires vm.simpleArch == "riscv64"

I would prefer if you could enable the test on all platforms, but just require the specific platform on the IR rules.
What would be even more fantastic: if you were able to also enable the IR rules for `x64` and `aarch64`, but we can also file a follow-up RFE for that.

test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMove.java line 49:

> 47:                                    "-XX:+UnlockExperimentalVMOptions", "-XX:-UseCompactObjectHeaders");
> 48:         TestFramework.runWithFlags("-XX:+UseCMoveUnconditionally", "-XX:-UseVectorCmov",
> 49:                                    "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCompactObjectHeaders");

Wait. Is this just a copy of the existing vector test, but run with CMove vectorization disabled?
If so, we could just add these additional runs to the existing test, and guard the IR test with corresponding flags:
Have an IR rule for `-XX:-UseVectorCmov` and one for `-XX:+UseVectorCmov`.

That would allow us to reduce some code duplication. And it would also avoid letting the two tests go out of sync when people add more to one but not the other.

What do you think?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28309#pullrequestreview-3465590460
PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2528003621
PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2528011154

From kcr at openjdk.org  Fri Nov 14 16:23:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Nov 2025 16:23:06 GMT
Subject: RFR: 8371591: VerifyJimage tool incorrectly skips all tests when
 comparing directory structure [v3]
In-Reply-To: <J5LGDzb7xzhy1qdduW8ZqwZqJaCPrgVQNckDUXxtoSs=.a7c4e40d-7396-4cb6-a2bf-f06f229693ec@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
 <J5LGDzb7xzhy1qdduW8ZqwZqJaCPrgVQNckDUXxtoSs=.a7c4e40d-7396-4cb6-a2bf-f06f229693ec@github.com>
Message-ID: <S0DUTnqh1tusqciW2tYqvRRtPJesoAy75GOuvJSv7CQ=.dbd5bda0-186b-4db8-84a2-7899c722a2c1@github.com>

On Thu, 13 Nov 2025 21:28:58 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Rewrite of VerifyJimage test to fix several severe issues.
>> 
>> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
>> 
>> Issue 1: Broken file comparison
>> 
>> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
>> 
>> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
>> 
>> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
>> 
>> Issue 2: Use of BasicImageReader for class file reading
>> 
>> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
>> 
>> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
>> 
>> Issue 3: File comparison mode was never run by default
>> 
>> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
>
> David Beaumont 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 branch 'master' into jdk_8371591_verify/squashed
>  - Remove unhelpful output
>  - Tweaked path to class name handling for clarity
>  - Fix very broken test and make it compatible with preview mode
>  - Make entry name reading idempotent

@david-beaumont Alan modified the title of the JBS bug. Update the PR title to match, then Skara will mark it as `ready`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28265#issuecomment-3533531935

From duke at openjdk.org  Fri Nov 14 16:57:15 2025
From: duke at openjdk.org (duke)
Date: Fri, 14 Nov 2025 16:57:15 GMT
Subject: RFR: 8371591: VerifyJimage test incorrectly skips all tests when
 comparing directory structure [v3]
In-Reply-To: <J5LGDzb7xzhy1qdduW8ZqwZqJaCPrgVQNckDUXxtoSs=.a7c4e40d-7396-4cb6-a2bf-f06f229693ec@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
 <J5LGDzb7xzhy1qdduW8ZqwZqJaCPrgVQNckDUXxtoSs=.a7c4e40d-7396-4cb6-a2bf-f06f229693ec@github.com>
Message-ID: <62o-XYWKpTnXFfYKIWsB8fAKPhYLHvnNWOJMtsELrNI=.6efa49cd-6a2d-41a9-b569-a7cb26fb7f49@github.com>

On Thu, 13 Nov 2025 21:28:58 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Rewrite of VerifyJimage test to fix several severe issues.
>> 
>> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
>> 
>> Issue 1: Broken file comparison
>> 
>> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
>> 
>> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
>> 
>> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
>> 
>> Issue 2: Use of BasicImageReader for class file reading
>> 
>> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
>> 
>> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
>> 
>> Issue 3: File comparison mode was never run by default
>> 
>> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
>
> David Beaumont 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 branch 'master' into jdk_8371591_verify/squashed
>  - Remove unhelpful output
>  - Tweaked path to class name handling for clarity
>  - Fix very broken test and make it compatible with preview mode
>  - Make entry name reading idempotent

@david-beaumont 
Your change (at version 6a4cb625c6c3b1efdf300a6e14396ff69c564949) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28265#issuecomment-3533690217

From mli at openjdk.org  Fri Nov 14 18:03:53 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 14 Nov 2025 18:03:53 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
Message-ID: <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>

> Hi,
> 
> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
> 
> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
> 
> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
> 
> # Test
> ## Jtreg
> 
> in progress...
> 
> ## Performance
> 
> Column names meanings:
> * p: with patch
> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> * m: without patch
> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> 
> #### Average improvement
> 
> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
> 
> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
> -- | -- | -- | --
> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
> 
> </google-sheets-html-origin>

Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:

 - add CMove+CmpP/N tests
 - fix cmovF/D_cmpP

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28309/files
  - new: https://git.openjdk.org/jdk/pull/28309/files/ec0d8cc4..5c0d645d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=00-01

  Stats: 359 lines in 2 files changed: 357 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28309/head:pull/28309

PR: https://git.openjdk.org/jdk/pull/28309

From mli at openjdk.org  Fri Nov 14 18:15:07 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 14 Nov 2025 18:15:07 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <ck9qtvcIKfxaa47UNuAa2Vqu98FzFZoLDIsNIdsCthM=.14fca2ef-a4f2-48b0-9ae7-8492a02d6f46@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <ck9qtvcIKfxaa47UNuAa2Vqu98FzFZoLDIsNIdsCthM=.14fca2ef-a4f2-48b0-9ae7-8492a02d6f46@github.com>
Message-ID: <5PzMJntiu2waMvciTLvXaUH15Fm3dXZPsDVvkuqWPI0=.68c6456a-e5d3-413e-bef8-d8da95de40bd@github.com>

On Fri, 14 Nov 2025 15:59:18 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add CMove+CmpP/N tests
>>  - fix cmovF/D_cmpP
>
> test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMove.java line 36:
> 
>> 34:  * @test
>> 35:  * @summary Test conditional move.
>> 36:  * @requires vm.simpleArch == "riscv64"
> 
> I would prefer if you could enable the test on all platforms, but just require the specific platform on the IR rules.
> What would be even more fantastic: if you were able to also enable the IR rules for `x64` and `aarch64`, but we can also file a follow-up RFE for that.

Make sense. I filed https://bugs.openjdk.org/browse/JDK-8371920 to track the task, will do it later after this pr.

> test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMove.java line 49:
> 
>> 47:                                    "-XX:+UnlockExperimentalVMOptions", "-XX:-UseCompactObjectHeaders");
>> 48:         TestFramework.runWithFlags("-XX:+UseCMoveUnconditionally", "-XX:-UseVectorCmov",
>> 49:                                    "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCompactObjectHeaders");
> 
> Wait. Is this just a copy of the existing vector test, but run with CMove vectorization disabled?
> If so, we could just add these additional runs to the existing test, and guard the IR test with corresponding flags:
> Have an IR rule for `-XX:-UseVectorCmov` and one for `-XX:+UseVectorCmov`.
> 
> That would allow us to reduce some code duplication. And it would also avoid letting the two tests go out of sync when people add more to one but not the other.
> 
> What do you think?

Good idea!
I can do it. What do you think about the name of the merged tests? `TestConditionalMove.java` or `TestScalarAndVectorConditionalMove.java`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2528463608
PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2528467634

From duke at openjdk.org  Fri Nov 14 18:27:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Nov 2025 18:27:17 GMT
Subject: Integrated: 8371591: VerifyJimage test incorrectly skips all tests
 when comparing directory structure
In-Reply-To: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
References: <8twIrGwrsuCZF5fjFa_UFGmMdCn6RXw-FrZ2IqB2hys=.dc554411-62b5-4f05-ac3a-680b8b7570e1@github.com>
Message-ID: <Kp1LM4T_v_6tBWN5QbGgwdrxjf9gW1sBM7SDhmnnQ44=.072b0199-31d0-49bb-b938-6d5ef7c17ef2@github.com>

On Wed, 12 Nov 2025 12:00:00 GMT, David Beaumont <duke at openjdk.org> wrote:

> Rewrite of VerifyJimage test to fix several severe issues.
> 
> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
> 
> Issue 1: Broken file comparison
> 
> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
> 
> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
> 
> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
> 
> Issue 2: Use of BasicImageReader for class file reading
> 
> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
> 
> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
> 
> Issue 3: File comparison mode was never run by default
> 
> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.

This pull request has now been integrated.

Changeset: 6e7eaf40
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e7eaf40d1b660cbec0a226911c9dc88f94756aa
Stats:     295 lines in 1 file changed: 136 ins; 43 del; 116 mod

8371591: VerifyJimage test incorrectly skips all tests when comparing directory structure

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/28265

From asemenyuk at openjdk.org  Fri Nov 14 18:28:17 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 18:28:17 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
 <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
Message-ID: <cnZcOHalJyxAIb3-gTT3bpBxfttaiFblTyVhvk0Nt6Q=.f4c1e505-242d-4b9d-9593-e655caf2aeb5@github.com>

On Thu, 13 Nov 2025 00:42:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MainResources.properties: remove unreferenced L10N key
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java line 49:
> 
>> 47:                 .bundler(CREATE_MAC_APP_IMAGE, MacBundlingEnvironment::createAppImage)
>> 48:                 .bundler(CREATE_MAC_DMG, LazyLoad::dmgSysEnv, MacBundlingEnvironment::createDmdPackage)
>> 49:                 .bundler(CREATE_MAC_PKG, MacBundlingEnvironment::createPkgPackage));
> 
> Do you know why `CREATE_MAC_PKG` does not need/use environment like `CREATE_MAC_DMG`?

For dmg packaging, we validate that hdiutil and osascript commands are available. We also need to find the SetFile utility that may be in multiple locations. For pkg, we assume pkgbuild and productbuild commands are available and don't do any validation. That is why we have [MacDmgSystemEnvironment](https://github.com/openjdk/jdk/blob/10f262a6ad9a6e89cd79409c5e1a3f7efda76928/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgSystemEnvironment.java) but don't have MacPkgSystemEnvironment. 

Historically, pkg tools were not validated. We can change it in a separate CR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528496058

From asemenyuk at openjdk.org  Fri Nov 14 18:53:08 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 18:53:08 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
 <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
Message-ID: <tTrtzqRk__PC5O85qTE--7YG2FZpIDZiHl3XYQzbDWs=.60d73c71-ccb8-40df-9756-b9b971947b24@github.com>

On Fri, 14 Nov 2025 01:16:31 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MainResources.properties: remove unreferenced L10N key
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 335:
> 
>> 333: 
>> 334:     public static final OptionValue<Boolean> MAC_APP_STORE = booleanOption("mac-app-store")
>> 335:             //.scope(MAC_SIGNING) // TODO: --mac-app-store should be applicable to app image signing operation because it redefines signing key
> 
> I do not like any TODO comments. They usually never got fixed. Bug needs to be filed if follow up is required.

Filed https://bugs.openjdk.org/browse/JDK-8371924

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528571171

From asemenyuk at openjdk.org  Fri Nov 14 18:57:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 18:57:09 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
 <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
Message-ID: <VQX3Vc7JqCZZFhIZ5zVzsI0JNq7XQ_Td77QLxRfOAeQ=.ab2009bc-c592-462e-a357-073d03a360e8@github.com>

On Fri, 14 Nov 2025 02:00:51 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MainResources.properties: remove unreferenced L10N key
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardValidator.java line 48:
> 
>> 46:     static final Predicate<Path> IS_DIRECTORY = Files::isDirectory;
>> 47: 
>> 48:     static final Predicate<Path> IS_EXISTENT_NOT_DIRECTORY = path -> {
> 
> `IS_EXISTENT_NOT_DIRECTORY` will be same as `IS_REGULAR_FILE`? And just do `return Files. isRegularFile(path)`.

`IS_EXISTENT_NOT_DIRECTORY` means it can be a regular file or a symlink.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528583051

From liach at openjdk.org  Fri Nov 14 19:29:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 19:29:13 GMT
Subject: RFR: 8368831:
 ResourceParsingClassHierarchyResolver.getClassInfo(ClassDesc) throws
 unspecified UncheckedIOException [v4]
In-Reply-To: <XLScJW2bF1SqJ57jGi_0lasslXEaQN2LWukDzWbfwqg=.3a924f83-89ab-4a19-bdd7-7ee5a598a686@github.com>
References: <PjC2_W6FCwj1IhMOjyYiJTwOywQr1yhmPWHPbz3v-EY=.3547aa18-f4c9-4c11-bf7e-ca2ea8c7ab76@github.com>
 <XLScJW2bF1SqJ57jGi_0lasslXEaQN2LWukDzWbfwqg=.3a924f83-89ab-4a19-bdd7-7ee5a598a686@github.com>
Message-ID: <Pb23ZuhIZI1PYJGOK2BrYvDyfvSjurPt5-WlU_7H010=.551960c7-ebdc-4cae-91d7-3a52528d414c@github.com>

On Tue, 30 Sep 2025 23:42:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ClassHierarchyResolver provided by users may sporadically run into exceptions due to reasons out of control, such as UncheckedIOException caused by a bad zip header. We should specify that users are allowed to fail their CHR when they encounter a failure when they support a ClassDesc to avoid hiding errors.
>
> Chen Liang 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:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/chr-exception
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
>    
>    Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>
>  - Fix non-IAE propagation
>  - Allow ClassHierarchyResolver to throw RuntimeException

Withdrawing this. Spec for [`ClassHierachyResolver.ofResourceParsing`](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/classfile/ClassHierarchyResolver.html#ofResourceParsing(java.util.function.Function)) states:

> Any [IOException](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/io/IOException.html) from the provided input stream is rethrown as an [UncheckedIOException](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/io/UncheckedIOException.html) in [getClassInfo(ClassDesc)](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/classfile/ClassHierarchyResolver.html#getClassInfo(java.lang.constant.ClassDesc)).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27559#issuecomment-3534248154

From liach at openjdk.org  Fri Nov 14 19:29:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 19:29:14 GMT
Subject: Withdrawn: 8368831:
 ResourceParsingClassHierarchyResolver.getClassInfo(ClassDesc) throws
 unspecified UncheckedIOException
In-Reply-To: <PjC2_W6FCwj1IhMOjyYiJTwOywQr1yhmPWHPbz3v-EY=.3547aa18-f4c9-4c11-bf7e-ca2ea8c7ab76@github.com>
References: <PjC2_W6FCwj1IhMOjyYiJTwOywQr1yhmPWHPbz3v-EY=.3547aa18-f4c9-4c11-bf7e-ca2ea8c7ab76@github.com>
Message-ID: <Pb5rjlvObA35PMkJeOsomCqi-Xo2PoF2RDIkNVGFGPo=.1c73838f-e7f8-4184-b97f-1c7dc865fa5d@github.com>

On Mon, 29 Sep 2025 20:40:37 GMT, Chen Liang <liach at openjdk.org> wrote:

> ClassHierarchyResolver provided by users may sporadically run into exceptions due to reasons out of control, such as UncheckedIOException caused by a bad zip header. We should specify that users are allowed to fail their CHR when they encounter a failure when they support a ClassDesc to avoid hiding errors.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27559

From bchristi at openjdk.org  Fri Nov 14 19:38:06 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 14 Nov 2025 19:38:06 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <pUC2CsOOeN2fmLlHuqNHcTO5fZYPLIDwAmZRJEGd2ZY=.3e0a1615-873f-41b2-bd9a-807d8e80a364@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
 <pUC2CsOOeN2fmLlHuqNHcTO5fZYPLIDwAmZRJEGd2ZY=.3e0a1615-873f-41b2-bd9a-807d8e80a364@github.com>
Message-ID: <6hHUTYN71vmfPtE9gricMXDS3d3Two16__qJax7gY7M=.db4c76c6-255d-408b-b69d-7e37b9be22b3@github.com>

On Fri, 14 Nov 2025 09:58:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The failures in the GitHub actions job appear related:
> 
> ```
> /home/runner/work/jdk/jdk/test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java:2011: error: unreported exception Throwable; must be caught or declared to be thrown
>                 super.finalize();
>                               ^
> ```

Indeed.
My understanding is that that is being handled by [JDK-8371682](https://bugs.openjdk.org/browse/JDK-8371682).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3534276282

From bchristi at openjdk.org  Fri Nov 14 19:42:07 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 14 Nov 2025 19:42:07 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
Message-ID: <PR9ANUi7n23h8pl0rPRa3m45QLAztZlpeBTyUAeQ4QQ=.4b787b72-bea2-4f62-9d60-9a24e4f84125@github.com>

On Thu, 13 Nov 2025 23:10:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug report:
> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to
> "[invoke] shutdown() when this executor is no longer referenced and it has no threads."
> 
> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)).
> 
> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)).
> 
> The finalize() method can safely be removed from ThreadPoolExecutor.

Thank you, reviewers. :)
Can I also get a review on the [CSR](https://bugs.openjdk.org/browse/JDK-8371856)? TIA.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3534294953

From asemenyuk at openjdk.org  Fri Nov 14 20:13:19 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 20:13:19 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
Message-ID: <zRIwwSezTPMCdbpxSRyCfheb1BK5ucixtbR_uYGkCCQ=.54a63b37-e39d-4a17-b3c3-78334d2f6af0@github.com>

On Wed, 12 Nov 2025 23:11:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
>> 
>> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
>> 
>> ### Error reporting improved
>> 
>> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
>> 
>> Command line (Windows): 
>> 
>> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
>> 
>> Old error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> 
>> 
>> New error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> Error: Option [--mac-package-name] is not valid on this platform
>> Error: Option [-p] is not valid with type [exe]
>> Error: Option [--linux-menu-group] is not valid on this platform
>> 
>> 
>>  2. Fix misleading error messages.
>> 
>> Command line (Windows): 
>> 
>> jpackage --input no --main-jar no.jar
>> 
>> Old error output:
>> 
>> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
>> 
>> 
>> New error output:
>> 
>> The value "no" provided for parameter --input is not a directory
>> 
>> 
>> 
>> 
>> ### Help output fixed
>> 
>> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
>> 
>> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
>> 
>> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
>> 
>> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
>> 
>> ### Functional changes
>> 
>> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
>> 
>> Like other JD...
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MainResources.properties: remove unreferenced L10N key

There were a few synchronization issues with jpackage. The major one was the use of static member fields throughout the codebase. Andy attempted to fix it with [JDK-8223322](https://bugs.openjdk.org/browse/JDK-8223322), but due to other synchronization issues, the fix for [JDK-8223322](https://bugs.openjdk.org/browse/JDK-8223322) https://github.com/openjdk/jdk/pull/1829 was never integrated. Instead, he applied a smaller-scope fix [JDK-8259238](https://bugs.openjdk.org/browse/JDK-8259238) that fixed the use of static member fields. However, the "synchronized" keyword in [JPackageToolProvider.java](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) was still in place. I don't know what the intent of this "synchronized" is. It doesn't apply to a global object but to the instance of the "jdk.jpackage.internal.JPackageToolProvider" class. Looks like the assumption was that the sy
 stem would create only a single instance of a specific tool provider. There is no such guarantee, though.

If multiple instances of the "jdk.jpackage.internal.JPackageToolProvider" class are created and used asynchronously, the "synchronized" keyword doesn't do what it is supposed to.

The new tool provider implementation in the "jdk.jpackage.internal.cli.Main" class doesn't use "synchronized" keyword. Command-line parsing code doesn't use global variables; it is thread-safe by design, rather than having thread safety as a patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28163#issuecomment-3534396848

From rriggs at openjdk.org  Fri Nov 14 20:15:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Nov 2025 20:15:03 GMT
Subject: RFR: 8371732: [redo] Change java.time month/day field types to
 'byte' [v2]
In-Reply-To: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
References: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
Message-ID: <ax8qXZEhKiwzmZVIi4eElP0EK5uhGzGkpbB-O0_c3D8=.4df11800-cd6f-412d-b098-912e649d1cde@github.com>

> Redo change (8371732) that failed when the updated class objects were incompatible.
> The fields of classes are changed to allow a more compact form of storage.
> 
> To ensure compatibility of the class objects, the fields are explicitly declared in SerialPersistentFields with the original field types.
> The fields are marked `transient` to indicate the field declarations are not used for serialization.
> The affected classes are java.time.LocalDate, MonthDay, and YearMonth.
> Tests are added to verify the types and names of serialized fields of each class.
> 
> HijrahDate only changes the field types, the fields are transient and there is no change to the serialized from of the HijrahDate.class object.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Use "Java SE 8" instead of version 1.8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28274/files
  - new: https://git.openjdk.org/jdk/pull/28274/files/39d8aa20..4876fac9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28274&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28274&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28274.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28274/head:pull/28274

PR: https://git.openjdk.org/jdk/pull/28274

From asemenyuk at openjdk.org  Fri Nov 14 20:35:34 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 20:35:34 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v7]
In-Reply-To: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
Message-ID: <5ieo5ugssXTwd_KmxA2CRYhFgc6Cfqylp5PaTU9zDj8=.af3269cf-dcb2-4b68-8941-8ad697839b0a@github.com>

> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
> 
> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
> 
> ### Error reporting improved
> 
> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
> 
> Command line (Windows): 
> 
> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
> 
> Old error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> 
> 
> New error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> Error: Option [--mac-package-name] is not valid on this platform
> Error: Option [-p] is not valid with type [exe]
> Error: Option [--linux-menu-group] is not valid on this platform
> 
> 
>  2. Fix misleading error messages.
> 
> Command line (Windows): 
> 
> jpackage --input no --main-jar no.jar
> 
> Old error output:
> 
> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
> 
> 
> New error output:
> 
> The value "no" provided for parameter --input is not a directory
> 
> 
> 
> 
> ### Help output fixed
> 
> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
> 
> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
> 
> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
> 
> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
> 
> ### Functional changes
> 
> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
> 
> Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.
> 
> In addition to `--opt...

Alexey Semenyuk has updated the pull request incrementally with five additional commits since the last revision:

 - Removed commented out code
 - Fix typo and trailing whitespace
 - Fix findings in the code review
 - StandardValidator: expose
 - Validator: formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28163/files
  - new: https://git.openjdk.org/jdk/pull/28163/files/f7de2646..862285d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28163&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28163&range=05-06

  Stats: 93 lines in 14 files changed: 20 ins; 14 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/28163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28163/head:pull/28163

PR: https://git.openjdk.org/jdk/pull/28163

From asemenyuk at openjdk.org  Fri Nov 14 20:35:36 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 20:35:36 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v5]
In-Reply-To: <lMP86wJo79yRwf7U2KliAsXc3WnXArp8ookZYuz9Dvo=.084bff47-57b9-4b42-a536-42d0dd9c886e@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <r8u5L0fySGlaC9-c6_Dh07LOuCIpPFN-8FfB3_Y7BEw=.d4adf13c-3867-472c-9612-11b8377110e2@github.com>
 <lMP86wJo79yRwf7U2KliAsXc3WnXArp8ookZYuz9Dvo=.084bff47-57b9-4b42-a536-42d0dd9c886e@github.com>
Message-ID: <EF9OgrYdIDIKFPhuK_FllmO9XBbcTUU7p1YbTiL9x7Q=.03350ebd-a6f6-4b5c-8e07-24e36290f56b@github.com>

On Wed, 12 Nov 2025 21:53:11 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update cli-*.txt help output files
>>  - StandardOption, HelpResources.properties: split description of the "add-launcher" option by OS
>>  - OptionSpecBuilder: bugfix
>
> src/jdk.internal.opt/share/classes/module-info.java line 1:
> 
>> 1: /*
> 
> Copyright year needs to be updated to 2025.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528829649

From asemenyuk at openjdk.org  Fri Nov 14 20:35:42 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 20:35:42 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
 <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
Message-ID: <nFy7KCEdinht36uSMzi8cdUEzkdPk4J94HNn4d71ngE=.a4df6939-28a0-4221-a629-1ccaaf7c01e4@github.com>

On Thu, 13 Nov 2025 03:17:22 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MainResources.properties: remove unreferenced L10N key
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/HelpFormatter.java line 46:
> 
>> 44:         this.optionGroups = Objects.requireNonNull(optionGroups);
>> 45:         this.formatter = Objects.requireNonNull(formatter);
>> 46: 
> 
> Extra new line.

Fixed

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/JOptSimpleOptionsBuilder.java line 184:
> 
>> 182:             try {
>> 183:                 initializer.run();
>> 184:                 throw new AssertionError();
> 
> Can you put a comment on why we need `throw new AssertionError()`? I assume that `initializer.run()` never exits.

Added a comment

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpec.java line 126:
> 
>> 124:      * <p>
>> 125:      * If the option has three names "a", "b", and "c", the stream will have three
>> 126:      * option spec objects each with a single name. The firt will have name "a", the
> 
> `firt` -> `first`

Fixed

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardAppImageFileOption.java line 227:
> 
>> 225:         }).map(option -> {
>> 226:             var spec = context.mapOptionSpec(option.spec());
>> 227:             var strValue = Optional.ofNullable(properties.get(spec.name().name()));
> 
> `name().name()` why we need name of the name and what it means?

`OptionSpec.name()` method returns a reference to an object of type `OptionName` that also has a `name()` method. Option name can be "option", or "--option", or "-o" string. So I decided to introduce the `OptionName` class to encapsulate these variants.

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 492:
> 
>> 490:                 context.asFileSource().ifPresent(propertyFile -> {
>> 491:                     b.converterExceptionFactory(forMessageWithOptionValueAndName(propertyFile));
>> 492:                     b.converterExceptionFormatString("error.properties-paramater-not-path");
> 
> `paramater` -> `parameter`. Below as well.

Fixed

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 544:
> 
>> 542:             }))
>> 543:             .converterExceptionFactory(ERROR_WITH_VALUE_AND_OPTION_NAME)
>> 544: //            .converterExceptionFormatString("error.paramater-not-launcher-shortcut-dir")
> 
> Remove if not needed.

Fixed

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 644:
> 
>> 642:                     final var theCause = cause.orElseThrow();
>> 643:                     if (theCause instanceof AddLauncherSyntaxException) {
>> 644: //                        return ERROR_WITH_VALUE_AND_OPTION_NAME.create(optionName,
> 
> Remove if not needed.

Fixed

> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java line 403:
> 
>> 401:             }
>> 402: 
>> 403: //            Builder expectMalformedError(String v) {
> 
> Remove if not needed.

Fixed

> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java line 544:
> 
>> 542:                 buildLauncherShortcutTest().optionValue("false"),
>> 543:                 buildLauncherShortcutTest().optionValue(""),
>> 544: //                buildLauncherShortcutTest().optionValue("").propertyFile(true),
> 
> Remove and line 547.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528828988
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528820042
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528837414
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528844728
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528827278
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528856437
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528856223
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528827729
PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2528828212

From asemenyuk at openjdk.org  Fri Nov 14 20:42:13 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Nov 2025 20:42:13 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v7]
In-Reply-To: <5ieo5ugssXTwd_KmxA2CRYhFgc6Cfqylp5PaTU9zDj8=.af3269cf-dcb2-4b68-8941-8ad697839b0a@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <5ieo5ugssXTwd_KmxA2CRYhFgc6Cfqylp5PaTU9zDj8=.af3269cf-dcb2-4b68-8941-8ad697839b0a@github.com>
Message-ID: <aiUAtZW-nADN-b7gtZh3bqs54xjiKF2vv0N7qvPV9tw=.92f0778c-e67c-46dd-b680-4e01b44fee4f@github.com>

On Fri, 14 Nov 2025 20:35:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
>> 
>> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
>> 
>> ### Error reporting improved
>> 
>> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
>> 
>> Command line (Windows): 
>> 
>> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
>> 
>> Old error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> 
>> 
>> New error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> Error: Option [--mac-package-name] is not valid on this platform
>> Error: Option [-p] is not valid with type [exe]
>> Error: Option [--linux-menu-group] is not valid on this platform
>> 
>> 
>>  2. Fix misleading error messages.
>> 
>> Command line (Windows): 
>> 
>> jpackage --input no --main-jar no.jar
>> 
>> Old error output:
>> 
>> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
>> 
>> 
>> New error output:
>> 
>> The value "no" provided for parameter --input is not a directory
>> 
>> 
>> 
>> 
>> ### Help output fixed
>> 
>> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
>> 
>> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
>> 
>> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
>> 
>> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
>> 
>> ### Functional changes
>> 
>> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
>> 
>> Like other JD...
>
> Alexey Semenyuk has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Removed commented out code
>  - Fix typo and trailing whitespace
>  - Fix findings in the code review
>  - StandardValidator: expose
>  - Validator: formatting

Pushed commits addressing all findings in the review.
Additionally:
 - Fix minor code formatting issue in src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Validator.java
 - Remove unreferenced keys from share\classes\jdk\jpackage\internal\resources\MainResources.properties

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28163#issuecomment-3534486280

From darcy at openjdk.org  Fri Nov 14 20:56:06 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Nov 2025 20:56:06 GMT
Subject: RFR: 8371732: [redo] Change java.time month/day field types to
 'byte' [v2]
In-Reply-To: <ax8qXZEhKiwzmZVIi4eElP0EK5uhGzGkpbB-O0_c3D8=.4df11800-cd6f-412d-b098-912e649d1cde@github.com>
References: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
 <ax8qXZEhKiwzmZVIi4eElP0EK5uhGzGkpbB-O0_c3D8=.4df11800-cd6f-412d-b098-912e649d1cde@github.com>
Message-ID: <ImB7Oa7ChjXDtzkEdGsDngF7IcZL77zDoMIDYwPxIms=.79d05683-3304-4688-8b7d-cbf74cc4c1a8@github.com>

On Fri, 14 Nov 2025 20:15:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Redo change (8371732) that failed when the updated class objects were incompatible.
>> The fields of classes are changed to allow a more compact form of storage.
>> 
>> To ensure compatibility of the class objects, the fields are explicitly declared in SerialPersistentFields with the original field types.
>> The fields are marked `transient` to indicate the field declarations are not used for serialization.
>> The affected classes are java.time.LocalDate, MonthDay, and YearMonth.
>> Tests are added to verify the types and names of serialized fields of each class.
>> 
>> HijrahDate only changes the field types, the fields are transient and there is no change to the serialized from of the HijrahDate.class object.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "Java SE 8" instead of version 1.8

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28274#pullrequestreview-3466769157

From rriggs at openjdk.org  Fri Nov 14 21:00:13 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Nov 2025 21:00:13 GMT
Subject: Integrated: 8371732: [redo] Change java.time month/day field types to
 'byte'
In-Reply-To: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
References: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
Message-ID: <4eJRTOIPh6kY6dGv4HHlLGtSp2pmLmcebYe_8vFuYFU=.2522862d-53c1-4f2d-b1fb-af1cf6804343@github.com>

On Wed, 12 Nov 2025 18:29:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Redo change (8371732) that failed when the updated class objects were incompatible.
> The fields of classes are changed to allow a more compact form of storage.
> 
> To ensure compatibility of the class objects, the fields are explicitly declared in SerialPersistentFields with the original field types.
> The fields are marked `transient` to indicate the field declarations are not used for serialization.
> The affected classes are java.time.LocalDate, MonthDay, and YearMonth.
> Tests are added to verify the types and names of serialized fields of each class.
> 
> HijrahDate only changes the field types, the fields are transient and there is no change to the serialized from of the HijrahDate.class object.

This pull request has now been integrated.

Changeset: cc05530b
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc05530b813564a40c233eaaa80b906795c6d752
Stats:     124 lines in 7 files changed: 100 ins; 0 del; 24 mod

8371732: [redo] Change java.time month/day field types to 'byte'

Reviewed-by: darcy, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/28274

From liach at openjdk.org  Fri Nov 14 21:20:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 21:20:41 GMT
Subject: RFR: 8367585: Move Utf8Entry length validation earlier [v2]
In-Reply-To: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
Message-ID: <VQ6ohAItv7niHtA7XxgMeP5i6VBj56O9LnPn-98yV-4=.ce5b8d62-1649-4fff-8bce-0157b14abec5@github.com>

> John Rose suggests in https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that ClassFile API should validate Utf8Entry length eagerly upon construction. Currently we validate upon writing to bytes, which avoids validation overhead. However, given that most class file utf8 data are shorter than 1/3 of the max length, which is always an encodable length, the performance impact should be low.
> 
> Preventing the creation of unrepresentable UTF8 entries can prevent passing such invalid instances around, making such problems easier to debug than a failure at building.
> 
> Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of the regularly run transformation benchmarks seems neutral, less than 5% perturbations.
> 
> I will update docs to reflect this change, given how widespread this is across JDK - it seems the only exempt classes are Signature, ClassSignature, and MethodSignature.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Redundant changes, improve stuff
 - Stage
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
 - Stage
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
 - Avoid being too specific
 - ... and 3 more: https://git.openjdk.org/jdk/compare/58b601ac...8973a15d

-------------

Changes: https://git.openjdk.org/jdk/pull/27281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27281&range=01
  Stats: 382 lines in 10 files changed: 212 ins; 53 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/27281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27281/head:pull/27281

PR: https://git.openjdk.org/jdk/pull/27281

From liach at openjdk.org  Fri Nov 14 21:20:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 21:20:43 GMT
Subject: RFR: 8367585: Move Utf8Entry length validation earlier [v2]
In-Reply-To: <LWU6F2M9hQ2Wv0Cbp_1--9p28aIF7uB04imxN6MCVIc=.ca0cca1c-a929-4335-bec9-402ee580a0a3@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
 <LWU6F2M9hQ2Wv0Cbp_1--9p28aIF7uB04imxN6MCVIc=.ca0cca1c-a929-4335-bec9-402ee580a0a3@github.com>
Message-ID: <s2273Wt48N9FutDyl9k6OOMMfkaWLn4-pAiMEFA98Ac=.ccb99639-df2e-4a86-b146-bf6f8fa654c4@github.com>

On Wed, 1 Oct 2025 14:57:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Redundant changes, improve stuff
>>  - Stage
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
>>  - Stage
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-utf8-length-early
>>  - Avoid being too specific
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/58b601ac...8973a15d
>
> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 160:
> 
>> 158:             if (!ModifiedUtf.isValidLengthInConstantPool(s)) {
>> 159:                 throw new IllegalArgumentException("utf8 length out of range of u2: " + ModifiedUtf.utfLen(s));
>> 160:             }
> 
> There might be multiple Utf8EntryImpl instances created and later reduced into a single entry to write, so the check performed here might be redundant.

I still think this is necessary. Most of the time, for strings with length < 20000, the check is almost trivial. Throwing an exception here provides a more useful stack trace about where the long string is first created, compared to a later exception which is harder to trace.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27281#discussion_r2528957813

From liach at openjdk.org  Fri Nov 14 21:43:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 21:43:49 GMT
Subject: RFR: 8367585: Move Utf8Entry length validation earlier [v3]
In-Reply-To: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
Message-ID: <lKAEDkjEZd7M2snPwoXp5LjO5QffNN3m-QYyenqwvq4=.58becf07-3f94-4a41-b224-cabb3c4aa340@github.com>

> John Rose suggests in https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that ClassFile API should validate Utf8Entry length eagerly upon construction. Currently we validate upon writing to bytes, which avoids validation overhead. However, given that most class file utf8 data are shorter than 1/3 of the max length, which is always an encodable length, the performance impact should be low.
> 
> Preventing the creation of unrepresentable UTF8 entries can prevent passing such invalid instances around, making such problems easier to debug than a failure at building.
> 
> Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of the regularly run transformation benchmarks seems neutral, less than 5% perturbations.
> 
> I will update docs to reflect this change, given how widespread this is across JDK - it seems the only exempt classes are Signature, ClassSignature, and MethodSignature.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27281/files
  - new: https://git.openjdk.org/jdk/pull/27281/files/8973a15d..15858087

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27281&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27281&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27281/head:pull/27281

PR: https://git.openjdk.org/jdk/pull/27281

From liach at openjdk.org  Fri Nov 14 21:57:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 21:57:06 GMT
Subject: RFR: 8367585: Prevent creation of unrepresentable Utf8Entry [v3]
In-Reply-To: <lKAEDkjEZd7M2snPwoXp5LjO5QffNN3m-QYyenqwvq4=.58becf07-3f94-4a41-b224-cabb3c4aa340@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
 <lKAEDkjEZd7M2snPwoXp5LjO5QffNN3m-QYyenqwvq4=.58becf07-3f94-4a41-b224-cabb3c4aa340@github.com>
Message-ID: <oqFZxS6BeBYh-kQEpyAHMR6NFy-FiDbstGyfckruWrg=.fbaab164-5bfb-4b6a-b9d3-7829fafc3f75@github.com>

On Fri, 14 Nov 2025 21:43:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> John Rose suggests in https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that ClassFile API should validate Utf8Entry length eagerly upon construction. Currently we validate upon writing to bytes, which avoids validation overhead. However, given that most class file utf8 data are shorter than 1/3 of the max length, which is always an encodable length, the performance impact should be low.
>> 
>> Preventing the creation of unrepresentable UTF8 entries can prevent passing such invalid instances around, making such problems easier to debug than a failure at building.
>> 
>> Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of the regularly run transformation benchmarks seems neutral, less than 5% perturbations.
>> 
>> I will update docs to reflect this change, given how widespread this is across JDK - it seems the only exempt classes are Signature, ClassSignature, and MethodSignature.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

I have removed the meaningless documentation noise. Now this patch simply focuses on preventing creation of unrepresentable Utf8Entry.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27281#issuecomment-3534770241

From almatvee at openjdk.org  Fri Nov 14 22:02:08 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 14 Nov 2025 22:02:08 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <cnZcOHalJyxAIb3-gTT3bpBxfttaiFblTyVhvk0Nt6Q=.f4c1e505-242d-4b9d-9593-e655caf2aeb5@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
 <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
 <cnZcOHalJyxAIb3-gTT3bpBxfttaiFblTyVhvk0Nt6Q=.f4c1e505-242d-4b9d-9593-e655caf2aeb5@github.com>
Message-ID: <m5HmrmosJE39CLOKFnc6QoIZfqWbrxhvuqiKXl5rxTQ=.f005e31e-4f32-4639-a28c-84fabbe6e99a@github.com>

On Fri, 14 Nov 2025 18:24:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java line 49:
>> 
>>> 47:                 .bundler(CREATE_MAC_APP_IMAGE, MacBundlingEnvironment::createAppImage)
>>> 48:                 .bundler(CREATE_MAC_DMG, LazyLoad::dmgSysEnv, MacBundlingEnvironment::createDmdPackage)
>>> 49:                 .bundler(CREATE_MAC_PKG, MacBundlingEnvironment::createPkgPackage));
>> 
>> Do you know why `CREATE_MAC_PKG` does not need/use environment like `CREATE_MAC_DMG`?
>
> For dmg packaging, we validate that hdiutil and osascript commands are available. We also need to find the SetFile utility that may be in multiple locations. For pkg, we assume pkgbuild and productbuild commands are available and don't do any validation. That is why we have [MacDmgSystemEnvironment](https://github.com/openjdk/jdk/blob/10f262a6ad9a6e89cd79409c5e1a3f7efda76928/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgSystemEnvironment.java) but don't have MacPkgSystemEnvironment. 
> 
> Historically, pkg tools were not validated. We can change it in a separate CR.

Thanks for explanation. Lets keep it this way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2529082020

From liach at openjdk.org  Fri Nov 14 22:03:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 22:03:06 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v7]
In-Reply-To: <QqC8K6j2oXplESNqslXh1QUiOoIsOq4AfiU8fvXewwc=.8d4526e7-7070-4b7d-94d1-0e707fb162eb@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <QqC8K6j2oXplESNqslXh1QUiOoIsOq4AfiU8fvXewwc=.8d4526e7-7070-4b7d-94d1-0e707fb162eb@github.com>
Message-ID: <7AjImdR7K6wEBfHy-2_lBABLtmor_2_tsV_M8iM-qsQ=.281ff055-3b11-4ad8-85c9-e1736d503628@github.com>

On Fri, 14 Nov 2025 15:56:47 GMT, jengebr <duke at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Polishing test and benchmark

src/java.base/share/classes/java/util/Collections.java line 5264:

> 5262:         public <T> T[] toArray(T[] a) {
> 5263:             if (a.length < 1)
> 5264:                 a = (T[])java.lang.reflect.Array.newInstance(a.getClass().getComponentType(), 1);

Suggestion:

                a = (T[]) Array.newInstance(a.getClass().getComponentType(), 1);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2529081917

From duke at openjdk.org  Fri Nov 14 22:28:24 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Fri, 14 Nov 2025 22:28:24 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v6]
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <WQNH5jxn2wUEn37ThX-qapBbaqPItwdMXC_1ku5zw9o=.74cadb4f-1904-4765-895d-09bc0c9b8483@github.com>

> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach

Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:

  rework

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28124/files
  - new: https://git.openjdk.org/jdk/pull/28124/files/fb7b28c0..b96a0152

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=04-05

  Stats: 76 lines in 1 file changed: 24 ins; 48 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28124/head:pull/28124

PR: https://git.openjdk.org/jdk/pull/28124

From liach at openjdk.org  Fri Nov 14 22:58:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 22:58:24 GMT
Subject: Integrated: 8371319: java.lang.reflect.Method#equals doesn't
 short-circuit with same instances
In-Reply-To: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
References: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
Message-ID: <grBTPJP62UC7HqjI9dbzEiocRpIMrMpWkSUW8uM3oVw=.63f99b65-6b11-4f67-8c9f-a2b01f12cc98@github.com>

On Mon, 10 Nov 2025 17:59:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There is currently no shortcut for fast equals for Method or Constructor. While the comparison for declaring class, name (interned strings' identity), and return type are very efficient with identity comparison, the comparison for parameter type is not so much: We always have to iterate through every parameter.
> 
> Luckily, even though we are burdened with the different method and constructor instance due to setAccessible, their parameter type arrays are shared most of the time; in particular, in the same root method/constructor hierarchy, all instances share the same method object. Thus, we can perform a `==` check on the incoming array to provide a fast path.
> 
> Benchmark numbers before and after:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.189 ? 0.024  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  2.449 ? 0.033  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.541 ? 0.027  ns/op
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.186 ? 0.042  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  1.078 ? 0.049  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.395 ? 0.018  ns/op

This pull request has now been integrated.

Changeset: 7aff8e15
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7aff8e15ba59b1e23d2e62c200d52a26da1a2030
Stats:     88 lines in 2 files changed: 88 ins; 0 del; 0 mod

8371319: java.lang.reflect.Method#equals doesn't short-circuit with same instances

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/28221

From liach at openjdk.org  Fri Nov 14 22:58:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 22:58:23 GMT
Subject: RFR: 8371319: java.lang.reflect.Method#equals doesn't
 short-circuit with same instances
In-Reply-To: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
References: <guvIKrL0od9upEB50uXRFrb5KniS7GhU2OymG35BT14=.c5b23a9d-afea-4bfb-9d29-c2a352d459a7@github.com>
Message-ID: <tytqwdLoNlW8a90UVexPsEgU7xod-XHaYWMThtlqHX8=.12e2edb8-9886-454e-b5a3-b88f387d860c@github.com>

On Mon, 10 Nov 2025 17:59:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There is currently no shortcut for fast equals for Method or Constructor. While the comparison for declaring class, name (interned strings' identity), and return type are very efficient with identity comparison, the comparison for parameter type is not so much: We always have to iterate through every parameter.
> 
> Luckily, even though we are burdened with the different method and constructor instance due to setAccessible, their parameter type arrays are shared most of the time; in particular, in the same root method/constructor hierarchy, all instances share the same method object. Thus, we can perform a `==` check on the incoming array to provide a fast path.
> 
> Benchmark numbers before and after:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.189 ? 0.024  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  2.449 ? 0.033  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.541 ? 0.027  ns/op
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ExecutableCompareBenchmark.distinctParams    avgt    5  1.186 ? 0.042  ns/op
> ExecutableCompareBenchmark.equalMethods      avgt    5  1.078 ? 0.049  ns/op
> ExecutableCompareBenchmark.sameMethodObject  avgt    5  0.395 ? 0.018  ns/op

Thanks for the reviews! Tier 1-3 passes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28221#issuecomment-3534972806

From liach at openjdk.org  Fri Nov 14 23:03:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Nov 2025 23:03:22 GMT
Subject: RFR: 8357728: Optimize Executable#synthesizeAllParams [v2]
In-Reply-To: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
References: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
Message-ID: <xaJ7tIzIK6QEEINEz3caZWqZ__Yhxn0ndJM4BX7SuLU=.9d442711-9aad-41bf-bd89-7e1c1932591d@github.com>

> Currently, fake parameters are created with "arg0" etc. strings that are retained for class file methods with no MethodParameters attribute. The original issue report observes many of these strings present in the heap. To address this issue, we can remove these eagerly created fake names, bringing their behavior in line with nameless parameters from MethodParameters attribute, such as those from inner class constructors. A unit test verifies that no name is retained in the Parameter object when the name is fake.
> 
> The original report recommends using a pool to store the arg name strings. I did not take that approach as I don't think it is very necessary; if the issue of retained fake names persist, we can update `Parameter::getName` to return fake names from a pool instead.

Chen Liang 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' of https://github.com/openjdk/jdk into fix/fake-param-name
 - 8357728: Optimize Executable#synthesizeAllParams

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25961/files
  - new: https://git.openjdk.org/jdk/pull/25961/files/a5a5dba4..a79e59cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25961&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25961&range=00-01

  Stats: 607435 lines in 7235 files changed: 409421 ins; 125072 del; 72942 mod
  Patch: https://git.openjdk.org/jdk/pull/25961.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25961/head:pull/25961

PR: https://git.openjdk.org/jdk/pull/25961

From sherman at openjdk.org  Fri Nov 14 23:55:04 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 14 Nov 2025 23:55:04 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v9]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <VHvfY9FbsQUUvsY6Nq3Z2OTNf7rJul20xf13Z8mytm8=.d21d38df-ea2a-4b9a-bcb6-d70aca8140cb@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 with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - update string class doc
 - Merge remote-tracking branch 'upstream/master' into JDK-8365675
   sync with master
 - update with new test cases
 - update to use value long for folding
 - small update
 - update
 - test case update
 - performance update
 - minor api doc updates
 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8365675
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7aff8e15...057ea814

-------------

Changes: https://git.openjdk.org/jdk/pull/27628/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=08
  Stats: 1448 lines in 13 files changed: 1236 ins; 207 del; 5 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  Fri Nov 14 23:57:11 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 14 Nov 2025 23:57:11 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: <NPPeE5V5So2nS47cMyWWG8k3RI_L2-ew_DmbiHBkBnM=.854c1ae0-7e76-4e9d-8f70-4c1181f183a2@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <AHtBR8KtQsMG9sup-cEEPY07xRW8aLMkooVJeWWV5sY=.adf6db85-cb73-4e38-a8b4-abc0d3108052@github.com>
 <NPPeE5V5So2nS47cMyWWG8k3RI_L2-ew_DmbiHBkBnM=.854c1ae0-7e76-4e9d-8f70-4c1181f183a2@github.com>
Message-ID: <GlKikk03dv0ybpzNrzCoFJ1rz6WXHJmvZgjSPV__EmY=.d9b51644-2206-4af7-9f1c-20c2a1758f6d@github.com>

On Fri, 7 Nov 2025 22:19:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to use value long for folding
>
> test/jdk/java/lang/String/UnicodeCaseFoldingTest.java line 31:
> 
>> 29:  * @compile --add-exports java.base/jdk.internal.lang=ALL-UNNAMED
>> 30:  * UnicodeCaseFoldingTest.java
>> 31:  * @run junit/othervm --add-exports java.base/jdk.internal.lang=ALL-UNNAMED
> 
> The @module directive can replace the explicit --add-exports and the explicit @compile may be unnecessary.
> 
> * @modules java.base/jdk.internal.lang:+open

updated as suggested

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2529280093

From liach at openjdk.org  Sat Nov 15 00:06:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 15 Nov 2025 00:06:13 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v8]
In-Reply-To: <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
Message-ID: <26o6kR-Vmb8AQ5Yk41KYvoaucWZsJbW2hKToVlzxYB0=.eb764ade-283b-4951-a7b9-c3a4cd8ee314@github.com>

On Thu, 13 Nov 2025 06:46:51 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix StreamOpFlagsTest

I don't know about the particular case about TreeSet, but I think with the advent of Comparator.naturalOrder in Java 8, people are much more likely to use it instead of null to represent the natural order, especially for Comparator-returning methods or Comparator fields. Offering such a conversion within the implementation, in my opinion, is better than checking and converting at every single use site that has a Comparator.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3535108496

From almatvee at openjdk.org  Sat Nov 15 00:31:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 15 Nov 2025 00:31:05 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <VQX3Vc7JqCZZFhIZ5zVzsI0JNq7XQ_Td77QLxRfOAeQ=.ab2009bc-c592-462e-a357-073d03a360e8@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
 <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
 <VQX3Vc7JqCZZFhIZ5zVzsI0JNq7XQ_Td77QLxRfOAeQ=.ab2009bc-c592-462e-a357-073d03a360e8@github.com>
Message-ID: <8pakCZstBnjUTFUbdCeiBXTgf439dkmzwyYlR5XQEfw=.6de03c31-9b5c-41a0-88cc-215b54fc4fe3@github.com>

On Fri, 14 Nov 2025 18:54:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardValidator.java line 48:
>> 
>>> 46:     static final Predicate<Path> IS_DIRECTORY = Files::isDirectory;
>>> 47: 
>>> 48:     static final Predicate<Path> IS_EXISTENT_NOT_DIRECTORY = path -> {
>> 
>> `IS_EXISTENT_NOT_DIRECTORY` will be same as `IS_REGULAR_FILE`? And just do `return Files. isRegularFile(path)`.
>
> `IS_EXISTENT_NOT_DIRECTORY` means it can be a regular file or a symlink.

In this case should it be something like below? Sounds more clear to me.

``` 
static final Predicate<Path> IS_FILE_OR_SYMLINK = path -> {
        return Files.isRegularFile(path) || Files.isSymbolicLink(path);
};

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2529319956

From asemenyuk at openjdk.org  Sat Nov 15 00:52:11 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 15 Nov 2025 00:52:11 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <8pakCZstBnjUTFUbdCeiBXTgf439dkmzwyYlR5XQEfw=.6de03c31-9b5c-41a0-88cc-215b54fc4fe3@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
 <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
 <VQX3Vc7JqCZZFhIZ5zVzsI0JNq7XQ_Td77QLxRfOAeQ=.ab2009bc-c592-462e-a357-073d03a360e8@github.com>
 <8pakCZstBnjUTFUbdCeiBXTgf439dkmzwyYlR5XQEfw=.6de03c31-9b5c-41a0-88cc-215b54fc4fe3@github.com>
Message-ID: <LvYbuPT5FfgS1CLnSNyGYmpunM5MgbqIDglgGtGxjiQ=.abb5f98c-6ded-42da-a0ad-372b7c448c8e@github.com>

On Sat, 15 Nov 2025 00:28:13 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> `IS_EXISTENT_NOT_DIRECTORY` means it can be a regular file or a symlink.
>
> In this case should it be something like below? Sounds more clear to me.
> 
> ``` 
> static final Predicate<Path> IS_FILE_OR_SYMLINK = path -> {
>         return Files.isRegularFile(path) || Files.isSymbolicLink(path);
> };

It isn't particularly clear to me, but I trust your fresh look. Will update you as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2529338660

From bpb at openjdk.org  Sat Nov 15 01:20:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 15 Nov 2025 01:20:10 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v6]
In-Reply-To: <LvYbuPT5FfgS1CLnSNyGYmpunM5MgbqIDglgGtGxjiQ=.abb5f98c-6ded-42da-a0ad-372b7c448c8e@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <N0hwBvZl57nOshfrSV_oGScEsdGKAzCxE7qt0AT4ZNo=.90078a55-34da-4f8c-9ff1-af4e34b338b9@github.com>
 <lsFsye-L5goACoEJ9-oqJ0Te6DN0e4Z9FEAKqyLbdHw=.08504275-ae59-46c0-8a77-cc09bb4c606d@github.com>
 <VQX3Vc7JqCZZFhIZ5zVzsI0JNq7XQ_Td77QLxRfOAeQ=.ab2009bc-c592-462e-a357-073d03a360e8@github.com>
 <8pakCZstBnjUTFUbdCeiBXTgf439dkmzwyYlR5XQEfw=.6de03c31-9b5c-41a0-88cc-215b54fc4fe3@github.com>
 <LvYbuPT5FfgS1CLnSNyGYmpunM5MgbqIDglgGtGxjiQ=.abb5f98c-6ded-42da-a0ad-372b7c448c8e@github.com>
Message-ID: <xk1babv0lduzYu8ci_eUDwpv1u51pyG4u53WEDfyGRU=.20915e28-59e3-4199-b724-9bad89472008@github.com>

On Sat, 15 Nov 2025 00:48:54 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> In this case should it be something like below? Sounds more clear to me.
>> 
>> ``` 
>> static final Predicate<Path> IS_FILE_OR_SYMLINK = path -> {
>>         return Files.isRegularFile(path) || Files.isSymbolicLink(path);
>> };
>
> It isn't particularly clear to me, but I trust your fresh look. Will update you as suggested.

Not my area here, but `IS_FILE_OR_SYMLINK` sounds good to me (as a NIO maintainer).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28163#discussion_r2529360710

From sherman at openjdk.org  Sat Nov 15 01:22:12 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 15 Nov 2025 01:22:12 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: <NPPeE5V5So2nS47cMyWWG8k3RI_L2-ew_DmbiHBkBnM=.854c1ae0-7e76-4e9d-8f70-4c1181f183a2@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <AHtBR8KtQsMG9sup-cEEPY07xRW8aLMkooVJeWWV5sY=.adf6db85-cb73-4e38-a8b4-abc0d3108052@github.com>
 <NPPeE5V5So2nS47cMyWWG8k3RI_L2-ew_DmbiHBkBnM=.854c1ae0-7e76-4e9d-8f70-4c1181f183a2@github.com>
Message-ID: <9jpJ-i9OwkJeyIcrnzm5wk9Pic_ObsGw-S-xcEI7vpA=.0aab5db7-b801-473c-90f7-a8c6bd92364c@github.com>

On Fri, 7 Nov 2025 21:40:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to use value long for folding
>
> src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 136:
> 
>> 134:     *
>> 135:     * <p>
>> 136:     * @spec https://www.unicode.org/reports/tr18/#Simple_Loose_Matches
> 
> I'd put @spec after @return.

updated according

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2529363242

From duke at openjdk.org  Sat Nov 15 02:08:01 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Sat, 15 Nov 2025 02:08:01 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v8]
In-Reply-To: <26o6kR-Vmb8AQ5Yk41KYvoaucWZsJbW2hKToVlzxYB0=.eb764ade-283b-4951-a7b9-c3a4cd8ee314@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
 <26o6kR-Vmb8AQ5Yk41KYvoaucWZsJbW2hKToVlzxYB0=.eb764ade-283b-4951-a7b9-c3a4cd8ee314@github.com>
Message-ID: <rFMiMLQyeyN1B-R-ozWjBw_DwCjs4duYP8YtSZnHnH8=.32860cb2-7082-46e8-8cd5-c337664271b5@github.com>

On Sat, 15 Nov 2025 00:03:40 GMT, Chen Liang <liach at openjdk.org> wrote:

> I don't know about the particular case about TreeSet, but I think with the advent of Comparator.naturalOrder in Java 8, people are much more likely to use it instead of null to represent the natural order, especially for Comparator-returning methods or Comparator fields. Offering such a conversion within the implementation, in my opinion, is better than checking and converting at every single use site that has a Comparator.

I agree with that, I think it seems better to *not* use null to signal natural order. But even if we did that here, the stream classes like `SortedOps` still need to handle null or `Comparator.naturalOrder()`, since the null signaling natural order is part of the contract of SortedSet, Spliterator, etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3535399552

From liach at openjdk.org  Sat Nov 15 03:26:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 15 Nov 2025 03:26:09 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v6]
In-Reply-To: <WQNH5jxn2wUEn37ThX-qapBbaqPItwdMXC_1ku5zw9o=.74cadb4f-1904-4765-895d-09bc0c9b8483@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <WQNH5jxn2wUEn37ThX-qapBbaqPItwdMXC_1ku5zw9o=.74cadb4f-1904-4765-895d-09bc0c9b8483@github.com>
Message-ID: <yMj0na0sDjbPeZy_HfAk6A4WeQJ09eeA_nNQmOYGdyU=.2774bf68-1601-41da-aacc-bd87ba3106cc@github.com>

On Fri, 14 Nov 2025 22:28:24 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
>> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
>> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach
>
> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rework

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 402:

> 400:     @ForceInline
> 401:     void checkSliceBounds(long offset, long length) {
> 402:         Preconditions.checkFromIndexSize(offset, length, this.length, this::sliceOutOfBoundException);

Is this performance-wise neutral? This is on a hot path and captures a lambda every time, need to verify compiler can eliminate this, which I doubt.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2529500502

From syan at openjdk.org  Sat Nov 15 04:09:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 15 Nov 2025 04:09:01 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <hkbUvD3G8QD-16jDxz6WF4glYdJioe21VMFm_3FWlSQ=.979554d6-1616-404f-9d20-7dfe7e733d24@github.com>

On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

Looking for 2rd reviewer, since this PR touch files in hotspot directory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3535663799

From jpai at openjdk.org  Sat Nov 15 04:53:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Nov 2025 04:53:04 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java
In-Reply-To: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
Message-ID: <cHe2LqzcuTeUVcnGGmhj6ybd-otgHPLi_DG0g127BLc=.186cd2bd-1a87-4cc5-866b-3a251baa4c46@github.com>

On Thu, 13 Nov 2025 02:31:31 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> In JDK 11, ThreadPoolExecutor.finalize() was specified to do nothing, leaving the finalize() method empty by [JDK-8371748](https://bugs.openjdk.org/browse/JDK-8371748), so I think it's safety to remove finalize() in testFinalizeMethodCallsSuperFinalize for test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java.
> 
> This PR also remove unnecessary '@SuppressWarnings("removal")' in test/jdk/java/util/concurrent/tck/JSR166TestCase.java and test/jdk/java/util/concurrent/tck/ExecutorsTest.java.
> 
> Change has been verified locally on linux-x64 by run test java/util/concurrent/tck/JSR166TestCase.java#default. Test-fix only, no risk,

The changes look good to me but I think Hannes' question is valid.

> > What does `testFinalizeMethodCallsSuperFinalize` test now?
> 
> I have verified java/util/concurrent/tck/JSR166TestCase.java#default locally, test still run passed. Test java/util/concurrent/tck/JSR166TestCase.java#default will invoke all the junit tests in java/util/concurrent/tck directory.

Is the testFinalizeMethodCallsSuperFinalize() needed or can it be removed? With the changes in this PR, I don't see what this method tests, especially given its name. It's a different matter that even without the changes to this PR, I am not sure what was being tested/asserted in that test method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28278#issuecomment-3535949036

From alanb at openjdk.org  Sat Nov 15 07:25:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Nov 2025 07:25:07 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <6hHUTYN71vmfPtE9gricMXDS3d3Two16__qJax7gY7M=.db4c76c6-255d-408b-b69d-7e37b9be22b3@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
 <pUC2CsOOeN2fmLlHuqNHcTO5fZYPLIDwAmZRJEGd2ZY=.3e0a1615-873f-41b2-bd9a-807d8e80a364@github.com>
 <6hHUTYN71vmfPtE9gricMXDS3d3Two16__qJax7gY7M=.db4c76c6-255d-408b-b69d-7e37b9be22b3@github.com>
Message-ID: <GxdAfZjP1AyrPeTMY5Rlk8hsh6RpkJKMF9rOmdYZKZs=.fabf195d-e178-4b9b-9d2d-699f4a8c1201@github.com>

On Fri, 14 Nov 2025 19:35:11 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Indeed. My understanding is that that is being handled by [JDK-8371682](https://bugs.openjdk.org/browse/JDK-8371682).

It might make more sense for this PR to remove testFinalizeMethodCallsSuperFinalize as it's part of the removal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3536146427

From alanb at openjdk.org  Sat Nov 15 08:19:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Nov 2025 08:19:20 GMT
Subject: Integrated: 8371226: Thread class description needs section on Thread
 Interruption
In-Reply-To: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
References: <fbEi6mzAfXxMWf_4p84bFPfrWgVXbkhIsaKA_6X7giY=.bd607f1c-bb3d-469f-9bc0-b94997d79753@github.com>
Message-ID: <SZcFBTyoK--QCYud3jCevgeDce5F80Zno5qdUMywil4=.7f18cf46-a0a9-4d71-a992-74fd7e63431a@github.com>

On Mon, 10 Nov 2025 14:37:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is docs only change to a add a new section to the Thread class description on Thread Interruption.  The new section provides guidance on handling InterruptedException. A subset of that guidance is also proposed for the InterruptedException class description.

This pull request has now been integrated.

Changeset: f6c90fe8
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6c90fe8f9986b02797ba1f967c71a592a892266
Stats:     84 lines in 2 files changed: 57 ins; 5 del; 22 mod

8371226: Thread class description needs section on Thread Interruption

Reviewed-by: prappo, vklang, liach, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/28216

From liach at openjdk.org  Sat Nov 15 08:59:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 15 Nov 2025 08:59:19 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v12]
In-Reply-To: <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
Message-ID: <Z6J31ksDj2H9Dicr0uemdgm1hToatESuJWmI3g_fb-Y=.9de2e579-6988-44d6-8589-da9354ea94e1@github.com>

On Fri, 14 Nov 2025 12:05:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Cleanup
>  - More cleanup of Field.set API docs, including some restructure from Alex
>  - Cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Update mutateFinals/modules test to exercise exports and opens cases
>  - Update Field.set spec to better align with setAccessible for public final field in public class in exported package
>  - Fix typo in java man page
>  - Add method to test if package exported
>  - Remove dup end body tag
>  - ... and 49 more: https://git.openjdk.org/jdk/compare/9eaa364a...7693e8fa

src/java.base/share/classes/java/lang/Module.java line 1032:

> 1030:      * Updates this module to export a package to another module.
> 1031:      *
> 1032:      * @apiNote Used addExports, Instrumentation::redefineModule, and --add-exports

Suggestion:

     * @apiNote Used by addExports, Instrumentation::redefineModule, and --add-exports

src/java.base/share/classes/java/lang/reflect/Field.java line 1621:

> 1619:     private String notAccessibleToCallerMessage(Class<?> caller, boolean unreflect) {
> 1620:         String exportOrOpen = Modifier.isPublic(modifiers)
> 1621:                 && Modifier.isPublic(clazz.getModifiers()) ? "exports" : "open";

Suggestion:

                && Modifier.isPublic(clazz.getModifiers()) ? "export" : "open";

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2529101056
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2529099290

From alanb at openjdk.org  Sat Nov 15 08:59:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Nov 2025 08:59:20 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v12]
In-Reply-To: <Z6J31ksDj2H9Dicr0uemdgm1hToatESuJWmI3g_fb-Y=.9de2e579-6988-44d6-8589-da9354ea94e1@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
 <Z6J31ksDj2H9Dicr0uemdgm1hToatESuJWmI3g_fb-Y=.9de2e579-6988-44d6-8589-da9354ea94e1@github.com>
Message-ID: <nfULlQYdzCqlUugtO2GhIBPk55nK2TiEL1pbeD6bzDs=.e4e02797-caa7-45e3-a9d5-03ae73dfdbc9@github.com>

On Fri, 14 Nov 2025 22:05:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:
>> 
>>  - Merge branch 'master' into JDK-8353835
>>  - Cleanup
>>  - More cleanup of Field.set API docs, including some restructure from Alex
>>  - Cleanup
>>  - Merge branch 'master' into JDK-8353835
>>  - Update mutateFinals/modules test to exercise exports and opens cases
>>  - Update Field.set spec to better align with setAccessible for public final field in public class in exported package
>>  - Fix typo in java man page
>>  - Add method to test if package exported
>>  - Remove dup end body tag
>>  - ... and 49 more: https://git.openjdk.org/jdk/compare/9eaa364a...7693e8fa
>
> src/java.base/share/classes/java/lang/reflect/Field.java line 1621:
> 
>> 1619:     private String notAccessibleToCallerMessage(Class<?> caller, boolean unreflect) {
>> 1620:         String exportOrOpen = Modifier.isPublic(modifiers)
>> 1621:                 && Modifier.isPublic(clazz.getModifiers()) ? "exports" : "open";
> 
> Suggestion:
> 
>                 && Modifier.isPublic(clazz.getModifiers()) ? "export" : "open";

With InaccessibleObjectException we put the (contextual) keyword in double quotes so that the exception message has `"exports" $P` or `"opens" $P`, and hopefully guide the developer to the module declaration. For this IllegalAccessException case then it should probably be the same so that the message has `"exports" $P to module $M`, in which case it should be "opens" rather than "open".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2529713811

From kbarrett at openjdk.org  Sat Nov 15 09:13:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 15 Nov 2025 09:13:02 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v2]
In-Reply-To: <O8UY1Avn7TB6KX_wIZOL6vQ4meS2BhQKWq-gSWEBpV4=.da66c1fb-a8bb-4170-b400-925ae8c929ea@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <pdqJnN9xntFDARyhDsUYVIZ9jIw_iNelprYPvuWZDvk=.1b32788d-1601-4039-83e5-645cafe4920a@github.com>
 <raGWDYJJ4f-LNkUZUR9Xro6k_qpiqJSmHGRdloYjU6o=.11b96d2b-aefc-4d19-a81a-caa3596202f2@github.com>
 <GCkEtnccjjGHrGFDnlB3t0iums36AVXlET0MUkWJuCc=.7a8424d4-4b25-4236-a6b1-729a6c58cee4@github.com>
 <kDWVCOPeXUFu_GbuOtP6qDoD52TpsY0_uN94PhUDrzs=.88933b41-77e1-4645-9a0a-7f70e4bffc9e@github.com>
 <O8UY1Avn7TB6KX_wIZOL6vQ4meS2BhQKWq-gSWEBpV4=.da66c1fb-a8bb-4170-b400-925ae8c929ea@github.com>
Message-ID: <HDFCmMxhTYMILT21ljN_4wit4CN3ydyaS0EhP9NKxpM=.803d4d2b-c532-47ba-b55b-f3f543b6b59a@github.com>

On Fri, 14 Nov 2025 14:45:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > For what it's worth, I think the described behavior is non-conforming to the C standards before C23
> 
> The standard was ambiguous prior to that and https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm is a good read on that topic.

Thanks for the reference to that paper; that's part of what I was looking for.
Having read it carefully, I have a number of points of disagreement with it.
But that doesn't matter, because, as Harald Eilertsen said

> it's nevertheless the behaviour of the allocator used by libc on FreeBSD.

So we have to cope with that behavior.

One thing I found surprising in n2293 is that Windows CRT is classified as a
weak-alignment environment. So why haven't we previously run into this same
problem on Windows? Is that categorization mistaken? Or perhaps we *have* run
into this, and there is some Windows-specific workaround lurking somewhere? In
which case perhaps that is no longer needed if we're going to allow for
weak-alignment allocators.

If Windows is a weak-alignment environment, that would also suggest we don't
have a dependency on strong-alignment in HotSpot, else we'd expect to have run
into problems there too. That would be good, because I was really not looking
forward to searching for such dependencies.

So can anyone verify the Windows categorization? I don't have easy access.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3536234030

From forax at openjdk.org  Sat Nov 15 09:31:14 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 15 Nov 2025 09:31:14 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v2]
In-Reply-To: <cStkQ8SJOSKc9kn-M5BtOxJchYsS_I9_4amAZ0FqDog=.12f916d9-ba66-4aaa-a1b9-5cf3de2c39a5@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <NWxQlK3_BVl6Fy5YCSa2S5u4SAzVEWNi73iS_D3OuhU=.1a6c85eb-533e-4bad-8984-b313f0f26717@github.com>
 <p4lQ-B2UBHgzBLSQY3GQf1bCCRB01DWkIN_jLRiSwXY=.f890f186-7618-4bcb-89b4-997fa4a8edbd@github.com>
 <hMA3EPOMFlD4JKHktdABoBOXDQPkz5Wakx86l2fkovM=.7139475b-2219-4ec4-945b-5682d5de4236@github.com>
 <cStkQ8SJOSKc9kn-M5BtOxJchYsS_I9_4amAZ0FqDog=.12f916d9-ba66-4aaa-a1b9-5cf3de2c39a5@github.com>
Message-ID: <-D1HJgu54RwfgUo-uQuTIxfyRuaCukduRv1vF-HQjlg=.8079901e-5751-488b-b018-5206f94a87a6@github.com>

On Tue, 11 Nov 2025 17:46:11 GMT, R?mi Forax <forax at openjdk.org> wrote:

>>> I wonder if it's not better to replace Comparator.naturalOrder() by null in the constructor of TreeSet, given that TreeSet does not provide a getter for it so the only way to get the comparator is using treeSet.spliterator().getComparator().
>> 
>> That wouldn't help with the `stream().sorted(Comparator.naturalOrder())` case; the example I supplied is somewhat contrived, I originally ran into this in Guava (see the [issue](https://github.com/google/guava/issues/6187) I opened there); the library is null-hostile and so always supplies a comparator to its sorted collections. Note that this won't directly fix the issue there until they move away from their custom natural order comparator to the one from the JDK.
>
>> That wouldn't help with the `stream().sorted(Comparator.naturalOrder())` case; the example I supplied is somewhat contrived, I originally ran into this in Guava (see the [issue](https://github.com/google/guava/issues/6187) I opened there); the library is null-hostile and so always supplies a comparator to its sorted collections. 
> 
> If you switch from Comparator.naturalOrder()) to null, you have to do it in stream.sorted() too (and also List.sort(Comparator), Collections.sort(Comparator), Array.sort(Comparator), Collections.reverseOrder(Comparator) etc)
> 
>> Note that this won't directly fix the issue there until they move away from their custom natural order comparator to the one from the JDK.
> 
> yes, comparing comparators with == is brittle anyway, but at least you can make it consistent for the JDK.

> @forax
> 
> > I wonder if it's not better to replace Comparator.naturalOrder() by null in the constructor of TreeSet, given that TreeSet does not provide a getter for it so the only way to get the comparator is using treeSet.spliterator().getComparator().
> 
> TreeSet does have a "getter" named `comparator()`. It's defined by SortedSet. Not sure this affects where the discussion is at the moment though.

ah, thanks Stuart,
so changing the Comparator at use site is definitively not a good idea :(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3536249353

From ch3cho at qq.com  Sat Nov 15 13:17:50 2025
From: ch3cho at qq.com (=?utf-8?B?S2VudCBEb25n?=)
Date: Sat, 15 Nov 2025 21:17:50 +0800
Subject: JDK-8370887 DelayScheduler Bug Discussion
Message-ID: <tencent_76B154EE69499B65C7B94D90F15245542606@qq.com>

Hi guys,


During our trial of Java 25, we found this bug JDK-8370887&nbsp;DelayScheduler.replace&nbsp;method may break the 4-ary heap in certain scenarios. Since NIO uses virtual threads for poller by default in Linux, it may affect the timeout of IO operations. If it can be fix, we would be more confident to use Java 25 and VT in our production environment.


After a full analysis, we found it is caused by a missing sift-up branch in DelayScheduler.replace&nbsp;method, and it's not quite hard to fix. And it stays silent in JBS for quite a while. Is there a schedule/plan for it to be fixed or maybe we can contribute a fix to it?


Thanks.


Kent Dong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251115/e62f7a89/attachment-0001.htm>

From duke at openjdk.org  Sat Nov 15 13:39:18 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Sat, 15 Nov 2025 13:39:18 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v7]
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <9610ib3tLj_3IiiEMUwnAkeu58Na8f2rg7UGoSCX0vQ=.7710bda1-9897-4c7f-b3ec-90403b8389f1@github.com>

> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach

Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:

  rework: eliminate lambda binding; introduce lightweight wrapper which should be eliminated by escape analysis

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28124/files
  - new: https://git.openjdk.org/jdk/pull/28124/files/b96a0152..9a2cc138

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=05-06

  Stats: 68 lines in 1 file changed: 41 ins; 24 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28124/head:pull/28124

PR: https://git.openjdk.org/jdk/pull/28124

From swen at openjdk.org  Sat Nov 15 14:45:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 15 Nov 2025 14:45:48 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v25]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <rVuZKbQQxPiMh8z38HtlAu-jz4ZMnePr_jdnffmWEko=.baa3b7df-f5b8-4acd-858c-7f91f3986ca2@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove DecimalDigitsTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/0070e7b3..50602632

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=23-24

  Stats: 95 lines in 1 file changed: 0 ins; 95 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

PR: https://git.openjdk.org/jdk/pull/26911

From viktor.klang at oracle.com  Sat Nov 15 16:56:56 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Sat, 15 Nov 2025 17:56:56 +0100
Subject: JDK-8370887 DelayScheduler Bug Discussion
In-Reply-To: <tencent_76B154EE69499B65C7B94D90F15245542606@qq.com>
References: <tencent_76B154EE69499B65C7B94D90F15245542606@qq.com>
Message-ID: <b8d535ce-aaca-4a8a-934a-9a49dd61105a@oracle.com>

Hi Kent,

Thanks for reporting, it has previously been reported and is tracked 
here: https://bugs.openjdk.org/browse/JDK-8370887

On 2025-11-15 14:17, Kent Dong wrote:
> Hi guys,
>
> During our trial of Java 25, we found this bug JDK-8370887 
> <https://bugs.openjdk.org/browse/JDK-8370887> DelayScheduler.replace 
> <https://delayscheduler.replace/>?method may break the 4-ary heap in 
> certain scenarios. Since NIO uses virtual threads for poller by 
> default in Linux, it may affect the timeout of IO operations. If it 
> can be fix, we would be more confident to use Java 25 and VT in our 
> production environment.
>
> After a full analysis, we found it is caused by a missing sift-up 
> branch in DelayScheduler.replace?method, and it's not quite hard to 
> fix. And it stays silent in JBS for quite a while. Is there a 
> schedule/plan for it to be fixed or maybe we can contribute a fix to it?
>
> Thanks.
>
> Kent Dong
>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251115/e330cba3/attachment-0001.htm>

From alan.bateman at oracle.com  Sat Nov 15 18:47:23 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Nov 2025 18:47:23 +0000
Subject: JDK-8370887 DelayScheduler Bug Discussion
In-Reply-To: <b8d535ce-aaca-4a8a-934a-9a49dd61105a@oracle.com>
References: <tencent_76B154EE69499B65C7B94D90F15245542606@qq.com>
 <b8d535ce-aaca-4a8a-934a-9a49dd61105a@oracle.com>
Message-ID: <0292b0fa-3311-4162-b033-90b809421cc8@oracle.com>



On 15/11/2025 16:56, Viktor Klang wrote:
>
> Hi Kent,
>
> Thanks for reporting, it has previously been reported and is tracked 
> here: https://bugs.openjdk.org/browse/JDK-8370887
>
>
Just to add to Viktor's link, there is an initial patch from Doug Lea 
that we are currently testing. So PR yet, but hopefully soon.

-Alan

From jvernee at openjdk.org  Sat Nov 15 18:57:12 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 15 Nov 2025 18:57:12 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v3]
In-Reply-To: <MqO3_Inf57nyfJtl0bEqKL1U0gtA-je3hfg6pxBz-Z8=.9631e5e3-7029-4311-947c-e105f34d8fdc@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <MqO3_Inf57nyfJtl0bEqKL1U0gtA-je3hfg6pxBz-Z8=.9631e5e3-7029-4311-947c-e105f34d8fdc@github.com>
Message-ID: <1IMETskhMt07HUa-VBc1q_F2NhqgM5k1iSkmpTKb9cY=.8744bc17-9905-49f1-89e3-829db6edcb6b@github.com>

On Fri, 14 Nov 2025 13:13:00 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   OS agnostic fix for alignment of native segments
>   
>   Only align up the requested memory if the requested alignment is larget
>   than max alignment provided by malloc, or if the requested size is not a
>   multiple of the alignment size.
>   
>   This work was sponsored by: The FreeBSD Foundation
>   
>   Co-authored-by: mcimadamore

src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 207:

> 205:         long result;
> 206:         if (byteAlignment > MAX_MALLOC_ALIGN || alignedSize % byteAlignment != 0) {
> 207:             allocationSize = alignedSize + byteAlignment - MAX_MALLOC_ALIGN;

The calculation of `allocationSize` looks no longer correct now that `byteAlignment` might be smaller than `MAX_MALLOC_ALIGN`, and it can result in a negative size.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2530070997

From dlsmith at openjdk.org  Sat Nov 15 21:10:11 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Sat, 15 Nov 2025 21:10:11 GMT
Subject: RFR: 8371732: [redo] Change java.time month/day field types to
 'byte' [v2]
In-Reply-To: <ax8qXZEhKiwzmZVIi4eElP0EK5uhGzGkpbB-O0_c3D8=.4df11800-cd6f-412d-b098-912e649d1cde@github.com>
References: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
 <ax8qXZEhKiwzmZVIi4eElP0EK5uhGzGkpbB-O0_c3D8=.4df11800-cd6f-412d-b098-912e649d1cde@github.com>
Message-ID: <5-X1rXJ3ZB44_ZizoHoT4k9JT5DaccXidcLCW344J_U=.b8a873c4-4bd6-47b2-906b-28a321b671b2@github.com>

On Fri, 14 Nov 2025 20:15:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Redo change (8371732) that failed when the updated class objects were incompatible.
>> The fields of classes are changed to allow a more compact form of storage.
>> 
>> To ensure compatibility of the class objects, the fields are explicitly declared in SerialPersistentFields with the original field types.
>> The fields are marked `transient` to indicate the field declarations are not used for serialization.
>> The affected classes are java.time.LocalDate, MonthDay, and YearMonth.
>> Tests are added to verify the types and names of serialized fields of each class.
>> 
>> HijrahDate only changes the field types, the fields are transient and there is no change to the serialized from of the HijrahDate.class object.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "Java SE 8" instead of version 1.8

Glad to see the fields back to being bytes.

FWIW, the `transient` is redundant: `serialPersistentFields` _explicitly_ declares the serializable fields (i.e., a set of name/type pairs); all that the `transient` does is aid in figuring out the _implicit_ serializable fields if there is no explicit declaration.

(Just to confirm, I tested that if I add `transient` to a field that is also listed in `serialPersistentFields`, serialization will read and write that field anyway.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28274#issuecomment-3536891063

From dlsmith at openjdk.org  Sat Nov 15 21:19:09 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Sat, 15 Nov 2025 21:19:09 GMT
Subject: RFR: 8371732: [redo] Change java.time month/day field types to
 'byte' [v2]
In-Reply-To: <ax8qXZEhKiwzmZVIi4eElP0EK5uhGzGkpbB-O0_c3D8=.4df11800-cd6f-412d-b098-912e649d1cde@github.com>
References: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
 <ax8qXZEhKiwzmZVIi4eElP0EK5uhGzGkpbB-O0_c3D8=.4df11800-cd6f-412d-b098-912e649d1cde@github.com>
Message-ID: <LRQfo8HvlVHSvYDB0gJ4ZMq8MElvfcQFvzs_um1TH1Y=.c8cdb4c0-3bdd-4109-a5c4-4d7549de79b4@github.com>

On Fri, 14 Nov 2025 20:15:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Redo change (8371732) that failed when the updated class objects were incompatible.
>> The fields of classes are changed to allow a more compact form of storage.
>> 
>> To ensure compatibility of the class objects, the fields are explicitly declared in SerialPersistentFields with the original field types.
>> The fields are marked `transient` to indicate the field declarations are not used for serialization.
>> The affected classes are java.time.LocalDate, MonthDay, and YearMonth.
>> Tests are added to verify the types and names of serialized fields of each class.
>> 
>> HijrahDate only changes the field types, the fields are transient and there is no change to the serialized from of the HijrahDate.class object.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "Java SE 8" instead of version 1.8

And then HijrahDate is weird, because it doesn't seem to declare `serialPersistentFields`? That's also fine, because the use of `transient` means that the implicit serializable field declaration is an empty set. But it's a little confusing that there's not one uniform strategy used everywhere.

Suggested (low-priority) followup: for all of these classes that use a proxy and throw in `readObject`, either declare all the fields `transient`, or declare an empty `serialPersistentFields`. No need to do both, but should use the same strategy everywhere.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28274#issuecomment-3536902621

From liach at openjdk.org  Sat Nov 15 23:11:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 15 Nov 2025 23:11:41 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs
Message-ID: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>

A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.

In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.

-------------

Commit messages:
 - Redundant
 - Test and more fixes
 - Copyright years
 - Testing
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
 - Null behavior for core reflection

Changes: https://git.openjdk.org/jdk/pull/28336/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371953
  Stats: 529 lines in 18 files changed: 504 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/28336.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28336/head:pull/28336

PR: https://git.openjdk.org/jdk/pull/28336

From alanb at openjdk.org  Sun Nov 16 08:48:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Nov 2025 08:48:08 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs
In-Reply-To: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
Message-ID: <k3dikddABdh7ZedN6N9WjNAUAHz8hH0JnehkEnHTqrI=.e8def0c4-6229-462d-bdec-2d0b868f0eae@github.com>

On Sat, 15 Nov 2025 23:04:53 GMT, Chen Liang <liach at openjdk.org> wrote:

> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
> 
> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.

src/java.base/share/classes/java/lang/Class.java line 2148:

> 2146:      *
> 2147:      * @param name the name of the method
> 2148:      * @param parameterTypes the list of parameters, may be or contain {@code null}

The method description already specifies that if parameterTypes is null then it works like an empty array, so "may be null" is okay here.

getMethod, getConstructor, ... throw NoSuchMethodException is the parameterTypes has a null element. Maybe it would be better to expand the description for `@throws NoSuchMethodException`? That would avoid suggesting in the parameter description that a null element is allowed.

src/java.base/share/classes/java/lang/Class.java line 3839:

> 3837:      */
> 3838:     public boolean isNestmateOf(Class<?> c) {
> 3839:         Objects.requireNonNull(c);

So the behavior change here is calling isNestmateOf(null) on a class object for a primitive or array class will throw NPE when it didn't throw it previously.  Technically an incompatible change but I agree it's in the weeds when it comes to impact.

test/jdk/java/lang/Class/APIContractTest.java line 35:

> 33: import static org.junit.jupiter.api.Assertions.*;
> 34: 
> 35: class APIContractTest {

We have a lot of existing tests that exercise the "API contract" so I think the naming of most of the tests is in this PR is a bit misleading - maybe start out with NullTests or something that makes it clear from the names that these are tests that fire nulls at everything. If some of these tests expand purpose in the future then they can be renamed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2531754070
PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2531755438
PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2531707408

From pminborg at openjdk.org  Sun Nov 16 09:40:19 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Sun, 16 Nov 2025 09:40:19 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <_twwdOdK3jZMnAaDPFubJhbEbR_FEK99I4obbpttveU=.21e193fa-067e-4df1-8cff-4cd0fc704e4f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <_twwdOdK3jZMnAaDPFubJhbEbR_FEK99I4obbpttveU=.21e193fa-067e-4df1-8cff-4cd0fc704e4f@github.com>
Message-ID: <CQ7EtP0euKkv6mqVzXXTc40PyYxMwy_WPzuw9zf_K0A=.5abfa43c-df2f-4201-a196-7c533514bda8@github.com>

On Fri, 14 Nov 2025 09:45:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 280:
> 
>> 278:      * {@code computingFunction} at least until initialization completes successfully.
>> 279:      * <p>
>> 280:      * If the provided computing function is already an instance of
> 
> Not sure how I feel about that -- it seems to soft-break equals...

Let's think about this once more.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2531779955

From duke at openjdk.org  Sun Nov 16 14:50:39 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Sun, 16 Nov 2025 14:50:39 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v8]
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>

> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach

Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:

  Adjust to TestMergeStoresMemorySegment.java requirements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28124/files
  - new: https://git.openjdk.org/jdk/pull/28124/files/9a2cc138..df86a856

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=06-07

  Stats: 22 lines in 1 file changed: 14 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28124/head:pull/28124

PR: https://git.openjdk.org/jdk/pull/28124

From liach at openjdk.org  Sun Nov 16 15:45:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 16 Nov 2025 15:45:24 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v2]
In-Reply-To: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
Message-ID: <_HsqXtV1o3GBOX12-2eZMYVplxraX37xhWP6-fxbs7E=.420b43dc-59e2-49d5-b98d-888b8e8334d2@github.com>

> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
> 
> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.

Chen Liang has updated the pull request incrementally with three additional commits since the last revision:

 - Rephrase for parameterTypes contains null
 - Rename tests to be more specific
 - Split annotated type new checks to another patch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28336/files
  - new: https://git.openjdk.org/jdk/pull/28336/files/c42f70fb..a93a84ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=00-01

  Stats: 134 lines in 9 files changed: 4 ins; 103 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/28336.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28336/head:pull/28336

PR: https://git.openjdk.org/jdk/pull/28336

From liach at openjdk.org  Sun Nov 16 15:52:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 16 Nov 2025 15:52:02 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v2]
In-Reply-To: <_HsqXtV1o3GBOX12-2eZMYVplxraX37xhWP6-fxbs7E=.420b43dc-59e2-49d5-b98d-888b8e8334d2@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <_HsqXtV1o3GBOX12-2eZMYVplxraX37xhWP6-fxbs7E=.420b43dc-59e2-49d5-b98d-888b8e8334d2@github.com>
Message-ID: <HQiBwmDW4oBZpdTXVBDXrXpBpZxL_mUIp1zv9EFmTcc=.d28c70c5-5e38-4dbf-9af5-770e821cf422@github.com>

On Sun, 16 Nov 2025 15:45:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
>> 
>> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.
>
> Chen Liang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rephrase for parameterTypes contains null
>  - Rename tests to be more specific
>  - Split annotated type new checks to another patch

I updated the parameterTypes null element behavior for NoSuchMethodException, and made the test names more specific. In addition, I moved my discovered null check issues with AnnotatedType's AnnotatedElement methods to a separate patch, as that has no spec change and is purely behavioral.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28336#issuecomment-3538890734

From kurt at openjdk.org  Sun Nov 16 16:07:15 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Sun, 16 Nov 2025 16:07:15 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v3]
In-Reply-To: <MqO3_Inf57nyfJtl0bEqKL1U0gtA-je3hfg6pxBz-Z8=.9631e5e3-7029-4311-947c-e105f34d8fdc@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <MqO3_Inf57nyfJtl0bEqKL1U0gtA-je3hfg6pxBz-Z8=.9631e5e3-7029-4311-947c-e105f34d8fdc@github.com>
Message-ID: <xZcB2PEIhF7vpzQZDeFgx1KsB1W1fJlBPvjM_w_Cqtg=.b4b40a70-11be-47ef-a798-431fa03203d8@github.com>

On Fri, 14 Nov 2025 13:13:00 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   OS agnostic fix for alignment of native segments
>   
>   Only align up the requested memory if the requested alignment is larget
>   than max alignment provided by malloc, or if the requested size is not a
>   multiple of the alignment size.
>   
>   This work was sponsored by: The FreeBSD Foundation
>   
>   Co-authored-by: mcimadamore

There are now two cases where we need to adjust `allocationSize` to add support for the weak-alignment environment. The current case where `byteAlignment > MAX_MALLOC_ALIGN` and now when `byteAlignment <= MAX_MALLOC_ALIGN && alignedSize < byteAlignment`. The calculation of `allocationSize`  in the first case should stay the same. For the second case increasing `allocationSize` to match `byteAlignment` will guarantee the returned pointer will be aligned to  `byteAlignment` or greater.

Edited to fix typo.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3538900093

From liach at openjdk.org  Sun Nov 16 16:10:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 16 Nov 2025 16:10:21 GMT
Subject: RFR: 8371960: Missing null check in AnnotatedType annotation accessor
 methods
Message-ID: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>

`AnnotatedElement` methods specify they throw NPE if they take any null argument: `isAnnotationPresent`, `get(Declared)Annotation`, `get(Declared)AnnnotationsByType`. However, `AnnotatedType` has implementation quality issues that it does not throw NPE for `isAnnotationPresent` and `get(Declared)Annotation`.

This patch fixes this oversight by adding explicit null checks. For `get(Declared)AnnotationsByType`, even though it did throw exceptions, it was in the middle of parsing, so throwing it in the beginning is better.

-------------

Commit messages:
 - Null checks for AnnotatedType

Changes: https://git.openjdk.org/jdk/pull/28341/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28341&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371960
  Stats: 105 lines in 2 files changed: 103 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28341.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28341/head:pull/28341

PR: https://git.openjdk.org/jdk/pull/28341

From liach at openjdk.org  Sun Nov 16 16:17:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 16 Nov 2025 16:17:06 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v8]
In-Reply-To: <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>
Message-ID: <jVYhdY7hRdbMEVUTkbOx9QqqCz6XN2gV_3o-xiEOZh4=.baecbe8d-2fda-4f82-8be8-d88ebf6b2c86@github.com>

On Sun, 16 Nov 2025 14:50:39 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
>> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
>> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach
>
> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust to TestMergeStoresMemorySegment.java requirements

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 535:

> 533:         }
> 534: 
> 535:         abstract String format(AbstractMemorySegmentImpl segment, long offset, long size, long length);

Even though this does look better, but abstract method in enum means extra classes, which become some extra burden for startup. If you can write this method to have a body like:

String formatString = switch (this) {
    case SLICE -> ...
    case ACCESS -> ...
};
return formatString.formatted(segment, size, offset, length);

This would be less costly.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 540:

> 538:     private static final class BoundsCheckHandler implements BiFunction<String, List<Number>, IndexOutOfBoundsException> {
> 539:         final AbstractMemorySegmentImpl segment;
> 540:         final BoundPolicy policy;

I recommend turning this into a private record. In addition, we should add a comment that we anticipate this record instance creation to be eliminated by escape analysis when segment access is compiled. I wonder if you have run benchmarks to verify this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2532054398
PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2532055796

From alanb at openjdk.org  Sun Nov 16 17:17:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Nov 2025 17:17:05 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v2]
In-Reply-To: <_HsqXtV1o3GBOX12-2eZMYVplxraX37xhWP6-fxbs7E=.420b43dc-59e2-49d5-b98d-888b8e8334d2@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <_HsqXtV1o3GBOX12-2eZMYVplxraX37xhWP6-fxbs7E=.420b43dc-59e2-49d5-b98d-888b8e8334d2@github.com>
Message-ID: <78FynSSES1uEvkg12Q7YbCSu119MqQeNWc8F6kNKTlI=.27e91f98-21b4-47eb-a59c-1dbcbb26e76c@github.com>

On Sun, 16 Nov 2025 15:45:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
>> 
>> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.
>
> Chen Liang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rephrase for parameterTypes contains null
>  - Rename tests to be more specific
>  - Split annotated type new checks to another patch

src/java.base/share/classes/java/lang/Class.java line 2152:

> 2150:      *         {@code name} and {@code parameterTypes}
> 2151:      * @throws NoSuchMethodException if a matching method is not found, such as
> 2152:      *         when {@code parameterTypes} contains {@code null},

It might be clear to say "or parameterTypes contains a null element" rather than "such as when ..."

src/java.base/share/classes/java/lang/Class.java line 2192:

> 2190:      *         including when this {@code Class} object represents
> 2191:      *         an interface, a primitive type, an array class, or void, and
> 2192:      *         when {@code parameterTypes} contains {@code null}

Should this be "an array class, void, or parameterTypes contains null" ?

src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 101:

> 99:      *         java.lang.Class}
> 100:      * @throws NullPointerException if {@code array} or any of its elements is
> 101:      *         {@code null}

This method does a defensive copy of the array when flag is "true". This was important for the (now removed) security manager execution mode where a permission check was specified when suppressing access checks (flag==true). Now we have this odd scenario where a null element will provoke an eager NPE if flag is true, but if flag is false then it may throw NPE after maybe re-enabling access checks on some elements. What would you think about cloning the array unconditionally and avoid needing to specifying the strange behavior.

src/java.base/share/classes/java/lang/reflect/Array.java line 121:

> 119:      * @return the length of the array
> 120:      * @throws NullPointerException if {@code array} is {@code null}
> 121:      * @throws    IllegalArgumentException if the object argument is not

Minor nit, you probably should align the two exception messages the same way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2532089139
PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2532089731
PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2532088472
PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2532084127

From alanb at openjdk.org  Sun Nov 16 17:26:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Nov 2025 17:26:50 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v13]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <dbW07VkPhX6rVrXYfyFABHfOEg-K9CIqJhHbJRNo1EA=.12f84b43-0f5c-43e9-a976-33c893f7850b@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:

 - More wordsmithing
 - Improve IAE exception message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25115/files
  - new: https://git.openjdk.org/jdk/pull/25115/files/7693e8fa..e935c32e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=11-12

  Stats: 38 lines in 4 files changed: 18 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

PR: https://git.openjdk.org/jdk/pull/25115

From alanb at openjdk.org  Sun Nov 16 17:31:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Nov 2025 17:31:19 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <lT0-ac-y31gy5-Z38R1iRu5CWazTSSEDFdw96m3GM_w=.d9e43c30-f60d-4240-81c8-89d47243e5c8@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

Thanks for checking that cpu_isalist == NULL is okay, the update to java_props_md.c looks okay to me.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28317#pullrequestreview-3470333746

From alanb at openjdk.org  Sun Nov 16 17:45:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Nov 2025 17:45:01 GMT
Subject: RFR: 8371960: Missing null check in AnnotatedType annotation
 accessor methods
In-Reply-To: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
References: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
Message-ID: <tQtOJrIQ9HtNOCZPgBEgWgmEIpJBH7ktQ2YERzuWZKw=.2aac7f54-b0c1-4cfe-82eb-1dc767aa1101@github.com>

On Sun, 16 Nov 2025 16:02:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> `AnnotatedElement` methods specify they throw NPE if they take any null argument: `isAnnotationPresent`, `get(Declared)Annotation`, `get(Declared)AnnnotationsByType`. However, `AnnotatedType` has implementation quality issues that it does not throw NPE for `isAnnotationPresent` and `get(Declared)Annotation`.
> 
> This patch fixes this oversight by adding explicit null checks. For `get(Declared)AnnotationsByType`, even though it did throw exceptions, it was in the middle of parsing, so throwing it in the beginning is better.

I'm trying to judge the behavior/compatibility impact. Are there cases where NPE will be thrown for cases that is doesn't throw today? I get it that the parameter checking doesn't check it and instead the NPE comes from deep in the implementation, just want to understand if there is any impact of the change or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28341#issuecomment-3539020865

From haraldei at openjdk.org  Sun Nov 16 18:09:47 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Sun, 16 Nov 2025 18:09:47 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v4]
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <OUMDlAzMnr9FL9zIpSYc4FTkoh8amuHiMlMYde6YD0E=.f04784a8-f89b-4c4d-9279-5fec912afa18@github.com>

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix calculation of allocationSize when byteAlignment < MAX_MALLOC_ALIGN
  
  This work was sponsored by: The FreeBSD Foundation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28235/files
  - new: https://git.openjdk.org/jdk/pull/28235/files/15daa51b..c723058e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28235/head:pull/28235

PR: https://git.openjdk.org/jdk/pull/28235

From haraldei at openjdk.org  Sun Nov 16 18:09:47 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Sun, 16 Nov 2025 18:09:47 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v3]
In-Reply-To: <1IMETskhMt07HUa-VBc1q_F2NhqgM5k1iSkmpTKb9cY=.8744bc17-9905-49f1-89e3-829db6edcb6b@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <MqO3_Inf57nyfJtl0bEqKL1U0gtA-je3hfg6pxBz-Z8=.9631e5e3-7029-4311-947c-e105f34d8fdc@github.com>
 <1IMETskhMt07HUa-VBc1q_F2NhqgM5k1iSkmpTKb9cY=.8744bc17-9905-49f1-89e3-829db6edcb6b@github.com>
Message-ID: <kTn03luEcpPbfIeukW5H063OWeqrBsB8Ja1Dmm6Xxhs=.9b8a3b09-a857-475e-896a-89e5b11e56e9@github.com>

On Sat, 15 Nov 2025 18:54:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   OS agnostic fix for alignment of native segments
>>   
>>   Only align up the requested memory if the requested alignment is larget
>>   than max alignment provided by malloc, or if the requested size is not a
>>   multiple of the alignment size.
>>   
>>   This work was sponsored by: The FreeBSD Foundation
>>   
>>   Co-authored-by: mcimadamore
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 207:
> 
>> 205:         long result;
>> 206:         if (byteAlignment > MAX_MALLOC_ALIGN || alignedSize % byteAlignment != 0) {
>> 207:             allocationSize = alignedSize + byteAlignment - MAX_MALLOC_ALIGN;
> 
> The calculation of `allocationSize` looks no longer correct now that `byteAlignment` might be smaller than `MAX_MALLOC_ALIGN`, and it can result in a negative size.

Yes, I've just pushed a patch that should fix that.

Also I think it should be possible to change the if-statement like this:


if (byteAlignment > MAX_MALLOC_ALIGN || alignedSize < byteAlignment) {
   ...


But did not include that in this patch, as I tried to keep the change as small as possible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2532130159

From davidalayachew at gmail.com  Sun Nov 16 18:51:07 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 16 Nov 2025 13:51:07 -0500
Subject: Could we add headList and tailList methods to j.u.List?
Message-ID: <CAA9v-_PD4cd5QfT1tK1nj_g7E575O=eeWgaMAsNO5Wx+TLyMdQ@mail.gmail.com>

Hello @core-libs-dev <core-libs-dev at openjdk.org>,

Could we add headList(int) and tailList(int) to j.u.List? I searched JBS
and found nothing.

It's commonly what people want when doing subList(int, int), so this should
be pretty well received.

If not, no worries.

In that case, would be nice if we could add an entry to JBS with a Won't
Fix, to make it easier for those looking to see why not. Maybe even link
this thread for further reading.

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251116/804ff1a9/attachment.htm>

From liach at openjdk.org  Sun Nov 16 18:59:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 16 Nov 2025 18:59:11 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v2]
In-Reply-To: <78FynSSES1uEvkg12Q7YbCSu119MqQeNWc8F6kNKTlI=.27e91f98-21b4-47eb-a59c-1dbcbb26e76c@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <_HsqXtV1o3GBOX12-2eZMYVplxraX37xhWP6-fxbs7E=.420b43dc-59e2-49d5-b98d-888b8e8334d2@github.com>
 <78FynSSES1uEvkg12Q7YbCSu119MqQeNWc8F6kNKTlI=.27e91f98-21b4-47eb-a59c-1dbcbb26e76c@github.com>
Message-ID: <SPuGfOajNkag5he3NnR5HFXgtzJlkB53Ez9qFCducus=.27361080-5d35-468f-88ab-5b649e22ddf3@github.com>

On Sun, 16 Nov 2025 17:11:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Rephrase for parameterTypes contains null
>>  - Rename tests to be more specific
>>  - Split annotated type new checks to another patch
>
> src/java.base/share/classes/java/lang/Class.java line 2152:
> 
>> 2150:      *         {@code name} and {@code parameterTypes}
>> 2151:      * @throws NoSuchMethodException if a matching method is not found, such as
>> 2152:      *         when {@code parameterTypes} contains {@code null},
> 
> It might be clearer to say "or parameterTypes contains a null element" rather than "such as when ..."

My impression of this behavior is that no method can have a parameter type array that contains a `null` value. So claiming there is no matching method for this scenario probably makes sense?

> Now we have this odd scenario where a null element will provoke an eager NPE if flag is true

Sorry, but I fail to see where that happens - I believe if the array has a null element, `array.clone()` executes successfully, and the NPE is only thrown after some elements are set accessible. If the array is null, the array iteration would immediately fail with a NullPointerException just like when clone is executed. So both `false` and `true` paths would have the same NPE behavior.

In addition, the other exceptions of this methods are already thrown with side effects on the elements in the array before the first null value, and the side effects is not additionally specified. I think we can specify the NPE without requiring the NPE to be thrown before any side effect has been committed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2532159152
PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2532158581

From duke at openjdk.org  Sun Nov 16 19:09:43 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 16 Nov 2025 19:09:43 GMT
Subject: RFR: 8367603: Optimize exact division in BigDecimal [v25]
In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
Message-ID: <WsZditYp46_jutS6yXimgZw2aahYGt3VFIHJzv14goo=.e3c19f0c-59f1-442b-9d30-1e83ab065634@github.com>

> A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Removed trailing whitespaces
 - Added further tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27271/files
  - new: https://git.openjdk.org/jdk/pull/27271/files/cf2a309e..aecc5536

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=23-24

  Stats: 48 lines in 1 file changed: 47 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27271/head:pull/27271

PR: https://git.openjdk.org/jdk/pull/27271

From liach at openjdk.org  Sun Nov 16 19:27:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 16 Nov 2025 19:27:11 GMT
Subject: RFR: 8371960: Missing null check in AnnotatedType annotation
 accessor methods
In-Reply-To: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
References: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
Message-ID: <9JbGQ3B9m62YH6nduesn7xiiQH7RjclKRwMSzWhQnYc=.7f59f51b-db1b-4f91-9b11-3466c6d1d21d@github.com>

On Sun, 16 Nov 2025 16:02:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> `AnnotatedElement` methods specify they throw NPE if they take any null argument: `isAnnotationPresent`, `get(Declared)Annotation`, `get(Declared)AnnnotationsByType`. However, `AnnotatedType` has implementation quality issues that it does not throw NPE for `isAnnotationPresent` and `get(Declared)Annotation`.
> 
> This patch fixes this oversight by adding explicit null checks. For `get(Declared)AnnotationsByType`, even though it did throw exceptions, it was in the middle of parsing, so throwing it in the beginning is better.

There are impact to the 3 methods:
 - `isAnnotationPresent`: previously returned `false`, now throws
 - `getAnnotation`: previously returned `null`, now throws
 - `getDeclaredAnnotation`: previously returned `null`, now throws

For these two methods:
 - `getAnnnotationsByType`
 - `getDeclaredAnnotationsByType`

They currently already throw NullPointerException from within AnnotationSupport.getIndirectlyPresent. The only action that happens before is a Map.get call, so I don't think the lifted null check would hide any existing linkage error or other exceptions.

I think the main impact of this change is that `AnnotatedType` is the only way to retrieve type annotations, so the accessors might see more frequent usage compared to those on other `AnnotatedElement`s.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28341#issuecomment-3539163577

From liach at openjdk.org  Sun Nov 16 19:29:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 16 Nov 2025 19:29:21 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v13]
In-Reply-To: <dbW07VkPhX6rVrXYfyFABHfOEg-K9CIqJhHbJRNo1EA=.12f84b43-0f5c-43e9-a976-33c893f7850b@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <dbW07VkPhX6rVrXYfyFABHfOEg-K9CIqJhHbJRNo1EA=.12f84b43-0f5c-43e9-a976-33c893f7850b@github.com>
Message-ID: <La7Dc9CoJ5onq2CQLO_HCs_TciPvce383SMG89afWKA=.1c67bfe4-dc0e-4d23-86c9-3125eb243c05@github.com>

On Sun, 16 Nov 2025 17:26:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More wordsmithing
>  - Improve IAE exception message

src/java.base/share/man/java.md line 471:

> 469: :   Mutation of final fields is possible with the reflection API of the Java Platform.
> 470:     _However, it compromises safety and performance in all programs.
> 471:     This option allows code_ in the specified modules to mutate final fields by reflection.

Intended that this emphasis ends at "code" instead of the end of the last sentence?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2532177598

From alanb at openjdk.org  Sun Nov 16 19:37:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Nov 2025 19:37:00 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v2]
In-Reply-To: <SPuGfOajNkag5he3NnR5HFXgtzJlkB53Ez9qFCducus=.27361080-5d35-468f-88ab-5b649e22ddf3@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <_HsqXtV1o3GBOX12-2eZMYVplxraX37xhWP6-fxbs7E=.420b43dc-59e2-49d5-b98d-888b8e8334d2@github.com>
 <78FynSSES1uEvkg12Q7YbCSu119MqQeNWc8F6kNKTlI=.27e91f98-21b4-47eb-a59c-1dbcbb26e76c@github.com>
 <SPuGfOajNkag5he3NnR5HFXgtzJlkB53Ez9qFCducus=.27361080-5d35-468f-88ab-5b649e22ddf3@github.com>
Message-ID: <yt2IKcjVXqLn4-_dcjpAy1YQnDbv_YPCT7N_E-MFT-E=.49041c38-89da-441b-8fcc-760fc097dc68@github.com>

On Sun, 16 Nov 2025 18:55:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> So both `false` and `true` paths would have the same NPE behavior.

Ah, okay, you're right, the false and true cases can both fail with side effects. Maybe for another issue but this method just document that it may fail (with InaccessibleObjectException, SecurityException or NullPointerException) after modifying some of the elements.

As a more general point, I don't think this method is useful since the removal of the security manager. That is, it's motivation was to do a bulk suppressed with just one permission check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2532181440

From alanb at openjdk.org  Sun Nov 16 19:46:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Nov 2025 19:46:04 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v2]
In-Reply-To: <SPuGfOajNkag5he3NnR5HFXgtzJlkB53Ez9qFCducus=.27361080-5d35-468f-88ab-5b649e22ddf3@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <_HsqXtV1o3GBOX12-2eZMYVplxraX37xhWP6-fxbs7E=.420b43dc-59e2-49d5-b98d-888b8e8334d2@github.com>
 <78FynSSES1uEvkg12Q7YbCSu119MqQeNWc8F6kNKTlI=.27e91f98-21b4-47eb-a59c-1dbcbb26e76c@github.com>
 <SPuGfOajNkag5he3NnR5HFXgtzJlkB53Ez9qFCducus=.27361080-5d35-468f-88ab-5b649e22ddf3@github.com>
Message-ID: <DeopxhIQ2_1IV5Wk8m5nbjXXGisWYUMkFMDuOjVWEIY=.48dcbb36-dc81-41c1-830d-19447e5cb14a@github.com>

On Sun, 16 Nov 2025 18:57:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 2152:
>> 
>>> 2150:      *         {@code name} and {@code parameterTypes}
>>> 2151:      * @throws NoSuchMethodException if a matching method is not found, such as
>>> 2152:      *         when {@code parameterTypes} contains {@code null},
>> 
>> It might be clearer to say "or parameterTypes contains a null element" rather than "such as when ..."
>
> My impression of this behavior is that no method can have a parameter type array that contains a `null` value. So claiming there is no matching method for this scenario probably makes sense?

That might be a bit too subtle for the reader and it would be clearer to be explicit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2532186795

From david.holmes at oracle.com  Mon Nov 17 00:34:03 2025
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 17 Nov 2025 10:34:03 +1000
Subject: On throwing InterruptedException
In-Reply-To: <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>
Message-ID: <873e4f65-08c7-442b-acd6-62fc92e32f88@oracle.com>

On 6/11/2025 7:37 pm, Alan Bateman wrote:
> On 05/11/2025 14:00, Remi Forax wrote:
>> :
>>
>> If a thread is interrupted, it should stop ASAP.
>> So if you catch InterruptedException and rethrow a new exception, this 
>> should be okay (as Alan said).
> Rethrowing the InterruptedException is okay. Throwing a new exception 
> that is not an InterruptedException is okay too but only after restoring 
> the interrupted status, otherwise the thread might block again is some 
> catch block as it unwinds.

I would qualify the "restoring the interrupted status" part as it all 
depends on the overall context. If converting the IE to some other 
exception is part of the cancellation behaviour for this API then it may 
not be necessary to restore the interrupted status because the user of 
the API already knows this aspect of the computation has been cancelled. 
That cancellation request (the interrupt) may not apply to anything 
higher in the call-chain. Which is IIRC exactly how FutureTask 
cancellation operates.

David
> -Alan


From dholmes at openjdk.org  Mon Nov 17 01:05:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Nov 2025 01:05:07 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <Vxb5s3-a97MSfXsESNA5FmTP0qKBKZ_jYuRDW183p20=.8c2cf58d-0179-472d-b023-5671ac537bb7@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

I think this is completely unnecessary - `sysinfo`  on Linux can't really fail, the only error possible is EFAULT if you pass a bad pointer for the struct - so don't do that.

Replacing numbers with words in the logging could break external parsing scripts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3539576209

From pavel.rappo at gmail.com  Mon Nov 17 02:32:20 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Mon, 17 Nov 2025 02:32:20 +0000
Subject: On throwing InterruptedException
In-Reply-To: <873e4f65-08c7-442b-acd6-62fc92e32f88@oracle.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>
 <873e4f65-08c7-442b-acd6-62fc92e32f88@oracle.com>
Message-ID: <CAChcVun2vxTpfCHg+yYKWLKahkgV+YQm8cuXvQ9aiDw==B4REQ@mail.gmail.com>

David, I'm not entirely sure what you are referring to, but it sounds
like an atypical case to which general guidelines do not apply.

If a FutureTask is cancelled, by interruption or otherwise, a call to
get() will throw CancellationException. If interruption occurs, it is
an implementation detail, and it is confined to the thread that is
executing the task. Such interruption has no bearing on a thread that
calls get().

If a thread executing the task is interrupted directly, then get()
will throw ExecutionException that wraps InterruptedException. This is
quite an unusual situation, as no one should interrupt the thread
except for its owner.


-Pavel

On Mon, Nov 17, 2025 at 12:34?AM David Holmes <david.holmes at oracle.com> wrote:
>
> On 6/11/2025 7:37 pm, Alan Bateman wrote:
> > On 05/11/2025 14:00, Remi Forax wrote:
> >> :
> >>
> >> If a thread is interrupted, it should stop ASAP.
> >> So if you catch InterruptedException and rethrow a new exception, this
> >> should be okay (as Alan said).
> > Rethrowing the InterruptedException is okay. Throwing a new exception
> > that is not an InterruptedException is okay too but only after restoring
> > the interrupted status, otherwise the thread might block again is some
> > catch block as it unwinds.
>
> I would qualify the "restoring the interrupted status" part as it all
> depends on the overall context. If converting the IE to some other
> exception is part of the cancellation behaviour for this API then it may
> not be necessary to restore the interrupted status because the user of
> the API already knows this aspect of the computation has been cancelled.
> That cancellation request (the interrupt) may not apply to anything
> higher in the call-chain. Which is IIRC exactly how FutureTask
> cancellation operates.
>
> David
> > -Alan
>

From ch3cho at qq.com  Mon Nov 17 02:34:58 2025
From: ch3cho at qq.com (=?utf-8?B?S2VudCBEb25n?=)
Date: Mon, 17 Nov 2025 10:34:58 +0800
Subject: JDK-8370887 DelayScheduler Bug Discussion
In-Reply-To: <0292b0fa-3311-4162-b033-90b809421cc8@oracle.com>
References: <tencent_76B154EE69499B65C7B94D90F15245542606@qq.com>
 <b8d535ce-aaca-4a8a-934a-9a49dd61105a@oracle.com>
 <0292b0fa-3311-4162-b033-90b809421cc8@oracle.com>
Message-ID: <tencent_841946E91347E5E296A05A8E9EC304112C0A@qq.com>

Hi Alan, Viktor,


Thanks for the information. We are looking forward to its PR and release.


Kent


         ????
         
       
????Alan Bateman <alan.bateman at oracle.com&gt;
?????2025?11?16? 02:47
????Viktor Klang <viktor.klang at oracle.com&gt;, Kent Dong <ch3cho at qq.com&gt;, core-libs-dev <core-libs-dev at openjdk.org&gt;
???Re: JDK-8370887 DelayScheduler Bug Discussion





On&nbsp;15/11/2025&nbsp;16:56,&nbsp;Viktor&nbsp;Klang&nbsp;wrote:
&gt;
&gt;&nbsp;Hi&nbsp;Kent,
&gt;
&gt;&nbsp;Thanks&nbsp;for&nbsp;reporting,&nbsp;it&nbsp;has&nbsp;previously&nbsp;been&nbsp;reported&nbsp;and&nbsp;is&nbsp;tracked&nbsp;
&gt;&nbsp;here:&nbsp;https://bugs.openjdk.org/browse/JDK-8370887
&gt;
&gt;
Just&nbsp;to&nbsp;add&nbsp;to&nbsp;Viktor's&nbsp;link,&nbsp;there&nbsp;is&nbsp;an&nbsp;initial&nbsp;patch&nbsp;from&nbsp;Doug&nbsp;Lea&nbsp;
that&nbsp;we&nbsp;are&nbsp;currently&nbsp;testing.&nbsp;So&nbsp;PR&nbsp;yet,&nbsp;but&nbsp;hopefully&nbsp;soon.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251117/5c287576/attachment.htm>

From syan at openjdk.org  Mon Nov 17 04:00:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 04:00:02 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java
In-Reply-To: <cHe2LqzcuTeUVcnGGmhj6ybd-otgHPLi_DG0g127BLc=.186cd2bd-1a87-4cc5-866b-3a251baa4c46@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
 <cHe2LqzcuTeUVcnGGmhj6ybd-otgHPLi_DG0g127BLc=.186cd2bd-1a87-4cc5-866b-3a251baa4c46@github.com>
Message-ID: <oR_IYaTcrLfILoXKbsSQucLn4jTCIFtU-HSvCDXCv1M=.c01854bf-e7f6-4815-8b5d-cdcbd1979175@github.com>

On Sat, 15 Nov 2025 04:50:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The changes look good to me but I think Hannes' question is valid.
> 
> > > What does `testFinalizeMethodCallsSuperFinalize` test now?
> > 
> > 
> > I have verified java/util/concurrent/tck/JSR166TestCase.java#default locally, test still run passed. Test java/util/concurrent/tck/JSR166TestCase.java#default will invoke all the junit tests in java/util/concurrent/tck directory.
> 
> Is the testFinalizeMethodCallsSuperFinalize() needed or can it be removed? With the changes in this PR, I don't see what this method tests, especially given its name. It's a different matter that even without the changes to this PR, I am not sure what was being tested/asserted in that test method.

Sorry, I get the questions now.

Test testFinalizeMethodCallsSuperFinalize was added by [JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324). Since https://github.com/openjdk/jdk/pull/28278 will remove the (empty) ThreadPoolExecutor.finalize() method, so testFinalizeMethodCallsSuperFinalize can be removed also.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28278#issuecomment-3539852107

From syan at openjdk.org  Mon Nov 17 04:02:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 04:02:25 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <GxdAfZjP1AyrPeTMY5Rlk8hsh6RpkJKMF9rOmdYZKZs=.fabf195d-e178-4b9b-9d2d-699f4a8c1201@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
 <pUC2CsOOeN2fmLlHuqNHcTO5fZYPLIDwAmZRJEGd2ZY=.3e0a1615-873f-41b2-bd9a-807d8e80a364@github.com>
 <6hHUTYN71vmfPtE9gricMXDS3d3Two16__qJax7gY7M=.db4c76c6-255d-408b-b69d-7e37b9be22b3@github.com>
 <GxdAfZjP1AyrPeTMY5Rlk8hsh6RpkJKMF9rOmdYZKZs=.fabf195d-e178-4b9b-9d2d-699f4a8c1201@github.com>
Message-ID: <tw1lvzeS6nMd0D3y7jDe_sHkN5K0EJhE8sTIiqMdSI0=.a68a0d3d-518d-4749-b4b9-8154939527ca@github.com>

On Sat, 15 Nov 2025 07:21:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Indeed. My understanding is that that is being handled by [JDK-8371682](https://bugs.openjdk.org/browse/JDK-8371682).
> 
> It might make more sense for this PR to remove testFinalizeMethodCallsSuperFinalize as it's part of the removal.

Should I close https://github.com/openjdk/jdk/pull/28278 as duplicated to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3539854399

From syan at openjdk.org  Mon Nov 17 04:38:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 04:38:46 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java [v2]
In-Reply-To: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
Message-ID: <WkeD_U5X_KG_r1MePzvBtuhRSM76soP9DxyZRQMXjd0=.966fa8fe-d959-4002-a00f-588b8ca800e4@github.com>

> Hi all,
> 
> In JDK 11, ThreadPoolExecutor.finalize() was specified to do nothing, leaving the finalize() method empty by [JDK-8371748](https://bugs.openjdk.org/browse/JDK-8371748), so I think it's safety to remove finalize() in testFinalizeMethodCallsSuperFinalize for test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java.
> 
> This PR also remove unnecessary '@SuppressWarnings("removal")' in test/jdk/java/util/concurrent/tck/JSR166TestCase.java and test/jdk/java/util/concurrent/tck/ExecutorsTest.java.
> 
> Change has been verified locally on linux-x64 by run test java/util/concurrent/tck/JSR166TestCase.java#default. Test-fix only, no risk,

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove testFinalizeMethodCallsSuperFinalize

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28278/files
  - new: https://git.openjdk.org/jdk/pull/28278/files/374c8ef8..3c57f3bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28278&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28278&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28278.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28278/head:pull/28278

PR: https://git.openjdk.org/jdk/pull/28278

From duke at openjdk.org  Mon Nov 17 05:22:19 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Mon, 17 Nov 2025 05:22:19 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v9]
In-Reply-To: <eWKZXOL8TIRztsYpQexPdc2t97yrXllPVwLWnojjqnM=.1acf8e34-2e7e-48bb-a3cb-bf4a2706f106@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <eWKZXOL8TIRztsYpQexPdc2t97yrXllPVwLWnojjqnM=.1acf8e34-2e7e-48bb-a3cb-bf4a2706f106@github.com>
Message-ID: <nrJVppYERRrcm2B43nrL3nic8qJ2Zrz-zmIjuJtt2zA=.b3420806-a56c-476b-8224-91e6dd3efd2e@github.com>

On Fri, 17 Oct 2025 22:25:44 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
>> 
>> Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior.
>
> Benjamin Peterson 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 15 additional commits since the last revision:
> 
>  - add test showing loading symlinked libraries with various combinations
>  - revert dll_load fix
>  - Merge branch 'master' into nativelibraries-fix
>  - add cast
>  - use os::malloc
>  - Merge branch 'master' into nativelibraries-fix
>  - fix compilation
>  - fix grammar
>  - add dot in os::dll_load rather than NativeLibraries.java
>  - Merge remote-tracking branch 'origin/master' into nativelibraries-fix
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/ab30fa02...09de5608

Did any thoughts come back from security?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3540027643

From fyang at openjdk.org  Mon Nov 17 06:41:08 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 17 Nov 2025 06:41:08 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>
Message-ID: <fGaaH4f7ZujpXZALIuQS4YcaZwKAm6PX4kf6mtkJDWE=.7a1ad9d4-c8bf-476d-bff6-194919c3fd81@github.com>

On Fri, 14 Nov 2025 18:03:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> 
>> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
>> 
>> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
>> 
>> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
>> 
>> # Test
>> ## Jtreg
>> 
>> in progress...
>> 
>> ## Performance
>> 
>> Column names meanings:
>> * p: with patch
>> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> * m: without patch
>> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> 
>> #### Average improvement
>> 
>> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
>> 
>> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
>> -- | -- | -- | --
>> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
>> 
>> </google-sheets-html-origin>
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add CMove+CmpP/N tests
>  - fix cmovF/D_cmpP

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2133:

> 2131:       break;
> 2132:     case BoolTest::ge:
> 2133:       assert(false, "Should go to BoolTest::le case");

I am not sure if it's safe to have these assertions for `ge` and `gt`. It seems to me that we should handle all possible condition codes here. Check this bug: https://bugs.openjdk.org/browse/JDK-8358892. We have added handling for `ge` and `gt` in `C2_MacroAssembler::enc_cmove_cmp_fp` to fix it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2532878358

From duke at openjdk.org  Mon Nov 17 06:41:18 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 17 Nov 2025 06:41:18 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
Message-ID: <Tk30e3S_f6fDRSCSQYr6pWse54zFjp1xK28GSB0x6_w=.adaa01ea-0bdf-48b9-ac23-ae7ec0f43519@github.com>

On Thu, 13 Nov 2025 23:10:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug report:
> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to
> "[invoke] shutdown() when this executor is no longer referenced and it has no threads."
> 
> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)).
> 
> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)).
> 
> The finalize() method can safely be removed from ThreadPoolExecutor.

Wrt. the?**CSR**?s ?**Compatibility Risk?Description**?:
> Subclasses that @?Override finalize, call super.finalize() or call finalize() directly will continue to compile and execute.

This?isn?t completely?correct, as?`super.finalize()` will?now?have `throws?Throwable`, where?it previously?didn?t, causing a?source incompatibility, as?seen in?`ThreadPoolExecutorSubclassTest`:
> ```
> /home/runner/work/jdk/jdk/test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java:2011:
> error: unreported exception Throwable; must be caught or declared to be thrown
>                 super.finalize();
>                               ^
> ```

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3540202811

From alanb at openjdk.org  Mon Nov 17 07:12:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 07:12:09 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <Tk30e3S_f6fDRSCSQYr6pWse54zFjp1xK28GSB0x6_w=.adaa01ea-0bdf-48b9-ac23-ae7ec0f43519@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
 <Tk30e3S_f6fDRSCSQYr6pWse54zFjp1xK28GSB0x6_w=.adaa01ea-0bdf-48b9-ac23-ae7ec0f43519@github.com>
Message-ID: <wXuR5UW73UaHVQjzwPV71JoI4JmLUWqXruOSidAgEB0=.5c9dccd3-a8fd-42cb-adb0-f97854b408ac@github.com>

On Mon, 17 Nov 2025 06:38:21 GMT, ExE Boss <duke at openjdk.org> wrote:

> `super.finalize()` will?now?have `throws?Throwable`, where?it previously?didn?t, causing a?source incompatibility, as?seen in?`ThreadPoolExecutorSubclassTest`:

Indeed, there is a source compatibility issue here. @bchristi-git Have you did corpus searches to see if there are many cases that extend TPE and invoke super.finalize? I wouldn't any in code written in recent years but maybe there is still older code that would need updating. The overall risk here is low though and the migration would be to just drop the super.finalize() as it doesn't do anything since JDK 11.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3540278101

From alanb at openjdk.org  Mon Nov 17 07:13:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 07:13:14 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v9]
In-Reply-To: <nrJVppYERRrcm2B43nrL3nic8qJ2Zrz-zmIjuJtt2zA=.b3420806-a56c-476b-8224-91e6dd3efd2e@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <eWKZXOL8TIRztsYpQexPdc2t97yrXllPVwLWnojjqnM=.1acf8e34-2e7e-48bb-a3cb-bf4a2706f106@github.com>
 <nrJVppYERRrcm2B43nrL3nic8qJ2Zrz-zmIjuJtt2zA=.b3420806-a56c-476b-8224-91e6dd3efd2e@github.com>
Message-ID: <KsNAlCjQvFJi-z3Q-BnocCg4ELXxeFRFjyugtdnh4wU=.2d842d82-349c-472a-901f-922accecef50@github.com>

On Mon, 17 Nov 2025 05:19:31 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> Did any thoughts come back from security?

Still discussing. Sorry I cannot share the details here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3540282068

From epeter at openjdk.org  Mon Nov 17 07:30:14 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 17 Nov 2025 07:30:14 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <5PzMJntiu2waMvciTLvXaUH15Fm3dXZPsDVvkuqWPI0=.68c6456a-e5d3-413e-bef8-d8da95de40bd@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <ck9qtvcIKfxaa47UNuAa2Vqu98FzFZoLDIsNIdsCthM=.14fca2ef-a4f2-48b0-9ae7-8492a02d6f46@github.com>
 <5PzMJntiu2waMvciTLvXaUH15Fm3dXZPsDVvkuqWPI0=.68c6456a-e5d3-413e-bef8-d8da95de40bd@github.com>
Message-ID: <46DWeMiCRNMC58wGr4T52KXbtRjU0PxQ4L6LuVFMZEo=.867fcc86-edd1-4492-9c1a-58f83d135969@github.com>

On Fri, 14 Nov 2025 18:11:28 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMove.java line 36:
>> 
>>> 34:  * @test
>>> 35:  * @summary Test conditional move.
>>> 36:  * @requires vm.simpleArch == "riscv64"
>> 
>> I would prefer if you could enable the test on all platforms, but just require the specific platform on the IR rules.
>> What would be even more fantastic: if you were able to also enable the IR rules for `x64` and `aarch64`, but we can also file a follow-up RFE for that.
>
> Make sense. I filed https://bugs.openjdk.org/browse/JDK-8371920 to track the task, will do it later after this pr.

I would suggest that you already make the move from `@requires` to IR rule level restrictions. But we can look at adding `x64` and `aarch64` in the separate RFE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2532986110

From epeter at openjdk.org  Mon Nov 17 07:42:13 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 17 Nov 2025 07:42:13 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>
Message-ID: <gI4813-J0PQLXvWINwjKKjVIP9ARmcj2y2fAh028QmI=.ea2165fb-54ef-4d1e-96d1-6064cee7132e@github.com>

On Fri, 14 Nov 2025 18:03:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> 
>> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
>> 
>> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
>> 
>> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
>> 
>> # Test
>> ## Jtreg
>> 
>> in progress...
>> 
>> ## Performance
>> 
>> Column names meanings:
>> * p: with patch
>> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> * m: without patch
>> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> 
>> #### Average improvement
>> 
>> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
>> 
>> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
>> -- | -- | -- | --
>> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
>> 
>> </google-sheets-html-origin>
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add CMove+CmpP/N tests
>  - fix cmovF/D_cmpP

test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMoveCmpObj.java line 131:

> 129:     //     applyIf = {"UseCompressedOops", "false"})
> 130:     // @IR(counts = {IRNode.CMOVE_L, ">0", IRNode.CMP_N, ">0"},
> 131:     //     applyIf = {"UseCompressedOops", "true"})

Do you plan to still do this in this PR? Probably a future RFE would be better. It could be nice if you could link to the RFE with the issue number from this comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2533013052

From epeter at openjdk.org  Mon Nov 17 07:46:12 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 17 Nov 2025 07:46:12 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <5PzMJntiu2waMvciTLvXaUH15Fm3dXZPsDVvkuqWPI0=.68c6456a-e5d3-413e-bef8-d8da95de40bd@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <ck9qtvcIKfxaa47UNuAa2Vqu98FzFZoLDIsNIdsCthM=.14fca2ef-a4f2-48b0-9ae7-8492a02d6f46@github.com>
 <5PzMJntiu2waMvciTLvXaUH15Fm3dXZPsDVvkuqWPI0=.68c6456a-e5d3-413e-bef8-d8da95de40bd@github.com>
Message-ID: <sHMOrlg1c8zjr5UuI64P9KnJ6Dtk4k-a_5jsLoMsWKo=.4e78c6f0-aee3-4433-baae-4c6777035372@github.com>

On Fri, 14 Nov 2025 18:12:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMove.java line 49:
>> 
>>> 47:                                    "-XX:+UnlockExperimentalVMOptions", "-XX:-UseCompactObjectHeaders");
>>> 48:         TestFramework.runWithFlags("-XX:+UseCMoveUnconditionally", "-XX:-UseVectorCmov",
>>> 49:                                    "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCompactObjectHeaders");
>> 
>> Wait. Is this just a copy of the existing vector test, but run with CMove vectorization disabled?
>> If so, we could just add these additional runs to the existing test, and guard the IR test with corresponding flags:
>> Have an IR rule for `-XX:-UseVectorCmov` and one for `-XX:+UseVectorCmov`.
>> 
>> That would allow us to reduce some code duplication. And it would also avoid letting the two tests go out of sync when people add more to one but not the other.
>> 
>> What do you think?
>
> Good idea!
> I can do it. What do you think about the name of the merged tests? `TestConditionalMove.java` or `TestScalarAndVectorConditionalMove.java`

`TestConditionalMove.java` sounds good :)

It would also be nice if we could move it out of the `irTests` directory, we would like to eventually move all tests away from it, and rather sort the tests by what they test and not by how we test them. Though now it's a little tricky because we check for both vector and scalar things. Still, I would propose that you move it under `c2/vectorization` or `c2/loopopts/superword`, since they do include vectorization tests. An alternative could also be in a new `c2/cmove` directory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2533020809

From cstein at openjdk.org  Mon Nov 17 07:56:35 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 17 Nov 2025 07:56:35 GMT
Subject: RFR: 8268613: jar --validate should check inital entries of a JAR
 file [v5]
In-Reply-To: <XfoQewk7-dEpabvrmUfS2X15_AW-qgCF7LHjL8cZJd4=.413cc204-6550-4eee-891b-0d3f591a3ff8@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
 <XfoQewk7-dEpabvrmUfS2X15_AW-qgCF7LHjL8cZJd4=.413cc204-6550-4eee-891b-0d3f591a3ff8@github.com>
Message-ID: <QseNXKabY-fPG613zHZON0DrnnVHj9T5N_Hkl_jhNc0=.fe222f6c-b5c8-499b-a1a7-4acb1c803e06@github.com>

On Thu, 13 Nov 2025 08:39:37 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dedicated error messages

Thanks for the reviews! Tier1-3 tests look good, thus:

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28154#issuecomment-3540403447

From cstein at openjdk.org  Mon Nov 17 07:56:36 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 17 Nov 2025 07:56:36 GMT
Subject: Integrated: 8268613: jar --validate should check inital entries of a
 JAR file
In-Reply-To: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
References: <X_F3GWVWDikWoEtxk8hjw99-HgAKgfxD6lretsLjdH8=.76ddefcb-07c6-47b9-aa4d-d9f1b3dc299e@github.com>
Message-ID: <HqxqfVFre4Mpd8PN-p9BRLn-CotGMGPBUN3R_m-tAd0=.11930732-7a99-4d8c-9334-43ab6b11ae14@github.com>

On Wed, 5 Nov 2025 17:29:10 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to include a validation check for expecting an optional JAR manifest entry being the first or second entry in JAR file. As the second entry, it must be only preceeded by an entry for the `META-INF/` directory.

This pull request has now been integrated.

Changeset: 8690d263
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8690d263d9dd0fd06ed41d9529fd8cc84e1c08c8
Stats:     111 lines in 3 files changed: 111 ins; 0 del; 0 mod

8268613: jar --validate should check inital entries of a JAR file

Reviewed-by: lancea, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/28154

From david.holmes at oracle.com  Mon Nov 17 08:06:44 2025
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 17 Nov 2025 18:06:44 +1000
Subject: On throwing InterruptedException
In-Reply-To: <CAChcVun2vxTpfCHg+yYKWLKahkgV+YQm8cuXvQ9aiDw==B4REQ@mail.gmail.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>
 <873e4f65-08c7-442b-acd6-62fc92e32f88@oracle.com>
 <CAChcVun2vxTpfCHg+yYKWLKahkgV+YQm8cuXvQ9aiDw==B4REQ@mail.gmail.com>
Message-ID: <d41990b1-4fcb-43f5-a853-d96eec09f39f@oracle.com>

On 17/11/2025 12:32 pm, Pavel Rappo wrote:
> David, I'm not entirely sure what you are referring to, but it sounds
> like an atypical case to which general guidelines do not apply.

It is just about making cancellation semantics a part of the API. 
Interrupt is just the mechanism to aid in implementing cancellation.

> If a FutureTask is cancelled, by interruption or otherwise, a call to
> get() will throw CancellationException. If interruption occurs, it is
> an implementation detail, and it is confined to the thread that is
> executing the task. Such interruption has no bearing on a thread that
> calls get().

Okay but that is just due to the async nature of FutureTask. Imagine 
instead a ServiceObject with methods to have a service performed, and a 
method to shutdown the service. The service methods are synchronous and 
throw ShutdownException if the service gets shutdown whilst the request 
is in progress. Interruption is just an available mechanism to aid in 
that and it may not be appropriate to leave the interrupt state set 
after the service method returns. Of course we have to look at the 
broader context in case there could be multiple levels of cancellation 
that apply - as Doug says in CPJ you can't necessarily distinguish 
whether an interruption means cancel the current task, or terminate the 
current thread. You need complete context to know what to do.

David
> If a thread executing the task is interrupted directly, then get()
> will throw ExecutionException that wraps InterruptedException. This is
> quite an unusual situation, as no one should interrupt the thread
> except for its owner.
> 
> 
> -Pavel
> 
> On Mon, Nov 17, 2025 at 12:34?AM David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 6/11/2025 7:37 pm, Alan Bateman wrote:
>>> On 05/11/2025 14:00, Remi Forax wrote:
>>>> :
>>>>
>>>> If a thread is interrupted, it should stop ASAP.
>>>> So if you catch InterruptedException and rethrow a new exception, this
>>>> should be okay (as Alan said).
>>> Rethrowing the InterruptedException is okay. Throwing a new exception
>>> that is not an InterruptedException is okay too but only after restoring
>>> the interrupted status, otherwise the thread might block again is some
>>> catch block as it unwinds.
>>
>> I would qualify the "restoring the interrupted status" part as it all
>> depends on the overall context. If converting the IE to some other
>> exception is part of the cancellation behaviour for this API then it may
>> not be necessary to restore the interrupted status because the user of
>> the API already knows this aspect of the computation has been cancelled.
>> That cancellation request (the interrupt) may not apply to anything
>> higher in the call-chain. Which is IIRC exactly how FutureTask
>> cancellation operates.
>>
>> David
>>> -Alan
>>


From pminborg at openjdk.org  Mon Nov 17 09:32:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 09:32:02 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v26]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <fiVbzfEtyzmeyqsFt4oJyaO7JqYV9og0Ox2FODrdZcQ=.b642fcf7-34c4-45e9-9173-67189cc8adb0@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 125 commits:

 - Merge branch 'master' into lazy-constants
 - Merge master
 - Fix tests and improve docs
 - Remove inner classes in LazyList
 - Fix TOC TOU issue
 - Improve documentation for List and Map factories
 - Improve doc details
 - Improve text for hashCode()
 - Refine text about reachabilit of the contents
 - Align doc links for get()
 - ... and 115 more: https://git.openjdk.org/jdk/compare/69e30244...3c26e095

-------------

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=25
  Stats: 8347 lines in 60 files changed: 3738 ins; 4490 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

PR: https://git.openjdk.org/jdk/pull/27605

From jpai at openjdk.org  Mon Nov 17 09:36:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 09:36:18 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java [v2]
In-Reply-To: <WkeD_U5X_KG_r1MePzvBtuhRSM76soP9DxyZRQMXjd0=.966fa8fe-d959-4002-a00f-588b8ca800e4@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
 <WkeD_U5X_KG_r1MePzvBtuhRSM76soP9DxyZRQMXjd0=.966fa8fe-d959-4002-a00f-588b8ca800e4@github.com>
Message-ID: <OMCiTAAE4P4VrDu3YW25ms2Ik46L_H1-VbZqFqVTRCk=.69827c0d-7cb5-4735-88ff-1313b3ebe79f@github.com>

On Mon, 17 Nov 2025 04:38:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> In JDK 11, ThreadPoolExecutor.finalize() was specified to do nothing, leaving the finalize() method empty by [JDK-8371748](https://bugs.openjdk.org/browse/JDK-8371748), so I think it's safety to remove finalize() in testFinalizeMethodCallsSuperFinalize for test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java.
>> 
>> This PR also remove unnecessary '@SuppressWarnings("removal")' in test/jdk/java/util/concurrent/tck/JSR166TestCase.java and test/jdk/java/util/concurrent/tck/ExecutorsTest.java.
>> 
>> Change has been verified locally on linux-x64 by run test java/util/concurrent/tck/JSR166TestCase.java#default. Test-fix only, no risk,
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove testFinalizeMethodCallsSuperFinalize

The change looks good to me. I'll let you decide with others on the other PR https://github.com/openjdk/jdk/pull/28311 whether the `testFinalizeMethodCallsSuperFinalize` test method removal should be part of this PR or the other one.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28278#pullrequestreview-3471833404

From mli at openjdk.org  Mon Nov 17 09:43:06 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 17 Nov 2025 09:43:06 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <gI4813-J0PQLXvWINwjKKjVIP9ARmcj2y2fAh028QmI=.ea2165fb-54ef-4d1e-96d1-6064cee7132e@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>
 <gI4813-J0PQLXvWINwjKKjVIP9ARmcj2y2fAh028QmI=.ea2165fb-54ef-4d1e-96d1-6064cee7132e@github.com>
Message-ID: <rO8v1ZQfbVSItMM8rFD-934neD8P_XRuIEbqlRXg91o=.3fd23b58-5691-412e-9db9-a3e1e5e2e8c6@github.com>

On Mon, 17 Nov 2025 07:39:19 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add CMove+CmpP/N tests
>>  - fix cmovF/D_cmpP
>
> test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMoveCmpObj.java line 131:
> 
>> 129:     //     applyIf = {"UseCompressedOops", "false"})
>> 130:     // @IR(counts = {IRNode.CMOVE_L, ">0", IRNode.CMP_N, ">0"},
>> 131:     //     applyIf = {"UseCompressedOops", "true"})
> 
> Do you plan to still do this in this PR? Probably a future RFE would be better. It could be nice if you could link to the RFE with the issue number from this comment.

In this PR, no, this one will only implement CMoveF/D and enable the vectorization of CMoveF/D, so do some preparation for https://github.com/openjdk/jdk/pull/28231.
To guarantee the generation of CMoveI/L, seems to me we need to improve the cost model when transfrom a phi to a conditional move. I can have a invetigation later, as this impact how & whether CMoveL/I can be generated and be vectorized accordingly. File https://bugs.openjdk.org/browse/JDK-8371984 to track it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2533384835

From epeter at openjdk.org  Mon Nov 17 09:55:06 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 17 Nov 2025 09:55:06 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <rO8v1ZQfbVSItMM8rFD-934neD8P_XRuIEbqlRXg91o=.3fd23b58-5691-412e-9db9-a3e1e5e2e8c6@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>
 <gI4813-J0PQLXvWINwjKKjVIP9ARmcj2y2fAh028QmI=.ea2165fb-54ef-4d1e-96d1-6064cee7132e@github.com>
 <rO8v1ZQfbVSItMM8rFD-934neD8P_XRuIEbqlRXg91o=.3fd23b58-5691-412e-9db9-a3e1e5e2e8c6@github.com>
Message-ID: <XCNbQaK3glnRkw_e37jszkh_xdf_3HKoOGJHg8i1Abs=.907062d0-ba88-45a8-9005-ef4d29070b2c@github.com>

On Mon, 17 Nov 2025 09:40:29 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMoveCmpObj.java line 131:
>> 
>>> 129:     //     applyIf = {"UseCompressedOops", "false"})
>>> 130:     // @IR(counts = {IRNode.CMOVE_L, ">0", IRNode.CMP_N, ">0"},
>>> 131:     //     applyIf = {"UseCompressedOops", "true"})
>> 
>> Do you plan to still do this in this PR? Probably a future RFE would be better. It could be nice if you could link to the RFE with the issue number from this comment.
>
> In this PR, no, this one will only implement CMoveF/D and enable the vectorization of CMoveF/D, so do some preparation for https://github.com/openjdk/jdk/pull/28231.
> To guarantee the generation of CMoveI/L, seems to me we need to improve the cost model when transfrom a phi to a conditional move. I can have a invetigation later, as this impact how & whether CMoveL/I can be generated and be vectorized accordingly. File https://bugs.openjdk.org/browse/JDK-8371984 to track it.

Ok. Sounds good. Just note: getting the cost model right here can be really difficult. People have played with the cost model in recent years, and it has also led to regressions in some cases. Just FYI, I'm not stopping you from trying if you like ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2533420545

From alan.bateman at oracle.com  Mon Nov 17 10:02:25 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Nov 2025 10:02:25 +0000
Subject: On throwing InterruptedException
In-Reply-To: <873e4f65-08c7-442b-acd6-62fc92e32f88@oracle.com>
References: <CAChcVunLQb43mQXdquD+mGj=V792yZKawuukZ_DZFa8f79F6vQ@mail.gmail.com>
 <1731802723.32055437.1762351224152.JavaMail.zimbra@univ-eiffel.fr>
 <1e7689ea-c8fd-463a-af1c-42cbf6dcd77e@oracle.com>
 <873e4f65-08c7-442b-acd6-62fc92e32f88@oracle.com>
Message-ID: <198e87fb-462f-404f-ba71-8c07bb362a1c@oracle.com>



On 17/11/2025 00:34, David Holmes wrote:
> On 6/11/2025 7:37 pm, Alan Bateman wrote:
>> Rethrowing the InterruptedException is okay. Throwing a new exception 
>> that is not an InterruptedException is okay too but only after 
>> restoring the interrupted status, otherwise the thread might block 
>> again is some catch block as it unwinds.
>
> I would qualify the "restoring the interrupted status" part as it all 
> depends on the overall context. If converting the IE to some other 
> exception is part of the cancellation behaviour for this API then it 
> may not be necessary to restore the interrupted status because the 
> user of the API already knows this aspect of the computation has been 
> cancelled. That cancellation request (the interrupt) may not apply to 
> anything higher in the call-chain. Which is IIRC exactly how 
> FutureTask cancellation operates.

Library code is unlikely to "know" the full context of its usage. If 
library code is handling IE by throwing some other exception then I 
think the advice has to be restore the interrupted status before 
throwing, otherwise some other part of the system, including code 
further up in the call chain, may block/hang. Yes, there will be a few 
cases that are more advanced or have more global knowledge, but you get 
into difficult coordination issues once you try to reduce the scope of 
the handling.

-Alan



From pminborg at openjdk.org  Mon Nov 17 10:17:19 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 10:17:19 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v8]
In-Reply-To: <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>
Message-ID: <hyRtEMEX1yoHgkJLu3v3DkWVZteXlz7endWkxxGECLA=.4b2438d3-f993-47ed-8383-f110b114f7e4@github.com>

On Sun, 16 Nov 2025 14:50:39 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
>> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
>> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach
>
> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust to TestMergeStoresMemorySegment.java requirements

Previously, AMSI implemented `BiFunction<String, List<Number>, RuntimeException>`, but now that there are two different ways of generating exceptions, we need something else. I think the concept of having the AMSI implement interfaces is a good way of expressing a zero-allocation-on-check invariant in all situations.

Another alternative, compared to the proposed way, would be to create two new private interfaces, perhaps called `RangeCheckingExceptionFormatter` and `SliceCheckingExceptionFormatter`. Here is a sketch which I am certain can be improved:


interface ExceptionFormatter extends BiFunction<String, List<Number>, RuntimeException> {
    MemorySegment segment();
}

interface RangeCheckingExceptionFormatter extends ExceptionFormatter {

    @Override
    default RuntimeException apply(String s, List<Number> numbers) {
        long offset = numbers.get(0).longValue();
        long length = segment().byteSize() - numbers.get(1).longValue() + 1;
        return new IndexOutOfBoundsException(String.format("... <range text> ... on segment %s; new offset = %d; new length = %d",
                segment(), offset, length));
    }
}

interface SliceCheckingExceptionFormatter extends ExceptionFormatter {
    @Override
    default RuntimeException apply(String s, List<Number> numbers) {
        long offset = numbers.get(0).longValue();
        long length = segment().byteSize() - numbers.get(1).longValue() + 1;
        return new IndexOutOfBoundsException(String.format("... <slice text> ... on segment %s; new offset = %d; new length = %d",
                segment(), offset, length));
    }
}


Then we can let AMSI implement these interfaces and trivially implement `ExceptionFormatter::segment` by returning `this`. Then, when we need an exception formatter in the two distinct cases, we just cast `this` to the appropriate formatter type. 

Maybe there is a better way, but I think you get the underlying idea. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3540957760

From mli at openjdk.org  Mon Nov 17 10:27:06 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 17 Nov 2025 10:27:06 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <XCNbQaK3glnRkw_e37jszkh_xdf_3HKoOGJHg8i1Abs=.907062d0-ba88-45a8-9005-ef4d29070b2c@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>
 <gI4813-J0PQLXvWINwjKKjVIP9ARmcj2y2fAh028QmI=.ea2165fb-54ef-4d1e-96d1-6064cee7132e@github.com>
 <rO8v1ZQfbVSItMM8rFD-934neD8P_XRuIEbqlRXg91o=.3fd23b58-5691-412e-9db9-a3e1e5e2e8c6@github.com>
 <XCNbQaK3glnRkw_e37jszkh_xdf_3HKoOGJHg8i1Abs=.907062d0-ba88-45a8-9005-ef4d29070b2c@github.com>
Message-ID: <oLSBl7Rf35DMhuBK5HT4Ji2v5x35Qah_PzGKKrJDPBg=.6a3ca36e-3496-4eb5-915b-c8c5c78d0800@github.com>

On Mon, 17 Nov 2025 09:51:39 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> In this PR, no, this one will only implement CMoveF/D and enable the vectorization of CMoveF/D, so do some preparation for https://github.com/openjdk/jdk/pull/28231.
>> To guarantee the generation of CMoveI/L, seems to me we need to improve the cost model when transfrom a phi to a conditional move. I can have a invetigation later, as this impact how & whether CMoveL/I can be generated and be vectorized accordingly. File https://bugs.openjdk.org/browse/JDK-8371984 to track it.
>
> Ok. Sounds good. Just note: getting the cost model right here can be really difficult. People have played with the cost model in recent years, and it has also led to regressions in some cases. Just FYI, I'm not stopping you from trying if you like ;)

Thanks for reminding! :) That's also the reason I won't do it in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2533522249

From alanb at openjdk.org  Mon Nov 17 10:48:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 10:48:13 GMT
Subject: RFR: 8371960: Missing null check in AnnotatedType annotation
 accessor methods
In-Reply-To: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
References: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
Message-ID: <SQGxXzPpHc_OhJGA5SdVDhsgAoHm5vS6MsZG1TZONkM=.4c3ba0cd-a888-4acd-a65c-f7df76814368@github.com>

On Sun, 16 Nov 2025 16:02:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> `AnnotatedElement` methods specify they throw NPE if they take any null argument: `isAnnotationPresent`, `get(Declared)Annotation`, `get(Declared)AnnnotationsByType`. However, `AnnotatedType` has implementation quality issues that it does not throw NPE for `isAnnotationPresent` and `get(Declared)Annotation`.
> 
> This patch fixes this oversight by adding explicit null checks. For `get(Declared)AnnotationsByType`, even though it did throw exceptions, it was in the middle of parsing, so throwing it in the beginning is better.

Marked as reviewed by alanb (Reviewer).

test/jdk/java/lang/reflect/AnnotatedElement/AnnotatedElementNullCheckTest.java line 87:

> 85:             var clazz = impl.getClass();
> 86:             if (!set.add(clazz)) {
> 87:                 fail("Duplicate implementation class %s in %s".formatted(clazz, impl));

Good sanity test on the method source.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28341#pullrequestreview-3472103024
PR Review Comment: https://git.openjdk.org/jdk/pull/28341#discussion_r2533583081

From alanb at openjdk.org  Mon Nov 17 10:48:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 10:48:15 GMT
Subject: RFR: 8371960: Missing null check in AnnotatedType annotation
 accessor methods
In-Reply-To: <9JbGQ3B9m62YH6nduesn7xiiQH7RjclKRwMSzWhQnYc=.7f59f51b-db1b-4f91-9b11-3466c6d1d21d@github.com>
References: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
 <9JbGQ3B9m62YH6nduesn7xiiQH7RjclKRwMSzWhQnYc=.7f59f51b-db1b-4f91-9b11-3466c6d1d21d@github.com>
Message-ID: <zTPnIxJasbSu53L_JCM42N_EU96GBHC0782dXCYtDLE=.4bc05557-e094-4aa2-acd7-335f0f7a5992@github.com>

On Sun, 16 Nov 2025 19:24:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think the main impact of this change is that `AnnotatedType` is the only way to retrieve type annotations, so the accessors might see more frequent usage compared to those on other `AnnotatedElement`s.

Yes, it seems this will really only be noticed if getAnnotatedReturnType/getAnnotatedParameterTypes/etc. methods are used and something has a bug that results in invoking AnnotatedType methods with null. Seems low risk.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28341#issuecomment-3541102393

From alanb at openjdk.org  Mon Nov 17 10:48:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 10:48:38 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v14]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:

 - Merge branch 'master' into JDK-8353835
 - Spurious italics
 - More wordsmithing
 - Improve IAE exception message
 - Merge branch 'master' into JDK-8353835
 - Cleanup
 - More cleanup of Field.set API docs, including some restructure from Alex
 - Cleanup
 - Merge branch 'master' into JDK-8353835
 - Update mutateFinals/modules test to exercise exports and opens cases
 - ... and 53 more: https://git.openjdk.org/jdk/compare/8690d263...c3c3cfff

-------------

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=13
  Stats: 5365 lines in 76 files changed: 5170 ins; 55 del; 140 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

PR: https://git.openjdk.org/jdk/pull/25115

From mcimadamore at openjdk.org  Mon Nov 17 11:19:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 17 Nov 2025 11:19:15 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v26]
In-Reply-To: <fiVbzfEtyzmeyqsFt4oJyaO7JqYV9og0Ox2FODrdZcQ=.b642fcf7-34c4-45e9-9173-67189cc8adb0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <fiVbzfEtyzmeyqsFt4oJyaO7JqYV9og0Ox2FODrdZcQ=.b642fcf7-34c4-45e9-9173-67189cc8adb0@github.com>
Message-ID: <UsVyM2P1jaGf874UM25dFDMfBQWBlhOyN22wwSfWqtQ=.04e2a58d-9a6d-4cf7-a274-df3f1645c64e@github.com>

On Mon, 17 Nov 2025 09:32:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 125 commits:
> 
>  - Merge branch 'master' into lazy-constants
>  - Merge master
>  - Fix tests and improve docs
>  - Remove inner classes in LazyList
>  - Fix TOC TOU issue
>  - Improve documentation for List and Map factories
>  - Improve doc details
>  - Improve text for hashCode()
>  - Refine text about reachabilit of the contents
>  - Align doc links for get()
>  - ... and 115 more: https://git.openjdk.org/jdk/compare/69e30244...3c26e095

src/java.base/share/classes/java/lang/LazyConstant.java line 244:

> 242:      * <p>
> 243:      * In other words, equals compares the identity of this lazy constant and {@code obj}
> 244:      * to determine equality. Hence, two lazy constant with the same contents are

Suggestion:

     * to determine equality. Hence, two lazy constants with the same contents are

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533674027

From pminborg at openjdk.org  Mon Nov 17 11:29:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 11:29:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v27]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <wmiyzAjTgb4hBR9rFi5881eXvQIwzbbKNdYHSxj_VQI=.16face2a-40c5-4d1d-bd31-335b6b020d33@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix forgotten text about (List|Map)::toString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/3c26e095..2d8f98fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=25-26

  Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

PR: https://git.openjdk.org/jdk/pull/27605

From mcimadamore at openjdk.org  Mon Nov 17 11:38:04 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 17 Nov 2025 11:38:04 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <iq1Jk7NLAvqBhVwcS95kaY0cgFCRt1DKCg_FfVZZSYY=.730253ad-fb3c-4546-ba66-8a0a7924fda7@github.com>

On Mon, 17 Nov 2025 11:34:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Great work!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3472270393

From pminborg at openjdk.org  Mon Nov 17 11:38:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 11:38:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/2d8f98fe..e5399c5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=26-27

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

PR: https://git.openjdk.org/jdk/pull/27605

From duke at openjdk.org  Mon Nov 17 13:26:20 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 17 Nov 2025 13:26:20 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <TPGlt2Gs6iU1gFx4-rGsygrzjYi7apia359gMsJwlBM=.dc939a2c-cd23-491f-9961-2ca0e48cd3a0@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

I've had a look mostly at the docs, everything I'm saying is optional (though I'd really like to see the Logger example changed).

src/java.base/share/classes/java/lang/LazyConstant.java line 42:

> 40:  * A lazy constant is created using the factory method
> 41:  * {@linkplain LazyConstant#of(Supplier) LazyConstant.of({@code <computing function>})}.
> 42:  * When created, the lazy constant is <em>not initialized</em>, meaning it has no contents.

Subjectively, might this be clearer as a bulleted list? This is a sequence of statements about the state transitions after all.

<ul>
<li>On creation the lazy constant is <em>not initialized</em> ...
<li>The first time {@linkplain #get() get()} is called ...
<li>Once a lazy constant is initialized ...

Or just splitting by paragraph.

src/java.base/share/classes/java/lang/LazyConstant.java line 60:

> 58:  *    private final LazyConstant<Logger> logger =
> 59:  *            // @link substring="of" target="#of" :
> 60:  *            LazyConstant.of( () -> Logger.create(Component.class) );

We had previously talked about whether the `Logger` example is a good one.

Personally I think it's a bad example if it encourages people to use loggers this way since:
* non static loggers aren't suitable to logging in static methods.
* The Logger framework has a perfectly functional mechanism for injecting static logger instances.
* Over-use of non-static logger instances pollutes internal APIs and ends up leaking a dependency on a specific logger instance, making refactoring hard.

src/java.base/share/classes/java/lang/LazyConstant.java line 66:

> 64:  *        // ...
> 65:  *    }
> 66:  * }

Arguably weird/wrong indents on closing '}' ?

src/java.base/share/classes/java/lang/LazyConstant.java line 241:

> 239: 
> 240:     /**
> 241:      * {@return if this lazy constant is the same as the provided {@code obj}}

Maybe say "is the same instance as ...", then you might be able to shorten the "In other words" paragraph below as they sort of say the same thing in almost the same words.

As a reader I'm more interested in *why* this slightly unexpected behaviour happens. Maybe a section in the class level docs, linked from here, explaining the issues with using the content for equals/hashCode would be better (that can also talk about lazy constants being mostly unsuitable as key types).

src/java.base/share/classes/java/lang/LazyConstant.java line 283:

> 281:      * <p>
> 282:      * The returned lazy constant strongly references the provided
> 283:      * {@code computingFunction} at least until initialization completes successfully.

As a reader I'm a bit nervous that I don't know if it will ever drop the function. Suppose my init relies on something chunky I want to be sure has gone away?

src/java.base/share/classes/java/nio/charset/Charset.java line 1:

> 1: /*

Side note: I'm slightly surprised to see the introduction and the usage happening in the same PR. Is this really being submitting in one go?

src/java.base/share/classes/java/nio/charset/Charset.java line 619:

> 617: 
> 618:     private static final LazyConstant<Charset> defaultCharset = LazyConstant.of(
> 619:             new Supplier<>() { public Charset get() { return defaultCharset0(); }});

Can these not be done with lambdas?

src/java.base/share/classes/java/util/List.java line 1210:

> 1208:      * invoked at most once per list index, even in a multi-threaded environment.
> 1209:      * Competing threads accessing an element already under computation will block until
> 1210:      * an element is computed or the computing function completes abnormally

Missing full-stop.

src/java.base/share/classes/java/util/List.java line 1238:

> 1236:      * <p>
> 1237:      * The returned lazy list strongly references its computing
> 1238:      * function used to compute elements at least so long as there are uninitialized

"at least so long as" sounds weird to me.

I think you would say either:
* "... at least *as* long as there are uninitialized elmements."
* "... so long as there are uninitialized elmements."

But you could always say:
* "... while there are uninitialized elements"

-------------

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3472336926
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533786705
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533801082
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533773546
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533830776
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533836397
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533841573
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533846906
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533855814
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533865784

From pminborg at openjdk.org  Mon Nov 17 13:34:30 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 13:34:30 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <TPGlt2Gs6iU1gFx4-rGsygrzjYi7apia359gMsJwlBM=.dc939a2c-cd23-491f-9961-2ca0e48cd3a0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
 <TPGlt2Gs6iU1gFx4-rGsygrzjYi7apia359gMsJwlBM=.dc939a2c-cd23-491f-9961-2ca0e48cd3a0@github.com>
Message-ID: <6LpdzFJhGUHodyEKeOMXvKH9nYsPhz7oDM6k4NpNsNE=.2f8b7bd1-2886-48b7-9f97-22b3b8ed7368@github.com>

On Mon, 17 Nov 2025 12:16:52 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 1:
> 
>> 1: /*
> 
> Side note: I'm slightly surprised to see the introduction and the usage happening in the same PR. Is this really being submitting in one go?

I've replaced `StableValue` with `LazyConstant`. So there is no new introduction, but just an adaptation.

> src/java.base/share/classes/java/nio/charset/Charset.java line 619:
> 
>> 617: 
>> 618:     private static final LazyConstant<Charset> defaultCharset = LazyConstant.of(
>> 619:             new Supplier<>() { public Charset get() { return defaultCharset0(); }});
> 
> Can these not be done with lambdas?

They can, but I wanted to keep it verbatim to the existing code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534085547
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534087249

From mli at openjdk.org  Mon Nov 17 13:35:15 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 17 Nov 2025 13:35:15 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v3]
In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
Message-ID: <woFBPoac1uz_szw8VuGTTZ_LUaCwcpHAGbBWeaD9YkU=.41d3f343-8242-45ee-b4ce-6250a6c10973@github.com>

> Hi,
> 
> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
> 
> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
> 
> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
> 
> # Test
> ## Jtreg
> 
> in progress...
> 
> ## Performance
> 
> Column names meanings:
> * p: with patch
> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> * m: without patch
> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> 
> #### Average improvement
> 
> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
> 
> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
> -- | -- | -- | --
> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
> 
> </google-sheets-html-origin>

Hamlin Li has updated the pull request incrementally with four additional commits since the last revision:

 - remove TestScalarConditionalMove.java
 - merge scalar and vector tests
 - rename to TestConditionalMove.java
 - add CMP_N

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28309/files
  - new: https://git.openjdk.org/jdk/pull/28309/files/5c0d645d..51451ab5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=01-02

  Stats: 10114 lines in 4 files changed: 3824 ins; 6290 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28309/head:pull/28309

PR: https://git.openjdk.org/jdk/pull/28309

From mli at openjdk.org  Mon Nov 17 13:35:17 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 17 Nov 2025 13:35:17 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v3]
In-Reply-To: <46DWeMiCRNMC58wGr4T52KXbtRjU0PxQ4L6LuVFMZEo=.867fcc86-edd1-4492-9c1a-58f83d135969@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <ck9qtvcIKfxaa47UNuAa2Vqu98FzFZoLDIsNIdsCthM=.14fca2ef-a4f2-48b0-9ae7-8492a02d6f46@github.com>
 <5PzMJntiu2waMvciTLvXaUH15Fm3dXZPsDVvkuqWPI0=.68c6456a-e5d3-413e-bef8-d8da95de40bd@github.com>
 <46DWeMiCRNMC58wGr4T52KXbtRjU0PxQ4L6LuVFMZEo=.867fcc86-edd1-4492-9c1a-58f83d135969@github.com>
Message-ID: <w6uiFh1DDm3yGLD0UAnUwD8I-H8dHFB25q6TSa0awVw=.f3f4d5d2-838b-4ab7-9f71-55d1186acfb8@github.com>

On Mon, 17 Nov 2025 07:27:30 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Make sense. I filed https://bugs.openjdk.org/browse/JDK-8371920 to track the task, will do it later after this pr.
>
> I would suggest that you already make the move from `@requires` to IR rule level restrictions. But we can look at adding `x64` and `aarch64` in the separate RFE.

Merge of scalar and vector tests is done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2534089875

From mli at openjdk.org  Mon Nov 17 13:42:18 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 17 Nov 2025 13:42:18 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <fGaaH4f7ZujpXZALIuQS4YcaZwKAm6PX4kf6mtkJDWE=.7a1ad9d4-c8bf-476d-bff6-194919c3fd81@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>
 <fGaaH4f7ZujpXZALIuQS4YcaZwKAm6PX4kf6mtkJDWE=.7a1ad9d4-c8bf-476d-bff6-194919c3fd81@github.com>
Message-ID: <o-rpi2-fDK76ZZHlXw8SGAYyDyjtx1Ai80vcvFDIjbQ=.a4b912e0-d345-4dc9-98a0-59a88ad1661a@github.com>

On Mon, 17 Nov 2025 06:37:15 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add CMove+CmpP/N tests
>>  - fix cmovF/D_cmpP
>
> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2133:
> 
>> 2131:       break;
>> 2132:     case BoolTest::ge:
>> 2133:       assert(false, "Should go to BoolTest::le case");
> 
> I am not sure if it's safe to have these assertions for `ge` and `gt`. It seems to me that we should handle all possible condition codes here. Check this bug: https://bugs.openjdk.org/browse/JDK-8358892. We have added handling for `ge` and `gt` in `C2_MacroAssembler::enc_cmove_cmp_fp` to fix it.

Make sense! Thanks!
I'll add the implementation for these condition codes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2534113207

From mli at openjdk.org  Mon Nov 17 13:42:20 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 17 Nov 2025 13:42:20 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v3]
In-Reply-To: <sHMOrlg1c8zjr5UuI64P9KnJ6Dtk4k-a_5jsLoMsWKo=.4e78c6f0-aee3-4433-baae-4c6777035372@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <ck9qtvcIKfxaa47UNuAa2Vqu98FzFZoLDIsNIdsCthM=.14fca2ef-a4f2-48b0-9ae7-8492a02d6f46@github.com>
 <5PzMJntiu2waMvciTLvXaUH15Fm3dXZPsDVvkuqWPI0=.68c6456a-e5d3-413e-bef8-d8da95de40bd@github.com>
 <sHMOrlg1c8zjr5UuI64P9KnJ6Dtk4k-a_5jsLoMsWKo=.4e78c6f0-aee3-4433-baae-4c6777035372@github.com>
Message-ID: <0aUmOv2i1H2WJDoQV1Uirgof7C42vvPSyY73giIsKcs=.ad6b18f6-36c4-46fc-b26d-dec8d519c535@github.com>

On Mon, 17 Nov 2025 07:43:02 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Good idea!
>> I can do it. What do you think about the name of the merged tests? `TestConditionalMove.java` or `TestScalarAndVectorConditionalMove.java`
>
> `TestConditionalMove.java` sounds good :)
> 
> It would also be nice if we could move it out of the `irTests` directory, we would like to eventually move all tests away from it, and rather sort the tests by what they test and not by how we test them. Though now it's a little tricky because we check for both vector and scalar things. Still, I would propose that you move it under `c2/vectorization` or `c2/loopopts/superword`, since they do include vectorization tests. An alternative could also be in a new `c2/cmove` directory.

I can do the move for this specific file at the last commit of this pr. Or we can move a bunch of tests (some other tests under irTests) in a separate pr, as there are `Asserts` in other tests under `irTests`. I prefer the latter one, as it put related changes in one specific pr. Plesae let me know how you think about it. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2534108304

From syan at openjdk.org  Mon Nov 17 13:52:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 13:52:02 GMT
Subject: RFR: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java [v2]
In-Reply-To: <WkeD_U5X_KG_r1MePzvBtuhRSM76soP9DxyZRQMXjd0=.966fa8fe-d959-4002-a00f-588b8ca800e4@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
 <WkeD_U5X_KG_r1MePzvBtuhRSM76soP9DxyZRQMXjd0=.966fa8fe-d959-4002-a00f-588b8ca800e4@github.com>
Message-ID: <e7iRZazieQ86t2HX2Cl97x-vCe2T39UMvlPVgO4ANig=.78afa463-2aa2-4247-ad76-a8a6bce412b6@github.com>

On Mon, 17 Nov 2025 04:38:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> In JDK 11, ThreadPoolExecutor.finalize() was specified to do nothing, leaving the finalize() method empty by [JDK-8371748](https://bugs.openjdk.org/browse/JDK-8371748), so I think it's safety to remove finalize() in testFinalizeMethodCallsSuperFinalize for test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java.
>> 
>> This PR also remove unnecessary '@SuppressWarnings("removal")' in test/jdk/java/util/concurrent/tck/JSR166TestCase.java and test/jdk/java/util/concurrent/tck/ExecutorsTest.java.
>> 
>> Change has been verified locally on linux-x64 by run test java/util/concurrent/tck/JSR166TestCase.java#default. Test-fix only, no risk,
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove testFinalizeMethodCallsSuperFinalize

Besides remove the testFinalizeMethodCallsSuperFinalize, this PR also remove two unnecessary '@SuppressWarnings("removal")'. So I think it's suitable integrate this PR standalone before https://github.com/openjdk/jdk/pull/28311.

Thanks all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28278#issuecomment-3541921000

From syan at openjdk.org  Mon Nov 17 13:52:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 13:52:03 GMT
Subject: Integrated: 8371682: Suppress javac warning from
 ThreadPoolExecutorSubclassTest.java
In-Reply-To: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
References: <cZxC6i7gTHFvfd040lMSyT3FVoZqksuWoFJ1KCTrrT4=.7e533d41-a53c-4009-8a93-cb07014e769a@github.com>
Message-ID: <jKOFEJLFSGMrdcRj1RFTT1Ejem_7ms2YNKg0Apand-U=.258ae010-7d7d-4237-9bb4-0fda1f2a19ed@github.com>

On Thu, 13 Nov 2025 02:31:31 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> In JDK 11, ThreadPoolExecutor.finalize() was specified to do nothing, leaving the finalize() method empty by [JDK-8371748](https://bugs.openjdk.org/browse/JDK-8371748), so I think it's safety to remove finalize() in testFinalizeMethodCallsSuperFinalize for test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java.
> 
> This PR also remove unnecessary '@SuppressWarnings("removal")' in test/jdk/java/util/concurrent/tck/JSR166TestCase.java and test/jdk/java/util/concurrent/tck/ExecutorsTest.java.
> 
> Change has been verified locally on linux-x64 by run test java/util/concurrent/tck/JSR166TestCase.java#default. Test-fix only, no risk,

This pull request has now been integrated.

Changeset: 44087ea5
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44087ea5d697deb3a7dd0e3c82f898dd9df1bfa3
Stats:     17 lines in 3 files changed: 0 ins; 17 del; 0 mod

8371682: Suppress javac warning from ThreadPoolExecutorSubclassTest.java

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/28278

From syan at openjdk.org  Mon Nov 17 13:52:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 13:52:46 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <PR9ANUi7n23h8pl0rPRa3m45QLAztZlpeBTyUAeQ4QQ=.4b787b72-bea2-4f62-9d60-9a24e4f84125@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
 <PR9ANUi7n23h8pl0rPRa3m45QLAztZlpeBTyUAeQ4QQ=.4b787b72-bea2-4f62-9d60-9a24e4f84125@github.com>
Message-ID: <Gj36qTR4zsiczSF3CS9ZOXNiZ9tdZgNrqEI80XncivM=.0932f4bc-26ad-4e0e-86c2-90148253501c@github.com>

On Fri, 14 Nov 2025 19:39:47 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> From the bug report:
>> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to
>> "[invoke] shutdown() when this executor is no longer referenced and it has no threads."
>> 
>> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)).
>> 
>> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)).
>> 
>> The finalize() method can safely be removed from ThreadPoolExecutor.
>
> Thank you, reviewers. :)
> Can I also get a review on the [CSR](https://bugs.openjdk.org/browse/JDK-8371856)? TIA.

@bchristi-git I have integrated https://github.com/openjdk/jdk/pull/28278, I think you should merge the master to fix the GHA test failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3541925754

From davidalayachew at gmail.com  Mon Nov 17 14:08:41 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 17 Nov 2025 09:08:41 -0500
Subject: Sharing more of my experience with a custom Gatherer (windowBy)
Message-ID: <CAA9v-_NMTq_v=-i=wFA=n7DMT7T02cwU_MwjnzgkdVj2ZZUUTA@mail.gmail.com>

Hello @core-libs-dev <core-libs-dev at openjdk.org>,

This is a follow up of one of my previous experience reports, a little over
a year ago.

https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127293.html

Just wanted to report more of my positive experiences with Gatherers,
specifically with a custom Gatherer that @Viktor Klang
<viktor.klang at oracle.com> made for me called windowBy. Here is the
implementation below.

<TR> Gatherer<TR, ?, List<TR>> windowBy(Predicate<TR>
includeInCurrentWindow) {
    class State {
        ArrayList<TR> window;

        boolean integrate(TR element, Gatherer.Downstream<? super List<TR>>
downstream) {
            if (window != null && !includeInCurrentWindow.test(element)) {
                var result = Collections.unmodifiableList(window);
                window = null;
                if (!downstream.push(result))
                    return false;
            }

            if (window == null)
                window = new ArrayList<>();

            return window.add(element);
        }

        void finish(Gatherer.Downstream<? super List<TR>> downstream) {
            if (window != null) {
                var result = Collections.unmodifiableList(window);
                window = null;
                downstream.push(result);
            }
        }
    }
    return Gatherer.<TR, State, List<TR>>ofSequential(State::new,
State::integrate, State::finish);
}

Clean and simple.

Anyways, as for my experience report, a found a brand new way to use this
custom Gatherer -- event coalescing.

Sometimes, if consecutive events being streamed are of the same type, then
to reduce computation, you might be able to avoid doing more work by
grouping together the potential duplicates, then handling them separately
in a coalescing path. I'd much rather solve that problem than a caching
problem lol.

Anyways, here are the 2 examples where it served me well.


   1. Network Request Coalescing.
      1. When checking the availability of certain networks, I am now able
      to save some bandwidth by combining multiple, consecutive
requests within a
      certain time to a certain network. And since I am definitely bandwidth
      bound, that helps. Nothing I couldn't do before, but keeping it within
      Streams allowed me to avoid ripping out my old solution when it stopped
      being a good fit. I wish I could share the code, but it's not my right to
      share it.
   2. Path-Finding Algorithm -- Clustering
      1. This one is still a work in progress, so I may be speaking
      prematurely here. But I was so impressed that this is working thus far.
      Long story short, I am building a path-finding algorithm where,
if a set of
      points are close enough together, then they can be serviced as a
group, and
      thus, lower the total weight of servicing those nodes, as opposed to
      servicing them individually. Again, not done yet, so I might be
jumping the
      gun, but it worked so well for me out of the box, that I thought it was
      worth sharing.

Hopefully this bumps up windowBy on the triage list of potential pre-built
gatherers to add to the standard library. And thanks again to Viktor and
friends for putting this Gatherers library together -- it's a great
addition!

Thank you all for your time and consideration!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251117/48cdc087/attachment-0001.htm>

From daniel.peintner at gmail.com  Mon Nov 17 14:09:30 2025
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Mon, 17 Nov 2025 15:09:30 +0100
Subject: [External] : Re: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <1c56649f-91f9-4421-a3d7-9c8c57189927@oracle.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
 <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
 <CAAoP7T7XG_zWj0GSM37oMMvPq=NJ300Aac9skq8erXjYzqvmqw@mail.gmail.com>
 <98fc3c7c-d485-487b-9ab5-f4257c40cacf@oracle.com>
 <CAAoP7T5PfnKaF6XFGaUcrBSUxQ58=eOKwSLkj+4rVPdQOL-FTQ@mail.gmail.com>
 <7aa147c9-108e-4194-be46-84399000578a@oracle.com>
 <CAAoP7T5RubQqdUGuH9M-sYZVMzA0j8mx2Kd2kHbVDeBzLMXhYg@mail.gmail.com>
 <1c56649f-91f9-4421-a3d7-9c8c57189927@oracle.com>
Message-ID: <CAAoP7T6cWDG3Nam=vNUL2pZ7nVRB7B6iKoQLUZA4EMd93N7PaQ@mail.gmail.com>

Hi Alexey,

Sorry for the late reply (I was inactive the last couple of days).

I feel free to comment w.r.t. the 2 issues which seem related

> [1] https://bugs.openjdk.org/browse/JDK-8371438

To me, it seems best to go with Option 2, which would make
"--mac-sign" option redundant.
* Using "--mac-sign" with other options could inform about redundant option
* Using "--mac-sign" option only should throw error

I have to admit, the *old* behavior was very handy ?

> [2] https://bugs.openjdk.org/browse/JDK-8371440

Error instead of warning makes sense to me ?

Both changes make the jpackage process very explicit and clear.

Thanks,

-- Daniel


>
> - Alexey
>
> On 11/6/2025 5:51 AM, Daniel Peintner wrote:
>
> Alexey, all,
>
> Thank you very much for your help.
> I still have issues making it to work, and I shared logs privately.
>
> Anyhow, some general comments/suggestions.
>
> You are right, with JDK21 it was enough to state  "--mac-sign"option, and it picked the (only/correct) certificate (in my case).
>
> As I understand, with JDK25 this is no longer the case. I don't want to argue whether the *old* or *new* way is preferred. However, it is a breaking change.
> Hence, what I may suggest, though, is that it throw errors if the expected information (i.e.,  "--mac-signing-key-user-name") is missing. Otherwise, a developer doesn't know that there is a problem.
>
> The same goes to situations when it is not unique which certificate to pick. You pointed me to [1] which fixes the problem that I can find the certificate with *partial* information without the need to specify the full --mac-signing-key-user-name.
> In situations where there are more matches, I would argue the process should fail again with an error message hinting the problem (e.g., certificate not uniquely identifiable). Looking at [2] I don't think this is the case.
>
> Thank you very much for your continuous support!
>
> -- Daniel
>
> [1] https://bugs.openjdk.org/browse/JDK-8371094
> [2] https://github.com/openjdk/jdk/commit/0555f6228c59c6739b8b824d64eb6c1545a5520a
>
>
>
> On Wed, Nov 5, 2025 at 7:31?PM Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
>>
>> Daniel,
>>
>> I've commented on the logs you shared privately. Adding some thoughts to the mail list.
>>
>> jpackage configuration at [1] is missing "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option. I noted it the private email as well.
>> At first I assumed it was a mistake, but then I came across an old thread about the very same jpackage issue at [2] where you state that "--mac-sign" option is sufficient to make jpackage find the signing identity. So this is intentional.
>>
>> jdk25 jpackage will not look up for the signing identity unless "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option is specified. I'm surprised it did in older releases.
>>
>> For the sake of backward compatibility we can restore this behavior. But I think jpackage should exit with an error if the "--mac-sign" option is specified, but neither "--mac-signing-key-user-name" nor "--mac-app-image-sign-identity" is. The old behavior, when without these options jpackage picked the first available certificate with the common name starting with "Developer ID Application: " substring is not secure. It literally tells jpackage to pick any certificate without any filtering. If there is only one such certificate installed and it gets replaced, you will not even notice that your app is signed with a different certificate.
>>
>> I suggest you add "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option to jpackage command line at [1] to make it work.
>>
>> [1] https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151
>> [2] https://mail.openjdk.org/pipermail/core-libs-dev/2021-August/080291.html
>>
>> - Alexey
>>
>> On 11/5/2025 4:16 AM, Daniel Peintner wrote:
>>
>> Hi Alexey,
>>
>> Thank you for your reply.
>>
>>> Does the warning message resembles the one at [1]?
>>
>>
>> Yes, exactly.
>>
>>>
>>> I think your evaluation that the step 1 failed is correct. I'd suggest adding "--verbose" option to the step 1 command line to get more details.
>>
>>
>> I updated a demo/test project to demonstrate the problem. You can now also try it yourself.
>> https://github.com/danielpeintner/Java11Test/tree/non-modular
>>
>> There you can also find the 3 jpackage commands I use
>> https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151
>>
>> W.r.t. sharing the logs file. I will send them to you *privately*. I quickly scanned them and I would rather not have them on the reflector.
>>
>> The weird thing is, that the difference seems to happen in step 1. Anyhow, running these commands the difference is also somehow in step 2 where
>> * JDK21 makes popping up a dialog which asks me whether I want to allow access to my keys
>> * JDK25 does not need any interaction
>>
>> I hope this helps to find the "difference".
>>
>> Thanks,
>>
>> -- Daniel
>>
>>
>>
>>
>>>
>>>
>>> [1] https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties#L85
>>>
>>> - Alexey
>>>
>>> On 11/4/2025 12:32 PM, Daniel Peintner wrote:
>>>
>>> Hi Alexey, all,
>>>
>>> I nailed down the problem to the following, which seems to differ between JDK25 and JDK21.
>>> Maybe this helps to reproduce the issue.
>>>
>>> jpackage is called 3 times in my process
>>>
>>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage --type app-image --input /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib --main-jar myPROJECT-25.11.03.jar --main-class eu.my_company.myproject.Launcher --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT --app-version 25.11.03 --runtime-image /Users/daniel/Documents/GitHub/myPROJECT/build/jre --java-options --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED --java-options --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED --java-options --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED --java-options --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED --java-options --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED --java-options --add-exports=java.management/javax.management=ALL-UNNAMED --java-options --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED --java-options --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED --icon src/main/deploy/package/macosx/myPROJECT.icns --mac-package-identifier eu.my-company.myproject --mac-sign
>>>
>>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage --type pkg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT --app-version 25.11.03 --app-image /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app --file-associations src/main/resources/associations.properties --app-version 25.11.03 --vendor "My Company" --copyright "My Company" --mac-sign
>>>
>>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage --type dmg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT --app-version 25.11.03 --app-image /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app --file-associations src/main/resources/associations.properties --app-version 25.11.03 --vendor "My Company" --copyright "My Company" --mac-sign
>>>
>>>
>>> First it creates the app-image and afterwards it creates pkg and dmg and signs it.
>>>
>>> As you can see in the 3 commands, it uses JDK21.
>>> Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after step 2 already with the following message in German
>>>
>>> Warnung: Nicht signiertes app-image wird zum Erstellen von signiertem pkg verwendet.
>>>
>>> It translates to something like: it tries to sign pkg and complains that the app-image is not signed.
>>> Hence, somehow step 1 failed already but does not show any error/warning.
>>>
>>> Please let me know whether the above helps to reproduce the issue.
>>>
>>> Thanks,
>>>
>>> -- Daniel
>>>
>>>
>>>
>>> On Tue, Nov 4, 2025 at 4:01?PM Daniel Peintner <daniel.peintner at gmail.com> wrote:
>>>>
>>>> Hi Alexey,
>>>>
>>>> Thank you for your reply.
>>>> I am using the badass runtime plugin which calls jpackage under the hood.
>>>>
>>>> While trying to create an example project, I noticed that there were some changes
>>>> '--mac-package-identifier' needs to go into imageOptions and not installerOptions.
>>>> see https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385
>>>>
>>>> That fixed the problem with jpackage. Anyhow, it still does not work with JDK25 and macOS signing.
>>>> Using the JDK25 seems to need additional options (compared to JDK21).
>>>>
>>>> With JDK25 and --mac-sign the process no longer opens the KeyChain access and asks for the credentials. Hence, the image itself is no longer signed which matches with what I see on the debug console
>>>> "non signed app-image used to sign dmg"  ... freely translated into English since I see the German version only
>>>>
>>>> Therefore, apple's notary service says invalid with the logs like "The binary is not signed with a valid Developer ID certificate".
>>>>
>>>> Using the *same* gradle file, switching to JDK21 works without any issues again.
>>>> I will try to investigate further.
>>>>
>>>> Thanks,
>>>>
>>>> -- Daniel
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
>>>>>
>>>>> Hi Daniel,
>>>>>
>>>>> I can not reproduce the issue you experience with jdk25.0.1:
>>>>>
>>>>> ---
>>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output --type app-image --main-jar hello.jar --main-class com.my_domain.project.Hello --mac-package-identifier com.my-domain.project
>>>>> $ echo $?
>>>>> 0
>>>>> ---
>>>>>
>>>>> If I run the same command line without ` --mac-package-identifier` option it fails as expected:
>>>>> ---
>>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output --type app-image --main-jar hello.jar --main-class com.my_domain.project.Hello
>>>>> Bundler Mac Application Image skipped because of a configuration problem: invalid mac bundle identifier [com.my_domain.project].
>>>>> Advice to fix: specify identifier with "--mac-package-identifier".
>>>>> ---
>>>>>
>>>>> The same failure for `--mac-package-identifier com.my_domain.project` (with the underscore):
>>>>> ---
>>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output --type app-image --main-jar hello.jar --main-class com.my_domain.project.Hello --mac-package-identifier com.my_domain.project
>>>>> Bundler Mac Application Image skipped because of a configuration problem: invalid mac bundle identifier [com.my_domain.project].
>>>>> Advice to fix: specify identifier with "--mac-package-identifier".
>>>>> ---
>>>>>
>>>>> Any chance you accidentally put the string with the underscore instead of the hyphen as a value of the `--mac-package-identifier` option on your command line?
>>>>>
>>>>> - Alexey
>>>>>
>>>>> On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am about to switch a JavaFX project from JDK21 to JDK25 and I noticed a problem when running jpackage.
>>>>>
>>>>> My domain has a hyphen, like in www.my-domain.com
>>>>> Hence, my Java package reads like this: com.my_domain.project
>>>>> Note: hyphen becomes underscore.
>>>>>
>>>>> Running vanilla jpackage in JDK21 complained with
>>>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>>>> due to the *invalid* underscore and suggests me to use "--mac-package-identifier"
>>>>>
>>>>> Hence, I added --mac-package-identifier com.my-domain.project (with the hyphen again)
>>>>> All good so far.
>>>>>
>>>>> Running the same code with JDK25 with the above settings shows the error message again
>>>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>>>>
>>>>> I can add any argument to  --mac-package-identifier
>>>>> It seems it is simply not taken into account.
>>>>>
>>>>> I am using JDK 25.0.1
>>>>>
>>>>> Is this a known issue with JDK25 and jpackage?
>>>>> Is there any other way to make jpackage work?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -- Daniel
>>>>>
>>>>>
>>>>>
>>>
>>
>

From rriggs at openjdk.org  Mon Nov 17 14:45:14 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Nov 2025 14:45:14 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v24]
In-Reply-To: <-YApwwtJ8DmPFiKl28zZcP6HUG3fHpV-Llaw0j-nUS0=.84263959-31f1-4fa7-af02-54830d3060d2@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <9wkLz_EcOnSMn-PwvZVYvwEbh3j0BqPqR_PgMvKwDkM=.f709c870-e48f-4be7-b3e5-f02edadfdc29@github.com>
 <-YApwwtJ8DmPFiKl28zZcP6HUG3fHpV-Llaw0j-nUS0=.84263959-31f1-4fa7-af02-54830d3060d2@github.com>
Message-ID: <iQQfWIwaHpaY6OZVC9WaOTQkfdXUQrxZKei-BuDLSoc=.37cc96fb-46de-4a96-ace7-444dffbf46cd@github.com>

On Fri, 14 Nov 2025 15:50:09 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The `DecimalDigits.appendPair` and `appendQuad` methods will experience performance degradation if a `StringBuilder` with `Encoding UTF16` is passed to them. This occurs when `DecimalDigits.appendPair` or `appendQuad` is used in `DateTimeFormatter::formatTo`.

Adding single purpose functions to Java Lang Access is not worth the added complexity and maintenance cost.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3542204264

From rriggs at openjdk.org  Mon Nov 17 14:50:19 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Nov 2025 14:50:19 GMT
Subject: RFR: 8371732: [redo] Change java.time month/day field types to
 'byte' [v2]
In-Reply-To: <ax8qXZEhKiwzmZVIi4eElP0EK5uhGzGkpbB-O0_c3D8=.4df11800-cd6f-412d-b098-912e649d1cde@github.com>
References: <FGdisi_MwsfuEFwDSN94dI_vE0AZAxQu-VhvHZiRwlI=.2872e0fc-0c03-47fc-9b42-5538ea922503@github.com>
 <ax8qXZEhKiwzmZVIi4eElP0EK5uhGzGkpbB-O0_c3D8=.4df11800-cd6f-412d-b098-912e649d1cde@github.com>
Message-ID: <nJP6QMRDU3vfPWRtnSbXIJfMw-kyFT5abtKjEywmYdE=.ed6e036c-e516-4c67-92d5-7184476f2190@github.com>

On Fri, 14 Nov 2025 20:15:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Redo change (8371732) that failed when the updated class objects were incompatible.
>> The fields of classes are changed to allow a more compact form of storage.
>> 
>> To ensure compatibility of the class objects, the fields are explicitly declared in SerialPersistentFields with the original field types.
>> The fields are marked `transient` to indicate the field declarations are not used for serialization.
>> The affected classes are java.time.LocalDate, MonthDay, and YearMonth.
>> Tests are added to verify the types and names of serialized fields of each class.
>> 
>> HijrahDate only changes the field types, the fields are transient and there is no change to the serialized from of the HijrahDate.class object.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "Java SE 8" instead of version 1.8

Using transient everywhere should have been the preferred solution but compatibility wins any argument at this point.
The actual serialized form is defined by the combination of writeReplace and readResolve and its documentation.
The other doc/spec is just for documentation. if/when other classes are changed, similar care will be needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28274#issuecomment-3542251560

From jvernee at openjdk.org  Mon Nov 17 15:06:00 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 15:06:00 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v4]
In-Reply-To: <OUMDlAzMnr9FL9zIpSYc4FTkoh8amuHiMlMYde6YD0E=.f04784a8-f89b-4c4d-9279-5fec912afa18@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <OUMDlAzMnr9FL9zIpSYc4FTkoh8amuHiMlMYde6YD0E=.f04784a8-f89b-4c4d-9279-5fec912afa18@github.com>
Message-ID: <E96tnkoiFCwdMNhtE4Qjmm_kRoJq-brdiqfTvjuke9E=.d61d6540-1583-4766-bc40-c1590b2f480d@github.com>

On Sun, 16 Nov 2025 18:09:47 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix calculation of allocationSize when byteAlignment < MAX_MALLOC_ALIGN
>   
>   This work was sponsored by: The FreeBSD Foundation

src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 207:

> 205:         long result;
> 206:         if (byteAlignment > MAX_MALLOC_ALIGN || alignedSize % byteAlignment != 0) {
> 207:             allocationSize = alignedSize + byteAlignment - Math.min(MAX_MALLOC_ALIGN, alignedSize);

This doesn't look correct to me. Let's say we want to do a 7 byte allocation (with `init == false`), aligned to 4. We get `7 % 4 -> 3` so we enter this branch, and then `allocationSize = 7 + 4 - 7`, and we end up allocating only 4 bytes. The previous computation only works if `MAX_MALLOC_ALIGN` is greater than `byteAlignment`.

I think it's simpler to just replace `MAX_MALLOC_ALIGN` in this `if` statement with an 'expected alignment' derived from the size.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2534441590

From alexey.semenyuk at oracle.com  Mon Nov 17 15:29:29 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 17 Nov 2025 10:29:29 -0500
Subject: [External] : Re: [jpackage] JDK25 no longer takes into account
 --mac-package-identifier
In-Reply-To: <CAAoP7T6cWDG3Nam=vNUL2pZ7nVRB7B6iKoQLUZA4EMd93N7PaQ@mail.gmail.com>
References: <CAAoP7T6T=9Zjnghb39K9S5+s1yzySVnHXqPUMbBaQZBzWOdQ1Q@mail.gmail.com>
 <6184b277-b030-4300-a319-81764ecac698@oracle.com>
 <CAAoP7T7cQa8j20p_-Ft+64AHz0zEXe1_Os+h0g405dtaxCRFkQ@mail.gmail.com>
 <CAAoP7T7XG_zWj0GSM37oMMvPq=NJ300Aac9skq8erXjYzqvmqw@mail.gmail.com>
 <98fc3c7c-d485-487b-9ab5-f4257c40cacf@oracle.com>
 <CAAoP7T5PfnKaF6XFGaUcrBSUxQ58=eOKwSLkj+4rVPdQOL-FTQ@mail.gmail.com>
 <7aa147c9-108e-4194-be46-84399000578a@oracle.com>
 <CAAoP7T5RubQqdUGuH9M-sYZVMzA0j8mx2Kd2kHbVDeBzLMXhYg@mail.gmail.com>
 <1c56649f-91f9-4421-a3d7-9c8c57189927@oracle.com>
 <CAAoP7T6cWDG3Nam=vNUL2pZ7nVRB7B6iKoQLUZA4EMd93N7PaQ@mail.gmail.com>
Message-ID: <ec4aaa2c-5cea-443a-81b2-3d815e9ff5dc@oracle.com>

Hi Daniel,

Thank you for your input! I've recorded your preference in the comment 
of the JDK-8371438 CR.

- Alexey

On 11/17/2025 9:09 AM, Daniel Peintner wrote:
> Hi Alexey,
>
> Sorry for the late reply (I was inactive the last couple of days).
>
> I feel free to comment w.r.t. the 2 issues which seem related
>
>> [1] https://bugs.openjdk.org/browse/JDK-8371438
> To me, it seems best to go with Option 2, which would make
> "--mac-sign" option redundant.
> * Using "--mac-sign" with other options could inform about redundant option
> * Using "--mac-sign" option only should throw error
>
> I have to admit, the *old* behavior was very handy ?
>
>> [2] https://bugs.openjdk.org/browse/JDK-8371440
> Error instead of warning makes sense to me ?
>
> Both changes make the jpackage process very explicit and clear.
>
> Thanks,
>
> -- Daniel
>
>
>> - Alexey
>>
>> On 11/6/2025 5:51 AM, Daniel Peintner wrote:
>>
>> Alexey, all,
>>
>> Thank you very much for your help.
>> I still have issues making it to work, and I shared logs privately.
>>
>> Anyhow, some general comments/suggestions.
>>
>> You are right, with JDK21 it was enough to state  "--mac-sign"option, and it picked the (only/correct) certificate (in my case).
>>
>> As I understand, with JDK25 this is no longer the case. I don't want to argue whether the *old* or *new* way is preferred. However, it is a breaking change.
>> Hence, what I may suggest, though, is that it throw errors if the expected information (i.e.,  "--mac-signing-key-user-name") is missing. Otherwise, a developer doesn't know that there is a problem.
>>
>> The same goes to situations when it is not unique which certificate to pick. You pointed me to [1] which fixes the problem that I can find the certificate with *partial* information without the need to specify the full --mac-signing-key-user-name.
>> In situations where there are more matches, I would argue the process should fail again with an error message hinting the problem (e.g., certificate not uniquely identifiable). Looking at [2] I don't think this is the case.
>>
>> Thank you very much for your continuous support!
>>
>> -- Daniel
>>
>> [1] https://bugs.openjdk.org/browse/JDK-8371094
>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/0555f6228c59c6739b8b824d64eb6c1545a5520a__;!!ACWV5N9M2RV99hQ!PJkRdYKqwvx3DpbGU7Vs7_nfA_KLAZB2TvQiF8kdh2Hcyc_rGP8CVybD7gIyYwr87rlWIBRU4T4TGWmpTV7qNnmWHOsYnII$
>>
>>
>>
>> On Wed, Nov 5, 2025 at 7:31?PM Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
>>> Daniel,
>>>
>>> I've commented on the logs you shared privately. Adding some thoughts to the mail list.
>>>
>>> jpackage configuration at [1] is missing "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option. I noted it the private email as well.
>>> At first I assumed it was a mistake, but then I came across an old thread about the very same jpackage issue at [2] where you state that "--mac-sign" option is sufficient to make jpackage find the signing identity. So this is intentional.
>>>
>>> jdk25 jpackage will not look up for the signing identity unless "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option is specified. I'm surprised it did in older releases.
>>>
>>> For the sake of backward compatibility we can restore this behavior. But I think jpackage should exit with an error if the "--mac-sign" option is specified, but neither "--mac-signing-key-user-name" nor "--mac-app-image-sign-identity" is. The old behavior, when without these options jpackage picked the first available certificate with the common name starting with "Developer ID Application: " substring is not secure. It literally tells jpackage to pick any certificate without any filtering. If there is only one such certificate installed and it gets replaced, you will not even notice that your app is signed with a different certificate.
>>>
>>> I suggest you add "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option to jpackage command line at [1] to make it work.
>>>
>>> [1] https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle*L148-L151__;Iw!!ACWV5N9M2RV99hQ!PJkRdYKqwvx3DpbGU7Vs7_nfA_KLAZB2TvQiF8kdh2Hcyc_rGP8CVybD7gIyYwr87rlWIBRU4T4TGWmpTV7qNnmWIrChN4Q$
>>> [2] https://mail.openjdk.org/pipermail/core-libs-dev/2021-August/080291.html
>>>
>>> - Alexey
>>>
>>> On 11/5/2025 4:16 AM, Daniel Peintner wrote:
>>>
>>> Hi Alexey,
>>>
>>> Thank you for your reply.
>>>
>>>> Does the warning message resembles the one at [1]?
>>>
>>> Yes, exactly.
>>>
>>>> I think your evaluation that the step 1 failed is correct. I'd suggest adding "--verbose" option to the step 1 command line to get more details.
>>>
>>> I updated a demo/test project to demonstrate the problem. You can now also try it yourself.
>>> https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!PJkRdYKqwvx3DpbGU7Vs7_nfA_KLAZB2TvQiF8kdh2Hcyc_rGP8CVybD7gIyYwr87rlWIBRU4T4TGWmpTV7qNnmW4l8hSl8$
>>>
>>> There you can also find the 3 jpackage commands I use
>>> https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle*L148-L151__;Iw!!ACWV5N9M2RV99hQ!PJkRdYKqwvx3DpbGU7Vs7_nfA_KLAZB2TvQiF8kdh2Hcyc_rGP8CVybD7gIyYwr87rlWIBRU4T4TGWmpTV7qNnmWIrChN4Q$
>>>
>>> W.r.t. sharing the logs file. I will send them to you *privately*. I quickly scanned them and I would rather not have them on the reflector.
>>>
>>> The weird thing is, that the difference seems to happen in step 1. Anyhow, running these commands the difference is also somehow in step 2 where
>>> * JDK21 makes popping up a dialog which asks me whether I want to allow access to my keys
>>> * JDK25 does not need any interaction
>>>
>>> I hope this helps to find the "difference".
>>>
>>> Thanks,
>>>
>>> -- Daniel
>>>
>>>
>>>
>>>
>>>>
>>>> [1] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties*L85__;Iw!!ACWV5N9M2RV99hQ!PJkRdYKqwvx3DpbGU7Vs7_nfA_KLAZB2TvQiF8kdh2Hcyc_rGP8CVybD7gIyYwr87rlWIBRU4T4TGWmpTV7qNnmWK1ot-C4$
>>>>
>>>> - Alexey
>>>>
>>>> On 11/4/2025 12:32 PM, Daniel Peintner wrote:
>>>>
>>>> Hi Alexey, all,
>>>>
>>>> I nailed down the problem to the following, which seems to differ between JDK25 and JDK21.
>>>> Maybe this helps to reproduce the issue.
>>>>
>>>> jpackage is called 3 times in my process
>>>>
>>>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage --type app-image --input /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib --main-jar myPROJECT-25.11.03.jar --main-class eu.my_company.myproject.Launcher --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT --app-version 25.11.03 --runtime-image /Users/daniel/Documents/GitHub/myPROJECT/build/jre --java-options --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED --java-options --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED --java-options --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED --java-options --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED --java-options --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED --java-options --add-exports=java.management/javax.management=ALL-UNNAMED --java-options --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED --java-options --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED --icon src/main/deploy/package/macosx/myPROJECT.icns --mac-package-identifier eu.my-company.myproject --mac-sign
>>>>
>>>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage --type pkg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT --app-version 25.11.03 --app-image /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app --file-associations src/main/resources/associations.properties --app-version 25.11.03 --vendor "My Company" --copyright "My Company" --mac-sign
>>>>
>>>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage --type dmg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT --app-version 25.11.03 --app-image /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app --file-associations src/main/resources/associations.properties --app-version 25.11.03 --vendor "My Company" --copyright "My Company" --mac-sign
>>>>
>>>>
>>>> First it creates the app-image and afterwards it creates pkg and dmg and signs it.
>>>>
>>>> As you can see in the 3 commands, it uses JDK21.
>>>> Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after step 2 already with the following message in German
>>>>
>>>> Warnung: Nicht signiertes app-image wird zum Erstellen von signiertem pkg verwendet.
>>>>
>>>> It translates to something like: it tries to sign pkg and complains that the app-image is not signed.
>>>> Hence, somehow step 1 failed already but does not show any error/warning.
>>>>
>>>> Please let me know whether the above helps to reproduce the issue.
>>>>
>>>> Thanks,
>>>>
>>>> -- Daniel
>>>>
>>>>
>>>>
>>>> On Tue, Nov 4, 2025 at 4:01?PM Daniel Peintner <daniel.peintner at gmail.com> wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> Thank you for your reply.
>>>>> I am using the badass runtime plugin which calls jpackage under the hood.
>>>>>
>>>>> While trying to create an example project, I noticed that there were some changes
>>>>> '--mac-package-identifier' needs to go into imageOptions and not installerOptions.
>>>>> see https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385__;!!ACWV5N9M2RV99hQ!PJkRdYKqwvx3DpbGU7Vs7_nfA_KLAZB2TvQiF8kdh2Hcyc_rGP8CVybD7gIyYwr87rlWIBRU4T4TGWmpTV7qNnmWRawqBnA$
>>>>>
>>>>> That fixed the problem with jpackage. Anyhow, it still does not work with JDK25 and macOS signing.
>>>>> Using the JDK25 seems to need additional options (compared to JDK21).
>>>>>
>>>>> With JDK25 and --mac-sign the process no longer opens the KeyChain access and asks for the credentials. Hence, the image itself is no longer signed which matches with what I see on the debug console
>>>>> "non signed app-image used to sign dmg"  ... freely translated into English since I see the German version only
>>>>>
>>>>> Therefore, apple's notary service says invalid with the logs like "The binary is not signed with a valid Developer ID certificate".
>>>>>
>>>>> Using the *same* gradle file, switching to JDK21 works without any issues again.
>>>>> I will try to investigate further.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -- Daniel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 3, 2025 at 7:30?PM Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
>>>>>> Hi Daniel,
>>>>>>
>>>>>> I can not reproduce the issue you experience with jdk25.0.1:
>>>>>>
>>>>>> ---
>>>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output --type app-image --main-jar hello.jar --main-class com.my_domain.project.Hello --mac-package-identifier com.my-domain.project
>>>>>> $ echo $?
>>>>>> 0
>>>>>> ---
>>>>>>
>>>>>> If I run the same command line without ` --mac-package-identifier` option it fails as expected:
>>>>>> ---
>>>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output --type app-image --main-jar hello.jar --main-class com.my_domain.project.Hello
>>>>>> Bundler Mac Application Image skipped because of a configuration problem: invalid mac bundle identifier [com.my_domain.project].
>>>>>> Advice to fix: specify identifier with "--mac-package-identifier".
>>>>>> ---
>>>>>>
>>>>>> The same failure for `--mac-package-identifier com.my_domain.project` (with the underscore):
>>>>>> ---
>>>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output --type app-image --main-jar hello.jar --main-class com.my_domain.project.Hello --mac-package-identifier com.my_domain.project
>>>>>> Bundler Mac Application Image skipped because of a configuration problem: invalid mac bundle identifier [com.my_domain.project].
>>>>>> Advice to fix: specify identifier with "--mac-package-identifier".
>>>>>> ---
>>>>>>
>>>>>> Any chance you accidentally put the string with the underscore instead of the hyphen as a value of the `--mac-package-identifier` option on your command line?
>>>>>>
>>>>>> - Alexey
>>>>>>
>>>>>> On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am about to switch a JavaFX project from JDK21 to JDK25 and I noticed a problem when running jpackage.
>>>>>>
>>>>>> My domain has a hyphen, like in https://urldefense.com/v3/__http://www.my-domain.com__;!!ACWV5N9M2RV99hQ!PJkRdYKqwvx3DpbGU7Vs7_nfA_KLAZB2TvQiF8kdh2Hcyc_rGP8CVybD7gIyYwr87rlWIBRU4T4TGWmpTV7qNnmW6E0-wvI$
>>>>>> Hence, my Java package reads like this: com.my_domain.project
>>>>>> Note: hyphen becomes underscore.
>>>>>>
>>>>>> Running vanilla jpackage in JDK21 complained with
>>>>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>>>>> due to the *invalid* underscore and suggests me to use "--mac-package-identifier"
>>>>>>
>>>>>> Hence, I added --mac-package-identifier com.my-domain.project (with the hyphen again)
>>>>>> All good so far.
>>>>>>
>>>>>> Running the same code with JDK25 with the above settings shows the error message again
>>>>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>>>>>
>>>>>> I can add any argument to  --mac-package-identifier
>>>>>> It seems it is simply not taken into account.
>>>>>>
>>>>>> I am using JDK 25.0.1
>>>>>>
>>>>>> Is this a known issue with JDK25 and jpackage?
>>>>>> Is there any other way to make jpackage work?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -- Daniel
>>>>>>
>>>>>>
>>>>>>


From cushon at openjdk.org  Mon Nov 17 15:34:38 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 17 Nov 2025 15:34:38 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v5]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <Zh8S8W7-4ukboC__9Pp3ZCQau34bEToL23hyLa_K-ZI=.14dd6540-50cb-4c9e-ae63-dee2ba4fa4c5@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon 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 six additional commits since the last revision:

 - Remove setStringWithoutNullTerminator demo
 - Merge branch 'master' into JDK-8369564
 - Add benchmarks, and demo setStringWithoutNullTerminator
 - Update length to code units instead of bytes
 - Consolidate duplicate code in read methods
 - 8369564: Provide a MemorySegment API to read strings with known lengths

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/53b064f2..b729b551

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=03-04

  Stats: 240500 lines in 1875 files changed: 154302 ins; 51772 del; 34426 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From cushon at openjdk.org  Mon Nov 17 15:34:39 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 17 Nov 2025 15:34:39 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v5]
In-Reply-To: <WiVNwFLXGy1ICUN13QKIjzhBmH-fDZI92YUL24fNsSQ=.dca402ab-4c57-4a4a-91a5-dc45822e2279@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <dqiRA1Cf-B0mnv2eZPWk0yrnd4CxrAWHHTITkpkGcBI=.15e7b58d-210d-4133-bbb4-eeb175a98c77@github.com>
 <_gORgVPPc2dmXVkRgjww36Z_6B80xoFP8MSDab7scZQ=.2ea4b41e-63bc-46d8-9608-a59602a66876@github.com>
 <TvrN7fAdIhb83QbP1GNwOBIFPZYmqcgQtkggJy8I6KE=.5f426b30-7864-4120-9bc4-b3cfcf927f74@github.com>
 <r9CSW0jDsnodAXtbpS7K39oNMXFdPWZpiyuW48Paxd8=.53d4d9ac-0d9d-4d9a-b9c1-a07623e0a477@github.com>
 <4AH-S5IP_abXOC121l0tB0oZWkXp8l4SmsN2w1sGlu0=.ad194b1f-ce60-4e16-b905-8ec8ce5dfb77@github.com>
 <WiVNwFLXGy1ICUN13QKIjzhBmH-fDZI92YUL24fNsSQ=.dca402ab-4c57-4a4a-91a5-dc45822e2279@github.com>
Message-ID: <EzfPrgBRcyhP8UpIWYL4xswLrUOGYtD47UW3KqGqvNs=.d58349e3-fafa-4cf2-a77b-5a1c6b72fe26@github.com>

On Mon, 3 Nov 2025 17:58:15 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>>> > A user can easily convert between one or the other length representation by multiplying/dividing by the right scalar
>>> 
>>> That is true of e.g. UTF-16 but not of UTF-8, since the encoding is variable width and doing the conversion from bytes to characters is more expensive there.
>> 
>> Sorry, I don't mean 'character' but 'code unit'. For instance, when reading a UTF-8 string, the unit would be one byte, for UTF-16 it would be two, for UTF-32 four. So a user would just need to divide by the unit size, at least that's the idea.
>
>> I can start a thread discussing the use-case here at a higher level.
> 
> Done: https://mail.openjdk.org/pipermail/panama-dev/2025-November/021182.html

There was some discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore wrote a document: [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2534538276

From duke at openjdk.org  Mon Nov 17 15:42:35 2025
From: duke at openjdk.org (jengebr)
Date: Mon, 17 Nov 2025 15:42:35 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v8]
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <UKGxnqO8V9PF0bNd0e_E3jjt3JqoH3dfm2VwBr0sQww=.af941765-2ab4-44cb-8596-37438c071d36@github.com>

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Removing explicit classname

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28116/files
  - new: https://git.openjdk.org/jdk/pull/28116/files/1fc9e9e0..04d9f35e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28116&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28116&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28116/head:pull/28116

PR: https://git.openjdk.org/jdk/pull/28116

From duke at openjdk.org  Mon Nov 17 15:42:37 2025
From: duke at openjdk.org (jengebr)
Date: Mon, 17 Nov 2025 15:42:37 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v7]
In-Reply-To: <7AjImdR7K6wEBfHy-2_lBABLtmor_2_tsV_M8iM-qsQ=.281ff055-3b11-4ad8-85c9-e1736d503628@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <QqC8K6j2oXplESNqslXh1QUiOoIsOq4AfiU8fvXewwc=.8d4526e7-7070-4b7d-94d1-0e707fb162eb@github.com>
 <7AjImdR7K6wEBfHy-2_lBABLtmor_2_tsV_M8iM-qsQ=.281ff055-3b11-4ad8-85c9-e1736d503628@github.com>
Message-ID: <6cn_8hq1StUqgvcP4Dp00JSonW-OyGlP89Ubz6-yu30=.e819f2a3-d87c-4f6a-aaf5-31fd40222caf@github.com>

On Fri, 14 Nov 2025 21:59:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> jengebr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Polishing test and benchmark
>
> src/java.base/share/classes/java/util/Collections.java line 5264:
> 
>> 5262:         public <T> T[] toArray(T[] a) {
>> 5263:             if (a.length < 1)
>> 5264:                 a = (T[])java.lang.reflect.Array.newInstance(a.getClass().getComponentType(), 1);
> 
> Suggestion:
> 
>                 a = (T[]) Array.newInstance(a.getClass().getComponentType(), 1);

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28116#discussion_r2534565967

From jvernee at openjdk.org  Mon Nov 17 15:48:11 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 15:48:11 GMT
Subject: RFR: 8357728: Avoid caching synthesized names in synthesized
 parameters [v2]
In-Reply-To: <xaJ7tIzIK6QEEINEz3caZWqZ__Yhxn0ndJM4BX7SuLU=.9d442711-9aad-41bf-bd89-7e1c1932591d@github.com>
References: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
 <xaJ7tIzIK6QEEINEz3caZWqZ__Yhxn0ndJM4BX7SuLU=.9d442711-9aad-41bf-bd89-7e1c1932591d@github.com>
Message-ID: <g_0l0HT8fcBiTFUrcKW8hheSuxpIEG9GxH9Xx50Mwlg=.004aee85-0349-4356-b0fd-2d06486cc773@github.com>

On Fri, 14 Nov 2025 23:03:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, fake parameters are created with "arg0" etc. strings that are retained for class file methods with no MethodParameters attribute. The original issue report observes many of these strings present in the heap. To address this issue, we can remove these eagerly created fake names, bringing their behavior in line with nameless parameters from MethodParameters attribute, such as those from inner class constructors. A unit test verifies that no name is retained in the Parameter object when the name is fake.
>> 
>> The original report recommends using a pool to store the arg name strings. I did not take that approach as I don't think it is very necessary; if the issue of retained fake names persist, we can update `Parameter::getName` to return fake names from a pool instead.
>
> Chen Liang 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' of https://github.com/openjdk/jdk into fix/fake-param-name
>  - 8357728: Optimize Executable#synthesizeAllParams

Looks good.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25961#pullrequestreview-3473381755

From liach at openjdk.org  Mon Nov 17 16:23:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 16:23:54 GMT
Subject: RFR: 8372002: VarHandle for receiver's superclass instance fields
 fails describeConstable
Message-ID: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>

In project Babylon work when a VarHandle needs to be unreflected, @mcimadamore discovered that our current unreflection of instance field var handles cannot unreflect instance fields from superclasses, and throws an InternalError instead.

We can easily fix this by iterating the superclasses for fields.

-------------

Commit messages:
 - 8372002: VarHandle for receiver's superclass instance fields fails describeConstable

Changes: https://git.openjdk.org/jdk/pull/28355/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28355&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372002
  Stats: 53 lines in 4 files changed: 38 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28355/head:pull/28355

PR: https://git.openjdk.org/jdk/pull/28355

From jvernee at openjdk.org  Mon Nov 17 16:26:31 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 16:26:31 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v4]
In-Reply-To: <E96tnkoiFCwdMNhtE4Qjmm_kRoJq-brdiqfTvjuke9E=.d61d6540-1583-4766-bc40-c1590b2f480d@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <OUMDlAzMnr9FL9zIpSYc4FTkoh8amuHiMlMYde6YD0E=.f04784a8-f89b-4c4d-9279-5fec912afa18@github.com>
 <E96tnkoiFCwdMNhtE4Qjmm_kRoJq-brdiqfTvjuke9E=.d61d6540-1583-4766-bc40-c1590b2f480d@github.com>
Message-ID: <REQV_gsJPvIMznOzabRzj4yorHmJulYz1_Li87EBnOY=.dc2adee3-6826-4bf5-a8e0-b029e4451187@github.com>

On Mon, 17 Nov 2025 15:03:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix calculation of allocationSize when byteAlignment < MAX_MALLOC_ALIGN
>>   
>>   This work was sponsored by: The FreeBSD Foundation
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 207:
> 
>> 205:         long result;
>> 206:         if (byteAlignment > MAX_MALLOC_ALIGN || alignedSize % byteAlignment != 0) {
>> 207:             allocationSize = alignedSize + byteAlignment - Math.min(MAX_MALLOC_ALIGN, alignedSize);
> 
> This doesn't look correct to me. Let's say we want to do a 7 byte allocation (with `init == false`), aligned to 4. We get `7 % 4 -> 3` so we enter this branch, and then `allocationSize = 7 + 4 - 7`, and we end up allocating only 4 bytes. The previous computation only works if `MAX_MALLOC_ALIGN` is greater than `byteAlignment`.
> 
> I think it's simpler to just replace `MAX_MALLOC_ALIGN` in this `if` statement with an 'expected alignment' derived from the size.

Maybe something like `expectedAlignment = Math.min(MAX_MALLOC_ALIGN, alignedSize % byteAlignment == 0 ?alignedSize : 0)` (i.e. don't assume any alignment for e.g. 7 byte allocations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2534734059

From liach at openjdk.org  Mon Nov 17 16:35:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 16:35:33 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v3]
In-Reply-To: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
Message-ID: <IGg_tlKRT9HBBwTdo62w_vZc_VnjBJRie_krmhRzSQY=.53d9a711-a09f-4f23-bdff-1df972a60097@github.com>

> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
> 
> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.

Chen Liang 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:

 - From review
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
 - Rephrase for parameterTypes contains null
 - Rename tests to be more specific
 - Split annotated type new checks to another patch
 - Redundant
 - Test and more fixes
 - Copyright years
 - Testing
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
 - ... and 1 more: https://git.openjdk.org/jdk/compare/1b24883c...51ef5789

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28336/files
  - new: https://git.openjdk.org/jdk/pull/28336/files/a93a84ff..51ef5789

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=01-02

  Stats: 808 lines in 42 files changed: 527 ins; 177 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/28336.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28336/head:pull/28336

PR: https://git.openjdk.org/jdk/pull/28336

From mli at openjdk.org  Mon Nov 17 16:40:53 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 17 Nov 2025 16:40:53 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v4]
In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
Message-ID: <0VUf9cNuKR6nc_V-Z2ylwW5YpmO13QUEBoDuQcctdCg=.3041a5fa-baf1-41f5-a271-854d68720fd8@github.com>

> Hi,
> 
> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
> 
> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
> 
> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
> 
> # Test
> ## Jtreg
> 
> in progress...
> 
> ## Performance
> 
> Column names meanings:
> * p: with patch
> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> * m: without patch
> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> 
> #### Average improvement
> 
> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
> 
> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
> -- | -- | -- | --
> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
> 
> </google-sheets-html-origin>

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  add BoolTest::ge/gt code and tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28309/files
  - new: https://git.openjdk.org/jdk/pull/28309/files/51451ab5..cf9168a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=02-03

  Stats: 1159 lines in 4 files changed: 968 ins; 4 del; 187 mod
  Patch: https://git.openjdk.org/jdk/pull/28309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28309/head:pull/28309

PR: https://git.openjdk.org/jdk/pull/28309

From mli at openjdk.org  Mon Nov 17 16:47:05 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 17 Nov 2025 16:47:05 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v2]
In-Reply-To: <o-rpi2-fDK76ZZHlXw8SGAYyDyjtx1Ai80vcvFDIjbQ=.a4b912e0-d345-4dc9-98a0-59a88ad1661a@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <8Y3gUUVCNU1ZpfRkZeJqgIUomP6NCDIQqqgN-lRgk5A=.60177ffe-52ba-46de-a099-57d73f096a49@github.com>
 <fGaaH4f7ZujpXZALIuQS4YcaZwKAm6PX4kf6mtkJDWE=.7a1ad9d4-c8bf-476d-bff6-194919c3fd81@github.com>
 <o-rpi2-fDK76ZZHlXw8SGAYyDyjtx1Ai80vcvFDIjbQ=.a4b912e0-d345-4dc9-98a0-59a88ad1661a@github.com>
Message-ID: <4K5xXIGM3anJGkUHGJ75fs6X-zfM_aDNI6Bi9yifK4c=.bb898013-6dbc-4e9a-8666-e8858f87d93f@github.com>

On Mon, 17 Nov 2025 13:38:40 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2133:
>> 
>>> 2131:       break;
>>> 2132:     case BoolTest::ge:
>>> 2133:       assert(false, "Should go to BoolTest::le case");
>> 
>> I am not sure if it's safe to have these assertions for `ge` and `gt`. It seems to me that we should handle all possible condition codes here. Check this bug: https://bugs.openjdk.org/browse/JDK-8358892. We have added handling for `ge` and `gt` in `C2_MacroAssembler::enc_cmove_cmp_fp` to fix it.
>
> Make sense! Thanks!
> I'll add the implementation for these condition codes.

I added some code and tests.
But the code path for `ge`/`gt` can not be triggerred (I added some new test based on previous tests added in https://bugs.openjdk.org/browse/JDK-8358892). So for now, I think it's safer for us to keep the `assert`, in this way, in the future when we get it triggerred by some code we can compse a jtreg test and fix it.
How do you think about it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2534803387

From alanb at openjdk.org  Mon Nov 17 16:47:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 16:47:07 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v3]
In-Reply-To: <IGg_tlKRT9HBBwTdo62w_vZc_VnjBJRie_krmhRzSQY=.53d9a711-a09f-4f23-bdff-1df972a60097@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <IGg_tlKRT9HBBwTdo62w_vZc_VnjBJRie_krmhRzSQY=.53d9a711-a09f-4f23-bdff-1df972a60097@github.com>
Message-ID: <aXp8CnT5XcEi6z-fhAZqJg5kCCb4FczV-8CVC4pUt4k=.21d05070-f168-4efd-830c-aa74df6f90b2@github.com>

On Mon, 17 Nov 2025 16:35:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
>> 
>> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.
>
> Chen Liang 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:
> 
>  - From review
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
>  - Rephrase for parameterTypes contains null
>  - Rename tests to be more specific
>  - Split annotated type new checks to another patch
>  - Redundant
>  - Test and more fixes
>  - Copyright years
>  - Testing
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c1109dc0...51ef5789

Latest version looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28336#pullrequestreview-3473639319

From rgiulietti at openjdk.org  Mon Nov 17 16:48:22 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 17 Nov 2025 16:48:22 GMT
Subject: RFR: 8367603: Optimize exact division in BigDecimal [v25]
In-Reply-To: <0zUQlypv2Mno6YgOv2DXfRgaPtCrz_Lu9diNMsgrI1I=.ffa6a6d2-e171-493a-8593-8011a7ada5cf@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
 <gMpgM_vzCr879wnmTmebhqWKa99YNVA63h_XkgdXhcE=.9b175f8a-3b97-4240-91e7-6850fe8d709d@github.com>
 <bCiGm_iFyMyVXol6dxTyKwk3XuGqWnL-i3LWHryquhs=.284b4e0a-1f0a-4944-8663-69eb67f4a689@github.com>
 <0zUQlypv2Mno6YgOv2DXfRgaPtCrz_Lu9diNMsgrI1I=.ffa6a6d2-e171-493a-8593-8011a7ada5cf@github.com>
Message-ID: <ylS_C_gQUDqLIGKq8yvpZFpPZThRiZUQmWA9O_w5yo4=.24bc32f0-69a3-4dc2-a522-0b853e52e997@github.com>

On Wed, 29 Oct 2025 11:48:04 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 1794:
>> 
>>> 1792:         if (this.signum() == 0) // 0/y
>>> 1793:             return zeroValueOf(preferredScale);
>>> 1794:         else {
>> 
>> The old algorithm has relatively few paths through it for different arguments.
>> 
>> Do the existing test cases provide adequate coverage of the new set of code paths?
>
> I think they do, @rgiulietti do you think the test coverage is adequate?

@fabioromano1 Thanks for the additional tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27271#discussion_r2534811634

From rgiulietti at openjdk.org  Mon Nov 17 16:48:20 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 17 Nov 2025 16:48:20 GMT
Subject: RFR: 8367603: Optimize exact division in BigDecimal [v25]
In-Reply-To: <WsZditYp46_jutS6yXimgZw2aahYGt3VFIHJzv14goo=.e3c19f0c-59f1-442b-9d30-1e83ab065634@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
 <WsZditYp46_jutS6yXimgZw2aahYGt3VFIHJzv14goo=.e3c19f0c-59f1-442b-9d30-1e83ab065634@github.com>
Message-ID: <b6KP0POADx5Lncrr7jQslyqCVDTv7DpQgaiGpFt5GJE=.eaa27088-7039-44fe-9be3-835b34e3e0f6@github.com>

On Sun, 16 Nov 2025 19:09:43 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator.
>
> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed trailing whitespaces
>  - Added further tests

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27271#pullrequestreview-3473650816

From jvernee at openjdk.org  Mon Nov 17 16:52:17 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 16:52:17 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <ESX4NSuqv_AXuodz38Wfa56U1Asqs9g44MiZeUSEZ3Y=.fe99ad0c-a3f2-41e5-99da-7af83e6845e9@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

test/jdk/java/lang/LazyConstant/LazyConstantTest.java line 234:

> 232:             return new Lazy<>(LazyConstant.of(computingFunction));
> 233:         }
> 234:     }

This appears to be unused?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534822362

From jvernee at openjdk.org  Mon Nov 17 17:11:14 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 17:11:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <VGv5qMEBjKT1FLCasY2G79nWj_AlN_8SmDHmfAJa1HM=.ec050ca4-d07f-4b29-92ff-2cf972045023@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by jvernee (Reviewer).

test/jdk/java/lang/LazyConstant/LazyListTest.java line 27:

> 25:  * @summary Basic tests for lazy list methods
> 26:  * @enablePreview
> 27:  * @run junit/othervm --add-opens java.base/java.util=ALL-UNNAMED LazyListTest

I think you can do this with

Suggestion:

 * @modules java.base/java.util:+open
 * @run junit LazyListTest

-------------

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3473667773
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534826477

From kurt at openjdk.org  Mon Nov 17 17:24:14 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Mon, 17 Nov 2025 17:24:14 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v4]
In-Reply-To: <OUMDlAzMnr9FL9zIpSYc4FTkoh8amuHiMlMYde6YD0E=.f04784a8-f89b-4c4d-9279-5fec912afa18@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <OUMDlAzMnr9FL9zIpSYc4FTkoh8amuHiMlMYde6YD0E=.f04784a8-f89b-4c4d-9279-5fec912afa18@github.com>
Message-ID: <lbKThjaXebmBmylFcrTQMilRkxNhliBopWPeVnMvPHE=.7a61b436-9766-453e-89ee-2d3fb6f262c2@github.com>

On Sun, 16 Nov 2025 18:09:47 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix calculation of allocationSize when byteAlignment < MAX_MALLOC_ALIGN
>   
>   This work was sponsored by: The FreeBSD Foundation

I believe this is the most concise way to support weak alignment allocators:
https://github.com/bsdkurt/jdk/commit/bb45e82a8772e50e321f07af37470fc4360b0adf

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3543039999

From liach at openjdk.org  Mon Nov 17 17:42:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 17:42:04 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v8]
In-Reply-To: <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>
Message-ID: <8qkbCFPZcWmTqEq86fprDDEiLRdJsYf019AD-192scc=.6e27bbc5-e9a1-4d6d-9f25-1dd14ef97e07@github.com>

On Sun, 16 Nov 2025 14:50:39 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
>> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
>> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach
>
> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust to TestMergeStoresMemorySegment.java requirements

I don't think the two private interfaces approach works - since there is only one `RuntimeException apply(String, List)` in AMSI, JLS mandates a compile error, and even if we compile, JVMS says any of these two methods can be chosen regardless of casting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3543103699

From rriggs at openjdk.org  Mon Nov 17 17:55:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Nov 2025 17:55:06 GMT
Subject: RFR: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
In-Reply-To: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
References: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
Message-ID: <m9G0Y7JhTgro-ngwiViAXZUMPVqTgi_9Z-ESPe5UNoc=.6e629b71-8a82-4ebb-9039-3dff3fba9516@github.com>

On Fri, 31 Oct 2025 00:00:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There were a few other holes in the recent migration of BytecodeDescriptor, most notably:
> 
> 1. BytecodeDescriptor is missing checks for `.`, `[` characters, leading, trailing, consecutive `/`, or empty name.
> 2. EnclosingMethod is only validated by hotspot to carry either field or method type. We still need to check for field types
> 
> I have written up the behavioral changes in the CSR. In addition, I have added a few more tests to ensure the failure case behaviors of the migrated use sites.

Looks ok; it would be good to have a second reviewer.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28079#pullrequestreview-3473919128

From liach at openjdk.org  Mon Nov 17 18:02:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 18:02:13 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v14]
In-Reply-To: <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>
Message-ID: <eR7Mgg7-b3UjII4_siBQHksyq-oA_gi_l5KGTiu69wo=.f1813ebc-62e4-4b7a-a800-221e8709c24c@github.com>

On Mon, 17 Nov 2025 10:48:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Spurious italics
>  - More wordsmithing
>  - Improve IAE exception message
>  - Merge branch 'master' into JDK-8353835
>  - Cleanup
>  - More cleanup of Field.set API docs, including some restructure from Alex
>  - Cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Update mutateFinals/modules test to exercise exports and opens cases
>  - ... and 53 more: https://git.openjdk.org/jdk/compare/8690d263...c3c3cfff

The core library changes look good to me.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3473937951

From duke at openjdk.org  Mon Nov 17 18:03:50 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Mon, 17 Nov 2025 18:03:50 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress option
 correctly
Message-ID: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>

This PR looks into updating the content of `--compress` option and plugin of `jlink`:

- Updates the `--compress` option description and warns that previous compression levels are deprecated to be removed in a future release.
- Updates the `--plugin` option description and warns that previous compression levels are deprecated to be removed in a future release.

-------------

Commit messages:
 - Update compression level explanation from jlink man page.

Changes: https://git.openjdk.org/jdk/pull/28359/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321139
  Stats: 14 lines in 1 file changed: 7 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From naoto at openjdk.org  Mon Nov 17 19:15:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Nov 2025 19:15:50 GMT
Subject: RFR: 8346944: Update Unicode Data Files to 17.0.0 [v2]
In-Reply-To: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>
References: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>
Message-ID: <H1KjzSPFDlZUJb0giZqZq3tR6h-1z1jdrJkVfP2HdzU=.c357204f-ca60-4a7c-a8de-c150e63a030a@github.com>

> Updates the JDK to use the latest Unicode 17.0.0, which also updates the ICU4J along with it ([8346947](https://bugs.openjdk.org/browse/JDK-8346947)
> Update ICU4J to Version 78.1). The corresponding CSR has already been approved.

Naoto Sato 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 'master' into JDK-8346944-Unicode-17
 - icudata path fix
 - Update versions
 - icu4j final
 - .md file changes
 - 17.0 final
 - icudata78b(binary)
 - CaseFolding.text -> 17, copyright symbol as is
 - icudt78b
 - 17-beta
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c26db986...088cdaea

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28093/files
  - new: https://git.openjdk.org/jdk/pull/28093/files/d9cff00a..088cdaea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28093&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28093&range=00-01

  Stats: 7827 lines in 200 files changed: 5016 ins; 1574 del; 1237 mod
  Patch: https://git.openjdk.org/jdk/pull/28093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28093/head:pull/28093

PR: https://git.openjdk.org/jdk/pull/28093

From psandoz at openjdk.org  Mon Nov 17 19:18:31 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 17 Nov 2025 19:18:31 GMT
Subject: RFR: 8372002: VarHandle for receiver's superclass instance fields
 fails describeConstable
In-Reply-To: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
References: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
Message-ID: <8XJFEYQxf-MlapD7pKXRcQTcRhJcnWdBV-XKR5hTV_8=.23f63852-cc45-4847-8a9b-b54c2d714453@github.com>

On Mon, 17 Nov 2025 16:15:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> In project Babylon work when a VarHandle needs to be unreflected, @mcimadamore discovered that our current unreflection of instance field var handles cannot unreflect instance fields from superclasses, and throws an InternalError instead.
> 
> We can easily fix this by iterating the superclasses for fields.

Looks good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28355#pullrequestreview-3474213148

From alanb at openjdk.org  Mon Nov 17 19:55:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 19:55:11 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <eHp-k23g-OqhOUsyqZ2cDOufAKJpufu_wQSwK4tMuXE=.0cc7eeac-cc94-431b-a161-524ef94c1cd2@github.com>

On Mon, 17 Nov 2025 17:54:21 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

> This PR looks into updating the content of `--compress` option and plugin of `jlink`:
> 
> - Updates the `--compress` option description and warns that previous compression levels are deprecated to be removed in a future release.
> - Updates the `--plugin` option description and warns that previous compression levels are deprecated to be removed in a future release.

src/jdk.jlink/share/man/jlink.md line 68:

> 66: 
> 67: `-c=zip-[0-9]` or `--compress=zip-[0-9]`
> 68: :   Enable compression of resources. The accepted values are:

All good for `--compress`. Can you double check that `-c` actually works?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2535339682

From bpb at openjdk.org  Mon Nov 17 20:26:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 17 Nov 2025 20:26:57 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v18]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <IuoxMcptxkzLxVzHpPhRRztqRKzIqN4Onu1TyfK5bis=.ebcf5b34-c7f1-4f36-aa2a-40ed7e8516a3@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 18 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 8 more: https://git.openjdk.org/jdk/compare/9ec773ad...75555455

-------------

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=17
  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 duke at openjdk.org  Mon Nov 17 20:37:05 2025
From: duke at openjdk.org (Almaz)
Date: Mon, 17 Nov 2025 20:37:05 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v4]
In-Reply-To: <REQV_gsJPvIMznOzabRzj4yorHmJulYz1_Li87EBnOY=.dc2adee3-6826-4bf5-a8e0-b029e4451187@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <OUMDlAzMnr9FL9zIpSYc4FTkoh8amuHiMlMYde6YD0E=.f04784a8-f89b-4c4d-9279-5fec912afa18@github.com>
 <E96tnkoiFCwdMNhtE4Qjmm_kRoJq-brdiqfTvjuke9E=.d61d6540-1583-4766-bc40-c1590b2f480d@github.com>
 <REQV_gsJPvIMznOzabRzj4yorHmJulYz1_Li87EBnOY=.dc2adee3-6826-4bf5-a8e0-b029e4451187@github.com>
Message-ID: <k2ioGWjNZOCBbs3nPYLne_vePOgCC4jJ6r7eSPV-XeI=.c582cfb7-09ac-4f72-9cf0-7d33ccac79bb@github.com>

On Mon, 17 Nov 2025 16:23:42 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> i.e. don't assume any alignment for e.g. 7 byte allocations

Section 7.25.4.1 of [the libc standard](https://open-std.org/JTC1/SC22/WG14/www/docs/n3685.pdf) says

> The pointer returned if the allocation succeeds is
suitably aligned so that it can be assigned to a pointer to any type of object with a fundamental
alignment requirement and size less than or equal to the size requested

IIUC it should be at least 4 bytes aligned

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2535435790

From duke at openjdk.org  Mon Nov 17 20:45:04 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Mon, 17 Nov 2025 20:45:04 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly
In-Reply-To: <eHp-k23g-OqhOUsyqZ2cDOufAKJpufu_wQSwK4tMuXE=.0cc7eeac-cc94-431b-a161-524ef94c1cd2@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <eHp-k23g-OqhOUsyqZ2cDOufAKJpufu_wQSwK4tMuXE=.0cc7eeac-cc94-431b-a161-524ef94c1cd2@github.com>
Message-ID: <ysZNKy9wkcIZZBOUTKqoHZnzSmTOhZRpvpu8n6m5b_s=.5077678d-b671-46de-857c-d9bdf291194b@github.com>

On Mon, 17 Nov 2025 19:52:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR looks into updating the content of `--compress` option and plugin of `jlink`:
>> 
>> - Updates the `--compress` option description and warns that previous compression levels are deprecated to be removed in a future release.
>> - Updates the `--plugin` option description and warns that previous compression levels are deprecated to be removed in a future release.
>
> src/jdk.jlink/share/man/jlink.md line 68:
> 
>> 66: 
>> 67: `-c=zip-[0-9]` or `--compress=zip-[0-9]`
>> 68: :   Enable compression of resources. The accepted values are:
> 
> All good for `--compress`. Can you double check that `-c` actually works?

Thank you so much for spotting this! `-c` does not work and `jlink --help` command does not list it either.  Will remove it from this part.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2535455349

From duke at openjdk.org  Mon Nov 17 20:49:35 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Mon, 17 Nov 2025 20:49:35 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v2]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <yDlZET5M6gY-m2NpvPfFjAY9vOAs5_LBJwcXMqOC63k=.8512938d-55c7-4097-b872-793e918041d3@github.com>

> This PR looks into updating the content of `--compress` option and plugin of `jlink`:
> 
> - Updates the `--compress` option description and warns that previous compression levels are deprecated to be removed in a future release.
> - Updates the `--plugin` option description and warns that previous compression levels are deprecated to be removed in a future release.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Remove legacy shortcut for --compress.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/b1517c35..8749e51e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From jvernee at openjdk.org  Mon Nov 17 22:38:11 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 22:38:11 GMT
Subject: RFR: 8372002: VarHandle for receiver's superclass instance fields
 fails describeConstable
In-Reply-To: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
References: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
Message-ID: <UsYxSkI_WzdQOhtcGRaHnXocz5t5qh5YwzAJ0-gHris=.5584b2b7-951b-4d6c-a65b-695a330b1e31@github.com>

On Mon, 17 Nov 2025 16:15:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> In project Babylon work when a VarHandle needs to be unreflected, @mcimadamore discovered that our current unreflection of instance field var handles cannot unreflect instance fields from superclasses, and throws an InternalError instead.
> 
> We can easily fix this by iterating the superclasses for fields.

Looks good.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28355#pullrequestreview-3474804861

From liach at openjdk.org  Tue Nov 18 00:34:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 00:34:04 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v8]
In-Reply-To: <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
Message-ID: <tAew8DuTNk1NgCytyqFgRzq0fbCW55PBF0hITJD1Jbw=.32ce3b16-6c28-42c6-bb28-2f94a03d4181@github.com>

On Thu, 13 Nov 2025 06:46:51 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix StreamOpFlagsTest

This patch looks fine to me. @viktorklang-ora Can you help review this again?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3544519815

From swen at openjdk.org  Tue Nov 18 00:55:17 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 18 Nov 2025 00:55:17 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v24]
In-Reply-To: <iQQfWIwaHpaY6OZVC9WaOTQkfdXUQrxZKei-BuDLSoc=.37cc96fb-46de-4a96-ace7-444dffbf46cd@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <9wkLz_EcOnSMn-PwvZVYvwEbh3j0BqPqR_PgMvKwDkM=.f709c870-e48f-4be7-b3e5-f02edadfdc29@github.com>
 <-YApwwtJ8DmPFiKl28zZcP6HUG3fHpV-Llaw0j-nUS0=.84263959-31f1-4fa7-af02-54830d3060d2@github.com>
 <iQQfWIwaHpaY6OZVC9WaOTQkfdXUQrxZKei-BuDLSoc=.37cc96fb-46de-4a96-ace7-444dffbf46cd@github.com>
Message-ID: <mAg1BnHaErlM7Q8USp-AY6GS488do-XWnQIeWrpMyFQ=.42029d5d-e92d-48af-86cd-91108f71643d@github.com>

On Mon, 17 Nov 2025 14:41:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > The `DecimalDigits.appendPair` and `appendQuad` methods will experience performance degradation if a `StringBuilder` with `Encoding UTF16` is passed to them. This occurs when `DecimalDigits.appendPair` or `appendQuad` is used in `DateTimeFormatter::formatTo`.
> 
> Adding single purpose functions to Java Lang Access is not worth the added complexity and maintenance cost.

Okay, most scenarios are Latin1, so we'll use the current version and not add any JLA bridging methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3544563863

From almatvee at openjdk.org  Tue Nov 18 01:27:33 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 18 Nov 2025 01:27:33 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v3]
In-Reply-To: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
Message-ID: <6pO3aJhJYHm3x7d6YSc-SibeGeiUzljnBcwPTLL686s=.4dd3cb74-6f0f-4fd7-bc9b-f573c7dfecd9@github.com>

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v4]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28033/files
  - new: https://git.openjdk.org/jdk/pull/28033/files/2ebe4149..e9078936

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28033&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28033&range=01-02

  Stats: 30 lines in 3 files changed: 29 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28033/head:pull/28033

PR: https://git.openjdk.org/jdk/pull/28033

From almatvee at openjdk.org  Tue Nov 18 01:27:37 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 18 Nov 2025 01:27:37 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v2]
In-Reply-To: <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>
Message-ID: <wWseNRIo-GmXg0fO6DvGaj07i9jD1NwxU9H-76x6rXE=.2afe2757-4518-44fc-a137-621deddf0b4b@github.com>

On Sat, 8 Nov 2025 04:21:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added JDK specific keys/values to Info.plist of embedded runtime.
>> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
>> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.
>
> Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8363980
>  - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v3]
>  - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v2]
>  - Merge remote-tracking branch 'upstream/master' into JDK-8363980
>  - Merge remote-tracking branch 'upstream/master' into JDK-8363980
>  - Merge remote-tracking branch 'upstream/master' into JDK-8363980
>  - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime

8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v4]
- Added PList check with minor modification to skip check if runtime directory does not exists.
- Updated CustomInfoPListTest.java to include `JavaVM` key.
- `useRuntimeInfoPlist` will also check for existence of `bin` folder to cover cases when runtime is provided via `--runtime-image`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3544629521

From asemenyuk at openjdk.org  Tue Nov 18 02:10:01 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Nov 2025 02:10:01 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v2]
In-Reply-To: <wWseNRIo-GmXg0fO6DvGaj07i9jD1NwxU9H-76x6rXE=.2afe2757-4518-44fc-a137-621deddf0b4b@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>
 <wWseNRIo-GmXg0fO6DvGaj07i9jD1NwxU9H-76x6rXE=.2afe2757-4518-44fc-a137-621deddf0b4b@github.com>
Message-ID: <7NpPTV1ZExp4fNeytAFrbj1u_8mK6GtcQ5X8dsOMkXs=.0bc405bd-df04-4c16-abec-c585a0c1b7ab@github.com>

On Tue, 18 Nov 2025 01:24:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> useRuntimeInfoPlist will also check for existence of bin folder to cover cases when runtime is provided via --runtime-image.

Do we have tests for these use cases?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3544702004

From asemenyuk at openjdk.org  Tue Nov 18 02:10:04 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Nov 2025 02:10:04 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v3]
In-Reply-To: <6pO3aJhJYHm3x7d6YSc-SibeGeiUzljnBcwPTLL686s=.4dd3cb74-6f0f-4fd7-bc9b-f573c7dfecd9@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <6pO3aJhJYHm3x7d6YSc-SibeGeiUzljnBcwPTLL686s=.4dd3cb74-6f0f-4fd7-bc9b-f573c7dfecd9@github.com>
Message-ID: <Fk9Cz5B7upSR0Ld-x3O77IaT_cPOsQ2pJ75v_WukLxY=.00829d4f-fbdc-4ee2-98c9-859f0907656c@github.com>

On Tue, 18 Nov 2025 01:27:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added JDK specific keys/values to Info.plist of embedded runtime.
>> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
>> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v4]

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 1229:

> 1227:                 if (!Files.isDirectory(appLayout.runtimeDirectory())) {
> 1228:                     return;
> 1229:                 }

A missing runtime directory is not a regular situation.

In such a case, (I believe `AppImagePackageTest.testEmpty()` is the only one) test should explicitly exclude this assert. See how `AppImagePackageTest.testEmpty()` excludes the `RUNTIME_DIRECTORY` and other asserts. 

I suggest removing the test for the runtime directory from the assert body and adding `MAC_RUNTIME_PLIST_JDK_KEY` assert to the list of excluded asserts in the `AppImagePackageTest.testEmpty()` test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2536064398

From almatvee at openjdk.org  Tue Nov 18 02:16:55 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 18 Nov 2025 02:16:55 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v4]
In-Reply-To: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
Message-ID: <AK44tiFiWZ4bk1eiZOMbcZwUDoawZKb1fku5ql5gClU=.0902275a-47ef-40a0-80bc-951f1a76771d@github.com>

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v5]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28033/files
  - new: https://git.openjdk.org/jdk/pull/28033/files/e9078936..b353b466

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28033&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28033&range=02-03

  Stats: 7 lines in 2 files changed: 1 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28033/head:pull/28033

PR: https://git.openjdk.org/jdk/pull/28033

From almatvee at openjdk.org  Tue Nov 18 02:16:56 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 18 Nov 2025 02:16:56 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v2]
In-Reply-To: <7NpPTV1ZExp4fNeytAFrbj1u_8mK6GtcQ5X8dsOMkXs=.0bc405bd-df04-4c16-abec-c585a0c1b7ab@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>
 <wWseNRIo-GmXg0fO6DvGaj07i9jD1NwxU9H-76x6rXE=.2afe2757-4518-44fc-a137-621deddf0b4b@github.com>
 <7NpPTV1ZExp4fNeytAFrbj1u_8mK6GtcQ5X8dsOMkXs=.0bc405bd-df04-4c16-abec-c585a0c1b7ab@github.com>
Message-ID: <nWBv8_MphAjKlnW_6eNbERwdu59M7bOhO7WdPj-u6Tg=.22f9b78e-f534-47c2-9a9f-22d1907a6b02@github.com>

On Tue, 18 Nov 2025 02:06:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> > useRuntimeInfoPlist will also check for existence of bin folder to cover cases when runtime is provided via --runtime-image.
> 
> Do we have tests for these use cases?

Yes, NoMPathRuntimeTest.java, MainClassTest.java and CookedRuntimeTest.java will fail without `bin` folder check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3544709668

From almatvee at openjdk.org  Tue Nov 18 02:16:59 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 18 Nov 2025 02:16:59 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v3]
In-Reply-To: <6pO3aJhJYHm3x7d6YSc-SibeGeiUzljnBcwPTLL686s=.4dd3cb74-6f0f-4fd7-bc9b-f573c7dfecd9@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <6pO3aJhJYHm3x7d6YSc-SibeGeiUzljnBcwPTLL686s=.4dd3cb74-6f0f-4fd7-bc9b-f573c7dfecd9@github.com>
Message-ID: <gNo3-ctW7b4AUOr4zIhF_Wp-I-s9gDTztFJRhwDj5zs=.2e851547-6a6a-45d9-8c49-2db37bece571@github.com>

On Tue, 18 Nov 2025 01:27:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added JDK specific keys/values to Info.plist of embedded runtime.
>> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
>> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v4]

8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v5]
- Removed the test for the runtime directory from the assert body and added MAC_RUNTIME_PLIST_JDK_KEY assert to the list of excluded asserts in the AppImagePackageTest.testEmpty() test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3544714334

From asemenyuk at openjdk.org  Tue Nov 18 02:56:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Nov 2025 02:56:12 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v2]
In-Reply-To: <nWBv8_MphAjKlnW_6eNbERwdu59M7bOhO7WdPj-u6Tg=.22f9b78e-f534-47c2-9a9f-22d1907a6b02@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>
 <wWseNRIo-GmXg0fO6DvGaj07i9jD1NwxU9H-76x6rXE=.2afe2757-4518-44fc-a137-621deddf0b4b@github.com>
 <7NpPTV1ZExp4fNeytAFrbj1u_8mK6GtcQ5X8dsOMkXs=.0bc405bd-df04-4c16-abec-c585a0c1b7ab@github.com>
 <nWBv8_MphAjKlnW_6eNbERwdu59M7bOhO7WdPj-u6Tg=.22f9b78e-f534-47c2-9a9f-22d1907a6b02@github.com>
Message-ID: <3UhSkVXKJRRjZltFQ4rQCaLhTidnSrHhQM9FaZPtUeM=.f6a9267c-c126-4664-bfb3-4c42e99e4ecb@github.com>

On Tue, 18 Nov 2025 02:10:38 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Yes, NoMPathRuntimeTest.java, MainClassTest.java and CookedRuntimeTest.java will fail without bin folder check.

I don't quite understand this.

As far as I can see, we don't have tests that specifically target this new feature. Am I missing anything?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3544796071

From joehw at openjdk.org  Tue Nov 18 05:11:13 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 18 Nov 2025 05:11:13 GMT
Subject: RFR: 8346944: Update Unicode Data Files to 17.0.0 [v2]
In-Reply-To: <H1KjzSPFDlZUJb0giZqZq3tR6h-1z1jdrJkVfP2HdzU=.c357204f-ca60-4a7c-a8de-c150e63a030a@github.com>
References: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>
 <H1KjzSPFDlZUJb0giZqZq3tR6h-1z1jdrJkVfP2HdzU=.c357204f-ca60-4a7c-a8de-c150e63a030a@github.com>
Message-ID: <nsDPXWZTI1iW0DQjMnsPS_sXvnYJJEnVJ7vQl4Nxzi4=.084057bb-8c3d-4df0-afa2-0a4cc288cc30@github.com>

On Mon, 17 Nov 2025 19:15:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Updates the JDK to use the latest Unicode 17.0.0, which also updates the ICU4J along with it ([8346947](https://bugs.openjdk.org/browse/JDK-8346947)
>> Update ICU4J to Version 78.1). The corresponding CSR has already been approved.
>
> Naoto Sato 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 'master' into JDK-8346944-Unicode-17
>  - icudata path fix
>  - Update versions
>  - icu4j final
>  - .md file changes
>  - 17.0 final
>  - icudata78b(binary)
>  - CaseFolding.text -> 17, copyright symbol as is
>  - icudt78b
>  - 17-beta
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/2b28d8c0...088cdaea

LGTM.

src/java.base/share/classes/jdk/internal/icu/util/VersionInfo.java line 57:

> 55:      */
> 56:     @Deprecated
> 57:     public static final String ICU_DATA_VERSION_PATH = "78b";

Now with fixed path "icudata", this seems to be no longer used.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28093#pullrequestreview-3475474397
PR Review Comment: https://git.openjdk.org/jdk/pull/28093#discussion_r2536321176

From alanb at openjdk.org  Tue Nov 18 07:46:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 07:46:04 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v2]
In-Reply-To: <ysZNKy9wkcIZZBOUTKqoHZnzSmTOhZRpvpu8n6m5b_s=.5077678d-b671-46de-857c-d9bdf291194b@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <eHp-k23g-OqhOUsyqZ2cDOufAKJpufu_wQSwK4tMuXE=.0cc7eeac-cc94-431b-a161-524ef94c1cd2@github.com>
 <ysZNKy9wkcIZZBOUTKqoHZnzSmTOhZRpvpu8n6m5b_s=.5077678d-b671-46de-857c-d9bdf291194b@github.com>
Message-ID: <jSKQJTt25kmvoF4qtRheQmrkb8FAjmyWdq41sxlQlE0=.66e6fd51-52cc-4a80-b5af-f1248f7e5bb8@github.com>

On Mon, 17 Nov 2025 20:42:11 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> src/jdk.jlink/share/man/jlink.md line 68:
>> 
>>> 66: 
>>> 67: `-c=zip-[0-9]` or `--compress=zip-[0-9]`
>>> 68: :   Enable compression of resources. The accepted values are:
>> 
>> All good for `--compress`. Can you double check that `-c` actually works?
>
> Thank you so much for spotting this! `-c` does not work and `jlink --help` command does not list it either.  Will remove it from this part.

I suspect something has got messed up in the CLI parsing. `-c` should be the short form of `--compress`. At this time, `-c`, with no params, is the equivalent of `--compress 2` so we get a confusing warning. As we've found, providing parameters to the short form doesn't seem to work.  So I think we need to dig into this more.

Also a comment on the "Deprecated values to be removed in a future release" section. This could easier to read that zip-0 and zip-6 are being deprecated. Instead of "Equivalent to zip-0", then maybe we should say "Use zip-0 instead".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2536671831

From alanb at openjdk.org  Tue Nov 18 08:04:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 08:04:13 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v14]
In-Reply-To: <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>
Message-ID: <WL_1J9AQuA01zD_xh3lYP8DaoBBzxqyqEreFmz4nJfE=.8c7c57b0-3b15-4a77-9b64-bc99522d6140@github.com>

On Mon, 17 Nov 2025 10:48:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Spurious italics
>  - More wordsmithing
>  - Improve IAE exception message
>  - Merge branch 'master' into JDK-8353835
>  - Cleanup
>  - More cleanup of Field.set API docs, including some restructure from Alex
>  - Cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Update mutateFinals/modules test to exercise exports and opens cases
>  - ... and 53 more: https://git.openjdk.org/jdk/compare/8690d263...c3c3cfff

Thanks for the comments and detailed reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3546036382

From alanb at openjdk.org  Tue Nov 18 08:10:21 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 08:10:21 GMT
Subject: Integrated: 8353835: Implement JEP 500: Prepare to Make Final Mean
 Final
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <s8o3-ZUCTSnulpiTqfDcWd8L91QR36zlpCTJ3XkE-kc=.44a7d9c6-92fc-4c6f-8049-cfbd5e48545b@github.com>

On Thu, 8 May 2025 11:22:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

This pull request has now been integrated.

Changeset: 26460b6f
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26460b6f12ce0763b79acfd98fca260b509a82c5
Stats:     5365 lines in 76 files changed: 5170 ins; 55 del; 140 mod

8353835: Implement JEP 500: Prepare to Make Final Mean Final

Reviewed-by: liach, vlivanov, dholmes, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/25115

From syan at openjdk.org  Tue Nov 18 08:32:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Nov 2025 08:32:43 GMT
Subject: RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS
Message-ID: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>

Hi all,

Test tools/jar/ReproducibleJar.java fails when running on a file system that only supports to 2038(e.g. XFS).

Before this PR, test check if the input test time after "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to "2038-01-19T03:14:07Z", then test will skip that check.

But the extraced time created by jar equal to "1970-01-01T00:00:00Z" actually. I think the extracted time set to unix epoch time is acceptable, so this PR fix the test make test check skip when the extracted time is unix epoch time.

Change has been verified locally on XFS file system and ext4 file system.

-------------

Commit messages:
 - 8371978: ReproducibleJar.testValidSourceDate fails on some machines

Changes: https://git.openjdk.org/jdk/pull/28367/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28367&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371978
  Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28367/head:pull/28367

PR: https://git.openjdk.org/jdk/pull/28367

From duke at openjdk.org  Tue Nov 18 09:03:13 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Tue, 18 Nov 2025 09:03:13 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v2]
In-Reply-To: <jSKQJTt25kmvoF4qtRheQmrkb8FAjmyWdq41sxlQlE0=.66e6fd51-52cc-4a80-b5af-f1248f7e5bb8@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <eHp-k23g-OqhOUsyqZ2cDOufAKJpufu_wQSwK4tMuXE=.0cc7eeac-cc94-431b-a161-524ef94c1cd2@github.com>
 <ysZNKy9wkcIZZBOUTKqoHZnzSmTOhZRpvpu8n6m5b_s=.5077678d-b671-46de-857c-d9bdf291194b@github.com>
 <jSKQJTt25kmvoF4qtRheQmrkb8FAjmyWdq41sxlQlE0=.66e6fd51-52cc-4a80-b5af-f1248f7e5bb8@github.com>
Message-ID: <1_70-rAo-dpg2R9YWfhc1sjAcnUHOhcRKAxjCWWIJPc=.12de5336-ff0e-4be3-b3e6-41133e49eb56@github.com>

On Tue, 18 Nov 2025 07:42:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thank you so much for spotting this! `-c` does not work and `jlink --help` command does not list it either.  Will remove it from this part.
>
> I suspect something has got messed up in the CLI parsing. `-c` should be the short form of `--compress`. At this time, `-c`, with no params, is the equivalent of `--compress 2` so we get a confusing warning. As we've found, providing parameters to the short form doesn't seem to work.  So I think we need to dig into this more.
> 
> Also a comment on the "Deprecated values to be removed in a future release" section. It would be easy to read it that zip-0 and zip-6 are being deprecated. Instead of "Equivalent to zip-0", then maybe we should say "Use zip-0 instead".

So maybe I should investigate first what happened to `-c` argument and then improve the documentation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2536961458

From alanb at openjdk.org  Tue Nov 18 09:16:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 09:16:56 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v2]
In-Reply-To: <1_70-rAo-dpg2R9YWfhc1sjAcnUHOhcRKAxjCWWIJPc=.12de5336-ff0e-4be3-b3e6-41133e49eb56@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <eHp-k23g-OqhOUsyqZ2cDOufAKJpufu_wQSwK4tMuXE=.0cc7eeac-cc94-431b-a161-524ef94c1cd2@github.com>
 <ysZNKy9wkcIZZBOUTKqoHZnzSmTOhZRpvpu8n6m5b_s=.5077678d-b671-46de-857c-d9bdf291194b@github.com>
 <jSKQJTt25kmvoF4qtRheQmrkb8FAjmyWdq41sxlQlE0=.66e6fd51-52cc-4a80-b5af-f1248f7e5bb8@github.com>
 <1_70-rAo-dpg2R9YWfhc1sjAcnUHOhcRKAxjCWWIJPc=.12de5336-ff0e-4be3-b3e6-41133e49eb56@github.com>
Message-ID: <XzvlblpBRRWvXhoSwgFC8bekI6xF7Egm91JfvZzf6_g=.73fca675-3451-464c-bf37-d90d6b22304d@github.com>

On Tue, 18 Nov 2025 08:59:52 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> I suspect something has got messed up in the CLI parsing. `-c` should be the short form of `--compress`. At this time, `-c`, with no params, is the equivalent of `--compress 2` so we get a confusing warning. As we've found, providing parameters to the short form doesn't seem to work.  So I think we need to dig into this more.
>> 
>> Also a comment on the "Deprecated values to be removed in a future release" section. It would be easy to read it that zip-0 and zip-6 are being deprecated. Instead of "Equivalent to zip-0", then maybe we should say "Use zip-0 instead".
>
> So maybe I should investigate first what happened to `-c` argument and then improve the documentation?

That would be great, if you have the cycles.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2537021267

From mbaesken at openjdk.org  Tue Nov 18 09:23:31 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Nov 2025 09:23:31 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <Vxb5s3-a97MSfXsESNA5FmTP0qKBKZ_jYuRDW183p20=.8c2cf58d-0179-472d-b023-5671ac537bb7@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <Vxb5s3-a97MSfXsESNA5FmTP0qKBKZ_jYuRDW183p20=.8c2cf58d-0179-472d-b023-5671ac537bb7@github.com>
Message-ID: <ZLVoT69m-Ug7z8M9r4Ln6JHuRqzHcHlivn_9Fw46sbw=.ec7dd71e-42ba-4cb1-b758-c50c4e743045@github.com>

On Mon, 17 Nov 2025 01:02:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think this is completely unnecessary - `sysinfo` on Linux can't really fail, the only error possible is EFAULT if you pass a bad pointer for the struct - so don't do that.
> 
> Replacing numbers with words in the logging could break external parsing scripts.

Hi David , not sure how likely those failures are.  Back then in the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522)  we discussed the checking might be needed and that's why the JBS issue was created. 
Checking other projects for potential sysinfo failures it seems that the 'bad pointer' issue you referred to is indeed the most likely one.
But if it is really 'completely unnecessary' we should probably kick out the checks we do at a number of places in the codebase ?
https://github.com/search?q=repo%3Aopenjdk%2Fjdk+%22sysinfo%28%22&type=code

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3546401054

From mli at openjdk.org  Tue Nov 18 09:27:44 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 18 Nov 2025 09:27:44 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v5]
In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
Message-ID: <ny8egKqL-RZlT-kK96j2sFcF-O7TG3G30Gdp6EVWwvc=.a1d4ecd4-8765-424b-bd86-bee4a1136ba5@github.com>

> Hi,
> 
> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
> 
> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
> 
> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
> 
> # Test
> ## Jtreg
> 
> in progress...
> 
> ## Performance
> 
> Column names meanings:
> * p: with patch
> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> * m: without patch
> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> 
> #### Average improvement
> 
> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
> 
> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
> -- | -- | -- | --
> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
> 
> </google-sheets-html-origin>

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  replace assert with log_warning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28309/files
  - new: https://git.openjdk.org/jdk/pull/28309/files/cf9168a2..572a7b74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28309/head:pull/28309

PR: https://git.openjdk.org/jdk/pull/28309

From duke at openjdk.org  Tue Nov 18 09:38:44 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Tue, 18 Nov 2025 09:38:44 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>

> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach

Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:

  improvements according to reviewer comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28124/files
  - new: https://git.openjdk.org/jdk/pull/28124/files/df86a856..1095cf6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=07-08

  Stats: 39 lines in 1 file changed: 7 ins; 28 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28124/head:pull/28124

PR: https://git.openjdk.org/jdk/pull/28124

From mbaesken at openjdk.org  Tue Nov 18 10:07:06 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Nov 2025 10:07:06 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <4pxXV1nliz8KLnOocflpYiyrxZqADXp8ie9cXrvOfgg=.5f27e765-d8bf-4527-ba69-183fc522ef87@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

If you search github, you find also a number of places where EPERM is checked after sysinfo, not sure if this is really happening these days on our platforms ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3546620502

From jpai at openjdk.org  Tue Nov 18 10:07:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Nov 2025 10:07:07 GMT
Subject: RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS
In-Reply-To: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>
References: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>
Message-ID: <4nOVxCCsXQea7cXWT98OiMZDiK9x9qmu0n19qyuj_eg=.4123cb44-ea93-4d2f-8618-76d3273d5b76@github.com>

On Tue, 18 Nov 2025 08:24:13 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test tools/jar/ReproducibleJar.java fails when running on a file system that only supports to 2038(e.g. XFS).
> 
> Before this PR, test check if the input test time after "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to "2038-01-19T03:14:07Z", then test will skip that check.
> 
> But the extraced time created by jar equal to "1970-01-01T00:00:00Z" actually. I think the extracted time set to unix epoch time is acceptable, so this PR fix the test make test check skip when the extracted time is unix epoch time.
> 
> Change has been verified locally on XFS file system and ext4 file system.

Hello @sendaoYan, the failure here is because the extracted date/time on the directory does not match the one in the JAR file's entry for that directory (due to the underlying filesystem). Would it be possible to see which part of the JDK code is setting this date on that directory to the Unix epoch time? I haven't had a chance to go over the JAR tool's code in detail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3546620963

From viktor.klang at oracle.com  Tue Nov 18 10:17:34 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 18 Nov 2025 11:17:34 +0100
Subject: [External] : Sharing more of my experience with a custom Gatherer
 (windowBy)
In-Reply-To: <CAA9v-_NMTq_v=-i=wFA=n7DMT7T02cwU_MwjnzgkdVj2ZZUUTA@mail.gmail.com>
References: <CAA9v-_NMTq_v=-i=wFA=n7DMT7T02cwU_MwjnzgkdVj2ZZUUTA@mail.gmail.com>
Message-ID: <4205915a-e73c-4250-bb40-03500b8f97e5@oracle.com>

Thanks for sharing your experience, David!

On 2025-11-17 15:08, David Alayachew wrote:
> Hello @core-libs-dev <mailto:core-libs-dev at openjdk.org>,
>
> This is a follow up of one of my previous experience reports, a little 
> over a year ago.
>
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127293.html
>
> Just wanted to report more of my positive experiences with Gatherers, 
> specifically with a custom Gatherer that @Viktor Klang 
> <mailto:viktor.klang at oracle.com>?made for me called windowBy. Here is 
> the implementation below.
>
> <TR> Gatherer<TR, ?, List<TR>> windowBy(Predicate<TR> 
> includeInCurrentWindow) {
> ? ? class State {
> ? ? ? ? ArrayList<TR> window;
>
> ? ? ? ? boolean integrate(TR element, Gatherer.Downstream<? super 
> List<TR>> downstream) {
> ? ? ? ? ? ? if (window != null && !includeInCurrentWindow.test(element)) {
> ? ? ? ? ? ? ? ? var result = Collections.unmodifiableList(window);
> ? ? ? ? ? ? ? ? window = null;
> ? ? ? ? ? ? ? ? if (!downstream.push(result))
> ? ? ? ? ? ? ? ? ? ? return false;
> ? ? ? ? ? ? }
>
> ? ? ? ? ? ? if (window == null)
> ? ? ? ? ? ? ? ? window = new ArrayList<>();
>
> ? ? ? ? ? ? return window.add(element);
> ? ? ? ? }
>
> ? ? ? ? void finish(Gatherer.Downstream<? super List<TR>> downstream) {
> ? ? ? ? ? ? if (window != null) {
> ? ? ? ? ? ? ? ? var result = Collections.unmodifiableList(window);
> ? ? ? ? ? ? ? ? window = null;
> ? ? ? ? ? ? ? ? downstream.push(result);
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> ? ? return Gatherer.<TR, State, List<TR>>ofSequential(State::new, 
> State::integrate, State::finish);
> }
>
> Clean and simple.
>
> Anyways, as for my experience report, a found a brand new way to use 
> this custom Gatherer -- event coalescing.
>
> Sometimes, if consecutive events being streamed are of the same type, 
> then to reduce computation, you might be able to avoid doing more work 
> by grouping together the potential duplicates, then handling them 
> separately in a coalescing path. I'd much rather solve that problem 
> than a caching problem lol.
>
> Anyways, here are the 2 examples where it served me well.
>
>  1. Network Request Coalescing.
>      1. When checking the availability of certain networks, I am now
>         able to save some bandwidth by combining multiple, consecutive
>         requests within a certain time to a certain network. And since
>         I am definitely bandwidth bound, that helps. Nothing I
>         couldn't do before, but keeping it within Streams allowed me
>         to avoid ripping out my old solution when it stopped being a
>         good fit. I wish I could share the code, but it's not my right
>         to share it.
>  2. Path-Finding Algorithm -- Clustering
>      1. This one is still a work in progress, so I may be speaking
>         prematurely here. But I was so impressed that this is working
>         thus far. Long story short, I am building a path-finding
>         algorithm where, if a set of points are close enough together,
>         then they can be serviced as a group, and thus, lower the
>         total weight of servicing those nodes, as opposed to servicing
>         them individually. Again, not done yet, so I might be jumping
>         the gun, but it worked so well for me out of the box, that I
>         thought it was worth sharing.
>
> Hopefully this bumps up windowBy on the triage list of potential 
> pre-built gatherers to add to the standard library. And thanks again 
> to Viktor and friends for putting this Gatherers library together -- 
> it's a great addition!
>
> Thank you all for your time and consideration!
> David Alayachew

-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251118/4b98c699/attachment-0001.htm>

From alanb at openjdk.org  Tue Nov 18 11:06:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 11:06:01 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <4pxXV1nliz8KLnOocflpYiyrxZqADXp8ie9cXrvOfgg=.5f27e765-d8bf-4527-ba69-183fc522ef87@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <4pxXV1nliz8KLnOocflpYiyrxZqADXp8ie9cXrvOfgg=.5f27e765-d8bf-4527-ba69-183fc522ef87@github.com>
Message-ID: <E73tqYoGeh5AWo_rHcHpJA1ZmCAszHjoUdFkbwyy-AY=.d2f77906-753e-43a6-82ee-f29522f0d307@github.com>

On Tue, 18 Nov 2025 10:03:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> If you search github, you find also a number of places where EPERM is checked after sysinfo, not sure if this is really happening these days on our platforms ?

seccomp comes up periodically where random syscalls fail with EPERM as they aren't permitted by the filter. I don't know if this is what you found in your search but the possibility of seccomp or interposer libraries creates the possibility of syscall failing, or failing with errors that aren't documented for the syscall.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3546964776

From duke at openjdk.org  Tue Nov 18 11:14:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 18 Nov 2025 11:14:53 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <bwaH6vYcIoTgJYP82UEA0OOsghn-xAy6nFcrNACU-Js=.a38419f2-9c6d-4dfd-8d3c-997c69aff313@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Wrt. replacing?`StableValue` with?a?`VarHandle` access?mode, that?has the?downside of?the?variable not?being constant?foldable[^1], as?the?`@Stable`?annotation is?only?available to?the?system?domain class?loaders (bootstrap?and?platform).

[^1]: Without making?use of?`-Xbootclasspath/a:?`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3547013114

From duke at openjdk.org  Tue Nov 18 12:07:12 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Tue, 18 Nov 2025 12:07:12 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v8]
In-Reply-To: <8qkbCFPZcWmTqEq86fprDDEiLRdJsYf019AD-192scc=.6e27bbc5-e9a1-4d6d-9f25-1dd14ef97e07@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>
 <8qkbCFPZcWmTqEq86fprDDEiLRdJsYf019AD-192scc=.6e27bbc5-e9a1-4d6d-9f25-1dd14ef97e07@github.com>
Message-ID: <7foEjjFbHpUmpLTBtYvvwPQhwxHMgTPfT5dcBcfG3CI=.b9889d3e-0c47-4042-be10-6445bfcff289@github.com>

On Mon, 17 Nov 2025 17:39:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust to TestMergeStoresMemorySegment.java requirements
>
> I don't think the two private interfaces approach works - since there is only one `RuntimeException apply(String, List)` in AMSI, JLS mandates a compile error, and even if we compile, JVMS says any of these two methods can be chosen regardless of casting.

@liach 
Benchmark results for MacOS

**master**:

Benchmark                          (ELEM_SIZE)  Mode  Cnt   Score   Error  Units
SegmentBulkHash.array                        8  avgt   30   1.962 ? 0.003  ns/op
SegmentBulkHash.array                       64  avgt   30   3.701 ? 0.005  ns/op
SegmentBulkHash.heapSegment                  8  avgt   30   3.121 ? 0.007  ns/op
SegmentBulkHash.heapSegment                 64  avgt   30  12.982 ? 0.033  ns/op
SegmentBulkHash.nativeSegment                8  avgt   30   2.901 ? 0.013  ns/op
SegmentBulkHash.nativeSegment               64  avgt   30  12.825 ? 0.025  ns/op
SegmentBulkHash.nativeSegmentJava            8  avgt   30   2.483 ? 0.007  ns/op
SegmentBulkHash.nativeSegmentJava           64  avgt   30  26.347 ? 0.203  ns/op



**1095cf6**:

Benchmark                          (ELEM_SIZE)  Mode  Cnt   Score   Error  Units
SegmentBulkHash.array                        8  avgt   30   1.968 ? 0.006  ns/op
SegmentBulkHash.array                       64  avgt   30   3.713 ? 0.006  ns/op
SegmentBulkHash.heapSegment                  8  avgt   30   3.125 ? 0.004  ns/op
SegmentBulkHash.heapSegment                 64  avgt   30  12.998 ? 0.023  ns/op
SegmentBulkHash.nativeSegment                8  avgt   30   2.917 ? 0.018  ns/op
SegmentBulkHash.nativeSegment               64  avgt   30  12.868 ? 0.020  ns/op
SegmentBulkHash.nativeSegmentJava            8  avgt   30   2.484 ? 0.006  ns/op
SegmentBulkHash.nativeSegmentJava           64  avgt   30  26.324 ? 0.044  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3547302256

From pminborg at openjdk.org  Tue Nov 18 12:19:34 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 18 Nov 2025 12:19:34 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <hZs96XTneTVOWiWq1dpNb_TbEKh-mkqg0MeWj-2vE-c=.2d7207dd-dc84-40af-b360-96c4c0e26a8e@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

> Wrt. replacing?`StableValue` with?a?`VarHandle` access?mode, that?has the?downside of?the?variable not?being constant?foldable[1](#user-content-fn-1-dd52c5569368829688622e7b8db815eb), as?the?`@Stable`?annotation is?only?available to?the?system?domain class?loaders (bootstrap?and?platform).

We think we can solve that. Stay tuned.

I will integrate this PR now.

There are outstanding comments in this PR that I will address in a separate follow-up PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3547354435
PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3547357897

From mcimadamore at openjdk.org  Tue Nov 18 12:20:26 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Nov 2025 12:20:26 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v8]
In-Reply-To: <8qkbCFPZcWmTqEq86fprDDEiLRdJsYf019AD-192scc=.6e27bbc5-e9a1-4d6d-9f25-1dd14ef97e07@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>
 <8qkbCFPZcWmTqEq86fprDDEiLRdJsYf019AD-192scc=.6e27bbc5-e9a1-4d6d-9f25-1dd14ef97e07@github.com>
Message-ID: <B-RTSV8vW9bebQrPtG-lc_KS745USnnpULfOfXrB_d8=.f7d9edea-461f-41d8-9764-b1dedba0b2d6@github.com>

On Mon, 17 Nov 2025 17:39:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust to TestMergeStoresMemorySegment.java requirements
>
> I don't think the two private interfaces approach works - since there is only one `RuntimeException apply(String, List)` in AMSI, JLS mandates a compile error, and even if we compile, JVMS says any of these two methods can be chosen regardless of casting.

> @liach Benchmark results for MacOS
> 
> **master**:
> 
> ```
> Benchmark                          (ELEM_SIZE)  Mode  Cnt   Score   Error  Units
> SegmentBulkHash.array                        8  avgt   30   1.962 ? 0.003  ns/op
> SegmentBulkHash.array                       64  avgt   30   3.701 ? 0.005  ns/op
> SegmentBulkHash.heapSegment                  8  avgt   30   3.121 ? 0.007  ns/op
> SegmentBulkHash.heapSegment                 64  avgt   30  12.982 ? 0.033  ns/op
> SegmentBulkHash.nativeSegment                8  avgt   30   2.901 ? 0.013  ns/op
> SegmentBulkHash.nativeSegment               64  avgt   30  12.825 ? 0.025  ns/op
> SegmentBulkHash.nativeSegmentJava            8  avgt   30   2.483 ? 0.007  ns/op
> SegmentBulkHash.nativeSegmentJava           64  avgt   30  26.347 ? 0.203  ns/op
> ```
> 
> **1095cf6**:
> 
> ```
> Benchmark                          (ELEM_SIZE)  Mode  Cnt   Score   Error  Units
> SegmentBulkHash.array                        8  avgt   30   1.968 ? 0.006  ns/op
> SegmentBulkHash.array                       64  avgt   30   3.713 ? 0.006  ns/op
> SegmentBulkHash.heapSegment                  8  avgt   30   3.125 ? 0.004  ns/op
> SegmentBulkHash.heapSegment                 64  avgt   30  12.998 ? 0.023  ns/op
> SegmentBulkHash.nativeSegment                8  avgt   30   2.917 ? 0.018  ns/op
> SegmentBulkHash.nativeSegment               64  avgt   30  12.868 ? 0.020  ns/op
> SegmentBulkHash.nativeSegmentJava            8  avgt   30   2.484 ? 0.006  ns/op
> SegmentBulkHash.nativeSegmentJava           64  avgt   30  26.324 ? 0.044  ns/op
> ```

Bulk operation is the worst benchmark to test impact of bound checks. I think something like LoopOverNonConstant is better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3547344005

From mcimadamore at openjdk.org  Tue Nov 18 12:20:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Nov 2025 12:20:29 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
Message-ID: <0Yg0-RkPBcM2ODyT3O5hGDqksG9rHKhwVwEin4Lfke0=.f4387125-329b-48fd-8fb2-21dd5126a44a@github.com>

On Tue, 18 Nov 2025 09:38:44 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
>> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
>> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach
>
> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improvements according to reviewer comments

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 413:

> 411:     private void checkBounds(long offset, long length, BoundPolicy policy) {
> 412:         if (length > 0) {
> 413:             Preconditions.checkIndex(offset, this.length - length + 1, new BoundsCheckHandler(this, policy));

This is a very very hot path. Allocating here is gonna have negative effect, especially when this code cannot be inlined (in which case the allocation can't be scalar replaced).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2537932200

From pminborg at openjdk.org  Tue Nov 18 12:24:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 18 Nov 2025 12:24:52 GMT
Subject: Integrated: 8366178: Implement JEP 526: Lazy Constants (Second
 Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <q_NHVMDzKC3YXrUppwHly5ADB4eB7ohZhcxi6wPN8kA=.92e38494-ced1-4c6b-8d80-28409de8888e@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

This pull request has now been integrated.

Changeset: f9464499
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f94644999766e752f7d60ce52c14a7db79005035
Stats:     8347 lines in 60 files changed: 3738 ins; 4490 del; 119 mod

8366178: Implement JEP 526: Lazy Constants (Second Preview)
8371882: Improve documentation for JEP 526: Lazy Constants

Reviewed-by: jvernee, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/27605

From mcimadamore at openjdk.org  Tue Nov 18 12:29:25 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Nov 2025 12:29:25 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
Message-ID: <HOICMiMIEJ2gdT_PmidHj1FgN_gAkgC_1Kt349na37c=.e5a503be-3ee7-47f8-9d67-3898ec017a72@github.com>

On Tue, 18 Nov 2025 09:38:44 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
>> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
>> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach
>
> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improvements according to reviewer comments

The fundamental issue here is that `checkIndex` takes a bi-function for the exception generation. This forces client to resort to _instance_ methods if they want to embed more of their state description into the generated message. And this requires allocation -- which fundamentally is against the performance goals of the check bound routines in AbstractMemorySegmentImpl.

It would be better if Preconditions had more primitive, non-throwing variants which just returned true/false. Then we could easily implement whatever logic we wanted on top. Maybe we should look there first, and then come back to improve messages in the FFM API?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3547403406

From duke at openjdk.org  Tue Nov 18 12:38:13 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Tue, 18 Nov 2025 12:38:13 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <0Yg0-RkPBcM2ODyT3O5hGDqksG9rHKhwVwEin4Lfke0=.f4387125-329b-48fd-8fb2-21dd5126a44a@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
 <0Yg0-RkPBcM2ODyT3O5hGDqksG9rHKhwVwEin4Lfke0=.f4387125-329b-48fd-8fb2-21dd5126a44a@github.com>
Message-ID: <vJUKIn0RZ5asqGjBsCPrtdNFOWNFFQgOYkCWbWi0pN8=.dda2f56c-6660-4c1f-8fd4-62557360e864@github.com>

On Tue, 18 Nov 2025 12:16:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improvements according to reviewer comments
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 413:
> 
>> 411:     private void checkBounds(long offset, long length, BoundPolicy policy) {
>> 412:         if (length > 0) {
>> 413:             Preconditions.checkIndex(offset, this.length - length + 1, new BoundsCheckHandler(this, policy));
> 
> This is a very very hot path. Allocating here is gonna have negative effect, especially when this code cannot be inlined (in which case the allocation can't be scalar replaced).

Thank you for pointing this out, I believe we can move on with this solution if and only if the escape analysis eliminates instance creation. I'll run benchmarks you mentioned in order to check if it's so.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2538008716

From pminborg at openjdk.org  Tue Nov 18 13:16:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 18 Nov 2025 13:16:08 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v8]
In-Reply-To: <8qkbCFPZcWmTqEq86fprDDEiLRdJsYf019AD-192scc=.6e27bbc5-e9a1-4d6d-9f25-1dd14ef97e07@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <MPFE-9Kh1P_oKOiS8NkjR3jdd_Zq_7u51pqhKphUXLI=.93d51c82-9953-4a3a-a161-d5e4481e5664@github.com>
 <8qkbCFPZcWmTqEq86fprDDEiLRdJsYf019AD-192scc=.6e27bbc5-e9a1-4d6d-9f25-1dd14ef97e07@github.com>
Message-ID: <9fw8A0X-1ec3wj91ubB-LIJHQQdGGZRO9OTOuJZCMoU=.c909380e-eb39-4c8f-a2f3-a175ebfb5e21@github.com>

On Mon, 17 Nov 2025 17:39:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> I don't think the two private interfaces approach works - since there is only one `RuntimeException apply(String, List)` in AMSI, JLS mandates a compile error, and even if we compile, JVMS says any of these two methods can be chosen regardless of casting.

There are other ways to solve the problem if we want to go down this path. But perhaps it is better to implement a more low-level version of Preconditions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3547601009

From abimpoudis at openjdk.org  Tue Nov 18 14:48:27 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 18 Nov 2025 14:48:27 GMT
Subject: RFR: 8359145: Implement JEP 530: Primitive Types in Patterns,
 instanceof, and switch (Fourth Preview) [v5]
In-Reply-To: <jFMc8Al_l5YNHDNvxZvTvffEVNoyCCS9pQePV0GISDQ=.77ea3404-94f0-4431-b09f-0336c78439db@github.com>
References: <jFMc8Al_l5YNHDNvxZvTvffEVNoyCCS9pQePV0GISDQ=.77ea3404-94f0-4431-b09f-0336c78439db@github.com>
Message-ID: <K_YSyMkCPAKLIdSRLYHkMozkj0VC-89cxE8Mi0Fz9JE=.d44a79a8-1f49-4c68-8c43-0e3f1145bba2@github.com>

> PR for Primitive Types in Patterns, instanceof, and switch (Fourth Preview).
> 
> spec: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into JDK-8359145
 - Merge branch 'master' into JDK-8359145
 - Update comment
 - Merge branch 'master' into JDK-8359145
 - Fix regression in Check
 - Merge branch 'master' into JDK-8359145
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
 - Address review
 - 8359145: JEP 530: Implement Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

-------------

Changes: https://git.openjdk.org/jdk/pull/27637/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27637&range=04
  Stats: 774 lines in 22 files changed: 714 ins; 10 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/27637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27637/head:pull/27637

PR: https://git.openjdk.org/jdk/pull/27637

From duke at openjdk.org  Tue Nov 18 15:10:12 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Tue, 18 Nov 2025 15:10:12 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <HOICMiMIEJ2gdT_PmidHj1FgN_gAkgC_1Kt349na37c=.e5a503be-3ee7-47f8-9d67-3898ec017a72@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
 <HOICMiMIEJ2gdT_PmidHj1FgN_gAkgC_1Kt349na37c=.e5a503be-3ee7-47f8-9d67-3898ec017a72@github.com>
Message-ID: <NwssHCyZ_ilf3DloqsE4xt52-uQu8xN7qTD-7wj46jI=.49d1b08d-9ed2-4fba-9547-43071e8e2566@github.com>

On Tue, 18 Nov 2025 12:26:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improvements according to reviewer comments
>
> The fundamental issue here is that `checkIndex` takes a bi-function for the exception generation. This forces client to resort to _instance_ methods if they want to embed more of their state description into the generated message. And this requires allocation -- which fundamentally is against the performance goals of the check bound routines in AbstractMemorySegmentImpl.
> 
> It would be better if Preconditions had more primitive, non-throwing variants which just returned true/false. Then we could easily implement whatever logic we wanted on top. Maybe we should look there first, and then come back to improve messages in the FFM API?

@mcimadamore 
I measured some benchmarks

**master**:

Benchmark                                                (asTypeCompiled)  (polluteProfile)  Mode  Cnt  Score    Error  Units
LoopOverNonConstant.BB_get                                            N/A               N/A  avgt   30  0.893 ?  0.004  ns/op
LoopOverNonConstant.BB_loop                                           N/A               N/A  avgt   30  0.243 ?  0.002  ms/op
LoopOverNonConstant.segment_get                                       N/A               N/A  avgt   30  0.997 ?  0.006  ns/op
LoopOverNonConstant.segment_loop                                      N/A               N/A  avgt   30  0.236 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_instance                             N/A               N/A  avgt   30  0.237 ?  0.007  ms/op
LoopOverNonConstant.segment_loop_instance_index                       N/A               N/A  avgt   30  0.233 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_instance_unaligned                   N/A               N/A  avgt   30  0.231 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_nested                               N/A               N/A  avgt   30  0.232 ?  0.002  ms/op
LoopOverNonConstant.segment_loop_nested_unaligned                     N/A               N/A  avgt   30  0.231 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_readonly                             N/A               N/A  avgt   30  0.229 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_slice                                N/A               N/A  avgt   30  0.230 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_unaligned                            N/A               N/A  avgt   30  0.229 ?  0.001  ms/op
LoopOverNonConstant.unsafe_get                                        N/A               N/A  avgt   30  0.452 ?  0.007  ns/op
LoopOverNonConstant.unsafe_loop                                       N/A               N/A  avgt   30  0.230 ?  0.002  ms/op


**1095cf6**:

Benchmark                                                (asTypeCompiled)  (polluteProfile)  Mode  Cnt  Score    Error  Units
LoopOverNonConstant.BB_get                                            N/A               N/A  avgt   30  0.802 ?  0.007  ns/op
LoopOverNonConstant.BB_loop                                           N/A               N/A  avgt   30  0.223 ?  0.001  ms/op
LoopOverNonConstant.segment_get                                       N/A               N/A  avgt   30  0.932 ?  0.007  ns/op
LoopOverNonConstant.segment_loop                                      N/A               N/A  avgt   30  0.226 ?  0.002  ms/op
LoopOverNonConstant.segment_loop_instance                             N/A               N/A  avgt   30  0.226 ?  0.002  ms/op
LoopOverNonConstant.segment_loop_instance_index                       N/A               N/A  avgt   30  0.228 ?  0.004  ms/op
LoopOverNonConstant.segment_loop_instance_unaligned                   N/A               N/A  avgt   30  0.226 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_nested                               N/A               N/A  avgt   30  0.224 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_nested_unaligned                     N/A               N/A  avgt   30  0.223 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_readonly                             N/A               N/A  avgt   30  0.225 ?  0.001  ms/op
LoopOverNonConstant.segment_loop_slice                                N/A               N/A  avgt   30  0.226 ?  0.002  ms/op
LoopOverNonConstant.segment_loop_unaligned                            N/A               N/A  avgt   30  0.224 ?  0.001  ms/op
LoopOverNonConstant.unsafe_get                                        N/A               N/A  avgt   30  0.434 ?  0.007  ns/op
LoopOverNonConstant.unsafe_loop                                       N/A               N/A  avgt   30  0.223 ?  0.001  ms/op


<img width="1670" height="1322" alt="Screenshot 2025-11-18 at 17 03 32" src="https://github.com/user-attachments/assets/9f117a08-0e1d-4858-960e-36b19142ae92" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3548049574

From jlahoda at openjdk.org  Tue Nov 18 15:15:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Nov 2025 15:15:36 GMT
Subject: RFR: 8359145: Implement JEP 530: Primitive Types in Patterns,
 instanceof, and switch (Fourth Preview) [v5]
In-Reply-To: <K_YSyMkCPAKLIdSRLYHkMozkj0VC-89cxE8Mi0Fz9JE=.d44a79a8-1f49-4c68-8c43-0e3f1145bba2@github.com>
References: <jFMc8Al_l5YNHDNvxZvTvffEVNoyCCS9pQePV0GISDQ=.77ea3404-94f0-4431-b09f-0336c78439db@github.com>
 <K_YSyMkCPAKLIdSRLYHkMozkj0VC-89cxE8Mi0Fz9JE=.d44a79a8-1f49-4c68-8c43-0e3f1145bba2@github.com>
Message-ID: <xmyC21SUcegmXtBD1MLIYB8PoFRv0zI6hKLne1Jhj6g=.bcfc80a6-024d-445a-809f-ea0ee9a257ce@github.com>

On Tue, 18 Nov 2025 14:48:27 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> PR for Primitive Types in Patterns, instanceof, and switch (Fourth Preview).
>> 
>> spec: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8359145
>  - Merge branch 'master' into JDK-8359145
>  - Update comment
>  - Merge branch 'master' into JDK-8359145
>  - Fix regression in Check
>  - Merge branch 'master' into JDK-8359145
>    
>    # Conflicts:
>    #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
>  - Address review
>  - 8359145: JEP 530: Implement Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

Marked as reviewed by jlahoda (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27637#pullrequestreview-3478324526

From liach at openjdk.org  Tue Nov 18 15:16:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 15:16:51 GMT
Subject: RFR: 8371960: Missing null check in AnnotatedType annotation
 accessor methods
In-Reply-To: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
References: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
Message-ID: <1elSc9J6TxY5pONuS7gJ34rxtGXsfJlrnUjR72BLmcs=.6747a5e6-4022-4894-bbd8-60e5a095f8e9@github.com>

On Sun, 16 Nov 2025 16:02:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> `AnnotatedElement` methods specify they throw NPE if they take any null argument: `isAnnotationPresent`, `get(Declared)Annotation`, `get(Declared)AnnnotationsByType`. However, `AnnotatedType` has implementation quality issues that it does not throw NPE for `isAnnotationPresent` and `get(Declared)Annotation`.
> 
> This patch fixes this oversight by adding explicit null checks. For `get(Declared)AnnotationsByType`, even though it did throw exceptions, it was in the middle of parsing, so throwing it in the beginning is better.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28341#issuecomment-3548094753

From liach at openjdk.org  Tue Nov 18 15:16:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 15:16:53 GMT
Subject: Integrated: 8371960: Missing null check in AnnotatedType annotation
 accessor methods
In-Reply-To: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
References: <wMxGOGwH4MuaTvzsgLeifMndFG486vglbapx-dxyHBY=.c6f7d218-abbe-4831-b950-d1d385acafb3@github.com>
Message-ID: <aOcviS66EmlYwIgUO1XVTXTcIY80iY_q8p87pcSmRv4=.dcd781e5-b6f1-4900-bd9e-c80f194d4f44@github.com>

On Sun, 16 Nov 2025 16:02:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> `AnnotatedElement` methods specify they throw NPE if they take any null argument: `isAnnotationPresent`, `get(Declared)Annotation`, `get(Declared)AnnnotationsByType`. However, `AnnotatedType` has implementation quality issues that it does not throw NPE for `isAnnotationPresent` and `get(Declared)Annotation`.
> 
> This patch fixes this oversight by adding explicit null checks. For `get(Declared)AnnotationsByType`, even though it did throw exceptions, it was in the middle of parsing, so throwing it in the beginning is better.

This pull request has now been integrated.

Changeset: b6d83eda
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6d83eda6bfa76da98274aa3ad294759cb56d3a5
Stats:     105 lines in 2 files changed: 103 ins; 0 del; 2 mod

8371960: Missing null check in AnnotatedType annotation accessor methods

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/28341

From duke at openjdk.org  Tue Nov 18 15:18:54 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Tue, 18 Nov 2025 15:18:54 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <HOICMiMIEJ2gdT_PmidHj1FgN_gAkgC_1Kt349na37c=.e5a503be-3ee7-47f8-9d67-3898ec017a72@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
 <HOICMiMIEJ2gdT_PmidHj1FgN_gAkgC_1Kt349na37c=.e5a503be-3ee7-47f8-9d67-3898ec017a72@github.com>
Message-ID: <17ZLu1JE8YvWx8cjZ8rodkUMoPX7oUDMmWt1MblTFCA=.cfb49995-4ec1-4fba-8ad2-f9143d77e462@github.com>

On Tue, 18 Nov 2025 12:26:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> It would be better if Preconditions had more primitive, non-throwing variants which just returned true/false. Then we could easily implement whatever logic we wanted on top. Maybe we should look there first, and then come back to improve messages in the FFM API?

should separate issue on https://bugs.openjdk.org be created for such Preconditions improvement?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3548122029

From liach at openjdk.org  Tue Nov 18 15:19:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 15:19:02 GMT
Subject: RFR: 8372002: VarHandle for receiver's superclass instance fields
 fails describeConstable
In-Reply-To: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
References: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
Message-ID: <tuyCe-twQaMPLpi7dnNOBMfgzBkkBDlyEXysXGHom1M=.1826b18b-be14-4828-8510-f09c1bc4be53@github.com>

On Mon, 17 Nov 2025 16:15:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> In project Babylon work when a VarHandle needs to be unreflected, @mcimadamore discovered that our current unreflection of instance field var handles cannot unreflect instance fields from superclasses, and throws an InternalError instead.
> 
> We can easily fix this by iterating the superclasses for fields.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28355#issuecomment-3548095865

From liach at openjdk.org  Tue Nov 18 15:19:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 15:19:03 GMT
Subject: Integrated: 8372002: VarHandle for receiver's superclass instance
 fields fails describeConstable
In-Reply-To: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
References: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
Message-ID: <JNkm2g_VZUwGOgt51jla3sIKyUSl5727_exoXXCsrqA=.b22f5c61-f60e-40b6-ab15-1b4712a9cfd1@github.com>

On Mon, 17 Nov 2025 16:15:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> In project Babylon work when a VarHandle needs to be unreflected, @mcimadamore discovered that our current unreflection of instance field var handles cannot unreflect instance fields from superclasses, and throws an InternalError instead.
> 
> We can easily fix this by iterating the superclasses for fields.

This pull request has now been integrated.

Changeset: 1f99cf94
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f99cf942449728cdeb9918b93fd9a97a51eb0b6
Stats:     53 lines in 4 files changed: 38 ins; 2 del; 13 mod

8372002: VarHandle for receiver's superclass instance fields fails describeConstable

Reviewed-by: psandoz, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/28355

From mcimadamore at openjdk.org  Tue Nov 18 16:02:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Nov 2025 16:02:49 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <vJUKIn0RZ5asqGjBsCPrtdNFOWNFFQgOYkCWbWi0pN8=.dda2f56c-6660-4c1f-8fd4-62557360e864@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
 <0Yg0-RkPBcM2ODyT3O5hGDqksG9rHKhwVwEin4Lfke0=.f4387125-329b-48fd-8fb2-21dd5126a44a@github.com>
 <vJUKIn0RZ5asqGjBsCPrtdNFOWNFFQgOYkCWbWi0pN8=.dda2f56c-6660-4c1f-8fd4-62557360e864@github.com>
Message-ID: <C-gzZ9YTQhGI4FAL3YuarPqUJ126cfVIDvK6FInHcMI=.a954db6c-983d-4057-8a8c-fa4de9b1a7d4@github.com>

On Tue, 18 Nov 2025 12:35:25 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 413:
>> 
>>> 411:     private void checkBounds(long offset, long length, BoundPolicy policy) {
>>> 412:         if (length > 0) {
>>> 413:             Preconditions.checkIndex(offset, this.length - length + 1, new BoundsCheckHandler(this, policy));
>> 
>> This is a very very hot path. Allocating here is gonna have negative effect, especially when this code cannot be inlined (in which case the allocation can't be scalar replaced).
>
> Thank you for pointing this out, I believe we can move on with this solution if and only if the escape analysis eliminates instance creation. I'll run benchmarks you mentioned in order to check if it's so.

The problem is that a JMH benchmark is typically not conclusive to evaluate impact of allocation. JMH benchmarks are small, so they typically run quite hot, and C2 can inline the entire benchmark code. This means escape analysis will routinely work in this context.

To make an example -- in an early version of the FFM API, we used not to have any static `MemorySegment::copy` method. The theory was that, instead of providing methods with explicit offset/length values, we could just address these use cases with a combination of `asSlice` + `copyFrom`. This seemed to be backed up by good JMH results.

But later on, some real world testing (with Apache Lucene) revealed that the cost for creating slices was visible, especially before the application was fully warmed up. This is kind of what I'm worried about here -- in the happy case I don't doubt that performance of this PR is (very) competitive (and I like the approach of your code changes!). But in cases where the code calling the bound check cannot be JIT-compiled (there might be many reasons for this), I wonder whether performance will remain competitive.

Unfortunately I don't know a good way to test this -- perhaps try to put a `DontInline ` in some of the JMH benchmarks and measure in that mode. @JornVernee  what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2538761884

From naoto at openjdk.org  Tue Nov 18 16:01:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Nov 2025 16:01:37 GMT
Subject: RFR: 8346944: Update Unicode Data Files to 17.0.0 [v2]
In-Reply-To: <nsDPXWZTI1iW0DQjMnsPS_sXvnYJJEnVJ7vQl4Nxzi4=.084057bb-8c3d-4df0-afa2-0a4cc288cc30@github.com>
References: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>
 <H1KjzSPFDlZUJb0giZqZq3tR6h-1z1jdrJkVfP2HdzU=.c357204f-ca60-4a7c-a8de-c150e63a030a@github.com>
 <nsDPXWZTI1iW0DQjMnsPS_sXvnYJJEnVJ7vQl4Nxzi4=.084057bb-8c3d-4df0-afa2-0a4cc288cc30@github.com>
Message-ID: <NFVavd7ktv9q0RYHqUYUguXUbxUjITdu1gejbHOViQk=.5a087f48-b511-42b7-b0cb-f9b2d7a8c7db@github.com>

On Tue, 18 Nov 2025 05:08:10 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato 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 'master' into JDK-8346944-Unicode-17
>>  - icudata path fix
>>  - Update versions
>>  - icu4j final
>>  - .md file changes
>>  - 17.0 final
>>  - icudata78b(binary)
>>  - CaseFolding.text -> 17, copyright symbol as is
>>  - icudt78b
>>  - 17-beta
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1164d56b...088cdaea
>
> src/java.base/share/classes/jdk/internal/icu/util/VersionInfo.java line 57:
> 
>> 55:      */
>> 56:     @Deprecated
>> 57:     public static final String ICU_DATA_VERSION_PATH = "78b";
> 
> Now with fixed path "icudata", this seems to be no longer used.

Correct. The change was in the upstream which was just merged to our codebase: https://github.com/unicode-org/icu/commit/d93b8bb3443e02c4845eaf31859194ebeaa05232#diff-2d49053b635edae3d63d88a8b058994e7b156a50d5056ac0fb3bbfe5daa7c4e4L242

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28093#discussion_r2538755579

From liach at openjdk.org  Tue Nov 18 16:07:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 16:07:23 GMT
Subject: RFR: 8372047: ClassTransform.transformingMethodBodies andThen composes
 incorrectly
Message-ID: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>

ClassMethodTransform and ClassFieldTransform are computing the chaining condition incorrectly - the composed transform should run when any of the component wants to run instead of when all copmonents want to run.

-------------

Commit messages:
 - 8372047: ClassTransform.transformingMethodBodies andThen composes incorrectly

Changes: https://git.openjdk.org/jdk/pull/28377/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28377&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372047
  Stats: 43 lines in 2 files changed: 32 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28377/head:pull/28377

PR: https://git.openjdk.org/jdk/pull/28377

From liach at openjdk.org  Tue Nov 18 16:39:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 16:39:32 GMT
Subject: RFR: 8372047: ClassTransform.transformingMethodBodies andThen
 composes incorrectly [v2]
In-Reply-To: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
References: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
Message-ID: <MI4SG1h2009JFt8ovNFWIHxR0IKc0dShyzNMgMbSDeI=.02ae31e6-1cf1-4296-8a8c-7e772c8360d8@github.com>

> ClassMethodTransform and ClassFieldTransform are computing the chaining condition incorrectly - the composed transform should run when any of the component wants to run instead of when all copmonents want to run, and the actual content tranforms can only compose if they apply to the same set of method or fields. So we should restrict this "optimization" to same filters.

Chen Liang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8372047: ClassTransform.transformingMethodBodies andThen composes incorrectly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28377/files
  - new: https://git.openjdk.org/jdk/pull/28377/files/e1c0aad7..b5ac4fcf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28377&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28377&range=00-01

  Stats: 52 lines in 2 files changed: 20 ins; 12 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/28377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28377/head:pull/28377

PR: https://git.openjdk.org/jdk/pull/28377

From mcimadamore at openjdk.org  Tue Nov 18 16:57:23 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Nov 2025 16:57:23 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <17ZLu1JE8YvWx8cjZ8rodkUMoPX7oUDMmWt1MblTFCA=.cfb49995-4ec1-4fba-8ad2-f9143d77e462@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
 <HOICMiMIEJ2gdT_PmidHj1FgN_gAkgC_1Kt349na37c=.e5a503be-3ee7-47f8-9d67-3898ec017a72@github.com>
 <17ZLu1JE8YvWx8cjZ8rodkUMoPX7oUDMmWt1MblTFCA=.cfb49995-4ec1-4fba-8ad2-f9143d77e462@github.com>
Message-ID: <kxdkgrOKq3N6__yba58XmsLG5YDfAgsgSOSF64AFEGE=.0a1de3cb-8d87-407e-b077-0a44731036b3@github.com>

On Tue, 18 Nov 2025 15:16:20 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> > It would be better if Preconditions had more primitive, non-throwing variants which just returned true/false. Then we could easily implement whatever logic we wanted on top. Maybe we should look there first, and then come back to improve messages in the FFM API?
> 
> should separate issue on https://bugs.openjdk.org be created for such Preconditions improvement?

It would probably be cleaner, yes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3548609447

From mcimadamore at openjdk.org  Tue Nov 18 16:59:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 18 Nov 2025 16:59:35 GMT
Subject: RFR: 8372002: VarHandle for receiver's superclass instance fields
 fails describeConstable
In-Reply-To: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
References: <g2fqs2u8DQ2nvjEZf-5uOu3JE3r0kBt9a9pRVzCI8zM=.2997592d-4b92-4949-8449-f1d98db76fb8@github.com>
Message-ID: <EebOpfeFnT-ZQTH1uaEMbRVDcvBVv5-x5uzok4SIqU4=.7135ef88-6839-4fbe-b2c8-17fae41e00f5@github.com>

On Mon, 17 Nov 2025 16:15:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> In project Babylon work when a VarHandle needs to be unreflected, @mcimadamore discovered that our current unreflection of instance field var handles cannot unreflect instance fields from superclasses, and throws an InternalError instead.
> 
> We can easily fix this by iterating the superclasses for fields.

Longer term I wonder if direct VarHandle impls should have a MemberName. It seems like we're doing a lot of heroics to re-resolve something we have already resolved!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28355#issuecomment-3548624070

From jvernee at openjdk.org  Tue Nov 18 17:14:05 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 18 Nov 2025 17:14:05 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <C-gzZ9YTQhGI4FAL3YuarPqUJ126cfVIDvK6FInHcMI=.a954db6c-983d-4057-8a8c-fa4de9b1a7d4@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
 <0Yg0-RkPBcM2ODyT3O5hGDqksG9rHKhwVwEin4Lfke0=.f4387125-329b-48fd-8fb2-21dd5126a44a@github.com>
 <vJUKIn0RZ5asqGjBsCPrtdNFOWNFFQgOYkCWbWi0pN8=.dda2f56c-6660-4c1f-8fd4-62557360e864@github.com>
 <C-gzZ9YTQhGI4FAL3YuarPqUJ126cfVIDvK6FInHcMI=.a954db6c-983d-4057-8a8c-fa4de9b1a7d4@github.com>
Message-ID: <Aza9XALw3ISOmsEvYS_UgJPpLCYgFqgF8BjhsY9j1yI=.f1cbf842-3349-4371-b5a2-0a57f9e83734@github.com>

On Tue, 18 Nov 2025 15:58:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Thank you for pointing this out, I believe we can move on with this solution if and only if the escape analysis eliminates instance creation. I'll run benchmarks you mentioned in order to check if it's so.
>
> The problem is that a JMH benchmark is typically not conclusive to evaluate impact of allocation. JMH benchmarks are small, so they typically run quite hot, and C2 can inline the entire benchmark code. This means escape analysis will routinely work in this context.
> 
> To make an example -- in an early version of the FFM API, we used not to have any static `MemorySegment::copy` method. The theory was that, instead of providing methods with explicit offset/length values, we could just address these use cases with a combination of `asSlice` + `copyFrom`. This seemed to be backed up by good JMH results.
> 
> But later on, some real world testing (with Apache Lucene) revealed that the cost for creating slices was visible, especially before the application was fully warmed up. This is kind of what I'm worried about here -- in the happy case I don't doubt that performance of this PR is (very) competitive (and I like the approach of your code changes!). But in cases where the code calling the bound check cannot be JIT-compiled (there might be many reasons for this), I wonder whether performance will remain competitive.
> 
> Unfortunately I don't know a good way to test this -- perhaps try to put a `DontInline ` in some of the JMH benchmarks and measure in that mode. @JornVernee  what do you think?

I think it's preferable to avoid the allocation, and I think we can. We can throw a pre-computed exception from `checkIndex`, and then catch that in checkBoundsAccess, and checkBoundsSlice, and re-throw a new exception with the right exception message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2539039154

From duke at openjdk.org  Tue Nov 18 17:16:30 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Tue, 18 Nov 2025 17:16:30 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <kxdkgrOKq3N6__yba58XmsLG5YDfAgsgSOSF64AFEGE=.0a1de3cb-8d87-407e-b077-0a44731036b3@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
 <HOICMiMIEJ2gdT_PmidHj1FgN_gAkgC_1Kt349na37c=.e5a503be-3ee7-47f8-9d67-3898ec017a72@github.com>
 <17ZLu1JE8YvWx8cjZ8rodkUMoPX7oUDMmWt1MblTFCA=.cfb49995-4ec1-4fba-8ad2-f9143d77e462@github.com>
 <kxdkgrOKq3N6__yba58XmsLG5YDfAgsgSOSF64AFEGE=.0a1de3cb-8d87-407e-b077-0a44731036b3@github.com>
Message-ID: <ftwP2AqpHjNVHCj6Wt8wlSty3J37Fzqb3D7WuvUk8EI=.1cbb8a7e-cda9-40fa-8803-5693255cce3c@github.com>

On Tue, 18 Nov 2025 16:54:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> It would probably be cleaner, yes

I can implement this one, but I don?t have account on the tracker to create the issue

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3548718139

From jvernee at openjdk.org  Tue Nov 18 17:27:59 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 18 Nov 2025 17:27:59 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v9]
In-Reply-To: <kxdkgrOKq3N6__yba58XmsLG5YDfAgsgSOSF64AFEGE=.0a1de3cb-8d87-407e-b077-0a44731036b3@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <Nu3JdwsgCCmhetXcOCtdMF2SqMFWo6b3bJdnZ9DCRJs=.96871f06-1c90-4b7e-9f40-80acd28ca901@github.com>
 <HOICMiMIEJ2gdT_PmidHj1FgN_gAkgC_1Kt349na37c=.e5a503be-3ee7-47f8-9d67-3898ec017a72@github.com>
 <17ZLu1JE8YvWx8cjZ8rodkUMoPX7oUDMmWt1MblTFCA=.cfb49995-4ec1-4fba-8ad2-f9143d77e462@github.com>
 <kxdkgrOKq3N6__yba58XmsLG5YDfAgsgSOSF64AFEGE=.0a1de3cb-8d87-407e-b077-0a44731036b3@github.com>
Message-ID: <blvtZfy1KsfRiFMNNLOWxPm33HY_AlUJeRhdfp0ZM4k=.74b57ce3-7c07-40b4-8428-ddefc6ccddad@github.com>

On Tue, 18 Nov 2025 16:54:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> It would be better if Preconditions had more primitive, non-throwing variants which just returned true/false.

Currently the `checkIndex` method is an intrinsic that produces a corresponding `RangeCheckNode`, so I guess we can't really expect the same performance if we add our own version of this API. I think we'd need to involve the compiler team in this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3548761225

From smarks at openjdk.org  Tue Nov 18 17:39:18 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 18 Nov 2025 17:39:18 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v8]
In-Reply-To: <UKGxnqO8V9PF0bNd0e_E3jjt3JqoH3dfm2VwBr0sQww=.af941765-2ab4-44cb-8596-37438c071d36@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <UKGxnqO8V9PF0bNd0e_E3jjt3JqoH3dfm2VwBr0sQww=.af941765-2ab4-44cb-8596-37438c071d36@github.com>
Message-ID: <h7ChZCecgHuhfp1keZZ0t4aW_Gar_OAbb8JjcsUB_gM=.4aa6cc2f-69d0-45aa-85b5-63c696cf5e83@github.com>

On Mon, 17 Nov 2025 15:42:35 GMT, jengebr <duke at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing explicit classname

Marked as reviewed by smarks (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28116#pullrequestreview-3478995078

From jtyuzawa at gmail.com  Tue Nov 18 17:44:40 2025
From: jtyuzawa at gmail.com (James Yuzawa)
Date: Tue, 18 Nov 2025 12:44:40 -0500
Subject: ThreadLocalRandom.nextGaussian() uses locking Random.nextGaussian()
 implementation
Message-ID: <DC08E336-4682-4B24-95A7-59E5017C483E@gmail.com>

Hello,

I have noticed in Java 25 (and earlier versions) that calling ThreadLocalRandom.current().nextGaussian() uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.

Here is a very simple reproducer:

ThreadLocalRandom r = ThreadLocalRandom.current();
// step into this call using a debugger
r.nextGaussian();

It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.

Sketch:

public interface RandomGenerator {
	default double nextGaussian() {
		// remove TAOCP comment since it is out of date
		return RandomSupport.computeNextGaussian(this);
	}
}

public class Random implements RandomGenerator {
	@Override
	public synchronized double nextGaussian() {
		// synchronized version ...
	}
}

public class ThreadLocalRandom extends Random {

	// ADD THIS
	@Override
	public double nextGaussian() {
		return RandomSupport.computeNextGaussian(this);
	}
}

A comment on ThreadLocalRandom introduced in JDK-8248862 states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to JDK-8248862 and a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.

I have a patch which remedies this by using the same implementation as RandomGenerator. I am willing to submit https://github.com/openjdk/jdk/compare/master...yuzawa-san:jdk:refs/heads/thread-local-random-nextGaussian Per the contribution instructions, I have signed the OCA in prior work on project Panama, but am looking for community input, sponsorship, and help creating an issue if this is something we wish to pursue.

Thank you,

James Yuzawa

From duke at openjdk.org  Tue Nov 18 17:56:14 2025
From: duke at openjdk.org (duke)
Date: Tue, 18 Nov 2025 17:56:14 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v8]
In-Reply-To: <UKGxnqO8V9PF0bNd0e_E3jjt3JqoH3dfm2VwBr0sQww=.af941765-2ab4-44cb-8596-37438c071d36@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <UKGxnqO8V9PF0bNd0e_E3jjt3JqoH3dfm2VwBr0sQww=.af941765-2ab4-44cb-8596-37438c071d36@github.com>
Message-ID: <_kKAJoGLxBoYxxNPbGrOJYvkOgW7kNbht43GsS4zNzI=.d5714dfb-0992-43b2-80f4-09b798c509f2@github.com>

On Mon, 17 Nov 2025 15:42:35 GMT, jengebr <duke at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing explicit classname

@jengebr 
Your change (at version 04d9f35eac998c8d158df585557730d289be13ce) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3548872096

From smarks at openjdk.org  Tue Nov 18 18:01:46 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 18 Nov 2025 18:01:46 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v8]
In-Reply-To: <UKGxnqO8V9PF0bNd0e_E3jjt3JqoH3dfm2VwBr0sQww=.af941765-2ab4-44cb-8596-37438c071d36@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <UKGxnqO8V9PF0bNd0e_E3jjt3JqoH3dfm2VwBr0sQww=.af941765-2ab4-44cb-8596-37438c071d36@github.com>
Message-ID: <VSZHxHxLsjTeZ8Ikte5iWzYBvYTyugd5AfN3vfqOD6I=.c22f7696-3c9f-4551-aed9-caa459ae1b17@github.com>

On Mon, 17 Nov 2025 15:42:35 GMT, jengebr <duke at openjdk.org> wrote:

>> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
>> 
>> ## Problem Context
>> 
>> ### ArrayList.addAll() Inefficiency
>> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
>> 
>> 1. Call `c.toArray()` - creates intermediate array
>> 2. Call `System.arraycopy()` to copy from intermediate array to destination
>> 3. Discard intermediate array
>> 
>> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
>> 
>> ### Collections.SingletonSet toArray() Missing Implementation
>> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
>> 
>> 1. Creates an Object[] of the expected size
>> 2. Iterates through the collection (1 element)
>> 3. Ensures "expected" size is the actual size
>> 4. Returns the array
>> 
>> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
>> 
>> ## Optimized Methods
>> 
>> ### ArrayList
>> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
>> 
>> ### Collections.SingletonSet
>> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
>> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
>> 
>> ## Performance Impact
>> 
>> | Class | Method | Size | Baseline | Optimized | Improvement |
>> |-------|--------|------|----------|-----------|-------------|
>> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **...
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing explicit classname

I'm running this through our internal CI system again and I can sponsor this when the run finishes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3548895677

From naoto at openjdk.org  Tue Nov 18 18:35:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Nov 2025 18:35:08 GMT
Subject: RFR: 8346944: Update Unicode Data Files to 17.0.0 [v2]
In-Reply-To: <H1KjzSPFDlZUJb0giZqZq3tR6h-1z1jdrJkVfP2HdzU=.c357204f-ca60-4a7c-a8de-c150e63a030a@github.com>
References: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>
 <H1KjzSPFDlZUJb0giZqZq3tR6h-1z1jdrJkVfP2HdzU=.c357204f-ca60-4a7c-a8de-c150e63a030a@github.com>
Message-ID: <tiQgIDhQp4x1-82QwWq5G4IWWiR6MqDmTzASL4YVatw=.62a28fdc-cd67-4375-ac88-6ee56396bf27@github.com>

On Mon, 17 Nov 2025 19:15:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Updates the JDK to use the latest Unicode 17.0.0, which also updates the ICU4J along with it ([8346947](https://bugs.openjdk.org/browse/JDK-8346947)
>> Update ICU4J to Version 78.1). The corresponding CSR has already been approved.
>
> Naoto Sato 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 'master' into JDK-8346944-Unicode-17
>  - icudata path fix
>  - Update versions
>  - icu4j final
>  - .md file changes
>  - 17.0 final
>  - icudata78b(binary)
>  - CaseFolding.text -> 17, copyright symbol as is
>  - icudt78b
>  - 17-beta
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/5b5b354e...088cdaea

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28093#issuecomment-3549048474

From naoto at openjdk.org  Tue Nov 18 18:39:20 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Nov 2025 18:39:20 GMT
Subject: Integrated: 8346944: Update Unicode Data Files to 17.0.0
In-Reply-To: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>
References: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>
Message-ID: <sLvXl2QGfBKvjcTGALkY38UTygWIOBE5Y1IBFbWmB6g=.75243c6f-edcc-4a13-b05b-39908c7e6c5e@github.com>

On Fri, 31 Oct 2025 20:53:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updates the JDK to use the latest Unicode 17.0.0, which also updates the ICU4J along with it ([8346947](https://bugs.openjdk.org/browse/JDK-8346947)
> Update ICU4J to Version 78.1). The corresponding CSR has already been approved.

This pull request has now been integrated.

Changeset: 4a975637
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a975637a144fa8aa449a1419e656721833513b5
Stats:     2977 lines in 35 files changed: 1345 ins; 650 del; 982 mod

8346944: Update Unicode Data Files to 17.0.0
8346947: Update ICU4J to Version 78.1

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/28093

From jlu at openjdk.org  Tue Nov 18 18:51:19 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Nov 2025 18:51:19 GMT
Subject: RFR: 8346944: Update Unicode Data Files to 17.0.0 [v2]
In-Reply-To: <H1KjzSPFDlZUJb0giZqZq3tR6h-1z1jdrJkVfP2HdzU=.c357204f-ca60-4a7c-a8de-c150e63a030a@github.com>
References: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>
 <H1KjzSPFDlZUJb0giZqZq3tR6h-1z1jdrJkVfP2HdzU=.c357204f-ca60-4a7c-a8de-c150e63a030a@github.com>
Message-ID: <a37eWZnXoMh6FrSmGa32gkzN02uytdR5cQT26xtC_s0=.b89cf6fc-df44-4a23-9afa-076eb77e04b5@github.com>

On Mon, 17 Nov 2025 19:15:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Updates the JDK to use the latest Unicode 17.0.0, which also updates the ICU4J along with it ([8346947](https://bugs.openjdk.org/browse/JDK-8346947)
>> Update ICU4J to Version 78.1). The corresponding CSR has already been approved.
>
> Naoto Sato 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 'master' into JDK-8346944-Unicode-17
>  - icudata path fix
>  - Update versions
>  - icu4j final
>  - .md file changes
>  - 17.0 final
>  - icudata78b(binary)
>  - CaseFolding.text -> 17, copyright symbol as is
>  - icudt78b
>  - 17-beta
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/40595ac9...088cdaea

lgtm. (Looks like I missed integration by a few minutes; perhaps my comment can go into Unicode 18)

src/java.base/share/classes/java/lang/Character.java line 746:

> 744:     public static final class UnicodeBlock extends Subset {
> 745:         /**
> 746:          * NUM_ENTITIES should match the total number of UnicodeBlocks.

I thought at first `NUM_ENTITIES` should be 790 due to 8 new `UnicodeBlock`s being added. However, it does go up to 804, becasue the total number includes the identifiers _and_ aliases (which is still a single `UnicodeBlock`). I think that distinction is worth correcting in the comment.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28093#pullrequestreview-3479235676
PR Review Comment: https://git.openjdk.org/jdk/pull/28093#discussion_r2539282547

From aph at openjdk.org  Tue Nov 18 19:07:35 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 18 Nov 2025 19:07:35 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64
In-Reply-To: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
Message-ID: <qDqhKa-Kemp2X37XkXV9twnAQHA0L9_awKCnqz-XWOA=.4f7ce8a0-9bbc-46c4-9080-8b46fbf5e7c0@github.com>

On Thu, 13 Nov 2025 20:41:56 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial.
> Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN).

src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp line 271:

> 269:     fmovd(rscratch1, v0); // rscratch1 = AS_LONG_BITS(X)
> 270:     lea(rscratch2, ExternalAddress((address)_L_tbl));
> 271:     movz(tmp5, 0x7F);

Comments are needed here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2533464197

From dhanalla at openjdk.org  Tue Nov 18 19:07:34 2025
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Tue, 18 Nov 2025 19:07:34 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log on
 aarch64
Message-ID: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>

This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial.
Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN).

-------------

Commit messages:
 - [AArch64] Math.log is 10% slower than StrictMath.log on aarch64
 - [AArch64] Math.log is 10% slower than StrictMath.log on aarch64
 - [AArch64] Math.log is 10% slower than StrictMath.log on aarch64
 - [AArch64] Math.log is 10% slower than StrictMath.log on aarch64
 - [AArch64] Math.log is 10% slower than StrictMath.log on macosx-aarch64
 - [AArch64] Math.log is 10% slower than StrictMath.log on macosx-aarch64

Changes: https://git.openjdk.org/jdk/pull/28306/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28306&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308776
  Stats: 544 lines in 7 files changed: 541 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28306/head:pull/28306

PR: https://git.openjdk.org/jdk/pull/28306

From naoto at openjdk.org  Tue Nov 18 19:31:20 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Nov 2025 19:31:20 GMT
Subject: RFR: 8346944: Update Unicode Data Files to 17.0.0 [v2]
In-Reply-To: <a37eWZnXoMh6FrSmGa32gkzN02uytdR5cQT26xtC_s0=.b89cf6fc-df44-4a23-9afa-076eb77e04b5@github.com>
References: <LsNyLjV346AgIE-jGXcJm3_uhYhnnD8FbmTXUjWqxaY=.51286aa7-7b98-4549-aeb9-d988920b1016@github.com>
 <H1KjzSPFDlZUJb0giZqZq3tR6h-1z1jdrJkVfP2HdzU=.c357204f-ca60-4a7c-a8de-c150e63a030a@github.com>
 <a37eWZnXoMh6FrSmGa32gkzN02uytdR5cQT26xtC_s0=.b89cf6fc-df44-4a23-9afa-076eb77e04b5@github.com>
Message-ID: <tw0-Z0tF4kPD-mlVDIboitrHTBI2HGTOL3BmdKKg1Ak=.576287b0-67c1-4e60-85a2-3affd90e2d5a@github.com>

On Tue, 18 Nov 2025 18:35:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato 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 'master' into JDK-8346944-Unicode-17
>>  - icudata path fix
>>  - Update versions
>>  - icu4j final
>>  - .md file changes
>>  - 17.0 final
>>  - icudata78b(binary)
>>  - CaseFolding.text -> 17, copyright symbol as is
>>  - icudt78b
>>  - 17-beta
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/e05cdfee...088cdaea
>
> src/java.base/share/classes/java/lang/Character.java line 746:
> 
>> 744:     public static final class UnicodeBlock extends Subset {
>> 745:         /**
>> 746:          * NUM_ENTITIES should match the total number of UnicodeBlocks.
> 
> I thought at first `NUM_ENTITIES` should be 790 due to 8 new `UnicodeBlock`s being added. However, it does go up to 804, becasue the total number includes the identifiers _and_ aliases (which is still a single `UnicodeBlock`). I think that distinction is worth correcting in the comment.

Good point. Filed: https://bugs.openjdk.org/browse/JDK-8372117

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28093#discussion_r2539417303

From almatvee at openjdk.org  Tue Nov 18 21:49:38 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 18 Nov 2025 21:49:38 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v2]
In-Reply-To: <3UhSkVXKJRRjZltFQ4rQCaLhTidnSrHhQM9FaZPtUeM=.f6a9267c-c126-4664-bfb3-4c42e99e4ecb@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>
 <wWseNRIo-GmXg0fO6DvGaj07i9jD1NwxU9H-76x6rXE=.2afe2757-4518-44fc-a137-621deddf0b4b@github.com>
 <7NpPTV1ZExp4fNeytAFrbj1u_8mK6GtcQ5X8dsOMkXs=.0bc405bd-df04-4c16-abec-c585a0c1b7ab@github.com>
 <nWBv8_MphAjKlnW_6eNbERwdu59M7bOhO7WdPj-u6Tg=.22f9b78e-f534-47c2-9a9f-22d1907a6b02@github.com>
 <3UhSkVXKJRRjZltFQ4rQCaLhTidnSrHhQM9FaZPtUeM=.f6a9267c-c126-4664-bfb3-4c42e99e4ecb@github.com>
Message-ID: <LEZy93UF4dOTDNRzK9nq8833ZnM5PWcTfeMTy_bS-kQ=.cde651b6-7e3e-4a4b-8448-a883165b37cc@github.com>

On Tue, 18 Nov 2025 02:53:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> > Yes, NoMPathRuntimeTest.java, MainClassTest.java and CookedRuntimeTest.java will fail without bin folder check.
> 
> I don't quite understand this.
> 
> As far as I can see, we don't have tests that specifically target this new feature. Am I missing anything?

`Files.isDirectory(env.resolvedLayout().runtimeDirectory().resolve("bin"))` was added to cover cased with `--app-image` and `--runtime-image`. `CookedRuntimeTest` test covers it except it only generates predefined runtime with `bin` folder. I will modified it to cover both cases with `bin` and without `bin` folder.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3549522161

From epeter at openjdk.org  Tue Nov 18 21:49:40 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 18 Nov 2025 21:49:40 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64
In-Reply-To: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
Message-ID: <9s7p49-bYB_amcD0q2XuEpeNPy4Ud1p38pE-UHEyB7c=.b9ef99f0-2381-4a83-856a-bc0dd273f4f1@github.com>

On Thu, 13 Nov 2025 20:41:56 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial.
> Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN).

Drive-by, cannot promise a full review. But I'm interested ;)

Mostly, I have questions about testing. Are there already tests for accuracy somewhere?

Do you have any benchmark results to support this PR? It would be good if we had a way to prove that performance is good for all sorts of inputs. I suppose we don't have any loops here, so we should just make sure to benchmark cases so that all possible paths of the intrinsic are covered, right?

src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 835:

> 833:       break;
> 834:     case vmIntrinsics::_dlog:
> 835:       // Math.log intrinsic is not implemented on AArch64 (see JDK-8210858),

Drive-by comment, and since you are removing this comment:
What is the state of https://bugs.openjdk.org/browse/JDK-8210858 ?

src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp line 3:

> 1: /* Copyright (c) 2018, Cavium. All rights reserved. (By BELLSOFT)
> 2:  * Copyright (c) 2016, 2021, Intel Corporation. All rights reserved.
> 3:  * Intel Math Library (LIBM) Source Code

Are the dates supposed to be updated? Maybe not, just asking.

test/jdk/java/lang/Math/TestLogMinValue.java line 28:

> 26:  * @bug 8308776
> 27:  * @build Tests
> 28:  * @summary Compare Math.log and StrictMath.log for Double.MIN_VALUE (denormal smallest positive) to ensure consistency.

Are there tests that check for consistency of the other values?

test/jdk/java/lang/Math/TestLogMonotonicity.java line 53:

> 51:             double nv = v * 2.0;
> 52:             if (nv == v)
> 53:                 break;

Suggestion:

            if (nv == v) {
                break;
            }

test/jdk/java/lang/Math/TestLogMonotonicity.java line 61:

> 59:         // Powers of two 2^1 .. 2^16
> 60:         for (int i = 1; i <= 16; i++) {
> 61:             list.add(Math.pow(2.0, i));

It seems you now only cover powers of 2, right? Is this sufficient? I don't know what other tests already exist, so maybe this is already covered elsewhere?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28306#pullrequestreview-3479700917
PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2539647684
PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2539650297
PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2539667697
PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2539657565
PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2539669991

From asemenyuk at openjdk.org  Tue Nov 18 21:49:38 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Nov 2025 21:49:38 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v2]
In-Reply-To: <LEZy93UF4dOTDNRzK9nq8833ZnM5PWcTfeMTy_bS-kQ=.cde651b6-7e3e-4a4b-8448-a883165b37cc@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <2epMsbAq5d0vqvFQ8bMqSg0SbVfgdhDNdLfphIdoOdw=.b1f46657-d621-4387-abb4-a6a65733f79a@github.com>
 <wWseNRIo-GmXg0fO6DvGaj07i9jD1NwxU9H-76x6rXE=.2afe2757-4518-44fc-a137-621deddf0b4b@github.com>
 <7NpPTV1ZExp4fNeytAFrbj1u_8mK6GtcQ5X8dsOMkXs=.0bc405bd-df04-4c16-abec-c585a0c1b7ab@github.com>
 <nWBv8_MphAjKlnW_6eNbERwdu59M7bOhO7WdPj-u6Tg=.22f9b78e-f534-47c2-9a9f-22d1907a6b02@github.com>
 <3UhSkVXKJRRjZltFQ4rQCaLhTidnSrHhQM9FaZPtUeM=.f6a9267c-c126-4664-bfb3-4c42e99e4ecb@github.com>
 <LEZy93UF4dOTDNRzK9nq8833ZnM5PWcTfeMTy_bS-kQ=.cde651b6-7e3e-4a4b-8448-a883165b37cc@github.com>
Message-ID: <KGStX5FzxR_BQ1alMYPO_YAxl09unkI8nDlOT0ud32c=.e5f2aa92-fe3b-436a-bfa3-4f47870ce7af@github.com>

On Tue, 18 Nov 2025 21:05:07 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> CookedRuntimeTest test covers it except it only generates predefined runtime with bin folder.

That is what I thought.

> I will modified it to cover both cases with bin and without bin folder.

Sounds good. Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3549558901

From epeter at openjdk.org  Tue Nov 18 21:49:41 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 18 Nov 2025 21:49:41 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64
In-Reply-To: <9s7p49-bYB_amcD0q2XuEpeNPy4Ud1p38pE-UHEyB7c=.b9ef99f0-2381-4a83-856a-bc0dd273f4f1@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
 <9s7p49-bYB_amcD0q2XuEpeNPy4Ud1p38pE-UHEyB7c=.b9ef99f0-2381-4a83-856a-bc0dd273f4f1@github.com>
Message-ID: <Lsot8T8Xe2hd1kalJeF2GMILFvR0ZZ6nItr91NNaES8=.254ecb21-c6e5-4f45-82f1-7be43112c3d0@github.com>

On Tue, 18 Nov 2025 20:49:33 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial.
>> Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN).
>
> test/jdk/java/lang/Math/TestLogMinValue.java line 28:
> 
>> 26:  * @bug 8308776
>> 27:  * @build Tests
>> 28:  * @summary Compare Math.log and StrictMath.log for Double.MIN_VALUE (denormal smallest positive) to ensure consistency.
> 
> Are there tests that check for consistency of the other values?

Do we have tests that already check for sufficient accuracy?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2539670255

From darcy at openjdk.org  Tue Nov 18 21:49:45 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Nov 2025 21:49:45 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64
In-Reply-To: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
Message-ID: <qW2UPFPlrIUuOTcOiU3_uqy687wnT54s9Mu8YOtI8V4=.ef8d809e-2d50-4f9c-b56f-8bc3043791a3@github.com>

On Thu, 13 Nov 2025 20:41:56 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial.
> Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN).

test/jdk/java/lang/Math/TestLogMinValue.java line 40:

> 38:         }
> 39:         if (mathLog != strictLog) {
> 40:             throw new AssertionError("Mismatch: Math.log=" + mathLog + " StrictMath.log=" + strictLog);

Is this assertion justified by the Math.log specification?

test/jdk/java/lang/Math/TestLogMonotonicity.java line 29:

> 27:  * @run main TestLogMonotonicity
> 28:  */
> 29: public class TestLogMonotonicity {

So the test is checking for monotonicity over value that are 2X the previous value?

That is a very weak test.

In other math library regression tests we test for monotonicity on successive values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2539695976
PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2539698410

From dl at openjdk.org  Tue Nov 18 22:27:46 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 18 Nov 2025 22:27:46 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v17]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <U3F2QHXV7Onf7wOejfGj1L77PzZ5LOFWeCa4LKGLjlE=.614d39c5-0439-47ad-a516-878a37c200e9@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Tweaks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/0f2f5908..40a624e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=15-16

  Stats: 110 lines in 1 file changed: 17 ins; 27 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From duke at openjdk.org  Tue Nov 18 23:39:46 2025
From: duke at openjdk.org (jengebr)
Date: Tue, 18 Nov 2025 23:39:46 GMT
Subject: Integrated: 8371164: ArrayList.addAll() optimizations
In-Reply-To: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
Message-ID: <QdxrForUTiCTdQbYGz1xRkpje0Q6IjaLhlkcGgFgYXw=.c00ebcbe-c75f-4b10-a0f1-59e6f0110918@github.com>

On Mon, 3 Nov 2025 20:45:44 GMT, jengebr <duke at openjdk.org> wrote:

> # JVM Collections Optimizations: Eliminating toArray() Performance Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in ArrayList.addAll() and Collections.SingletonSet.toArray() methods by implementing direct optimizations that bypass inefficient intermediate allocations and abstract implementations. The optimizations target high-frequency operations identified through profiling analysis, delivering 37% performance improvements for ArrayList operations and 17-43% performance improvements for SingletonSet operations under real-world conditions where multiple collection types are used.
> 
> ## Problem Context
> 
> ### ArrayList.addAll() Inefficiency
> ArrayList.addAll() currently calls `c.toArray()` on the source collection to avoid iterator-based copying, but this creates unnecessary intermediate array allocation when the source is also an ArrayList. The method performs:
> 
> 1. Call `c.toArray()` - creates intermediate array
> 2. Call `System.arraycopy()` to copy from intermediate array to destination
> 3. Discard intermediate array
> 
> When both source and destination are ArrayList instances, this can be optimized to direct array copying.
> 
> ### Collections.SingletonSet toArray() Missing Implementation
> Collections.SingletonSet inherits the default `AbstractCollection.toArray()` implementation, which:
> 
> 1. Creates an Object[] of the expected size
> 2. Iterates through the collection (1 element)
> 3. Ensures "expected" size is the actual size
> 4. Returns the array
> 
> For a single-element collection, this overhead is disproportionate to the actual work needed. Additionally, this implementation is vulnerable to call site poisoning, showing 74-118% performance degradation under megamorphic conditions.
> 
> ## Optimized Methods
> 
> ### ArrayList
> - **`addAll(Collection<? extends E> c)`**: Added fast path for ArrayList-to-ArrayList copying using direct `System.arraycopy()` from source's internal `elementData` array, eliminating intermediate `toArray()` allocation
> 
> ### Collections.SingletonSet
> - **`toArray()`**: Direct implementation returning `new Object[] {element}`
> - **`toArray(T[] a)`**: Direct implementation with proper array sizing and null termination per Collection contract
> 
> ## Performance Impact
> 
> | Class | Method | Size | Baseline | Optimized | Improvement |
> |-------|--------|------|----------|-----------|-------------|
> | ArrayList | addAll | 0 | 10.149 ns/op, 40 B/op | 3.929 ns/op, 24 B/op | **61% faster, 40% less allocation** |
> | ArrayList | addAll | 5 | 23.804 ns/op, 104 B...

This pull request has now been integrated.

Changeset: aeea8497
Author:    John Engebretson <jengebr at amazon.com>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aeea8497562aabda12f292ad93c9f0f6935cc842
Stats:     179 lines in 4 files changed: 175 ins; 1 del; 3 mod

8371164: ArrayList.addAll() optimizations

Reviewed-by: smarks, ogillespie

-------------

PR: https://git.openjdk.org/jdk/pull/28116

From almatvee at openjdk.org  Wed Nov 19 00:35:23 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 19 Nov 2025 00:35:23 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v5]
In-Reply-To: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
Message-ID: <dMCNaR409G7eGPrLIM_1_Urp8QynY1FgpvCpaRxy6ks=.fe1d2a69-6123-4676-9fde-85819112210e@github.com>

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v6]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28033/files
  - new: https://git.openjdk.org/jdk/pull/28033/files/b353b466..0ff6d34f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28033&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28033&range=03-04

  Stats: 15 lines in 1 file changed: 13 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28033/head:pull/28033

PR: https://git.openjdk.org/jdk/pull/28033

From almatvee at openjdk.org  Wed Nov 19 00:38:19 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 19 Nov 2025 00:38:19 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v4]
In-Reply-To: <AK44tiFiWZ4bk1eiZOMbcZwUDoawZKb1fku5ql5gClU=.0902275a-47ef-40a0-80bc-951f1a76771d@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <AK44tiFiWZ4bk1eiZOMbcZwUDoawZKb1fku5ql5gClU=.0902275a-47ef-40a0-80bc-951f1a76771d@github.com>
Message-ID: <RlIfSAXGsY3nYe2cR_2EtP5tdjgeW3kPiLrF_a0OLYs=.912a5fd0-369e-4293-b24b-e91e513fcebf@github.com>

On Tue, 18 Nov 2025 02:16:55 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added JDK specific keys/values to Info.plist of embedded runtime.
>> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
>> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v5]

8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v6]
- Updated `CookedRuntimeTest` to cover test case without `bin` folder on macOS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3550041583

From dlong at openjdk.org  Wed Nov 19 01:42:03 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 19 Nov 2025 01:42:03 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64
In-Reply-To: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
Message-ID: <5Z9vlKxZLXWCQR6MmvxJF16gqSblYGxMeRZPQjVeNOw=.3fc4f163-533e-4bed-8666-b82de2c3f7e4@github.com>

On Thu, 13 Nov 2025 20:41:56 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial.
> Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN).

If it was explained somewhere why Math.log is 10% slower than StrictMath.log, I missed it.  I would naively assume that Math.log can use the StrictMath.log implementation and get the same performance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28306#issuecomment-3550193135

From darcy at openjdk.org  Wed Nov 19 02:10:22 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 19 Nov 2025 02:10:22 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64
In-Reply-To: <5Z9vlKxZLXWCQR6MmvxJF16gqSblYGxMeRZPQjVeNOw=.3fc4f163-533e-4bed-8666-b82de2c3f7e4@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
 <5Z9vlKxZLXWCQR6MmvxJF16gqSblYGxMeRZPQjVeNOw=.3fc4f163-533e-4bed-8666-b82de2c3f7e4@github.com>
Message-ID: <fbpwo4mGAKrGp1Hr1Kgr4DoEhM73ne7G5QBUxEmyqZk=.ec03819f-d73f-41a5-8de4-6118e8da8b33@github.com>

On Wed, 19 Nov 2025 01:38:40 GMT, Dean Long <dlong at openjdk.org> wrote:

> If it was explained somewhere why Math.log is 10% slower than StrictMath.log, I missed it. I would naively assume that Math.log can use the StrictMath.log implementation and get the same performance.

Yes, the methods in StrictMath are a legal implementation of the corresponding methods in Math.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28306#issuecomment-3550343344

From asemenyuk at openjdk.org  Wed Nov 19 05:29:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 19 Nov 2025 05:29:10 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime [v5]
In-Reply-To: <dMCNaR409G7eGPrLIM_1_Urp8QynY1FgpvCpaRxy6ks=.fe1d2a69-6123-4676-9fde-85819112210e@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
 <dMCNaR409G7eGPrLIM_1_Urp8QynY1FgpvCpaRxy6ks=.fe1d2a69-6123-4676-9fde-85819112210e@github.com>
Message-ID: <TyiPncIWBJ0HYDt_jFitdugT45_tMHqhBNxM1JETTZY=.4ab80a1d-9423-47ab-a6dc-db5c1dab80f6@github.com>

On Wed, 19 Nov 2025 00:35:23 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added JDK specific keys/values to Info.plist of embedded runtime.
>> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
>> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v6]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28033#pullrequestreview-3480873966

From stuart.marks at oracle.com  Wed Nov 19 05:48:51 2025
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 18 Nov 2025 21:48:51 -0800
Subject: Could we add headList and tailList methods to j.u.List?
In-Reply-To: <CAA9v-_PD4cd5QfT1tK1nj_g7E575O=eeWgaMAsNO5Wx+TLyMdQ@mail.gmail.com>
References: <CAA9v-_PD4cd5QfT1tK1nj_g7E575O=eeWgaMAsNO5Wx+TLyMdQ@mail.gmail.com>
Message-ID: <0cb56a20-466b-4513-8b37-a3686aade656@oracle.com>



On 11/16/25 10:51 AM, David Alayachew wrote:
> Could we add headList(int) and tailList(int) to j.u.List? I searched JBS and found 
> nothing.
> 
> It's commonly what people want when doing subList(int, int), so this should be 
> pretty well received.

Maybe. :-)

There's a nexus of diffuse concerns here.

One concern is subranges of things in general, such as Strings, CharSequences, 
Lists, and arrays. Subranges are all expressed as methods with (start, end) 
parameters. These are powerful enough to do anything you need to do, but they're 
sometimes inconvenient.

One reason these can be inconvenient is related to the second concern, which is that 
sometimes the APIs require the creation of a local variable, which in turn forces an 
expression to turn into a statement. For example, consider a task of getting a 
String from somewhere, taking the first three characters, and passing that elsewhere 
to perform further work. One can write that as

     furtherWork(getString().substring(0, 3));

But if you want to take the *last* three characters and pass them along, you have to 
do this:

     var tmp = getString();
     furtherWork(tmp.substring(tmp.length() - 3));

This isn't terrible, but sometimes it disrupts an expression to declare a local 
variable.

At least there is a one-arg substring method that takes characters to the end of the 
string. If this method weren't there, you'd have to call length() twice (or store 
the length in another local variable). Again, not terrible, but yet another thing 
that adds friction.

A third concern is that people come along and ask whether we can have something in 
Java that's rather like Python's slices. For a variety of reasons I don't think we 
should accept negative indexes or step values other than 1, but there are some 
things that probably occur frequently. For example, to get the last three characters 
of a string, one can write s[-3:]. That's pretty nice.

You had asked about List, not String, but I think similar issues apply. I'd guess 
that String and substring operations are a lot more frequent than subList 
operations. But maybe you have some subList use cases in mind. Could you give more 
details about what you're thinking of?

> In that case, would be nice if we could add an entry to JBS with a Won't Fix, to 
> make it easier for those looking to see why not. Maybe even link this thread for 
> further reading.

Heh, yeah I've done that a couple times -- filed a bug just to close it out with an 
explanation why. I was wondering whether anybody would find that useful. I think 
this topic is worth some discussion, though, so I won't do that quite yet. :-)

s'marks


From dholmes at openjdk.org  Wed Nov 19 06:43:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 06:43:20 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v3]
In-Reply-To: <k3dikddABdh7ZedN6N9WjNAUAHz8hH0JnehkEnHTqrI=.e8def0c4-6229-462d-bdec-2d0b868f0eae@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <k3dikddABdh7ZedN6N9WjNAUAHz8hH0JnehkEnHTqrI=.e8def0c4-6229-462d-bdec-2d0b868f0eae@github.com>
Message-ID: <E8Rew0ig4zOTmggLaoja-KSyWTc3B37Z3pRlwPy1PgI=.1e616e48-59d1-4d78-bebe-e7c8a2e8d67e@github.com>

On Sun, 16 Nov 2025 08:45:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chen Liang 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:
>> 
>>  - From review
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
>>  - Rephrase for parameterTypes contains null
>>  - Rename tests to be more specific
>>  - Split annotated type new checks to another patch
>>  - Redundant
>>  - Test and more fixes
>>  - Copyright years
>>  - Testing
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/edfda06d...51ef5789
>
> src/java.base/share/classes/java/lang/Class.java line 3839:
> 
>> 3837:      */
>> 3838:     public boolean isNestmateOf(Class<?> c) {
>> 3839:         Objects.requireNonNull(c);
> 
> So the behavior change here is calling isNestmateOf(null) on a class object for a primitive or array class will throw NPE when it didn't throw it previously.  Technically an incompatible change but I agree it's in the weeds when it comes to impact.

A null check was not considered necessary for this API. If you ask `c.isNestMateOf(null)` the answer is `false`. We chose not to report you had "asked a stupid question".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2540733026

From dholmes at openjdk.org  Wed Nov 19 06:49:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 06:49:50 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v3]
In-Reply-To: <k3dikddABdh7ZedN6N9WjNAUAHz8hH0JnehkEnHTqrI=.e8def0c4-6229-462d-bdec-2d0b868f0eae@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <k3dikddABdh7ZedN6N9WjNAUAHz8hH0JnehkEnHTqrI=.e8def0c4-6229-462d-bdec-2d0b868f0eae@github.com>
Message-ID: <AqI-ISshFzmPmuoh_doaBnFurbU5KIxtxhOKEs_1KC8=.7de95210-0db4-4598-b94e-61a9b54b0ea5@github.com>

On Sun, 16 Nov 2025 08:45:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chen Liang 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:
>> 
>>  - From review
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
>>  - Rephrase for parameterTypes contains null
>>  - Rename tests to be more specific
>>  - Split annotated type new checks to another patch
>>  - Redundant
>>  - Test and more fixes
>>  - Copyright years
>>  - Testing
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/9a3fb483...51ef5789
>
> src/java.base/share/classes/java/lang/Class.java line 3839:
> 
>> 3837:      */
>> 3838:     public boolean isNestmateOf(Class<?> c) {
>> 3839:         Objects.requireNonNull(c);
> 
> So the behavior change here is calling isNestmateOf(null) on a class object for a primitive or array class will throw NPE when it didn't throw it previously.  Technically an incompatible change but I agree it's in the weeds when it comes to impact.

Removed erroneous comment

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2540743370

From dholmes at openjdk.org  Wed Nov 19 07:34:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 07:34:30 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v3]
In-Reply-To: <AqI-ISshFzmPmuoh_doaBnFurbU5KIxtxhOKEs_1KC8=.7de95210-0db4-4598-b94e-61a9b54b0ea5@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <k3dikddABdh7ZedN6N9WjNAUAHz8hH0JnehkEnHTqrI=.e8def0c4-6229-462d-bdec-2d0b868f0eae@github.com>
 <AqI-ISshFzmPmuoh_doaBnFurbU5KIxtxhOKEs_1KC8=.7de95210-0db4-4598-b94e-61a9b54b0ea5@github.com>
Message-ID: <E8rnvaqo-gbxByH-4TYQpGQ0C5zA1OE6Jzf8V52R5wI=.03a181d8-0306-4f45-8122-76c1e2738747@github.com>

On Wed, 19 Nov 2025 06:45:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 3839:
>> 
>>> 3837:      */
>>> 3838:     public boolean isNestmateOf(Class<?> c) {
>>> 3839:         Objects.requireNonNull(c);
>> 
>> So the behavior change here is calling isNestmateOf(null) on a class object for a primitive or array class will throw NPE when it didn't throw it previously.  Technically an incompatible change but I agree it's in the weeds when it comes to impact.
>
> Removed erroneous comment

I went back through the nestmates design archives that I have to see if this particular issue was ever raised but I could not find it called out. I'm not a fan of explicit null checks as they penalize all the good code. I also don't think the inconsistency is/was an issue. If code does not need to use a parameter to complete its function then it also doesn't need to validate the unused parameter. YMMV.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2540864248

From alan.bateman at oracle.com  Wed Nov 19 07:44:25 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Nov 2025 07:44:25 +0000
Subject: ThreadLocalRandom.nextGaussian() uses locking
 Random.nextGaussian() implementation
In-Reply-To: <DC08E336-4682-4B24-95A7-59E5017C483E@gmail.com>
References: <DC08E336-4682-4B24-95A7-59E5017C483E@gmail.com>
Message-ID: <e97aa82f-dad8-4924-8f6c-dcdbeed9ec17@oracle.com>



On 18/11/2025 17:44, James Yuzawa wrote:
> Hello,
>
> I have noticed in Java 25 (and earlier versions) that calling ThreadLocalRandom.current().nextGaussian() uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>
>
I think this is a mistake that crept in with JEP 356 in JDK 17 and the 
follow up work. We need to create an issue in JBS to track this.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251119/1371c9c7/attachment-0001.htm>

From asotona at openjdk.org  Wed Nov 19 07:45:11 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Nov 2025 07:45:11 GMT
Subject: RFR: 8372047: ClassTransform.transformingMethodBodies andThen
 composes incorrectly [v2]
In-Reply-To: <MI4SG1h2009JFt8ovNFWIHxR0IKc0dShyzNMgMbSDeI=.02ae31e6-1cf1-4296-8a8c-7e772c8360d8@github.com>
References: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
 <MI4SG1h2009JFt8ovNFWIHxR0IKc0dShyzNMgMbSDeI=.02ae31e6-1cf1-4296-8a8c-7e772c8360d8@github.com>
Message-ID: <_a8jn8P1C2K_1jEVIYdJGFXapubX9tdFBg244L7JOIc=.52e29f2d-0b75-4649-b99f-f0f4d4c54ae3@github.com>

On Tue, 18 Nov 2025 16:39:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ClassMethodTransform and ClassFieldTransform are computing the chaining condition incorrectly - the composed transform should run when any of the component wants to run instead of when all copmonents want to run, and the actual content tranforms can only compose if they apply to the same set of method or fields. So we should restrict this "optimization" to same filters.
>
> Chen Liang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8372047: ClassTransform.transformingMethodBodies andThen composes incorrectly

src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java line 123:

> 121:         @Override
> 122:         public ClassTransform andThen(ClassTransform next) {
> 123:             if (next instanceof ClassMethodTransform(var nextTransform, var nextFilter) && filter == nextFilter)

I'm trying to figure out a case where filters of the chained transforms are identical.
Is it covered by some tests?
Unless there is a real benefit in a frequent use case I suggest to remove this optimization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28377#discussion_r2540884396

From asotona at openjdk.org  Wed Nov 19 07:53:43 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Nov 2025 07:53:43 GMT
Subject: RFR: 8367585: Prevent creation of unrepresentable Utf8Entry [v3]
In-Reply-To: <lKAEDkjEZd7M2snPwoXp5LjO5QffNN3m-QYyenqwvq4=.58becf07-3f94-4a41-b224-cabb3c4aa340@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
 <lKAEDkjEZd7M2snPwoXp5LjO5QffNN3m-QYyenqwvq4=.58becf07-3f94-4a41-b224-cabb3c4aa340@github.com>
Message-ID: <xDCu1LceIusWCBiPirIPSIUOuNsru4k79svaTXtCdA4=.84593ec8-711c-4b2c-b803-f941d298934c@github.com>

On Fri, 14 Nov 2025 21:43:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> John Rose suggests in https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that ClassFile API should validate Utf8Entry length eagerly upon construction. Currently we validate upon writing to bytes, which avoids validation overhead. However, given that most class file utf8 data are shorter than 1/3 of the max length, which is always an encodable length, the performance impact should be low.
>> 
>> Preventing the creation of unrepresentable UTF8 entries can prevent passing such invalid instances around, making such problems easier to debug than a failure at building.
>> 
>> Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of the regularly run transformation benchmarks seems neutral, less than 5% perturbations.
>> 
>> I will update docs to reflect this change, given how widespread this is across JDK - it seems the only exempt classes are Signature, ClassSignature, and MethodSignature.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

It looks good in this form.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27281#pullrequestreview-3481288186

From alan.bateman at oracle.com  Wed Nov 19 07:57:47 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Nov 2025 07:57:47 +0000
Subject: ThreadLocalRandom.nextGaussian() uses locking
 Random.nextGaussian() implementation
In-Reply-To: <e97aa82f-dad8-4924-8f6c-dcdbeed9ec17@oracle.com>
References: <DC08E336-4682-4B24-95A7-59E5017C483E@gmail.com>
 <e97aa82f-dad8-4924-8f6c-dcdbeed9ec17@oracle.com>
Message-ID: <4c74686d-9cf4-40a8-930d-aa513de71954@oracle.com>



On 19/11/2025 07:44, Alan Bateman wrote:
>
> We need to create an issue in JBS to track this.

I've created JDK-8372134 [1] to track this.

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8372134

From dholmes at openjdk.org  Wed Nov 19 08:00:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 08:00:46 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <E73tqYoGeh5AWo_rHcHpJA1ZmCAszHjoUdFkbwyy-AY=.d2f77906-753e-43a6-82ee-f29522f0d307@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <4pxXV1nliz8KLnOocflpYiyrxZqADXp8ie9cXrvOfgg=.5f27e765-d8bf-4527-ba69-183fc522ef87@github.com>
 <E73tqYoGeh5AWo_rHcHpJA1ZmCAszHjoUdFkbwyy-AY=.d2f77906-753e-43a6-82ee-f29522f0d307@github.com>
Message-ID: <yS2-J8Qow_bjlLIVO4lqxn4G5NemzOa_984A9PPbpts=.00b5e805-0bc3-4ec7-a6ac-ee91cd10b05f@github.com>

On Tue, 18 Nov 2025 11:01:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> the possibility of seccomp or interposer libraries creates the possibility of syscall failing, or failing with errors that aren't documented for the syscall.

That certainly complicates things and could potentially invalidate any code where we check for the expected/specified set of errors. I grudgingly withdraw my objection.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3551288993

From dholmes at openjdk.org  Wed Nov 19 08:00:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 08:00:46 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <6wi89g5vMiAiGZzgljM43lQwsgOA5dc94LNBd64AktI=.5e954a04-6e28-4453-8bdd-4c7341a9fb69@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

src/hotspot/os/linux/os_linux.cpp line 2455:

> 2453:     os::print_dhm(st, "OS uptime:", (long) sinfo.uptime);
> 2454:   } else {
> 2455:     st->print_cr("OS uptime could not be retrieved.");

I think an assert would be preferable here. This code can't be parsed so I think it better not to inject it.

src/hotspot/os/linux/os_linux.cpp line 2594:

> 2592:   } else {
> 2593:     st->print(", swap could not be determined");
> 2594:   }

Again probably better to assert and say nothing, or use 0 as a placeholder.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2540928254
PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2540930104

From cushon at openjdk.org  Wed Nov 19 08:34:09 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 19 Nov 2025 08:34:09 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v6]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <3x5-_dlxTal-kAmIH6aSBDPdHKVzsuXmUuO9fCQK0OM=.03d185dc-d5bd-486e-a6c0-36c293dadd52@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:

 - Updates from panama-dev thread
 - .

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/b729b551..3f6ee815

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=04-05

  Stats: 278 lines in 9 files changed: 228 ins; 15 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From abimpoudis at openjdk.org  Wed Nov 19 08:51:28 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 19 Nov 2025 08:51:28 GMT
Subject: Integrated: 8359145: Implement JEP 530: Primitive Types in Patterns, 
 instanceof, and switch (Fourth Preview)
In-Reply-To: <jFMc8Al_l5YNHDNvxZvTvffEVNoyCCS9pQePV0GISDQ=.77ea3404-94f0-4431-b09f-0336c78439db@github.com>
References: <jFMc8Al_l5YNHDNvxZvTvffEVNoyCCS9pQePV0GISDQ=.77ea3404-94f0-4431-b09f-0336c78439db@github.com>
Message-ID: <JtMItjVUDYPOPcO3vfvHdTNiQuxSr547ApUMSx-M5XY=.8d7908c2-1315-4bdc-a1bf-b4ce32cba583@github.com>

On Sun, 5 Oct 2025 13:55:14 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> PR for Primitive Types in Patterns, instanceof, and switch (Fourth Preview).
> 
> spec: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

This pull request has now been integrated.

Changeset: 99135d2e
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99135d2e05bb501fe9f9f0d36abd25894d0f93de
Stats:     774 lines in 22 files changed: 714 ins; 10 del; 50 mod

8359145: Implement JEP 530: Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/27637

From galder at openjdk.org  Wed Nov 19 09:18:35 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 19 Nov 2025 09:18:35 GMT
Subject: RFR: 8372119: Missing copyright header in MinMaxVector
Message-ID: <QgQzaCpP8hWV8jnYHb-asJJFASYygMjGdiZdwEJ-0pg=.8671d8ed-82ae-4fc8-ba3f-02966666fc28@github.com>

Trivial PR to add missing copyright header in JMH benchmark.

-------------

Commit messages:
 - 8372119: Missing copyright header in MinMaxVector

Changes: https://git.openjdk.org/jdk/pull/28387/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28387&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372119
  Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28387/head:pull/28387

PR: https://git.openjdk.org/jdk/pull/28387

From cushon at openjdk.org  Wed Nov 19 10:14:41 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 19 Nov 2025 10:14:41 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/3f6ee815..0593827f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=05-06

  Stats: 30 lines in 4 files changed: 3 ins; 14 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From mbaesken at openjdk.org  Wed Nov 19 10:17:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 10:17:09 GMT
Subject: RFR: 8333871: check sysinfo return values [v3]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <dWoDleZzlIUEFhYnTXBzlwZxo8PQ4dtyVL9pbJ02n5k=.7054e3ee-a6d3-4e82-a2c1-983328de4f35@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  use more asserts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28317/files
  - new: https://git.openjdk.org/jdk/pull/28317/files/e9d2b1b4..6284ef29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=01-02

  Stats: 6 lines in 1 file changed: 2 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28317/head:pull/28317

PR: https://git.openjdk.org/jdk/pull/28317

From mbaesken at openjdk.org  Wed Nov 19 10:17:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 10:17:11 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <6wi89g5vMiAiGZzgljM43lQwsgOA5dc94LNBd64AktI=.5e954a04-6e28-4453-8bdd-4c7341a9fb69@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <6wi89g5vMiAiGZzgljM43lQwsgOA5dc94LNBd64AktI=.5e954a04-6e28-4453-8bdd-4c7341a9fb69@github.com>
Message-ID: <Ki5GNjd8J2LL9SV0VqSjgzLwkMS8_kqyZCaDIuxfX-s=.7950c785-3469-4b27-b2d0-b2e6948744c5@github.com>

On Wed, 19 Nov 2025 07:57:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   0 - terminate not needed
>
> src/hotspot/os/linux/os_linux.cpp line 2594:
> 
>> 2592:   } else {
>> 2593:     st->print(", swap could not be determined");
>> 2594:   }
> 
> Again probably better to assert and say nothing, or use 0 as a placeholder.

Hi David, I added asserts where you suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2541371007

From haraldei at openjdk.org  Wed Nov 19 10:54:42 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Wed, 19 Nov 2025 10:54:42 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v5]
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <iVqtHfbx6gEG7V2kLK7mZqU2mu1btqxGnvWxyebUQNE=.5469e731-ebf3-48d9-897c-d356cc3ccc90@github.com>

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:

  use suggested solution by bsdkurt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28235/files
  - new: https://git.openjdk.org/jdk/pull/28235/files/c723058e..efbbfc3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28235/head:pull/28235

PR: https://git.openjdk.org/jdk/pull/28235

From haraldei at openjdk.org  Wed Nov 19 10:54:43 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Wed, 19 Nov 2025 10:54:43 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v4]
In-Reply-To: <OUMDlAzMnr9FL9zIpSYc4FTkoh8amuHiMlMYde6YD0E=.f04784a8-f89b-4c4d-9279-5fec912afa18@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <OUMDlAzMnr9FL9zIpSYc4FTkoh8amuHiMlMYde6YD0E=.f04784a8-f89b-4c4d-9279-5fec912afa18@github.com>
Message-ID: <75m-8lwmrGuTsq7VZG_wvDEFFlDZzxaUCHcAwDRjBJY=.f1d8b83d-1893-4eac-8558-f3d09e54ad8c@github.com>

On Sun, 16 Nov 2025 18:09:47 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix calculation of allocationSize when byteAlignment < MAX_MALLOC_ALIGN
>   
>   This work was sponsored by: The FreeBSD Foundation

> I believe this is the most concise way to support weak alignment allocators: [bsdkurt at bb45e82](https://github.com/bsdkurt/jdk/commit/bb45e82a8772e50e321f07af37470fc4360b0adf)

I think so too, I've updated the PR with the change now. Let's see if the tests agree. Both FreeBSD and Linux seemed happy on my local setup at least.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3552042604

From davidalayachew at gmail.com  Wed Nov 19 11:54:22 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 19 Nov 2025 06:54:22 -0500
Subject: Could we add headList and tailList methods to j.u.List?
In-Reply-To: <0cb56a20-466b-4513-8b37-a3686aade656@oracle.com>
References: <CAA9v-_PD4cd5QfT1tK1nj_g7E575O=eeWgaMAsNO5Wx+TLyMdQ@mail.gmail.com>
 <0cb56a20-466b-4513-8b37-a3686aade656@oracle.com>
Message-ID: <CAA9v-_PxfUQcppKX48majs+CsPE2VKNWCZeQnmM6BMSD+G+vmQ@mail.gmail.com>

Thanks for the response @Stuart Marks <stuart.marks at oracle.com>!

> A third concern is that people come along and ask whether we can
> have something in Java that's rather like Python's slices.

Hah, this email started out as a request for Python slices lol. But I came
to the same conclusion as you.

I am quite curious about what Project Amber has to say about this. Range
patterns, for example.

> You had asked about List, not String, but I think similar issues apply.
> I'd guess that String and substring operations are a lot more frequent
> than subList operations. But maybe you have some subList use cases in
> mind. Could you give more details about what you're thinking of?

I definitely agree that there is heavy overlap in the problem spaces of
subList and substring.

As for use cases, mostly Path-Finding algorithms and NLP
<https://en.wikipedia.org/wiki/Natural_language_processing> work. The PFA
is mostly self explanatory, but for NLP, I splice up Strings in a bunch of
different ways. You have to cycle through different permutations of word
groupings to anchor a phrase to a concept (so I get to use both substring
and subList lol). And each concept has an associated type for it -- a
permitted subtype of a sealed type (which may itself be another permitted
subtype of another).

Since most of this is me trimming from the front or end, it became way more
manageable to make headList and subList for myself. So, I think that they
could be useful for others too.

I will say -- zooming out (while thinking of the substring/subList
duality), String and List are just Sequences of X. Maybe there is value in
making something more broad here? Maybe some Sequence-like interface where
we expose some helpful range methods? It would all devolve to the statement
forms you mentioned earlier. And in an ideal world, Project Amber could
latch onto that if/when range patterns go live. I remember watching this
video by Brian Goetz about Growing the Language
<https://www.youtube.com/watch?v=Gz7Or9C0TpM>. It kind of feels like an
interface like this would be very amenable, though I might also be thinking
too far ahead lol.

On Wed, Nov 19, 2025 at 12:48?AM Stuart Marks <stuart.marks at oracle.com>
wrote:

>
>
> On 11/16/25 10:51 AM, David Alayachew wrote:
> > Could we add headList(int) and tailList(int) to j.u.List? I searched JBS
> and found
> > nothing.
> >
> > It's commonly what people want when doing subList(int, int), so this
> should be
> > pretty well received.
>
> Maybe. :-)
>
> There's a nexus of diffuse concerns here.
>
> One concern is subranges of things in general, such as Strings,
> CharSequences,
> Lists, and arrays. Subranges are all expressed as methods with (start,
> end)
> parameters. These are powerful enough to do anything you need to do, but
> they're
> sometimes inconvenient.
>
> One reason these can be inconvenient is related to the second concern,
> which is that
> sometimes the APIs require the creation of a local variable, which in turn
> forces an
> expression to turn into a statement. For example, consider a task of
> getting a
> String from somewhere, taking the first three characters, and passing that
> elsewhere
> to perform further work. One can write that as
>
>      furtherWork(getString().substring(0, 3));
>
> But if you want to take the *last* three characters and pass them along,
> you have to
> do this:
>
>      var tmp = getString();
>      furtherWork(tmp.substring(tmp.length() - 3));
>
> This isn't terrible, but sometimes it disrupts an expression to declare a
> local
> variable.
>
> At least there is a one-arg substring method that takes characters to the
> end of the
> string. If this method weren't there, you'd have to call length() twice
> (or store
> the length in another local variable). Again, not terrible, but yet
> another thing
> that adds friction.
>
> A third concern is that people come along and ask whether we can have
> something in
> Java that's rather like Python's slices. For a variety of reasons I don't
> think we
> should accept negative indexes or step values other than 1, but there are
> some
> things that probably occur frequently. For example, to get the last three
> characters
> of a string, one can write s[-3:]. That's pretty nice.
>
> You had asked about List, not String, but I think similar issues apply.
> I'd guess
> that String and substring operations are a lot more frequent than subList
> operations. But maybe you have some subList use cases in mind. Could you
> give more
> details about what you're thinking of?
>
> > In that case, would be nice if we could add an entry to JBS with a Won't
> Fix, to
> > make it easier for those looking to see why not. Maybe even link this
> thread for
> > further reading.
>
> Heh, yeah I've done that a couple times -- filed a bug just to close it
> out with an
> explanation why. I was wondering whether anybody would find that useful. I
> think
> this topic is worth some discussion, though, so I won't do that quite yet.
> :-)
>
> s'marks
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251119/2a398be7/attachment-0001.htm>

From chagedorn at openjdk.org  Wed Nov 19 12:29:16 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 19 Nov 2025 12:29:16 GMT
Subject: RFR: 8372119: Missing copyright header in MinMaxVector
In-Reply-To: <QgQzaCpP8hWV8jnYHb-asJJFASYygMjGdiZdwEJ-0pg=.8671d8ed-82ae-4fc8-ba3f-02966666fc28@github.com>
References: <QgQzaCpP8hWV8jnYHb-asJJFASYygMjGdiZdwEJ-0pg=.8671d8ed-82ae-4fc8-ba3f-02966666fc28@github.com>
Message-ID: <PSS5QJGjjsai20CokpWh_tSKaHalP8tUGjWzbAmcYeQ=.c044e680-8693-4aaf-b41a-de162ff3053f@github.com>

On Wed, 19 Nov 2025 09:07:22 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> Trivial PR to add missing copyright header in JMH benchmark.

Looks good and trivial.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28387#pullrequestreview-3482443651

From mbaesken at openjdk.org  Wed Nov 19 12:34:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 12:34:43 GMT
Subject: RFR: 8333871: Check sysinfo return values [v4]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <uqLoUHT3pm7xIpY7tvqNAMxIqQAfjmmB-jzhoeMfh5U=.1b79dc7e-0c7a-4017-a18f-2e741337c065@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

Matthias Baesken 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:

 - Merge remote-tracking branch 'origin/master' into JDK-8333871
 - use more asserts
 - 0 - terminate not needed
 - JDK-8333871

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28317/files
  - new: https://git.openjdk.org/jdk/pull/28317/files/6284ef29..2f4c7c94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=02-03

  Stats: 86 lines in 5 files changed: 67 ins; 6 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28317/head:pull/28317

PR: https://git.openjdk.org/jdk/pull/28317

From duke at openjdk.org  Wed Nov 19 12:37:02 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 19 Nov 2025 12:37:02 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v5]
In-Reply-To: <iVqtHfbx6gEG7V2kLK7mZqU2mu1btqxGnvWxyebUQNE=.5469e731-ebf3-48d9-897c-d356cc3ccc90@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <iVqtHfbx6gEG7V2kLK7mZqU2mu1btqxGnvWxyebUQNE=.5469e731-ebf3-48d9-897c-d356cc3ccc90@github.com>
Message-ID: <NuoLbZziufKTOnGalgo2Bu2fs23MVYBJXcfQr6xoT0o=.08241a26-7b59-4268-9a02-d02b943d3916@github.com>

On Wed, 19 Nov 2025 10:54:42 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use suggested solution by bsdkurt

src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 215:

> 213:             result = Utils.alignUp(allocationBase, byteAlignment);
> 214:         } else {
> 215:             allocationSize = (alignedSize < byteAlignment) ? byteAlignment : alignedSize;

This can probably use [`Math?::max?(long,?long)`], which is an intrinsic[^1].
Suggestion:

            allocationSize = Math.max(alignedSize, byteAlignment);


[^1]: For whatever reason, [`StrictMath?::max?(long,?long)`] is?the?only?overload which?doesn?t?have `@IntrinsicCandidate`, even?though it?s?just a?simple?call to?`Math?::max?(long,?long)`, and?so?gets intrisified?anyway after?inlining; same?with [`StrictMath?::min?(long,?long)`] and?[`Math?::min?(long,?long)`].

[`Math?::max?(long,?long)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Math.html#max%28long%2Clong%29
[`Math?::min?(long,?long)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Math.html#min%28long%2Clong%29
[`StrictMath?::max?(long,?long)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/StrictMath.html#max%28long%2Clong%29
[`StrictMath?::min?(long,?long)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/StrictMath.html#min%28long%2Clong%29

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2541810615

From duke at openjdk.org  Wed Nov 19 12:44:27 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 19 Nov 2025 12:44:27 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v23]
In-Reply-To: <ccjONjaWl9NC1pfg5h7pftIjtCSvlgHpreCLPvpjYs0=.b40d7438-c775-41f5-b341-91fa20ff2f84@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <cmiCHyxoygmKRBJr0k-6v69EGaLUF6YSBkgZkxwIa_8=.75e26131-d106-4fa4-9168-acddc0c08bf2@github.com>
 <moDgiO0Wfo9G3OriAvqQU1ug42ze11uJMOoDGbFLTO0=.0b51eb1d-9566-4b05-957a-9bf580a56ccc@github.com>
 <ccjONjaWl9NC1pfg5h7pftIjtCSvlgHpreCLPvpjYs0=.b40d7438-c775-41f5-b341-91fa20ff2f84@github.com>
Message-ID: <TOxYQ7wOcEWv8QrBPlxUR34vy1HXpAdBsRaXuXNmlKo=.68dd2395-76a7-43af-a6b6-e7d439f328c4@github.com>

On Mon, 10 Nov 2025 08:03:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/util/UUID/UUIDTest.java line 154:
>> 
>>> 152:         long timestamp = System.currentTimeMillis();
>>> 153:         try {
>>> 154:             UUID u = UUID.ofEpochMillis(timestamp);
>> 
>> Note?that this?test will?start?failing in?20889?[HE].
>> 
>> [HE]: https://en.wikipedia.org/wiki/Holocene_calendar
>
> Hello @ExE-Boss, what would be the failure in that case? I had a very brief look at the linked page and I couldn't relate how that impacts the timestamp based `UUID.ofEpochMillis(...)`.

`UUID::ofEpochMillis` throws?`IllegalArgumentException` when?the?timestamp doesn?t?fit within?48?bits, and?+10889-08-02T05:31:50.656Z[^1] needs?49?bits to?represent, which?is?tested on?line?183:
https://github.com/openjdk/jdk/blob/27613619899658cdf17c154839606b111e6cf8f0/test/jdk/java/util/UUID/UUIDTest.java#L180-L185

[^1]: At?the?start of?August?20889?[HE].

[HE]: https://en.wikipedia.org/wiki/Holocene_calendar

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2541831537

From mbaesken at openjdk.org  Wed Nov 19 12:52:07 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 12:52:07 GMT
Subject: RFR: 8333871: Check sysinfo return values [v5]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <3ykgR3X2ByYyZAPZQC594cFLuyhFYZr-9ZpsWR8I5A0=.20122600-a79f-4c0e-af46-53e11ec37e47@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge master
 - Merge remote-tracking branch 'origin/master' into JDK-8333871
 - use more asserts
 - 0 - terminate not needed
 - JDK-8333871

-------------

Changes: https://git.openjdk.org/jdk/pull/28317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=04
  Stats: 15 lines in 2 files changed: 8 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28317/head:pull/28317

PR: https://git.openjdk.org/jdk/pull/28317

From pminborg at openjdk.org  Wed Nov 19 13:26:40 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Nov 2025 13:26:40 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP
Message-ID: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>

This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).

-------------

Commit messages:
 - Adress comments in original PR
 - Add sections

Changes: https://git.openjdk.org/jdk/pull/28388/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28388&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372146
  Stats: 25 lines in 6 files changed: 6 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28388/head:pull/28388

PR: https://git.openjdk.org/jdk/pull/28388

From haraldei at openjdk.org  Wed Nov 19 13:29:28 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Wed, 19 Nov 2025 13:29:28 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:

  Replace conditional with Math.max intrinsic
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28235/files
  - new: https://git.openjdk.org/jdk/pull/28235/files/efbbfc3e..d5232988

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28235/head:pull/28235

PR: https://git.openjdk.org/jdk/pull/28235

From haraldei at openjdk.org  Wed Nov 19 13:29:30 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Wed, 19 Nov 2025 13:29:30 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v5]
In-Reply-To: <NuoLbZziufKTOnGalgo2Bu2fs23MVYBJXcfQr6xoT0o=.08241a26-7b59-4268-9a02-d02b943d3916@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <iVqtHfbx6gEG7V2kLK7mZqU2mu1btqxGnvWxyebUQNE=.5469e731-ebf3-48d9-897c-d356cc3ccc90@github.com>
 <NuoLbZziufKTOnGalgo2Bu2fs23MVYBJXcfQr6xoT0o=.08241a26-7b59-4268-9a02-d02b943d3916@github.com>
Message-ID: <Dgp6OoFxtSOUDF8B-Klyaq-Ag8vBUS6QvAjGH7ulRMY=.5713a8b9-d616-4059-9f6a-2c3ba8d8f3dd@github.com>

On Wed, 19 Nov 2025 12:30:00 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use suggested solution by bsdkurt
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 215:
> 
>> 213:             result = Utils.alignUp(allocationBase, byteAlignment);
>> 214:         } else {
>> 215:             allocationSize = (alignedSize < byteAlignment) ? byteAlignment : alignedSize;
> 
> This can probably use [`Math?::max?(long,?long)`], which is an intrinsic[^1].
> Suggestion:
> 
>             allocationSize = Math.max(alignedSize, byteAlignment);
> 
> 
> [^1]: For whatever reason, [`StrictMath?::max?(long,?long)`] is?the?only?overload which?doesn?t?have `@IntrinsicCandidate`, even?though it?s?just a?simple?call to?`Math?::max?(long,?long)`, and?so?gets intrisified?anyway after?inlining; same?with [`StrictMath?::min?(long,?long)`] and?[`Math?::min?(long,?long)`].
> 
> [`Math?::max?(long,?long)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Math.html#max%28long%2Clong%29
> [`Math?::min?(long,?long)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Math.html#min%28long%2Clong%29
> [`StrictMath?::max?(long,?long)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/StrictMath.html#max%28long%2Clong%29
> [`StrictMath?::min?(long,?long)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/StrictMath.html#min%28long%2Clong%29

That makes sense, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2542003220

From liach at openjdk.org  Wed Nov 19 13:31:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Nov 2025 13:31:47 GMT
Subject: RFR: 8372047: ClassTransform.transformingMethodBodies andThen
 composes incorrectly [v2]
In-Reply-To: <_a8jn8P1C2K_1jEVIYdJGFXapubX9tdFBg244L7JOIc=.52e29f2d-0b75-4649-b99f-f0f4d4c54ae3@github.com>
References: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
 <MI4SG1h2009JFt8ovNFWIHxR0IKc0dShyzNMgMbSDeI=.02ae31e6-1cf1-4296-8a8c-7e772c8360d8@github.com>
 <_a8jn8P1C2K_1jEVIYdJGFXapubX9tdFBg244L7JOIc=.52e29f2d-0b75-4649-b99f-f0f4d4c54ae3@github.com>
Message-ID: <yeXVwxLH2-CFiZTUxANrlHELH9vOfIbeOWTliz9oF_o=.6e75d368-234d-48c6-bf8f-e4fa5cc5d971@github.com>

On Wed, 19 Nov 2025 07:40:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8372047: ClassTransform.transformingMethodBodies andThen composes incorrectly
>
> src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java line 123:
> 
>> 121:         @Override
>> 122:         public ClassTransform andThen(ClassTransform next) {
>> 123:             if (next instanceof ClassMethodTransform(var nextTransform, var nextFilter) && filter == nextFilter)
> 
> I'm trying to figure out a case where filters of the chained transforms are identical.
> Is it covered by some tests?
> Unless there is a real benefit in a frequent use case I suggest to remove this optimization.

This is only intended for the no-filter transform, which uses the same stateless lambda.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28377#discussion_r2542016226

From liach at openjdk.org  Wed Nov 19 13:34:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Nov 2025 13:34:53 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v3]
In-Reply-To: <E8rnvaqo-gbxByH-4TYQpGQ0C5zA1OE6Jzf8V52R5wI=.03a181d8-0306-4f45-8122-76c1e2738747@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <k3dikddABdh7ZedN6N9WjNAUAHz8hH0JnehkEnHTqrI=.e8def0c4-6229-462d-bdec-2d0b868f0eae@github.com>
 <AqI-ISshFzmPmuoh_doaBnFurbU5KIxtxhOKEs_1KC8=.7de95210-0db4-4598-b94e-61a9b54b0ea5@github.com>
 <E8rnvaqo-gbxByH-4TYQpGQ0C5zA1OE6Jzf8V52R5wI=.03a181d8-0306-4f45-8122-76c1e2738747@github.com>
Message-ID: <7MZPV25Iw_nFE8m8zUt11zr6rBK6MfihY3bxdK1MxXg=.8a4a522d-2b09-4e82-a70d-09bd810fdb61@github.com>

On Wed, 19 Nov 2025 07:32:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Removed erroneous comment
>
> I went back through the nestmates design archives that I have to see if this particular issue was ever raised but I could not find it called out. I'm not a fan of explicit null checks as they penalize all the good code. I also don't think the inconsistency is/was an issue. If code does not need to use a parameter to complete its function then it also doesn't need to validate the unused parameter. YMMV.

I think checking ahead is better. If we move c.isPrimitive call to be before isPrimitive, the new consistent NPE becomes a compatibility risk. Better perform checks early to prevent compatibility constraints. And I don't think c is an unused parameter here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2542027546

From duke at openjdk.org  Wed Nov 19 13:49:32 2025
From: duke at openjdk.org (jengebr)
Date: Wed, 19 Nov 2025 13:49:32 GMT
Subject: RFR: 8371164: ArrayList.addAll() optimizations [v8]
In-Reply-To: <VSZHxHxLsjTeZ8Ikte5iWzYBvYTyugd5AfN3vfqOD6I=.c22f7696-3c9f-4551-aed9-caa459ae1b17@github.com>
References: <t8Q5pZZLtX0OvSldThiBu6oKe-9mglmc--fu2m2t6ng=.918a34e0-4d59-4a36-b1cc-571124825a3a@github.com>
 <UKGxnqO8V9PF0bNd0e_E3jjt3JqoH3dfm2VwBr0sQww=.af941765-2ab4-44cb-8596-37438c071d36@github.com>
 <VSZHxHxLsjTeZ8Ikte5iWzYBvYTyugd5AfN3vfqOD6I=.c22f7696-3c9f-4551-aed9-caa459ae1b17@github.com>
Message-ID: <Gry0JdpE6zgj4zQlNB5zcueXIfjNC6j8Xnqn_IwgukU=.5daf6d30-2690-4706-8406-0a26a6eb4a05@github.com>

On Tue, 18 Nov 2025 17:58:49 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> jengebr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing explicit classname
>
> I'm running this through our internal CI system again and I can sponsor this when the run finishes.

@stuart-marks thank you very much!  :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28116#issuecomment-3552791059

From pminborg at openjdk.org  Wed Nov 19 14:03:37 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Nov 2025 14:03:37 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP
In-Reply-To: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
Message-ID: <CivDGipxDetX_H7wuC-UOMSlaSshV9U8243vj7N9mCA=.fc01100e-e76b-4889-946c-7c9ce17b1f1c@github.com>

On Wed, 19 Nov 2025 11:54:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).

This PR passes tier1, tier2, and tier3 on multiple platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28388#issuecomment-3552854818

From liach at openjdk.org  Wed Nov 19 14:15:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Nov 2025 14:15:09 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v4]
In-Reply-To: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
Message-ID: <rDxgyCjSgZvuXnaatWB_VibMf3rC0ihHi3bNN4IDL6Y=.61e1139e-9ab3-40ec-b8d7-a15b9d380a61@github.com>

> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
> 
> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.

Chen Liang 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 13 additional commits since the last revision:

 - Class-level null hostile statement
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
 - From review
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/core-reflection-null-checks
 - Rephrase for parameterTypes contains null
 - Rename tests to be more specific
 - Split annotated type new checks to another patch
 - Redundant
 - Test and more fixes
 - Copyright years
 - ... and 3 more: https://git.openjdk.org/jdk/compare/b3cee9b2...5fdce5d9

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28336/files
  - new: https://git.openjdk.org/jdk/pull/28336/files/51ef5789..5fdce5d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=02-03

  Stats: 21172 lines in 297 files changed: 13285 ins; 5635 del; 2252 mod
  Patch: https://git.openjdk.org/jdk/pull/28336.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28336/head:pull/28336

PR: https://git.openjdk.org/jdk/pull/28336

From liach at openjdk.org  Wed Nov 19 14:18:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Nov 2025 14:18:53 GMT
Subject: RFR: 8372047: ClassTransform.transformingMethodBodies andThen
 composes incorrectly [v3]
In-Reply-To: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
References: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
Message-ID: <Ulz51B4LNMyBvTnHhFUcutqkDb0vV8IjWNqplfwcaQQ=.2bf8fbbe-dafa-4ea8-ad79-b6ffc6f36016@github.com>

> ClassMethodTransform and ClassFieldTransform are computing the chaining condition incorrectly - the composed transform should run when any of the component wants to run instead of when all copmonents want to run, and the actual content tranforms can only compose if they apply to the same set of method or fields. So we should restrict this "optimization" to same filters.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Make it clear where the filter is shared

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28377/files
  - new: https://git.openjdk.org/jdk/pull/28377/files/b5ac4fcf..708f02bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28377&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28377&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28377/head:pull/28377

PR: https://git.openjdk.org/jdk/pull/28377

From vklang at openjdk.org  Wed Nov 19 14:26:47 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 19 Nov 2025 14:26:47 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v8]
In-Reply-To: <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
Message-ID: <s_QZYrMeG8Uf_q-YiUtTbGYxyyFCkFUAu96I17DqGUo=.1b924ca2-5919-4ff5-885f-1ea93012a126@github.com>

On Thu, 13 Nov 2025 06:46:51 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix StreamOpFlagsTest

Looks good, thanks!

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28226#pullrequestreview-3483010086

From mcimadamore at openjdk.org  Wed Nov 19 14:32:38 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 14:32:38 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
Message-ID: <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>

On Wed, 19 Nov 2025 13:29:28 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace conditional with Math.max intrinsic
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Marked as reviewed by mcimadamore (Reviewer).

I think the proposed simpler patch makes sense. Basically, it artificially expands the allocation size to match the alignment, which is probably not going to cause any side-effect as that is likely what was happening anyway...

-------------

PR Review: https://git.openjdk.org/jdk/pull/28235#pullrequestreview-3483048759
PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3553007776

From thartmann at openjdk.org  Wed Nov 19 14:33:33 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Nov 2025 14:33:33 GMT
Subject: RFR: 8372119: Missing copyright header in MinMaxVector
In-Reply-To: <QgQzaCpP8hWV8jnYHb-asJJFASYygMjGdiZdwEJ-0pg=.8671d8ed-82ae-4fc8-ba3f-02966666fc28@github.com>
References: <QgQzaCpP8hWV8jnYHb-asJJFASYygMjGdiZdwEJ-0pg=.8671d8ed-82ae-4fc8-ba3f-02966666fc28@github.com>
Message-ID: <T3rigtgg__HkUqLPXpvfSr8-OCwSXbuPl8b05hxXRIc=.0f54d739-6412-43a6-b7d5-c03ac3b4dbd2@github.com>

On Wed, 19 Nov 2025 09:07:22 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> Trivial PR to add missing copyright header in JMH benchmark.

Looks good to me too.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28387#pullrequestreview-3483045474

From mcimadamore at openjdk.org  Wed Nov 19 14:48:30 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 14:48:30 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
Message-ID: <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>

On Wed, 19 Nov 2025 10:14:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

src/java.base/share/classes/java/lang/String.java line 2019:

> 2017:     }
> 2018: 
> 2019:     boolean bytesCompatible(Charset charset, int srcIndex, int numChars) {

Surprisingly here we don't do anything for the case where the string is UTF16 and the target charset is also UTF16?

src/java.base/share/classes/java/lang/String.java line 2030:

> 2028:     }
> 2029: 
> 2030:     void copyToSegmentRaw(MemorySegment segment, long offset, int srcIndex, int numChars) {

This method takes an index, expressed in chars, and uses that as a byte offset in a bulk copy operation. I don't think this is correct. E.g. if the string is UTF16 (and not LATIN1), there is a scaling factor to be applied?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542331027
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542323659

From mcimadamore at openjdk.org  Wed Nov 19 14:48:32 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 14:48:32 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
 <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>
Message-ID: <snk1ibJWOo28bSfye1bh0eR2GcmPNAs1ofbjCYlcn-M=.289030e1-0b91-4ef3-990f-25757b872ff8@github.com>

On Wed, 19 Nov 2025 14:43:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode
>
> src/java.base/share/classes/java/lang/String.java line 2030:
> 
>> 2028:     }
>> 2029: 
>> 2030:     void copyToSegmentRaw(MemorySegment segment, long offset, int srcIndex, int numChars) {
> 
> This method takes an index, expressed in chars, and uses that as a byte offset in a bulk copy operation. I don't think this is correct. E.g. if the string is UTF16 (and not LATIN1), there is a scaling factor to be applied?

In other words, it seems to me that here we have hardwired the knowledge that we can only get here is the string is latin1. I don't think this was the original intent of this method -- however, if that's the case, we should also add an assertion to avoid misuse.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542337230

From mcimadamore at openjdk.org  Wed Nov 19 14:51:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 14:51:35 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
Message-ID: <pG1eD15gcCzH2H-nKuLj76ngCFzcL8QI6KFeJ_0gLL4=.108b506f-99a7-4d94-a973-25c5c7e542f4@github.com>

On Wed, 19 Nov 2025 10:14:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 194:

> 192:         MemorySegment segment;
> 193:         if (StringSupport.bytesCompatible(str, charset, srcIndex, numChars)) {
> 194:             segment = allocateNoInit(numChars);

This also seems to rely on the fact that we end up here only for latin1 strings. Again, I don't think this is correct, but if it's deliberate, we should add an assertion check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542352073

From mcimadamore at openjdk.org  Wed Nov 19 14:56:31 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 14:56:31 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
Message-ID: <98Nvh8i9sL6mKa_NPS72wQhnmr3juct9GzVu358lXu4=.0999db1b-806e-43b2-b77c-681c9e8d243f@github.com>

On Wed, 19 Nov 2025 10:14:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2649:

> 2647:      *
> 2648:      * @param src      the Java string to be written into this segment
> 2649:      * @param dstEncoding the charset used to {@linkplain Charset#newEncoder() encode}

I'm not sure we have a dependency on the charset being standard?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542365995

From liach at openjdk.org  Wed Nov 19 14:59:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Nov 2025 14:59:28 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v5]
In-Reply-To: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
Message-ID: <vi_JDBHzzgEJTHoPfloEYU_3I_qI6AAWXQTPVV6Pb-A=.09190cf5-0929-442a-a64b-aff76277ac2e@github.com>

> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
> 
> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Remove explict NPE clauses, use the consolidated version

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28336/files
  - new: https://git.openjdk.org/jdk/pull/28336/files/5fdce5d9..757ffefd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=03-04

  Stats: 25 lines in 1 file changed: 3 ins; 21 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28336.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28336/head:pull/28336

PR: https://git.openjdk.org/jdk/pull/28336

From mcimadamore at openjdk.org  Wed Nov 19 15:06:46 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 15:06:46 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
Message-ID: <0lOpR-lFysqowVFSM9SL6UGJEHp1cFpSfTlfDJyayek=.ff295fee-66c1-414e-8be1-7c20606c9ee4@github.com>

On Wed, 19 Nov 2025 10:14:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

Overall, looks good, but I think we should put some more care when going to char-based indices to byte array indices, esp. if we will optimize the UTF16 case in the future

-------------

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3483251965

From asotona at openjdk.org  Wed Nov 19 15:19:06 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Nov 2025 15:19:06 GMT
Subject: RFR: 8372047: ClassTransform.transformingMethodBodies andThen
 composes incorrectly [v3]
In-Reply-To: <Ulz51B4LNMyBvTnHhFUcutqkDb0vV8IjWNqplfwcaQQ=.2bf8fbbe-dafa-4ea8-ad79-b6ffc6f36016@github.com>
References: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
 <Ulz51B4LNMyBvTnHhFUcutqkDb0vV8IjWNqplfwcaQQ=.2bf8fbbe-dafa-4ea8-ad79-b6ffc6f36016@github.com>
Message-ID: <ABIktQ-kHWPEXKCAj81R8mQi8OENuoSt5qSIFmvyUtE=.07dc7ee5-98e3-499f-be3d-a4e89530cb4a@github.com>

On Wed, 19 Nov 2025 14:18:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ClassMethodTransform and ClassFieldTransform are computing the chaining condition incorrectly - the composed transform should run when any of the component wants to run instead of when all copmonents want to run, and the actual content tranforms can only compose if they apply to the same set of method or fields. So we should restrict this "optimization" to same filters.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make it clear where the filter is shared

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28377#pullrequestreview-3483317473

From liach at openjdk.org  Wed Nov 19 15:22:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Nov 2025 15:22:23 GMT
Subject: RFR: 8357728: Avoid caching synthesized names in synthesized
 parameters [v2]
In-Reply-To: <xaJ7tIzIK6QEEINEz3caZWqZ__Yhxn0ndJM4BX7SuLU=.9d442711-9aad-41bf-bd89-7e1c1932591d@github.com>
References: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
 <xaJ7tIzIK6QEEINEz3caZWqZ__Yhxn0ndJM4BX7SuLU=.9d442711-9aad-41bf-bd89-7e1c1932591d@github.com>
Message-ID: <31CtM8xQanWRrmO71MPNWaX-emNz76cXt0MURbJP9uw=.7f883583-6f99-4e55-8075-e6950c3d3765@github.com>

On Fri, 14 Nov 2025 23:03:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, fake parameters are created with "arg0" etc. strings that are retained for class file methods with no MethodParameters attribute. The original issue report observes many of these strings present in the heap. To address this issue, we can remove these eagerly created fake names, bringing their behavior in line with nameless parameters from MethodParameters attribute, such as those from inner class constructors. A unit test verifies that no name is retained in the Parameter object when the name is fake.
>> 
>> The original report recommends using a pool to store the arg name strings. I did not take that approach as I don't think it is very necessary; if the issue of retained fake names persist, we can update `Parameter::getName` to return fake names from a pool instead.
>
> Chen Liang 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' of https://github.com/openjdk/jdk into fix/fake-param-name
>  - 8357728: Optimize Executable#synthesizeAllParams

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25961#issuecomment-3553288307

From liach at openjdk.org  Wed Nov 19 15:22:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Nov 2025 15:22:25 GMT
Subject: Integrated: 8357728: Avoid caching synthesized names in synthesized
 parameters
In-Reply-To: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
References: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
Message-ID: <pG4ysgSn9bV1czhJ38BlYM9TdKrRx0QC1s0bfnTOTVQ=.a15df6c7-7e91-4f68-9136-228a931ecc6c@github.com>

On Tue, 24 Jun 2025 22:32:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, fake parameters are created with "arg0" etc. strings that are retained for class file methods with no MethodParameters attribute. The original issue report observes many of these strings present in the heap. To address this issue, we can remove these eagerly created fake names, bringing their behavior in line with nameless parameters from MethodParameters attribute, such as those from inner class constructors. A unit test verifies that no name is retained in the Parameter object when the name is fake.
> 
> The original report recommends using a pool to store the arg name strings. I did not take that approach as I don't think it is very necessary; if the issue of retained fake names persist, we can update `Parameter::getName` to return fake names from a pool instead.

This pull request has now been integrated.

Changeset: f0afd89f
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0afd89f66c0b42ff06fbb76378a5b2028b76a10
Stats:     84 lines in 3 files changed: 81 ins; 0 del; 3 mod

8357728: Avoid caching synthesized names in synthesized parameters

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/25961

From liach at openjdk.org  Wed Nov 19 15:39:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Nov 2025 15:39:31 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v6]
In-Reply-To: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
Message-ID: <nysoMM1Km4ZFbBWMWXAP6mDwSgK5xyavtB3F2I4Hx-I=.6ec98d2b-cf23-426d-b3a3-01e3fe881550@github.com>

> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
> 
> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Redundant extra sentences

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28336/files
  - new: https://git.openjdk.org/jdk/pull/28336/files/757ffefd..975f98d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28336&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28336.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28336/head:pull/28336

PR: https://git.openjdk.org/jdk/pull/28336

From alanb at openjdk.org  Wed Nov 19 15:57:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Nov 2025 15:57:02 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v6]
In-Reply-To: <nysoMM1Km4ZFbBWMWXAP6mDwSgK5xyavtB3F2I4Hx-I=.6ec98d2b-cf23-426d-b3a3-01e3fe881550@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <nysoMM1Km4ZFbBWMWXAP6mDwSgK5xyavtB3F2I4Hx-I=.6ec98d2b-cf23-426d-b3a3-01e3fe881550@github.com>
Message-ID: <xSQki6AOrf2FGdn3WRcfFdNbr19HttzfSqQB8bwWutE=.1ee49f1f-ddc1-4093-93a1-1bb5aaaf1789@github.com>

On Wed, 19 Nov 2025 15:39:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
>> 
>> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Redundant extra sentences

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28336#pullrequestreview-3483520073

From almatvee at openjdk.org  Wed Nov 19 16:10:35 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 19 Nov 2025 16:10:35 GMT
Subject: Integrated: 8363980: [macos] Add JDK specific keys/values to
 Info.plist of embedded runtime
In-Reply-To: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
References: <AtUQBwMfv3boZxBkH_de27kwKPdRndO2AB9e7cKbazc=.86e29bb5-3941-407e-b71e-10542010e307@github.com>
Message-ID: <Rqy6XfkMmQxR833MXc0NXKizphbDIZ4UOrdcFlSdYMg=.40ee237d-22cd-4726-82f5-92dea8e184c4@github.com>

On Wed, 29 Oct 2025 01:32:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

This pull request has now been integrated.

Changeset: 9ea8201b
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ea8201b7494fe9107d4abd78c02ac765a5751d4
Stats:     89 lines in 8 files changed: 68 ins; 9 del; 12 mod

8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/28033

From liach at openjdk.org  Wed Nov 19 16:20:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Nov 2025 16:20:19 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP
In-Reply-To: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
Message-ID: <4aeuUoyvhz2lkMQCeb3UvwZDU1kNECjrtmynBJ_Yyio=.214312f5-f309-406f-99fa-a04b70561998@github.com>

On Wed, 19 Nov 2025 11:54:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).

lgtm

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28388#pullrequestreview-3483521522

From duke at openjdk.org  Wed Nov 19 16:29:12 2025
From: duke at openjdk.org (duke)
Date: Wed, 19 Nov 2025 16:29:12 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v8]
In-Reply-To: <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
Message-ID: <uON3YCrYju1uAXV3SkF6I5njCff8nqk3QW8UE05twCI=.0f9de133-d435-4893-bf36-c8a23789283b@github.com>

On Thu, 13 Nov 2025 06:46:51 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix StreamOpFlagsTest

@kilink 
Your change (at version 9452d7474d90557faad63ad0a76043e3d0f6e0fa) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3553562889

From sgehwolf at openjdk.org  Wed Nov 19 16:35:04 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 19 Nov 2025 16:35:04 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v8]
In-Reply-To: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com>
Message-ID: <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com>

On Fri, 14 Nov 2025 16:00:43 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR include build changes from @magicus and jlink change to verify the build signature.
>> 
>> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
>> 
>> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>>                                                                                                                                                                  
>> ? java --version
>> openjdk 26-internal 2026-03-17
>> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
>> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>>                                                                                                                                                                  
>> ? jlink --version                                                                       
>> 26-internal
>>                                                                                                                                                                  
>> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux                                                                                                                                        
>>                                                                                                                                                                  
>> ? jlink --add-modules java.base --output macos
>>                                                             
>> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25    
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>>                                                                                                                                                                  
>> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adapt review feedbacks

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 259:

> 257: 
> 258:             try (var r = new BufferedReader(new InputStreamReader(release.get()))) {
> 259:                 return Optional.of(r.readLine());

As suggested on the CSR we should read the entire file, not just the first line and treat the entire content as a string in a specific encoding. While I wasn't able to get the JDK build a vendor name with new lines (due to jrt-fs.jar putting `COMPANYNAME` in the MANIFEST.MF) it's conceivable that some `release.txt` file might have more than one line.

Alternatively we need to specify that the file must not contain line breaks or unusual encodings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2541860576

From mcimadamore at openjdk.org  Wed Nov 19 17:10:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 17:10:55 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP
In-Reply-To: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
Message-ID: <gEqpNasH9iMQBmot1rr_MANzBnar2eoZvwe1gsGzL8k=.dd3126e0-b096-4cbf-9a4e-13374ef0da20@github.com>

On Wed, 19 Nov 2025 11:54:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/java/lang/LazyConstant.java line 245:

> 243: 
> 244:     /**
> 245:      * {@return if this lazy constant is the same instance as the provided {@code obj}}

Suggestion:

     * {@return {@code true} if this lazy constant is the same instance as the provided {@code obj}}

-------------

PR Review: https://git.openjdk.org/jdk/pull/28388#pullrequestreview-3483688099
PR Review Comment: https://git.openjdk.org/jdk/pull/28388#discussion_r2542744396

From asemenyuk at openjdk.org  Wed Nov 19 17:25:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 19 Nov 2025 17:25:57 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v8]
In-Reply-To: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
Message-ID: <x7pCkfDY3xJEBBFf7wxFWNOLfrA0vYjm1-GuMhT-Lmg=.60dab3ec-c574-442f-9226-7a045521c3fe@github.com>

> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
> 
> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
> 
> ### Error reporting improved
> 
> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
> 
> Command line (Windows): 
> 
> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
> 
> Old error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> 
> 
> New error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> Error: Option [--mac-package-name] is not valid on this platform
> Error: Option [-p] is not valid with type [exe]
> Error: Option [--linux-menu-group] is not valid on this platform
> 
> 
>  2. Fix misleading error messages.
> 
> Command line (Windows): 
> 
> jpackage --input no --main-jar no.jar
> 
> Old error output:
> 
> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
> 
> 
> New error output:
> 
> The value "no" provided for parameter --input is not a directory
> 
> 
> 
> 
> ### Help output fixed
> 
> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
> 
> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
> 
> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
> 
> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
> 
> ### Functional changes
> 
> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
> 
> Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.
> 
> In addition to `--opt...

Alexey Semenyuk 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 56 additional commits since the last revision:

 - AsyncTest: call javac and jar tool providers only once for all async jpackage invocations instead of per each of them
 - Merge branch 'master' into JDK-8333727
 - the cli: Options: add copyWithDefaultValue(WithOptionIdentifier withId, Supplier<Object> valueSupplier)
 - PackageType: minor
 - "main.option." -> "help.option."
 - StandardValidator: rename IS_EXISTENT_NOT_DIRECTORY into IS_FILE_OR_SYMLINK.
 - Removed commented out code
 - Fix typo and trailing whitespace
 - Fix findings in the code review
 - StandardValidator: expose
 - ... and 46 more: https://git.openjdk.org/jdk/compare/1f94aae3...bee331c4

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28163/files
  - new: https://git.openjdk.org/jdk/pull/28163/files/862285d6..bee331c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28163&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28163&range=06-07

  Stats: 180068 lines in 1231 files changed: 122174 ins; 27892 del; 30002 mod
  Patch: https://git.openjdk.org/jdk/pull/28163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28163/head:pull/28163

PR: https://git.openjdk.org/jdk/pull/28163

From naoto at openjdk.org  Wed Nov 19 19:52:11 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Nov 2025 19:52:11 GMT
Subject: RFR: 8372117: Correct the misleading comment in Character.UnicodeBlock
Message-ID: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>

Trivial comment fix in `Character.UnicodeBlock`

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/28401/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28401&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372117
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28401/head:pull/28401

PR: https://git.openjdk.org/jdk/pull/28401

From bpb at openjdk.org  Wed Nov 19 20:13:23 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 20:13:23 GMT
Subject: RFR: 8372117: Correct the misleading comment in
 Character.UnicodeBlock
In-Reply-To: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
References: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
Message-ID: <d-Zdv8CTq9kJvpXSK5Ma7E6z1GKlHc9zMtrdYVJxo9s=.685b8193-6f07-4157-ab85-671df97c05f4@github.com>

On Wed, 19 Nov 2025 19:45:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial comment fix in `Character.UnicodeBlock`

Looks all right to me.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28401#pullrequestreview-3484556929

From duke at openjdk.org  Wed Nov 19 20:39:09 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 19 Nov 2025 20:39:09 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
 <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>
Message-ID: <ctYtB_c9b8d9MznTFkh6XUGMKlEpVW52WcYuUnMAijE=.ba43143a-04f5-49dc-8e1a-03ecf1b6661e@github.com>

On Wed, 19 Nov 2025 14:44:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode
>
> src/java.base/share/classes/java/lang/String.java line 2019:
> 
>> 2017:     }
>> 2018: 
>> 2019:     boolean bytesCompatible(Charset charset, int srcIndex, int numChars) {
> 
> Surprisingly here we don't do anything for the case where the string is UTF16 and the target charset is also UTF16?

The **UTF?16**?`Charset`s disallow unpaired?surrogates, which?**Java** `String`s?allow.

So?this can?only return?`true` for?**UTF?16** when?the?platform and?charset endianness?match and?the?`String` doesn?t?have any?unpaired?surrogates.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2543486247

From joehw at openjdk.org  Wed Nov 19 21:28:22 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Nov 2025 21:28:22 GMT
Subject: RFR: 8372117: Correct the misleading comment in
 Character.UnicodeBlock
In-Reply-To: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
References: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
Message-ID: <ATgtucUBE7Bj5gmfN8_yXuM-P_ffKXLsHoCvcxAkPm8=.7795169d-22cf-414d-829e-a35bee86b471@github.com>

On Wed, 19 Nov 2025 19:45:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial comment fix in `Character.UnicodeBlock`

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28401#pullrequestreview-3484801309

From jlu at openjdk.org  Wed Nov 19 21:44:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Nov 2025 21:44:56 GMT
Subject: RFR: 8372117: Correct the misleading comment in
 Character.UnicodeBlock
In-Reply-To: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
References: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
Message-ID: <T9r54b2cgqX2bgWOG-6rbFTFeaM0Mrhaix7HBFowMSg=.1532a9eb-e263-4533-b36b-b21b40dcb2c1@github.com>

On Wed, 19 Nov 2025 19:45:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial comment fix in `Character.UnicodeBlock`

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28401#pullrequestreview-3484852437

From asemenyuk at openjdk.org  Wed Nov 19 22:17:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 19 Nov 2025 22:17:50 GMT
Subject: RFR: 8372118: Test tools/jpackage/macosx/DmgContentTest.java failed
Message-ID: <4jx8j0FLhF6HbVcsaE-CHgBZeNaeC89B2nuZgw8CCGs=.94bb4097-79a2-4af5-b6ed-6e9b0a0790ff@github.com>

Don't follow symlinks when copying the app image directory tree into the blank .dmg file.

-------------

Commit messages:
 - 8372118: Test tools/jpackage/macosx/DmgContentTest.java failed

Changes: https://git.openjdk.org/jdk/pull/28403/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28403&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372118
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28403.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28403/head:pull/28403

PR: https://git.openjdk.org/jdk/pull/28403

From almatvee at openjdk.org  Wed Nov 19 22:17:50 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 19 Nov 2025 22:17:50 GMT
Subject: RFR: 8372118: Test tools/jpackage/macosx/DmgContentTest.java
 failed
In-Reply-To: <4jx8j0FLhF6HbVcsaE-CHgBZeNaeC89B2nuZgw8CCGs=.94bb4097-79a2-4af5-b6ed-6e9b0a0790ff@github.com>
References: <4jx8j0FLhF6HbVcsaE-CHgBZeNaeC89B2nuZgw8CCGs=.94bb4097-79a2-4af5-b6ed-6e9b0a0790ff@github.com>
Message-ID: <UUrrLD-WpMO-7U1KmDbI4K30L0C41kmOoXhmF_u4f4s=.6da56799-d5f8-45da-9b3f-0b91de724a79@github.com>

On Wed, 19 Nov 2025 22:05:42 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Don't follow symlinks when copying the app image directory tree into the blank .dmg file.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28403#pullrequestreview-3484941213

From asemenyuk at openjdk.org  Wed Nov 19 22:17:51 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 19 Nov 2025 22:17:51 GMT
Subject: RFR: 8372118: Test tools/jpackage/macosx/DmgContentTest.java
 failed
In-Reply-To: <4jx8j0FLhF6HbVcsaE-CHgBZeNaeC89B2nuZgw8CCGs=.94bb4097-79a2-4af5-b6ed-6e9b0a0790ff@github.com>
References: <4jx8j0FLhF6HbVcsaE-CHgBZeNaeC89B2nuZgw8CCGs=.94bb4097-79a2-4af5-b6ed-6e9b0a0790ff@github.com>
Message-ID: <mKbUXixpKk7hMaMDIk2GyfljoN8AGm_cm6D2TsSmB_k=.dc0e8187-20f8-4058-bb83-b1442887939d@github.com>

On Wed, 19 Nov 2025 22:05:42 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Don't follow symlinks when copying the app image directory tree into the blank .dmg file.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28403#issuecomment-3554829293

From duke at openjdk.org  Wed Nov 19 22:25:19 2025
From: duke at openjdk.org (duke)
Date: Wed, 19 Nov 2025 22:25:19 GMT
Subject: Withdrawn: 8368349: Add library notes discussing abs and IEEE 754
 operations
In-Reply-To: <m1LxnsIwcOIj1UpwV_Z91wTnQ3pGHSJK32k6_OyY6vk=.0196a64a-bcc5-4a3d-99ba-18ca9effc763@github.com>
References: <m1LxnsIwcOIj1UpwV_Z91wTnQ3pGHSJK32k6_OyY6vk=.0196a64a-bcc5-4a3d-99ba-18ca9effc763@github.com>
Message-ID: <XajXThkdhLYHtxndaRi7z_iWi1uUn4H4tfngQ-FjpB0=.43530a93-26cb-4eff-9eff-be2c2b912640@github.com>

On Tue, 23 Sep 2025 03:02:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add apiNote linking {Math, StrictMath}.abs to the IEEE 754 abs operation.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27443

From asemenyuk at openjdk.org  Wed Nov 19 23:25:40 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 19 Nov 2025 23:25:40 GMT
Subject: Integrated: 8372118: Test tools/jpackage/macosx/DmgContentTest.java
 failed
In-Reply-To: <4jx8j0FLhF6HbVcsaE-CHgBZeNaeC89B2nuZgw8CCGs=.94bb4097-79a2-4af5-b6ed-6e9b0a0790ff@github.com>
References: <4jx8j0FLhF6HbVcsaE-CHgBZeNaeC89B2nuZgw8CCGs=.94bb4097-79a2-4af5-b6ed-6e9b0a0790ff@github.com>
Message-ID: <0iin4Q2YhSXFesOX2rDgbODKH9uqcNby8rOSgw59VOI=.410e0d57-990d-413d-9219-e14d68b7d34a@github.com>

On Wed, 19 Nov 2025 22:05:42 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Don't follow symlinks when copying the app image directory tree into the blank .dmg file.

This pull request has now been integrated.

Changeset: c8e64e7c
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8e64e7c33cabcc5c94616808b9c59ab5b7cd14e
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8372118: Test tools/jpackage/macosx/DmgContentTest.java failed

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28403

From almatvee at openjdk.org  Wed Nov 19 23:54:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 19 Nov 2025 23:54:01 GMT
Subject: RFR: 8333727: Use JOpt in jpackage to parse command line [v8]
In-Reply-To: <x7pCkfDY3xJEBBFf7wxFWNOLfrA0vYjm1-GuMhT-Lmg=.60dab3ec-c574-442f-9226-7a045521c3fe@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
 <x7pCkfDY3xJEBBFf7wxFWNOLfrA0vYjm1-GuMhT-Lmg=.60dab3ec-c574-442f-9226-7a045521c3fe@github.com>
Message-ID: <F20qYk26LLLzilGFFAveJzeU8R6QNte4RVOWcHOULVQ=.599f0ad2-c3a1-4588-b14e-0fc9ddeb0360@github.com>

On Wed, 19 Nov 2025 17:25:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
>> 
>> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
>> 
>> ### Error reporting improved
>> 
>> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
>> 
>> Command line (Windows): 
>> 
>> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
>> 
>> Old error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> 
>> 
>> New error output:
>> 
>> Error: Option [--linux-shortcut] is not valid on this platform
>> Error: Option [--mac-package-name] is not valid on this platform
>> Error: Option [-p] is not valid with type [exe]
>> Error: Option [--linux-menu-group] is not valid on this platform
>> 
>> 
>>  2. Fix misleading error messages.
>> 
>> Command line (Windows): 
>> 
>> jpackage --input no --main-jar no.jar
>> 
>> Old error output:
>> 
>> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
>> 
>> 
>> New error output:
>> 
>> The value "no" provided for parameter --input is not a directory
>> 
>> 
>> 
>> 
>> ### Help output fixed
>> 
>> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
>> 
>> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
>> 
>> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
>> 
>> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
>> 
>> ### Functional changes
>> 
>> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
>> 
>> Like other JD...
>
> Alexey Semenyuk 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 56 additional commits since the last revision:
> 
>  - AsyncTest: call javac and jar tool providers only once for all async jpackage invocations instead of per each of them
>  - Merge branch 'master' into JDK-8333727
>  - the cli: Options: add copyWithDefaultValue(WithOptionIdentifier withId, Supplier<Object> valueSupplier)
>  - PackageType: minor
>  - "main.option." -> "help.option."
>  - StandardValidator: rename IS_EXISTENT_NOT_DIRECTORY into IS_FILE_OR_SYMLINK.
>  - Removed commented out code
>  - Fix typo and trailing whitespace
>  - Fix findings in the code review
>  - StandardValidator: expose
>  - ... and 46 more: https://git.openjdk.org/jdk/compare/6f10a48c...bee331c4

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28163#pullrequestreview-3485149144

From asemenyuk at openjdk.org  Thu Nov 20 00:40:41 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 00:40:41 GMT
Subject: RFR: 8371440: jpackage should exit with an error if it finds multiple
 matching signing certificates
Message-ID: <3BDrBA_jtbA5L5T59NRlDuhq9DX_J87MAY3Cx8Tb8RE=.a0c1ce5b-02f5-4fb1-88bb-8d6d819b1588@github.com>

jpackage will exit with an error if the value of the `--mac-signing-key-user-name` option matches multiple certificates of the same type (app image or installer).

Previously, jpackage would emit an error that multiple certificates match the value of the `--mac-signing-key-user-name` option, pick the first matching certificate, and keep going.

-------------

Commit messages:
 - 8371440: jpackage should exit with an error if it finds multiple matching signing certificates

Changes: https://git.openjdk.org/jdk/pull/28405/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28405&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371440
  Stats: 36 lines in 3 files changed: 16 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28405/head:pull/28405

PR: https://git.openjdk.org/jdk/pull/28405

From asemenyuk at openjdk.org  Thu Nov 20 00:40:42 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 00:40:42 GMT
Subject: RFR: 8371440: jpackage should exit with an error if it finds
 multiple matching signing certificates
In-Reply-To: <3BDrBA_jtbA5L5T59NRlDuhq9DX_J87MAY3Cx8Tb8RE=.a0c1ce5b-02f5-4fb1-88bb-8d6d819b1588@github.com>
References: <3BDrBA_jtbA5L5T59NRlDuhq9DX_J87MAY3Cx8Tb8RE=.a0c1ce5b-02f5-4fb1-88bb-8d6d819b1588@github.com>
Message-ID: <JEgVR_rbH5ePGiKh7E3e4hAfMYz6wzr8m9N7sBZuHEo=.06dddf72-ad3e-4cd6-87fa-c7bc17af8df4@github.com>

On Wed, 19 Nov 2025 23:46:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage will exit with an error if the value of the `--mac-signing-key-user-name` option matches multiple certificates of the same type (app image or installer).
> 
> Previously, jpackage would emit an error that multiple certificates match the value of the `--mac-signing-key-user-name` option, pick the first matching certificate, and keep going.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28405#issuecomment-3555213251

From almatvee at openjdk.org  Thu Nov 20 01:02:09 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 20 Nov 2025 01:02:09 GMT
Subject: RFR: 8371440: jpackage should exit with an error if it finds
 multiple matching signing certificates
In-Reply-To: <3BDrBA_jtbA5L5T59NRlDuhq9DX_J87MAY3Cx8Tb8RE=.a0c1ce5b-02f5-4fb1-88bb-8d6d819b1588@github.com>
References: <3BDrBA_jtbA5L5T59NRlDuhq9DX_J87MAY3Cx8Tb8RE=.a0c1ce5b-02f5-4fb1-88bb-8d6d819b1588@github.com>
Message-ID: <d0Cy3poBVZbpnH5iqurWb4qkUhd2JVqXzbcei9K_RjE=.cc2f9471-6da3-4465-81ad-26f222b68c78@github.com>

On Wed, 19 Nov 2025 23:46:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage will exit with an error if the value of the `--mac-signing-key-user-name` option matches multiple certificates of the same type (app image or installer).
> 
> Previously, jpackage would emit an error that multiple certificates match the value of the `--mac-signing-key-user-name` option, pick the first matching certificate, and keep going.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28405#pullrequestreview-3485256165

From asemenyuk at openjdk.org  Thu Nov 20 01:32:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 01:32:56 GMT
Subject: Integrated: 8371440: jpackage should exit with an error if it finds
 multiple matching signing certificates
In-Reply-To: <3BDrBA_jtbA5L5T59NRlDuhq9DX_J87MAY3Cx8Tb8RE=.a0c1ce5b-02f5-4fb1-88bb-8d6d819b1588@github.com>
References: <3BDrBA_jtbA5L5T59NRlDuhq9DX_J87MAY3Cx8Tb8RE=.a0c1ce5b-02f5-4fb1-88bb-8d6d819b1588@github.com>
Message-ID: <eja1nolCTXIUqT8yyXeXuoNzOGiN45Wlbc6dfcIyIPk=.ff1a005b-fc9a-4284-b646-2796776ac671@github.com>

On Wed, 19 Nov 2025 23:46:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage will exit with an error if the value of the `--mac-signing-key-user-name` option matches multiple certificates of the same type (app image or installer).
> 
> Previously, jpackage would emit an error that multiple certificates match the value of the `--mac-signing-key-user-name` option, pick the first matching certificate, and keep going.

This pull request has now been integrated.

Changeset: 2acd8776
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2acd8776f26686a93708eb9fc408ff4e2bbe287c
Stats:     36 lines in 3 files changed: 16 ins; 7 del; 13 mod

8371440: jpackage should exit with an error if it finds multiple matching signing certificates

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28405

From jvernee at openjdk.org  Thu Nov 20 01:40:24 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 01:40:24 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP
In-Reply-To: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
Message-ID: <DYRcVBtCYzZiynCpJx2I4gZdCINcnzJ4HcccoxoSogk=.e3e1a113-39b8-4c6a-b52e-ba23f287c643@github.com>

On Wed, 19 Nov 2025 11:54:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28388#pullrequestreview-3485327840

From erfang at openjdk.org  Thu Nov 20 04:01:09 2025
From: erfang at openjdk.org (Eric Fang)
Date: Thu, 20 Nov 2025 04:01:09 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v2]
In-Reply-To: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
Message-ID: <4vSKAtr0tUG0V193gIvnEFdHm18ZhqflVAwk-09IVQ0=.081806f5-6303-4b4f-975d-7c85427ccae5@github.com>

> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
> 
> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
> 
> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
> 
> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
> 
> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
> 
> Current optimizations related to `VectorMaskCastNode` include:
> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
> 
> This PR does the following optimizations:
> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as th...

Eric Fang 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 three additional commits since the last revision:

 - Don't read and write the same memory in the JMH benchmarks
 - Merge branch 'master' into JDK-8370863-mask-cast-opt
 - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns
   
   `VectorMaskCastNode` is used to cast a vector mask from one type to
   another type. The cast may be generated by calling the vector API `cast`
   or generated by the compiler. For example, some vector mask operations
   like `trueCount` require the input mask to be integer types, so for
   floating point type masks, the compiler will cast the mask to the
   corresponding integer type mask automatically before doing the mask
   operation. This kind of cast is very common.
   
   If the vector element size is not changed, the `VectorMaskCastNode`
   don't generate code, otherwise code will be generated to extend or narrow
   the mask. This IR node is not free no matter it generates code or not
   because it may block some optimizations. For example:
   1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))`
   The middle `VectorMaskCast` prevented the following optimization:
   `(VectorStoremask (VectorLoadMask x)) => (x)`
   2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which
   blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
   
   In these IR patterns, the value of the input `x` is not changed, so we
   can safely do the optimization. But if the input value is changed, we
   can't eliminate the cast.
   
   The general idea of this PR is introducing an `uncast_mask` helper
   function, which can be used to uncast a chain of `VectorMaskCastNode`,
   like the existing `Node::uncast(bool)` function. The funtion returns
   the first non `VectorMaskCastNode`.
   
   The intended use case is when the IR pattern to be optimized may
   contain one or more consecutive `VectorMaskCastNode` and this does not
   affect the correctness of the optimization. Then this function can be
   called to eliminate the `VectorMaskCastNode` chain.
   
   Current optimizations related to `VectorMaskCastNode` include:
   1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
   2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
   
   This PR does the following optimizations:
   1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)`
   as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`.
   Because as long as types of the head and tail `VectorMaskCastNode` are
   consistent, the optimization is correct.
   2. Supports a new optimization pattern
   `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`.
   Since the value before and after the pattern is a boolean vector, it
   remains unchanged as long as the vector length remains the same, and
   this is guranteed in the api level.
   
   I conducted some simple research on different mask generation methods
   and mask operations, and obtained the following table, which includes
   some potential optimization opportunities that may use this `uncast_mask`
   function.
   
   ```
   mask_gen\op    toLong   anyTrue allTrue trueCount firstTrue lastTrue
   compare        N/A      N/A     N/A     N/A       N/A       N/A
   maskAll        TBI      TBI     TBI     TBI       TBI       TBI
   fromLong       TBI      TBI     N/A     TBI       TBI       TBI
   
   mask_gen\op    and      or      xor     andNot    not       laneIsSet
   compare        N/A      N/A     N/A     N/A       TBI       N/A
   maskAll        TBI      TBI     TBI     TBI       TBI       TBI
   fromLong       N/A      N/A     N/A     N/A       TBI       TBI
   ```
   `TBI` indicated that there may be potential optimizations here that
   require further investigation.
   
   Benchmarks:
   
   On a Nvidia Grace machine with 128-bit SVE2:
   ```
   Benchmark			Unit	Before	Error	After	Error	Uplift
   microMaskLoadCastStoreByte64	ops/us	59.23	0.21	148.12	0.07	2.50
   microMaskLoadCastStoreDouble128	ops/us	2.43	0.00	38.31	0.01	15.73
   microMaskLoadCastStoreFloat128	ops/us	6.19	0.00	75.67	0.11	12.22
   microMaskLoadCastStoreInt128	ops/us	6.19	0.00	75.67	0.03	12.22
   microMaskLoadCastStoreLong128	ops/us	2.43	0.00	38.32	0.01	15.74
   microMaskLoadCastStoreShort64	ops/us	28.89	0.02	75.60	0.09	2.62
   ```
   
   On a Nvidia Grace machine with 128-bit NEON:
   ```
   Benchmark			Unit	Before	Error	After	Error	Uplift
   microMaskLoadCastStoreByte64	ops/us	75.75	0.19	149.74	0.08	1.98
   microMaskLoadCastStoreDouble128	ops/us	8.71	0.03	38.71	0.05	4.44
   microMaskLoadCastStoreFloat128	ops/us	24.05	0.03	76.49	0.05	3.18
   microMaskLoadCastStoreInt128	ops/us	24.06	0.02	76.51	0.05	3.18
   microMaskLoadCastStoreLong128	ops/us	8.72	0.01	38.71	0.02	4.44
   microMaskLoadCastStoreShort64	ops/us	24.64	0.01	76.43	0.06	3.10
   ```
   
   On an AMD EPYC 9124 16-Core Processor with AVX3:
   ```
   Benchmark			Unit	Before	Error	After	Error	Uplift
   microMaskLoadCastStoreByte64	ops/us	82.13	0.31	115.14	0.08	1.40
   microMaskLoadCastStoreDouble128	ops/us	0.32	0.00	0.32	0.00	1.01
   microMaskLoadCastStoreFloat128	ops/us	42.18	0.05	57.56	0.07	1.36
   microMaskLoadCastStoreInt128	ops/us	42.19	0.01	57.53	0.08	1.36
   microMaskLoadCastStoreLong128	ops/us	0.30	0.01	0.32	0.00	1.05
   microMaskLoadCastStoreShort64	ops/us	42.18	0.05	57.59	0.01	1.37
   ```
   
   On an AMD EPYC 9124 16-Core Processor with AVX2:
   ```
   Benchmark			Unit	Before	Error	After	Error	Uplift
   microMaskLoadCastStoreByte64	ops/us	73.53	0.20	114.98	0.03	1.56
   microMaskLoadCastStoreDouble128	ops/us	0.29	0.01	0.30	0.00	1.00
   microMaskLoadCastStoreFloat128	ops/us	30.78	0.14	57.50	0.01	1.87
   microMaskLoadCastStoreInt128	ops/us	30.65	0.26	57.50	0.01	1.88
   microMaskLoadCastStoreLong128	ops/us	0.30	0.00	0.30	0.00	0.99
   microMaskLoadCastStoreShort64	ops/us	24.92	0.00	57.49	0.01	2.31
   ```
   
   On an AMD EPYC 9124 16-Core Processor with AVX1:
   ```
   Benchmark			Unit	Before	Error	After	Error	Uplift
   microMaskLoadCastStoreByte64	ops/us	79.68	0.01	248.49	0.91	3.12
   microMaskLoadCastStoreDouble128	ops/us	0.28	0.00	0.28	0.00	1.00
   microMaskLoadCastStoreFloat128	ops/us	31.11	0.04	95.48	2.27	3.07
   microMaskLoadCastStoreInt128	ops/us	31.10	0.03	99.94	1.87	3.21
   microMaskLoadCastStoreLong128	ops/us	0.28	0.00	0.28	0.00	0.99
   microMaskLoadCastStoreShort64	ops/us	31.11	0.02	94.97	2.30	3.05
   ```
   
   This PR was tested on 128-bit, 256-bit, and 512-bit (QEMU) aarch64
   environments, and two 512-bit x64 machines with various configurations,
   including sve2, sve1, neon, avx3, avx2, avx1, sse4 and sse3, all tests
   passed.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28313/files
  - new: https://git.openjdk.org/jdk/pull/28313/files/fca9b3e5..3b0ff7d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=00-01

  Stats: 28723 lines in 501 files changed: 18169 ins; 7171 del; 3383 mod
  Patch: https://git.openjdk.org/jdk/pull/28313.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28313/head:pull/28313

PR: https://git.openjdk.org/jdk/pull/28313

From erfang at openjdk.org  Thu Nov 20 04:05:41 2025
From: erfang at openjdk.org (Eric Fang)
Date: Thu, 20 Nov 2025 04:05:41 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns
In-Reply-To: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
Message-ID: <LKoYbZH1qST469Y6llNIPmejb-TPo6-gL1HxG183s-8=.661b100f-c510-4c05-9dbf-337527960093@github.com>

On Fri, 14 Nov 2025 01:17:50 GMT, Eric Fang <erfang at openjdk.org> wrote:

> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
> 
> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
> 
> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
> 
> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
> 
> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
> 
> Current optimizations related to `VectorMaskCastNode` include:
> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
> 
> This PR does the following optimizations:
> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as th...

Updated the JMH benchmarks and the new test results:

On a Nvidia Grace machine with 128-bit SVE2:

    Benchmark                       Unit    Before  Error   After   Error   Uplift
    microMaskLoadCastStoreByte64    ops/us  64.29   0.02    146.67  0.09    2.28
    microMaskLoadCastStoreDouble128 ops/us  10.05   0.00    38.10   0.01    3.79
    microMaskLoadCastStoreFloat128  ops/us  19.94   0.00    75.05   0.07    3.76
    microMaskLoadCastStoreInt128    ops/us  19.94   0.00    75.13   0.01    3.77
    microMaskLoadCastStoreLong128   ops/us  10.04   0.00    38.09   0.01    3.79
    microMaskLoadCastStoreShort64   ops/us  31.52   0.02    75.12   0.02    2.38

On a Nvidia Grace machine with 128-bit NEON:

    Benchmark                       Unit    Before  Error   After   Error   Uplift
    microMaskLoadCastStoreByte64    ops/us  73.33   0.01    147.01  0.06    2.00
    microMaskLoadCastStoreDouble128 ops/us  8.54    0.03    38.19   0.01    4.47
    microMaskLoadCastStoreFloat128  ops/us  23.75   0.01    75.27   0.10    3.17
    microMaskLoadCastStoreInt128    ops/us  23.73   0.01    75.25   0.07    3.17
    microMaskLoadCastStoreLong128   ops/us  8.56    0.03    38.19   0.01    4.46
    microMaskLoadCastStoreShort64   ops/us  24.32   0.00    75.35   0.07    3.10

On an AMD EPYC 9124 16-Core Processor with AVX3:

    Benchmark                       Unit    Before  Error   After   Error   Uplift
    microMaskLoadCastStoreByte64    ops/us  82.39   0.11    115.15  0.03    1.40
    microMaskLoadCastStoreDouble128 ops/us  0.32    0.00    0.32    0.00    0.99
    microMaskLoadCastStoreFloat128  ops/us  42.10   0.10    57.58   0.02    1.37
    microMaskLoadCastStoreInt128    ops/us  42.10   0.08    57.57   0.02    1.37
    microMaskLoadCastStoreLong128   ops/us  0.32    0.00    0.32    0.00    0.99
    microMaskLoadCastStoreShort64   ops/us  42.16   0.05    57.54   0.04    1.36


On an AMD EPYC 9124 16-Core Processor with AVX2:

    Benchmark                       Unit    Before  Error   After   Error   Uplift
    microMaskLoadCastStoreByte64    ops/us  73.59   0.27    115.14  0.04    1.56
    microMaskLoadCastStoreDouble128 ops/us  0.30    0.00    0.30    0.00    1.01
    microMaskLoadCastStoreFloat128  ops/us  30.68   0.09    57.57   0.02    1.88
    microMaskLoadCastStoreInt128    ops/us  30.75   0.09    57.58   0.01    1.87
    microMaskLoadCastStoreLong128   ops/us  0.30    0.00    0.30    0.00    1.00
    microMaskLoadCastStoreShort64   ops/us  24.95   0.01    57.59   0.01    2.31

On an AMD EPYC 9124 16-Core Processor with AVX1:

    Benchmark                       Unit    Before  Error   After   Error   Uplift
    microMaskLoadCastStoreByte64    ops/us  73.68   0.02    115.17  0.03    1.56
    microMaskLoadCastStoreDouble128 ops/us  0.30    0.00    0.30    0.00    1.01
    microMaskLoadCastStoreFloat128  ops/us  30.80   0.12    57.59   0.01    1.87
    microMaskLoadCastStoreInt128    ops/us  30.70   0.11    57.58   0.01    1.88
    microMaskLoadCastStoreLong128   ops/us  0.30    0.00    0.30    0.00    0.99
    microMaskLoadCastStoreShort64   ops/us  24.95   0.01    57.56   0.02    2.31

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3555660413

From dholmes at openjdk.org  Thu Nov 20 04:55:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 04:55:56 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v6]
In-Reply-To: <7MZPV25Iw_nFE8m8zUt11zr6rBK6MfihY3bxdK1MxXg=.8a4a522d-2b09-4e82-a70d-09bd810fdb61@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <k3dikddABdh7ZedN6N9WjNAUAHz8hH0JnehkEnHTqrI=.e8def0c4-6229-462d-bdec-2d0b868f0eae@github.com>
 <AqI-ISshFzmPmuoh_doaBnFurbU5KIxtxhOKEs_1KC8=.7de95210-0db4-4598-b94e-61a9b54b0ea5@github.com>
 <E8rnvaqo-gbxByH-4TYQpGQ0C5zA1OE6Jzf8V52R5wI=.03a181d8-0306-4f45-8122-76c1e2738747@github.com>
 <7MZPV25Iw_nFE8m8zUt11zr6rBK6MfihY3bxdK1MxXg=.8a4a522d-2b09-4e82-a70d-09bd810fdb61@github.com>
Message-ID: <YPo9EZsE8zJGUJy5WdO-DorlpyKyhPWgraiMdd5lF60=.6d4c8a8b-8052-4ad1-8eaf-58469287638d@github.com>

On Wed, 19 Nov 2025 13:31:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I went back through the nestmates design archives that I have to see if this particular issue was ever raised but I could not find it called out. I'm not a fan of explicit null checks as they penalize all the good code. I also don't think the inconsistency is/was an issue. If code does not need to use a parameter to complete its function then it also doesn't need to validate the unused parameter. YMMV.
>
> I think checking ahead is better. If we move c.isPrimitive call to be before isPrimitive, the new consistent NPE becomes a compatibility risk. Better perform checks early to prevent compatibility constraints. And I don't think c is an unused parameter here.

Yes you are right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28336#discussion_r2544325718

From dholmes at openjdk.org  Thu Nov 20 05:03:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 05:03:11 GMT
Subject: RFR: 8333871: Check sysinfo return values [v5]
In-Reply-To: <3ykgR3X2ByYyZAPZQC594cFLuyhFYZr-9ZpsWR8I5A0=.20122600-a79f-4c0e-af46-53e11ec37e47@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <3ykgR3X2ByYyZAPZQC594cFLuyhFYZr-9ZpsWR8I5A0=.20122600-a79f-4c0e-af46-53e11ec37e47@github.com>
Message-ID: <_6HDANESo9PVzJPFr_stWvoBL3tB-Edv10EmoOKBW4k=.3cf0ecae-9532-45b4-8d7a-d9da35eb7c15@github.com>

On Wed, 19 Nov 2025 12:52:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge master
>  - Merge remote-tracking branch 'origin/master' into JDK-8333871
>  - use more asserts
>  - 0 - terminate not needed
>  - JDK-8333871

src/hotspot/os/linux/os_linux.cpp line 2436:

> 2434:     os::print_dhm(st, "OS uptime:", (long) sinfo.uptime);
> 2435:   }
> 2436:   assert(ret == 0, "sysinfo must return 0");

Sorry we should report the value of `errno` if the assert fails
Suggestion:

  assert(ret == 0, "sysinfo failed: %s", os::strerror(errno));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2544337803

From fyang at openjdk.org  Thu Nov 20 07:46:54 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 20 Nov 2025 07:46:54 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v5]
In-Reply-To: <ny8egKqL-RZlT-kK96j2sFcF-O7TG3G30Gdp6EVWwvc=.a1d4ecd4-8765-424b-bd86-bee4a1136ba5@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <ny8egKqL-RZlT-kK96j2sFcF-O7TG3G30Gdp6EVWwvc=.a1d4ecd4-8765-424b-bd86-bee4a1136ba5@github.com>
Message-ID: <xMp_1lcGJGFi1TFr2ahEODh0y9OR4Bmm2xH832CEPvY=.b9c104b6-c5a4-44df-a47b-c37127f66a88@github.com>

On Tue, 18 Nov 2025 09:27:44 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> 
>> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
>> 
>> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
>> 
>> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
>> 
>> # Test
>> ## Jtreg
>> 
>> in progress...
>> 
>> ## Performance
>> 
>> Column names meanings:
>> * p: with patch
>> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> * m: without patch
>> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> 
>> #### Average improvement
>> 
>> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
>> 
>> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
>> -- | -- | -- | --
>> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
>> 
>> </google-sheets-html-origin>
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace assert with log_warning

@Hamlin-Li : Thanks for the update. I am having another look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3556397859

From mbaesken at openjdk.org  Thu Nov 20 08:27:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Nov 2025 08:27:43 GMT
Subject: RFR: 8333871: Check sysinfo return values [v6]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Better assert messages

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28317/files
  - new: https://git.openjdk.org/jdk/pull/28317/files/e498891b..22a2f6aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28317/head:pull/28317

PR: https://git.openjdk.org/jdk/pull/28317

From cushon at openjdk.org  Thu Nov 20 08:59:11 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 20 Nov 2025 08:59:11 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/0593827f..faa4c5b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=06-07

  Stats: 12 lines in 5 files changed: 3 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From cushon at openjdk.org  Thu Nov 20 08:59:13 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 20 Nov 2025 08:59:13 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
Message-ID: <c3gt3ASSzKZN5pgKP2DvEFsDcW5gKtA7trDQbdd3Ilg=.43358de3-482b-4d95-8bfa-d46bc04452dd@github.com>

On Wed, 19 Nov 2025 10:14:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

Thanks for the review!

> I think we should put some more care when going to char-based indices to byte array indices, esp. if we will optimize the UTF16 case in the future

Thanks for catching that. I have made some initial updates and added an assertion. To confirm do you think it's OK to leave optimizing the UTF16 case as future work, as long as the current assumptions are clearly documented and guarded by assertions?

Also, I'm planning to spend more time on test coverage for this and going over the javadoc again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3556664930

From cushon at openjdk.org  Thu Nov 20 08:59:15 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 20 Nov 2025 08:59:15 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <snk1ibJWOo28bSfye1bh0eR2GcmPNAs1ofbjCYlcn-M=.289030e1-0b91-4ef3-990f-25757b872ff8@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
 <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>
 <snk1ibJWOo28bSfye1bh0eR2GcmPNAs1ofbjCYlcn-M=.289030e1-0b91-4ef3-990f-25757b872ff8@github.com>
Message-ID: <T6OZiODm3DrLnmSsLMYkMpf8jCjfRs6vbBVY0YlowDw=.7251097c-5ec9-46fc-b5ca-94c0a2278483@github.com>

On Wed, 19 Nov 2025 14:45:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 2030:
>> 
>>> 2028:     }
>>> 2029: 
>>> 2030:     void copyToSegmentRaw(MemorySegment segment, long offset, int srcIndex, int numChars) {
>> 
>> This method takes an index, expressed in chars, and uses that as a byte offset in a bulk copy operation. I don't think this is correct. E.g. if the string is UTF16 (and not LATIN1), there is a scaling factor to be applied?
>
> In other words, it seems to me that here we have hardwired the knowledge that we can only get here is the string is latin1. I don't think this was the original intent of this method -- however, if that's the case, we should also add an assertion to avoid misuse.

Thanks for catching this. For `copyToSegmentRaw`, I have updated the parameter names to not refer to chars.

I have also tentatively added an assertion to `copyToSegmentRaw` to only support latin1 strings, which could be relaxed if `bytesCompatible` is updated to handle UTF-16

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2544854187

From cushon at openjdk.org  Thu Nov 20 08:59:19 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 20 Nov 2025 08:59:19 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <98Nvh8i9sL6mKa_NPS72wQhnmr3juct9GzVu358lXu4=.0999db1b-806e-43b2-b77c-681c9e8d243f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
 <98Nvh8i9sL6mKa_NPS72wQhnmr3juct9GzVu358lXu4=.0999db1b-806e-43b2-b77c-681c9e8d243f@github.com>
Message-ID: <eiIAMcBsxOZEjzzcQEdUUhu5a8AEmOFv_31NRmGsPrc=.6cb5374b-bb28-46a8-a496-daf7e8dc9c0e@github.com>

On Wed, 19 Nov 2025 14:52:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2649:
> 
>> 2647:      *
>> 2648:      * @param src      the Java string to be written into this segment
>> 2649:      * @param dstEncoding the charset used to {@linkplain Charset#newEncoder() encode}
> 
> I'm not sure we have a dependency on the charset being standard?

We do not, thanks, fixed.

Although I think the existing `allocateFrom(String, Charset)` method does have an undocumented dependency, because it uses `CharsetKind` to get the terminator char length, which only supports standard Charsets. If we add a fast path for UTF-16 that may need a dependency on a standard Charset (or a standard way to get the code unit size of a charset, if it has one).

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 194:
> 
>> 192:         MemorySegment segment;
>> 193:         if (StringSupport.bytesCompatible(str, charset, srcIndex, numChars)) {
>> 194:             segment = allocateNoInit(numChars);
> 
> This also seems to rely on the fact that we end up here only for latin1 strings. Again, I don't think this is correct, but if it's deliberate, we should add an assertion check.

Good point. I think we make a similar assumption in the existing `allocateFrom(String, Charset)`, it does  `length + termCharSize` and that should perhaps be `(length + 1) * codeUnitSize`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2544835957
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2544862879

From pminborg at openjdk.org  Thu Nov 20 09:06:24 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 20 Nov 2025 09:06:24 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP
In-Reply-To: <gEqpNasH9iMQBmot1rr_MANzBnar2eoZvwe1gsGzL8k=.dd3126e0-b096-4cbf-9a4e-13374ef0da20@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
 <gEqpNasH9iMQBmot1rr_MANzBnar2eoZvwe1gsGzL8k=.dd3126e0-b096-4cbf-9a4e-13374ef0da20@github.com>
Message-ID: <6wDMi8Qmn1LkG-CN5DC8l5dYX-BrjBN_Xo_Vu-u_mtw=.c68acc6d-2304-482d-8d2e-9e7156802b71@github.com>

On Wed, 19 Nov 2025 16:27:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 245:
> 
>> 243: 
>> 244:     /**
>> 245:      * {@return if this lazy constant is the same instance as the provided {@code obj}}
> 
> Suggestion:
> 
>      * {@return {@code true} if this lazy constant is the same instance as the provided {@code obj}}

Yes. This is JDK style. Personally, I like the shorter version better but will change.

If we do the change, the sentence does not say what is returned if they are not the same instance for example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28388#discussion_r2544968211

From pminborg at openjdk.org  Thu Nov 20 09:14:28 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 20 Nov 2025 09:14:28 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP
In-Reply-To: <6wDMi8Qmn1LkG-CN5DC8l5dYX-BrjBN_Xo_Vu-u_mtw=.c68acc6d-2304-482d-8d2e-9e7156802b71@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
 <gEqpNasH9iMQBmot1rr_MANzBnar2eoZvwe1gsGzL8k=.dd3126e0-b096-4cbf-9a4e-13374ef0da20@github.com>
 <6wDMi8Qmn1LkG-CN5DC8l5dYX-BrjBN_Xo_Vu-u_mtw=.c68acc6d-2304-482d-8d2e-9e7156802b71@github.com>
Message-ID: <DYsUUPUFVvLD4nGPDrPuRu5_JXS9ZZUG1AO2aKTc29s=.b0e0d364-8ef6-4ed7-952c-d4a8323e4b9e@github.com>

On Thu, 20 Nov 2025 09:01:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/LazyConstant.java line 245:
>> 
>>> 243: 
>>> 244:     /**
>>> 245:      * {@return if this lazy constant is the same instance as the provided {@code obj}}
>> 
>> Suggestion:
>> 
>>      * {@return {@code true} if this lazy constant is the same instance as the provided {@code obj}}
>
> Yes. This is JDK style. Personally, I like the shorter version better but will change.
> 
> If we do the change, the sentence does not say what is returned if they are not the same instance for example.

I have changed it so it will conform to e.g., `File` specification on predicates.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28388#discussion_r2545002502

From sgehwolf at openjdk.org  Thu Nov 20 09:21:00 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Nov 2025 09:21:00 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as UTF-8
 properly
Message-ID: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>

Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.

Testing:
- [x] GHA
- [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.

Thoughts?

-------------

Commit messages:
 - Add a test for the encoding issue
 - 8372155: RealeaseInfoPlugin doesn't handle input file as UTF-8 properly

Changes: https://git.openjdk.org/jdk/pull/28399/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28399&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372155
  Stats: 86 lines in 2 files changed: 84 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28399/head:pull/28399

PR: https://git.openjdk.org/jdk/pull/28399

From pminborg at openjdk.org  Thu Nov 20 09:26:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 20 Nov 2025 09:26:15 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP [v2]
In-Reply-To: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
Message-ID: <FTKvsq4OCqLrZ3ZwnPqpQrhuVEUMEu5DTkqjwJgC0sY=.43f96234-e13e-4a90-9959-9b716f15ba22@github.com>

> This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Clarify LC::equals

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28388/files
  - new: https://git.openjdk.org/jdk/pull/28388/files/938b97ca..06916c4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28388&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28388&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28388/head:pull/28388

PR: https://git.openjdk.org/jdk/pull/28388

From jpai at openjdk.org  Thu Nov 20 09:50:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 09:50:53 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly
In-Reply-To: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
Message-ID: <Xg4Nmx1rQB8R6UdsGRch4CR6Msm-Z3ih88I7nQ_dx38=.88d65697-952a-4fea-9c1b-24b738cdd8f6@github.com>

On Wed, 19 Nov 2025 17:47:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
> 
> Testing:
> - [x] GHA
> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
> 
> Thoughts?

Hello Severin, would it better to (even) specify the expectations of the `--release-info` jlink plugin and what encoding it expects for the file content?

I might be wrong, but even with the use of `UTF-8` for reading the given file (like proposed in this PR), it may not guarantee that it is the right Charset to use for that file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3556940180

From jpai at openjdk.org  Thu Nov 20 10:01:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 10:01:09 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v8]
In-Reply-To: <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
Message-ID: <ftVVLV1o2JYl2xAWbC9qbpnkIJDppgFZ15iNpGvGIu4=.951f55bc-f427-4752-92ed-7955837faf7d@github.com>

On Thu, 13 Nov 2025 06:46:51 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix StreamOpFlagsTest

Hello Patrick, the copyright year on each of these files will need an update. For example, `2012, 2025,` in place of `2012, 2013,` in the `SortedOpTest.java`. Similary for the other updated files in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3556976892

From sgehwolf at openjdk.org  Thu Nov 20 10:26:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Nov 2025 10:26:01 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly
In-Reply-To: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
Message-ID: <T6wMFDBwyQw8oiJ0N27EwmHOQiHS-qrnuN4HTestlsA=.a0cc458d-d1be-4771-ad6b-a9618b037fed@github.com>

On Wed, 19 Nov 2025 17:47:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
> 
> Testing:
> - [x] GHA
> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
> 
> Thoughts?

Thanks for the review.

> Hello Severin, would it better to (even) specify the expectations of the `--release-info` jlink plugin and what encoding it expects for the file content?

IIUYC, you'd like to have the help text amended for `--release-info` to say it expects the input file in `UTF-8`? Is that what you are saying?

IMO it would be best for `--release-info` to not only require a file as an option but also the encoding. It could perhaps default to `UTF-8`. @AlanBateman Any thoughts on this?

> I might be wrong, but even with the use of `UTF-8` for reading the given file (like proposed in this PR), it may not guarantee that it is the right Charset to use for that file.

True. If somebody passes an ISO-8859-1 (or any non-utf8) encoded file to `--release-info` it would break for any non-ASCII characters.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3557105439

From jpai at openjdk.org  Thu Nov 20 10:38:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 10:38:11 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly
In-Reply-To: <T6wMFDBwyQw8oiJ0N27EwmHOQiHS-qrnuN4HTestlsA=.a0cc458d-d1be-4771-ad6b-a9618b037fed@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <T6wMFDBwyQw8oiJ0N27EwmHOQiHS-qrnuN4HTestlsA=.a0cc458d-d1be-4771-ad6b-a9618b037fed@github.com>
Message-ID: <vzRzNgDFR1Rd8_N3hvlmJ1oDalrTnNZkhDyUBDlE8-0=.f83dad1d-6876-4b92-956a-2e41eda4dbea@github.com>

On Thu, 20 Nov 2025 10:23:04 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > Hello Severin, would it better to (even) specify the expectations of the `--release-info` jlink plugin and what encoding it expects for the file content?
> 
> IIUYC, you'd like to have the help text amended for `--release-info` to say it expects the input file in `UTF-8`? Is that what you are saying?

Correct, but not necessarily UTF-8. I am not familiar where all this release-info gets used during jlink and then in the generated image. So whatever encoding is appropriate for such content, I think we should specify it, in the help text and man page of jlink.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3557168114

From haraldei at openjdk.org  Thu Nov 20 10:42:31 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Thu, 20 Nov 2025 10:42:31 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
Message-ID: <62sr6iW1OTnDN1fcqyXtIgO6r6zVKm8X0Zludyp0PoI=.75323915-24c0-4779-9f02-a942a17d1063@github.com>

On Wed, 19 Nov 2025 13:29:28 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace conditional with Math.max intrinsic
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

I like that the openjdk bot is open to persuasion :)

Should I also add [the test](https://github.com/openjdk/jdk/pull/28235#issuecomment-3532821794) suggested by @Yqwed before we conclude this PR, or is it better to leave it for a later one?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3557197285

From duke at openjdk.org  Thu Nov 20 10:51:06 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Thu, 20 Nov 2025 10:51:06 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>

> This PR looks into updating the content of `--compress` option and plugin of `jlink`:
> 
> - Updates the `--compress` option description and warns that previous compression levels are deprecated to be removed in a future release.
> - Updates the `--plugin` option description and warns that previous compression levels are deprecated to be removed in a future release.

Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:

 - Remove extra line.
 - Align behavior of compression levels to the input received and sync help+documentation messages.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/8749e51e..2e6a3f18

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=01-02

  Stats: 59 lines in 4 files changed: 48 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Thu Nov 20 11:04:42 2025
From: duke at openjdk.org (Almaz)
Date: Thu, 20 Nov 2025 11:04:42 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
Message-ID: <zhDXuw2lpa_V1hcdUpDJL11OOBUKS-jqnVPSqPMNNss=.8c7c9753-02da-4728-8c51-c01e2c881ee5@github.com>

On Wed, 19 Nov 2025 14:30:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace conditional with Math.max intrinsic
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> I think the proposed simpler patch makes sense. Basically, it artificially expands the allocation size to match the alignment, which is probably not going to cause any side-effect as that is likely what was happening anyway...

@mcimadamore:

Question regarding `MAX_MALLOC_ALIGN = Unsafe.ADDRESS_SIZE == 4 ? 8 : 16;`

Is 16 here just a heuristic based on known malloc implementations or is it backed by something? I can't find anything regarding that in the libc standard. 

Not related to this particular PR: should `MAX_MALLOC_ALIGN` be `MIN_MALLOC_ALIGN` instead? Larger allocations might be page size aligned.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3557358928

From sgehwolf at openjdk.org  Thu Nov 20 11:05:59 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Nov 2025 11:05:59 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly [v2]
In-Reply-To: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
Message-ID: <Jij1th2_VlYUgWxm-zd0FkoP2wKO1aoctTGlijjLWBg=.ccb555d2-f820-4053-a6fb-5f5b2754196b@github.com>

> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
> 
> Testing:
> - [x] GHA
> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Specify that the input file shall be UTF-8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28399/files
  - new: https://git.openjdk.org/jdk/pull/28399/files/2059e527..2f48c81b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28399&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28399&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28399/head:pull/28399

PR: https://git.openjdk.org/jdk/pull/28399

From sgehwolf at openjdk.org  Thu Nov 20 11:06:00 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Nov 2025 11:06:00 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly
In-Reply-To: <vzRzNgDFR1Rd8_N3hvlmJ1oDalrTnNZkhDyUBDlE8-0=.f83dad1d-6876-4b92-956a-2e41eda4dbea@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <T6wMFDBwyQw8oiJ0N27EwmHOQiHS-qrnuN4HTestlsA=.a0cc458d-d1be-4771-ad6b-a9618b037fed@github.com>
 <vzRzNgDFR1Rd8_N3hvlmJ1oDalrTnNZkhDyUBDlE8-0=.f83dad1d-6876-4b92-956a-2e41eda4dbea@github.com>
Message-ID: <0yvuRnalKuPhBDs6e0L4xCUCuKgYI5TahuLtVs9iQb4=.22ed2413-c547-48be-9acc-243522361e73@github.com>

On Thu, 20 Nov 2025 10:33:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Correct, but not necessarily UTF-8.

It expects the input file to be UTF-8 now. So I've added that the plugin help text in https://github.com/openjdk/jdk/pull/28399/commits/2f48c81b90e358dabd01b96a89e2dcc9d882c781

> I am not familiar where all this release-info gets used during jlink and then in the generated image.

It's the plugin that creates the `$JDK/release` file. That's it.

> So whatever encoding is appropriate for such content, I think we should specify it, in the help text and man page of jlink.

I've added it to the `--list-plugin` help text now. Plugins aren't mentioned in the `jlink` man page, so it doesn't seem appropriate to mention it the `jlink` man page. Here is how it looks like when using `jlink --list-plugins` with the latest update:


  --release-info <file>|add:<key1>=<value1>:<key2>=<value2>:...|del:<key list>
                            <file> option is to load release properties from
                            the supplied file. The specified file is expected
                            to be encoded in UTF-8.
                            add: is to add properties to the release file.
                            Any number of <key>=<value> pairs can be passed.
                            del: is to delete the list of keys in release file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3557356452

From alanb at openjdk.org  Thu Nov 20 11:10:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Nov 2025 11:10:58 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly
In-Reply-To: <T6wMFDBwyQw8oiJ0N27EwmHOQiHS-qrnuN4HTestlsA=.a0cc458d-d1be-4771-ad6b-a9618b037fed@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <T6wMFDBwyQw8oiJ0N27EwmHOQiHS-qrnuN4HTestlsA=.a0cc458d-d1be-4771-ad6b-a9618b037fed@github.com>
Message-ID: <aGI5voHPLs0Nu4BMjnUBOYcgnUIKp-uZbgg3p6Inrho=.4dc65eff-f547-4722-9519-73f7fe930b99@github.com>

On Thu, 20 Nov 2025 10:23:04 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> IMO it would be best for `--release-info` to not only require a file as an option but also the encoding. It could perhaps default to `UTF-8`. @AlanBateman Any thoughts on this?

It's very likely that tools that read the release file aren't using Properties API so I think having it UTF-8 is best.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3557393145

From mcimadamore at openjdk.org  Thu Nov 20 11:36:07 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Nov 2025 11:36:07 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
Message-ID: <7GPlLrIKdco0l6GK-Ez6IleE3CLvCnCdlF_kekTvDqo=.1745539c-dd1a-4db3-a121-319e5c74fe04@github.com>

On Wed, 19 Nov 2025 14:30:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace conditional with Math.max intrinsic
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> I think the proposed simpler patch makes sense. Basically, it artificially expands the allocation size to match the alignment, which is probably not going to cause any side-effect as that is likely what was happening anyway...

> @mcimadamore:
> 
> Question regarding `MAX_MALLOC_ALIGN = Unsafe.ADDRESS_SIZE == 4 ? 8 : 16;`
> 
> Is 16 here just a heuristic based on known malloc implementations or is it backed by something? I can't find anything regarding that in the libc standard.
> 
> Not related to this particular PR: should `MAX_MALLOC_ALIGN` be `MIN_MALLOC_ALIGN` instead? Larger allocations might be page size aligned.

I think this is a common assumption on malloc/Linux:

https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html

> The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems)

I believe the underlying reason has to do with the system ABI -- e.g. what malloc returns has to provide at least enough alignment as required for the fundamental types supported by the ABI.

The main question raised in this PR is whether malloc is technically also allowed to return things that are less aligned than the size  of the max supported data type in the ABI. Here is where the C standard changed a bit -- as in C23 is now a bit clearer that, when allocating, say, 4 bytes, malloc is free to return a memory region that is aligned to 4 bytes, not 8 or 16. This is because if you take the `void*`  returned by `malloc` you might cast it to `int*` or `char*` and expect it to work fine. If you try and cast it to `long*`, while the type system lets you do that, you will end up with undefined behavior anyway (as the allocated region is not big enough to read/write longs)... which is why (I think) the clarification was added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3557507640

From mcimadamore at openjdk.org  Thu Nov 20 11:38:44 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Nov 2025 11:38:44 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP [v2]
In-Reply-To: <FTKvsq4OCqLrZ3ZwnPqpQrhuVEUMEu5DTkqjwJgC0sY=.43f96234-e13e-4a90-9959-9b716f15ba22@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
 <FTKvsq4OCqLrZ3ZwnPqpQrhuVEUMEu5DTkqjwJgC0sY=.43f96234-e13e-4a90-9959-9b716f15ba22@github.com>
Message-ID: <nNN5unsHoJR1vvNMzo9BLUcQirVDHGBy-eud0RiD0ps=.eef4c872-39d6-43e0-a4c4-07039a850c6a@github.com>

On Thu, 20 Nov 2025 09:26:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify LC::equals

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28388#pullrequestreview-3487331182

From mcimadamore at openjdk.org  Thu Nov 20 11:40:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Nov 2025 11:40:14 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <ctYtB_c9b8d9MznTFkh6XUGMKlEpVW52WcYuUnMAijE=.ba43143a-04f5-49dc-8e1a-03ecf1b6661e@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
 <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>
 <ctYtB_c9b8d9MznTFkh6XUGMKlEpVW52WcYuUnMAijE=.ba43143a-04f5-49dc-8e1a-03ecf1b6661e@github.com>
Message-ID: <0xfjBX84l7g2VW4oenRlGQaNth4JbfNnMh_e9M_s1_8=.f0d5b2e3-114d-46e1-ab21-a05bbafa43e7@github.com>

On Wed, 19 Nov 2025 20:34:21 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 2019:
>> 
>>> 2017:     }
>>> 2018: 
>>> 2019:     boolean bytesCompatible(Charset charset, int srcIndex, int numChars) {
>> 
>> Surprisingly here we don't do anything for the case where the string is UTF16 and the target charset is also UTF16?
>
> The **UTF?16**?`Charset`s disallow unpaired?surrogates, which?**Java** `String`s?allow.
> 
> So?this can?only return?`true` for?**UTF?16** when?the?platform and?charset endianness?match and?the?`String` doesn?t?have any?unpaired?surrogates.

Yeah, tricky stuff -- we'll need to think more before changing this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2545655612

From mcimadamore at openjdk.org  Thu Nov 20 11:46:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Nov 2025 11:46:47 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <c3gt3ASSzKZN5pgKP2DvEFsDcW5gKtA7trDQbdd3Ilg=.43358de3-482b-4d95-8bfa-d46bc04452dd@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
 <c3gt3ASSzKZN5pgKP2DvEFsDcW5gKtA7trDQbdd3Ilg=.43358de3-482b-4d95-8bfa-d46bc04452dd@github.com>
Message-ID: <Xm8tJX7zY95zyy0edxO-lSlDXt47BxcQS3EfwqELSf8=.5adac543-0901-499d-bc58-22c0d00122c9@github.com>

On Thu, 20 Nov 2025 08:52:36 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> To confirm do you think it's OK to leave optimizing the UTF16 case as future work, as long as the current assumptions are clearly documented and guarded by assertions?

I think this is ok, yes -- maybe add a link (comment) between the assertion being thrown and String::bytesCompatible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3557546629

From mcimadamore at openjdk.org  Thu Nov 20 11:46:45 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Nov 2025 11:46:45 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
Message-ID: <LOOfv4yCD5Ar3AsZZLx9FcTgpHVymdPQL93jgvfH1Rw=.044e342a-4eac-44d2-87ab-d71d5570ecf0@github.com>

On Thu, 20 Nov 2025 08:59:11 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Overall approach looks solid, thanks for working on this improvement!

-------------

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3487372885

From sgehwolf at openjdk.org  Thu Nov 20 12:05:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Nov 2025 12:05:01 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly
In-Reply-To: <aGI5voHPLs0Nu4BMjnUBOYcgnUIKp-uZbgg3p6Inrho=.4dc65eff-f547-4722-9519-73f7fe930b99@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <T6wMFDBwyQw8oiJ0N27EwmHOQiHS-qrnuN4HTestlsA=.a0cc458d-d1be-4771-ad6b-a9618b037fed@github.com>
 <aGI5voHPLs0Nu4BMjnUBOYcgnUIKp-uZbgg3p6Inrho=.4dc65eff-f547-4722-9519-73f7fe930b99@github.com>
Message-ID: <8fCOQd0evG3beDKf2hXUwXLpl5bVkOzM6B_BFjNH7yI=.0236a1c5-3160-43b8-ad80-91a8aab39c83@github.com>

On Thu, 20 Nov 2025 11:07:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > IMO it would be best for `--release-info` to not only require a file as an option but also the encoding. It could perhaps default to `UTF-8`. @AlanBateman Any thoughts on this?
> 
> It's very likely that tools that read the release file aren't using Properties API so I think having it UTF-8 is best.

The output `$JDK/release` file will be UTF-8 since the `ReleaseInfoPlugin` uses `PrintWriter(BytearrayOutputStream)` to write the content bytes to the `ResourcePoolEntry`. That in-turn uses `UTF-8` since JEP 400 (by means of `Charset.defaultCharset()`.

Question is if it's worth supporting arbitrary *input* encondings for `--release-info <file>` usages. `<file>` is currently in UTF-8 in the JDK build, so went with that expectation. But arguably it could be any other encoding a user chooses. So to make it generic, it's conceivable to allow `--release-info=<file>,<encoding>` or some such to allow non-UTF-8 as input and still do the right thing (Note: output would still be UTF-8). Perhaps it's not worth the trouble?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3557623960

From alanb at openjdk.org  Thu Nov 20 12:11:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Nov 2025 12:11:44 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly [v2]
In-Reply-To: <Jij1th2_VlYUgWxm-zd0FkoP2wKO1aoctTGlijjLWBg=.ccb555d2-f820-4053-a6fb-5f5b2754196b@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <Jij1th2_VlYUgWxm-zd0FkoP2wKO1aoctTGlijjLWBg=.ccb555d2-f820-4053-a6fb-5f5b2754196b@github.com>
Message-ID: <JEXIww9uirVB-hi5rok1ZIEfNovD55f56osP_zxy9-k=.b1482a7f-3f19-4557-84e2-1385765d8e80@github.com>

On Thu, 20 Nov 2025 11:05:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
>> 
>> Testing:
>> - [x] GHA
>> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Specify that the input file shall be UTF-8

> Question is if it's worth supporting arbitrary _input_ encondings for `--release-info <file>` usages. `<file>` is currently in UTF-8 in the JDK build, so went with that expectation. But arguably it could be any other encoding a user chooses. So to make it generic, it's conceivable to allow `--release-info=<file>,<encoding>` or some such to allow non-UTF-8 as input and still do the right thing (Note: output would still be UTF-8). Perhaps it's not worth the trouble?

That seems unnecessary complexity, I think we should just keep it as UTF-8.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3557683372

From jpai at openjdk.org  Thu Nov 20 12:15:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 12:15:53 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
Message-ID: <jJad_byg_l20nlbAZjHDUCadnTNL6FdNmGCTESHyRE0=.d1e86a93-6478-466c-83bf-595d304d7bb8@github.com>

On Thu, 20 Nov 2025 10:51:06 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove extra line.
>  - Align behavior of compression levels to the input received and sync help+documentation messages.

src/jdk.jlink/share/man/jlink.md line 67:

> 65: :   Link service provider modules and their dependencies.
> 66: 
> 67: `-c zip-[0-9]` or `--compress=zip-[0-9]`

Nit - the use of square brackets is usually meant to imply "optional". Here it is mandatory to specify a digit between 0 and 9 following the "zip-" text. Perhaps using angular bracket would be better?

-c zip-<0-9> or --compress=zip-<0-9>

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2545798379

From dfuchs at openjdk.org  Thu Nov 20 12:26:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:21 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v2]
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <fbZzaZTDoy8CE5Q-391sOVBezopxpDa7ggDCKJ2R3po=.cac468b3-953b-491f-8bb5-05b3222db78b@github.com>

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

Daniel Fuchs 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 'SelectorManagerVT-8372159' into ConnectionCloseLock-8372198
 - 8372198: Avoid closing PlainHttpConnection while holding a lock

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28421/files
  - new: https://git.openjdk.org/jdk/pull/28421/files/177e7ee3..97ce3737

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=00-01

  Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod
  Patch: https://git.openjdk.org/jdk/pull/28421.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28421/head:pull/28421

PR: https://git.openjdk.org/jdk/pull/28421

From dfuchs at openjdk.org  Thu Nov 20 12:26:22 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:22 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <BEkaPOGOa8LRlqic4jsZvlx97AR8RVfNhjk5_1Kvips=.741bab98-7b90-4f2c-aadc-c93d62650091@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

Something went wrong when I tried to merge the main PR branch in the dependent PR branch. I'm going to withdraw this PR and start again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28421#issuecomment-3557752299

From dfuchs at openjdk.org  Thu Nov 20 12:26:23 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:23 GMT
Subject: Withdrawn: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <S8TUGJh8rmGEbyRwrMCP7SaPKA6HJG8O_HHX17gFyDw=.2eb7031f-a01d-42d1-8efc-1b49466b48dc@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/28421

From alanb at openjdk.org  Thu Nov 20 12:38:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Nov 2025 12:38:12 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly [v2]
In-Reply-To: <Jij1th2_VlYUgWxm-zd0FkoP2wKO1aoctTGlijjLWBg=.ccb555d2-f820-4053-a6fb-5f5b2754196b@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <Jij1th2_VlYUgWxm-zd0FkoP2wKO1aoctTGlijjLWBg=.ccb555d2-f820-4053-a6fb-5f5b2754196b@github.com>
Message-ID: <wEFIlvPWKZ-NnzGJkjJKxSErhI3LW_km-w1cTmbG_M8=.cc19135a-1b2f-4199-ae58-00fcd0d2636c@github.com>

On Thu, 20 Nov 2025 11:05:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
>> 
>> Testing:
>> - [x] GHA
>> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Specify that the input file shall be UTF-8

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java line 111:

> 109:                 // --release-info <file>
> 110:                 Properties props = new Properties();
> 111:                 try (InputStreamReader isr = new InputStreamReader(new FileInputStream(operation), "UTF-8")) {

`try (Reader reader = Files.newBufferedReader(Path.of(operation)))` for something shorter.

test/jdk/tools/jlink/plugins/ReleaseInfoPluginTest.java line 74:

> 72:         var release = image.resolve("release");
> 73:         Properties props = new Properties();
> 74:         try (InputStreamReader isr = new InputStreamReader(new FileInputStream(release.toFile()), "UTF-8")) {

Same here, the new APIs always use UTF-8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28399#discussion_r2545889489
PR Review Comment: https://git.openjdk.org/jdk/pull/28399#discussion_r2545893876

From haraldei at openjdk.org  Thu Nov 20 12:43:45 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Thu, 20 Nov 2025 12:43:45 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <zhDXuw2lpa_V1hcdUpDJL11OOBUKS-jqnVPSqPMNNss=.8c7c9753-02da-4728-8c51-c01e2c881ee5@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
 <zhDXuw2lpa_V1hcdUpDJL11OOBUKS-jqnVPSqPMNNss=.8c7c9753-02da-4728-8c51-c01e2c881ee5@github.com>
Message-ID: <9ZVnmjA-LjcGLVnYPCO8IB1kqbsBOxFE5HgORP5izyk=.b974fda1-7038-4072-8c06-1b5b60abc6de@github.com>

On Thu, 20 Nov 2025 11:02:32 GMT, Almaz <duke at openjdk.org> wrote:

>> I think the proposed simpler patch makes sense. Basically, it artificially expands the allocation size to match the alignment, which is probably not going to cause any side-effect as that is likely what was happening anyway...
>
> @mcimadamore:
> 
> Question regarding `MAX_MALLOC_ALIGN = Unsafe.ADDRESS_SIZE == 4 ? 8 : 16;`
> 
> Is 16 here just a heuristic based on known malloc implementations or is it backed by something? I can't find anything regarding that in the libc standard. 
> 
> Not related to this particular PR: should `MAX_MALLOC_ALIGN` be `MIN_MALLOC_ALIGN` instead? Larger allocations might be page size aligned.

> Should I also add [the test](https://github.com/openjdk/jdk/pull/28235#issuecomment-3532821794) suggested by @Yqwed before we conclude this PR, or is it better to leave it for a later one?

I've tested it a bit, but I'm not sure it provides any extra value. It seems to only trigger on the same condition as the existing `testActualByteAlignment` and `testAlignedAccess` tests in `TestMemoryAlignment.java`..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3557849641

From duke at openjdk.org  Thu Nov 20 13:01:39 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Thu, 20 Nov 2025 13:01:39 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <jJad_byg_l20nlbAZjHDUCadnTNL6FdNmGCTESHyRE0=.d1e86a93-6478-466c-83bf-595d304d7bb8@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
 <jJad_byg_l20nlbAZjHDUCadnTNL6FdNmGCTESHyRE0=.d1e86a93-6478-466c-83bf-595d304d7bb8@github.com>
Message-ID: <WH3ecv0QGys2-QpqltzMyz2jQGi2ZBXOo23JX9PG3GU=.77c2d810-e693-4ec2-888f-41c82094120f@github.com>

On Thu, 20 Nov 2025 12:12:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove extra line.
>>  - Align behavior of compression levels to the input received and sync help+documentation messages.
>
> src/jdk.jlink/share/man/jlink.md line 67:
> 
>> 65: :   Link service provider modules and their dependencies.
>> 66: 
>> 67: `-c zip-[0-9]` or `--compress=zip-[0-9]`
> 
> Nit - the use of square brackets is usually meant to imply "optional". Here it is mandatory to specify a digit between 0 and 9 following the "zip-" text. Perhaps using angular bracket would be better?
> 
> -c zip-<0-9> or --compress=zip-<0-9>

Good point. Thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2545978005

From duke at openjdk.org  Thu Nov 20 13:01:41 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Thu, 20 Nov 2025 13:01:41 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <XzvlblpBRRWvXhoSwgFC8bekI6xF7Egm91JfvZzf6_g=.73fca675-3451-464c-bf37-d90d6b22304d@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <eHp-k23g-OqhOUsyqZ2cDOufAKJpufu_wQSwK4tMuXE=.0cc7eeac-cc94-431b-a161-524ef94c1cd2@github.com>
 <ysZNKy9wkcIZZBOUTKqoHZnzSmTOhZRpvpu8n6m5b_s=.5077678d-b671-46de-857c-d9bdf291194b@github.com>
 <jSKQJTt25kmvoF4qtRheQmrkb8FAjmyWdq41sxlQlE0=.66e6fd51-52cc-4a80-b5af-f1248f7e5bb8@github.com>
 <1_70-rAo-dpg2R9YWfhc1sjAcnUHOhcRKAxjCWWIJPc=.12de5336-ff0e-4be3-b3e6-41133e49eb56@github.com>
 <XzvlblpBRRWvXhoSwgFC8bekI6xF7Egm91JfvZzf6_g=.73fca675-3451-464c-bf37-d90d6b22304d@github.com>
Message-ID: <3YXJCbs5n0eiOgoMjlfRmeL9IBRkp5ru_xM54f5Nv7o=.a73fa4a8-f354-4c24-935f-7a1d03b2b2bb@github.com>

On Tue, 18 Nov 2025 09:13:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So maybe I should investigate first what happened to `-c` argument and then improve the documentation?
>
> That would be great, if you have the cycles.

I looked into the issue and provided a fix. Hence I modified the description of this PR and issue related to it. Please let me know if is ok to change the title of the bug and PR as well, to proper reflect the changes introduced. Thank you ? .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2545982273

From sgehwolf at openjdk.org  Thu Nov 20 13:38:16 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Nov 2025 13:38:16 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly [v3]
In-Reply-To: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
Message-ID: <VqY4Q6bwkPv6jC8DWUfNlDyC6lIKHbtTX1c_48nla5k=.3191978f-9b69-433e-ab57-c6aa35ee692f@github.com>

> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
> 
> Testing:
> - [x] GHA
> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback from Alan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28399/files
  - new: https://git.openjdk.org/jdk/pull/28399/files/2f48c81b..580b4b13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28399&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28399&range=01-02

  Stats: 13 lines in 2 files changed: 3 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28399/head:pull/28399

PR: https://git.openjdk.org/jdk/pull/28399

From sgehwolf at openjdk.org  Thu Nov 20 13:38:19 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Nov 2025 13:38:19 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly [v2]
In-Reply-To: <wEFIlvPWKZ-NnzGJkjJKxSErhI3LW_km-w1cTmbG_M8=.cc19135a-1b2f-4199-ae58-00fcd0d2636c@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <Jij1th2_VlYUgWxm-zd0FkoP2wKO1aoctTGlijjLWBg=.ccb555d2-f820-4053-a6fb-5f5b2754196b@github.com>
 <wEFIlvPWKZ-NnzGJkjJKxSErhI3LW_km-w1cTmbG_M8=.cc19135a-1b2f-4199-ae58-00fcd0d2636c@github.com>
Message-ID: <xycW-s0SaQAwHAj5jAfoTEl0MWpswaogjMOoR7PCULA=.02002a6f-8894-42cb-963f-dd6b3d11df09@github.com>

On Thu, 20 Nov 2025 12:33:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Specify that the input file shall be UTF-8
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java line 111:
> 
>> 109:                 // --release-info <file>
>> 110:                 Properties props = new Properties();
>> 111:                 try (InputStreamReader isr = new InputStreamReader(new FileInputStream(operation), "UTF-8")) {
> 
> `try (Reader reader = Files.newBufferedReader(Path.of(operation)))` for something shorter.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28399#discussion_r2546098359

From liach at openjdk.org  Thu Nov 20 13:43:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Nov 2025 13:43:27 GMT
Subject: RFR: 8372047: ClassTransform.transformingMethodBodies andThen
 composes incorrectly [v3]
In-Reply-To: <Ulz51B4LNMyBvTnHhFUcutqkDb0vV8IjWNqplfwcaQQ=.2bf8fbbe-dafa-4ea8-ad79-b6ffc6f36016@github.com>
References: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
 <Ulz51B4LNMyBvTnHhFUcutqkDb0vV8IjWNqplfwcaQQ=.2bf8fbbe-dafa-4ea8-ad79-b6ffc6f36016@github.com>
Message-ID: <Ra2s9M-IkILrwuf2X78tCUzvAt9B24iehawiW1Hg2W0=.847c2641-3b51-4bd9-a831-2eebb2e7c0a2@github.com>

On Wed, 19 Nov 2025 14:18:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ClassMethodTransform and ClassFieldTransform are computing the chaining condition incorrectly - the composed transform should run when any of the component wants to run instead of when all copmonents want to run, and the actual content tranforms can only compose if they apply to the same set of method or fields. So we should restrict this "optimization" to same filters.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make it clear where the filter is shared

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28377#issuecomment-3558108693

From liach at openjdk.org  Thu Nov 20 13:43:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Nov 2025 13:43:28 GMT
Subject: Integrated: 8372047: ClassTransform.transformingMethodBodies andThen
 composes incorrectly
In-Reply-To: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
References: <XTAmHrvCz-Q1zaVfieqrGhzE1ZLoDYqsJncW5eOkBPE=.90711506-acd9-47d7-b938-a104a4f8da0e@github.com>
Message-ID: <FMmVSYUXF8c7gds3_9S120tkwAo9kh7ciupnEXlKVmQ=.27f65cb3-50ef-400d-bb44-b87c45b2e664@github.com>

On Tue, 18 Nov 2025 16:00:49 GMT, Chen Liang <liach at openjdk.org> wrote:

> ClassMethodTransform and ClassFieldTransform are computing the chaining condition incorrectly - the composed transform should run when any of the component wants to run instead of when all copmonents want to run, and the actual content tranforms can only compose if they apply to the same set of method or fields. So we should restrict this "optimization" to same filters.

This pull request has now been integrated.

Changeset: 7b11bd1b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7b11bd1b1d8dbc9bedcd8cf14e78c8f5eb06a71f
Stats:     77 lines in 2 files changed: 52 ins; 10 del; 15 mod

8372047: ClassTransform.transformingMethodBodies andThen composes incorrectly

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/28377

From duke at openjdk.org  Thu Nov 20 13:47:53 2025
From: duke at openjdk.org (Almaz)
Date: Thu, 20 Nov 2025 13:47:53 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <7GPlLrIKdco0l6GK-Ez6IleE3CLvCnCdlF_kekTvDqo=.1745539c-dd1a-4db3-a121-319e5c74fe04@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
 <7GPlLrIKdco0l6GK-Ez6IleE3CLvCnCdlF_kekTvDqo=.1745539c-dd1a-4db3-a121-319e5c74fe04@github.com>
Message-ID: <_G_KO4wYar6SMQ9-kbYDQ6Iw1W8O_Tgx3IxvdQxcwLA=.0e2c607f-60b5-4111-9a22-bb6b4bb25c4c@github.com>

On Thu, 20 Nov 2025 11:32:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I think the proposed simpler patch makes sense. Basically, it artificially expands the allocation size to match the alignment, which is probably not going to cause any side-effect as that is likely what was happening anyway...
>
>> @mcimadamore:
>> 
>> Question regarding `MAX_MALLOC_ALIGN = Unsafe.ADDRESS_SIZE == 4 ? 8 : 16;`
>> 
>> Is 16 here just a heuristic based on known malloc implementations or is it backed by something? I can't find anything regarding that in the libc standard.
>> 
>> Not related to this particular PR: should `MAX_MALLOC_ALIGN` be `MIN_MALLOC_ALIGN` instead? Larger allocations might be page size aligned.
> 
> I think this is a common assumption on malloc/Linux:
> 
> https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html
> 
>> The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems)
> 
> I believe the underlying reason has to do with the system ABI -- e.g. what malloc returns has to provide at least enough alignment as required for the fundamental types supported by the ABI.
> 
> The main question raised in this PR is whether malloc is technically also allowed to return things that are less aligned than the size  of the max supported data type in the ABI. Here is where the C standard changed a bit -- as in C23 is now a bit clearer that, when allocating, say, 4 bytes, malloc is free to return a memory region that is aligned to 4 bytes, not 8 or 16. This is because if you take the `void*`  returned by `malloc` you might cast it to `int*` or `char*` and expect it to work fine. If you try and cast it to `long*`, while the type system lets you do that, you will end up with undefined behavior anyway (as the allocated region is not big enough to read/write longs)... which is why (I think) the clarification was added.

Thanks, @mcimadamore!

> https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html

Are you intentionally linking GNU's C Library here instead of WG14?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3558146250

From liach at openjdk.org  Thu Nov 20 13:53:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Nov 2025 13:53:19 GMT
Subject: RFR: 8372146: Follow-up changes to the Lazy Constants JEP [v2]
In-Reply-To: <FTKvsq4OCqLrZ3ZwnPqpQrhuVEUMEu5DTkqjwJgC0sY=.43f96234-e13e-4a90-9959-9b716f15ba22@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
 <FTKvsq4OCqLrZ3ZwnPqpQrhuVEUMEu5DTkqjwJgC0sY=.43f96234-e13e-4a90-9959-9b716f15ba22@github.com>
Message-ID: <cENON6tEyaD6N0iwTHZijOs9Kd75b7FzmJprZXw6fPA=.4aa02da4-fabf-48bd-8614-2cfd2f18e591@github.com>

On Thu, 20 Nov 2025 09:26:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify LC::equals

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28388#pullrequestreview-3487968694

From liach at openjdk.org  Thu Nov 20 13:52:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Nov 2025 13:52:01 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v8]
In-Reply-To: <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <jLjcKJyS7bbvdnI0Su6HDXigzqMsxvjRNNOEd92xFPo=.1de607af-cb51-4cb2-9a58-01330e338ff1@github.com>
Message-ID: <3o4-FZ3OH-JhM37_BHLGnHiRkNpz5Xa0cwSxIzO2NNU=.5e433d7c-c315-436a-a213-875dea5b6ab4@github.com>

On Thu, 13 Nov 2025 06:46:51 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix StreamOpFlagsTest

Note for copyright year update: You can first update your `master` branch reference via `git fetch <upstream> master:master`, and execute `bash bin/update_copyright_year.sh` to have the years automatically updated for you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3558167247

From pminborg at openjdk.org  Thu Nov 20 13:55:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 20 Nov 2025 13:55:52 GMT
Subject: RFR: 8372258: Improve TypeVariable support
Message-ID: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>

The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate.

-------------

Commit messages:
 - Creat copies of mutable generic declarations

Changes: https://git.openjdk.org/jdk/pull/28429/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28429&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372258
  Stats: 82 lines in 2 files changed: 78 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28429/head:pull/28429

PR: https://git.openjdk.org/jdk/pull/28429

From liach at openjdk.org  Thu Nov 20 13:55:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Nov 2025 13:55:52 GMT
Subject: RFR: 8372258: Improve TypeVariable support
In-Reply-To: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
References: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
Message-ID: <z_r7Isn2f82z3qIp3vVoU5o93Izdlj0rlh-76mcS2sk=.d4c55c9d-1132-4989-a7f1-c71febfde886@github.com>

On Thu, 20 Nov 2025 13:06:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28429#pullrequestreview-3487980865

From pminborg at openjdk.org  Thu Nov 20 13:55:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 20 Nov 2025 13:55:53 GMT
Subject: RFR: 8372258: Improve TypeVariable support
In-Reply-To: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
References: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
Message-ID: <KdKVGSOjceYoBP3wrZ5JJZSxU-zcn8Pwk1jxVvzzt5M=.625d4772-3e1e-451d-b20c-1991ab2210d5@github.com>

On Thu, 20 Nov 2025 13:06:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate.

This PR passes tier1-tier3 tests on multiple platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28429#issuecomment-3557975090

From mcimadamore at openjdk.org  Thu Nov 20 14:31:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Nov 2025 14:31:58 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <_G_KO4wYar6SMQ9-kbYDQ6Iw1W8O_Tgx3IxvdQxcwLA=.0e2c607f-60b5-4111-9a22-bb6b4bb25c4c@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
 <7GPlLrIKdco0l6GK-Ez6IleE3CLvCnCdlF_kekTvDqo=.1745539c-dd1a-4db3-a121-319e5c74fe04@github.com>
 <_G_KO4wYar6SMQ9-kbYDQ6Iw1W8O_Tgx3IxvdQxcwLA=.0e2c607f-60b5-4111-9a22-bb6b4bb25c4c@github.com>
Message-ID: <i1OMPFfxQBHnK3k1Ly3h7R6-JrqIqAfPdwceoCrM2QU=.d326a919-c61a-4f28-b4f4-e45b45c5b0f8@github.com>

On Thu, 20 Nov 2025 13:44:39 GMT, Almaz <duke at openjdk.org> wrote:

> Are you intentionally linking GNU's C Library here instead of WG14?

Yes, because I think that's where this "trick" came from in the first place.

Re. use of `MAX` vs. `MIN` I think the idea is that, while what `malloc` return *might* be page aligned, there's no guarantee for it to do so. Once you go past 8/16 bytes you are really on your own, unless you use an aligning allocation function (so we need to manually align by over-allocating and then slicing the result).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3558348291

From duke at openjdk.org  Thu Nov 20 14:46:03 2025
From: duke at openjdk.org (Almaz)
Date: Thu, 20 Nov 2025 14:46:03 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <i1OMPFfxQBHnK3k1Ly3h7R6-JrqIqAfPdwceoCrM2QU=.d326a919-c61a-4f28-b4f4-e45b45c5b0f8@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
 <7GPlLrIKdco0l6GK-Ez6IleE3CLvCnCdlF_kekTvDqo=.1745539c-dd1a-4db3-a121-319e5c74fe04@github.com>
 <_G_KO4wYar6SMQ9-kbYDQ6Iw1W8O_Tgx3IxvdQxcwLA=.0e2c607f-60b5-4111-9a22-bb6b4bb25c4c@github.com>
 <i1OMPFfxQBHnK3k1Ly3h7R6-JrqIqAfPdwceoCrM2QU=.d326a919-c61a-4f28-b4f4-e45b45c5b0f8@github.com>
Message-ID: <qeqZOflyFvuT6CGD_xSJm1GqChAfZf9OLKsBQ8ub1gc=.8387b4a5-cf65-457a-afd6-6e48d5e6ae5d@github.com>

On Thu, 20 Nov 2025 14:28:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Yes, because I think that's where this "trick" came from in the first place.

Doesn't existence of this PR implies that hotspot is running in GNU libc non-conformant environments? With this patch applied `MAX_MALLOC_ALIGN` will assume GNU libc and at the same time there will be `allocationSize = Math.max(alignedSize, byteAlignment);` which is a workaround for cases where GNU libc guarantess do not hold.

Wouldn't it be safer to code against WG14's version?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3558418909

From rriggs at openjdk.org  Thu Nov 20 14:49:15 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Nov 2025 14:49:15 GMT
Subject: RFR: 8372155: RealeaseInfoPlugin doesn't handle input file as
 UTF-8 properly [v3]
In-Reply-To: <VqY4Q6bwkPv6jC8DWUfNlDyC6lIKHbtTX1c_48nla5k=.3191978f-9b69-433e-ab57-c6aa35ee692f@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <VqY4Q6bwkPv6jC8DWUfNlDyC6lIKHbtTX1c_48nla5k=.3191978f-9b69-433e-ab57-c6aa35ee692f@github.com>
Message-ID: <DW01vzlbfZMNof0oiCQxdwGjY8V2WjWJxFYprzYeeMA=.8caf469c-a245-49bf-a4a3-68b2e66775e6@github.com>

On Thu, 20 Nov 2025 13:38:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
>> 
>> Testing:
>> - [x] GHA
>> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback from Alan

Please fix the typo in the PR title. (I corrected the issue title).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3558435896

From rriggs at openjdk.org  Thu Nov 20 14:52:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Nov 2025 14:52:59 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <WH3ecv0QGys2-QpqltzMyz2jQGi2ZBXOo23JX9PG3GU=.77c2d810-e693-4ec2-888f-41c82094120f@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
 <jJad_byg_l20nlbAZjHDUCadnTNL6FdNmGCTESHyRE0=.d1e86a93-6478-466c-83bf-595d304d7bb8@github.com>
 <WH3ecv0QGys2-QpqltzMyz2jQGi2ZBXOo23JX9PG3GU=.77c2d810-e693-4ec2-888f-41c82094120f@github.com>
Message-ID: <JSWnv-432jILEA8x1UmCkDXbS40hgNj0MggIBH_Hr6I=.ba870ff9-a6f7-41c4-ba70-615bc7421943@github.com>

On Thu, 20 Nov 2025 12:57:58 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> src/jdk.jlink/share/man/jlink.md line 67:
>> 
>>> 65: :   Link service provider modules and their dependencies.
>>> 66: 
>>> 67: `-c zip-[0-9]` or `--compress=zip-[0-9]`
>> 
>> Nit - the use of square brackets is usually meant to imply "optional". Here it is mandatory to specify a digit between 0 and 9 following the "zip-" text. Perhaps using angular bracket would be better?
>> 
>> -c zip-<0-9> or --compress=zip-<0-9>
>
> Good point. Thank you.

> Nit - the use of square brackets is usually meant to imply "optional". Here it is mandatory to specify a digit between 0 and 9 following the "zip-" text. Perhaps using angular bracket would be better?

Hmmm,  square brackets in the shell are a regex indicating a wildcard.  I think that `[0-9]` reads better in the shell/command line context.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2546361650

From jvernee at openjdk.org  Thu Nov 20 15:05:21 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 15:05:21 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
Message-ID: <21eAeYBuJBlAFFjmdb0SYy_PyVlfLax3_1zhOt3oTg4=.322a6e6a-6081-4504-b608-497bcb9189f9@github.com>

On Wed, 19 Nov 2025 13:29:28 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace conditional with Math.max intrinsic
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 215:

> 213:             result = Utils.alignUp(allocationBase, byteAlignment);
> 214:         } else {
> 215:             allocationSize = Math.max(alignedSize, byteAlignment);

This looks correct but it really needs a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2546407970

From jvernee at openjdk.org  Thu Nov 20 15:05:22 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 15:05:22 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <21eAeYBuJBlAFFjmdb0SYy_PyVlfLax3_1zhOt3oTg4=.322a6e6a-6081-4504-b608-497bcb9189f9@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <21eAeYBuJBlAFFjmdb0SYy_PyVlfLax3_1zhOt3oTg4=.322a6e6a-6081-4504-b608-497bcb9189f9@github.com>
Message-ID: <flRtYALiQ-FFxEWIsAi2bfUZAHDOjdrwpFUSvziCOSQ=.90a4cb00-df81-48d6-b201-0c7ae6eb15ac@github.com>

On Thu, 20 Nov 2025 14:57:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace conditional with Math.max intrinsic
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 215:
> 
>> 213:             result = Utils.alignUp(allocationBase, byteAlignment);
>> 214:         } else {
>> 215:             allocationSize = Math.max(alignedSize, byteAlignment);
> 
> This looks correct but it really needs a comment.

Suggestion:

            // always allocate at least 'byteAlignment' bytes, so that malloc is guaranteed to 
            // return a pointer aligned to that alignment, for cases where byteAlignment > alignedSize
            allocationSize = Math.max(alignedSize, byteAlignment);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2546417290

From jvernee at openjdk.org  Thu Nov 20 15:05:23 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 15:05:23 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <flRtYALiQ-FFxEWIsAi2bfUZAHDOjdrwpFUSvziCOSQ=.90a4cb00-df81-48d6-b201-0c7ae6eb15ac@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <21eAeYBuJBlAFFjmdb0SYy_PyVlfLax3_1zhOt3oTg4=.322a6e6a-6081-4504-b608-497bcb9189f9@github.com>
 <flRtYALiQ-FFxEWIsAi2bfUZAHDOjdrwpFUSvziCOSQ=.90a4cb00-df81-48d6-b201-0c7ae6eb15ac@github.com>
Message-ID: <q0WEBNYbn8rrxomuiQ_ya-PqdimsxfRniNeum5u_cR8=.df295903-5d93-42ae-9f82-8f076c3f8067@github.com>

On Thu, 20 Nov 2025 14:59:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 215:
>> 
>>> 213:             result = Utils.alignUp(allocationBase, byteAlignment);
>>> 214:         } else {
>>> 215:             allocationSize = Math.max(alignedSize, byteAlignment);
>> 
>> This looks correct but it really needs a comment.
>
> Suggestion:
> 
>             // always allocate at least 'byteAlignment' bytes, so that malloc is guaranteed to 
>             // return a pointer aligned to that alignment, for cases where byteAlignment > alignedSize
>             allocationSize = Math.max(alignedSize, byteAlignment);

Also, just a thought: theoretically we would be allocating 'too much', e.g. in a case where we need 1 byte with 16 byte alignment, in cases where malloc would already return a 16 byte aligned address. But I don't think it matters in practice since a 16 byte alignment in the implementation means that malloc can't use the 'other' 15 bytes after a 1 byte allocation any ways, since those addresses are not 16 byte aligned.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28235#discussion_r2546430391

From asemenyuk at openjdk.org  Thu Nov 20 15:22:20 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 15:22:20 GMT
Subject: Integrated: 8333727: Use JOpt in jpackage to parse command line
In-Reply-To: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
References: <almNdY7Z97cIxUEHsqfDJRoR9BFak1qA4LW-_Kd7Cqs=.c8befb1a-4a72-4fbc-a9bb-79678aee24c7@github.com>
Message-ID: <ecfsLaHF4GUPcRtlCq_mDxX9_Zkb9Ax52ZBTA88Qbek=.f6317aca-d487-48ab-90f1-b4e1ca397fcc@github.com>

On Wed, 5 Nov 2025 19:29:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Use "JOpt Simple" from [jdk.internal.joptsimple](https://github.com/openjdk/jdk/tree/master/src/jdk.internal.opt/share/classes/jdk/internal/joptsimple) package to parse jpackage command line.
> 
> All command-line parsing code is placed in a new "jdk.jpackage.internal.cli" package with 92% unit test coverage.
> 
> ### Error reporting improved
> 
> 1. In case of multiple command-line errors, all are reported, unlike previously, only the first one was reported.
> 
> Command line (Windows): 
> 
> jpackage --linux-shortcut --mac-package-name foo -p m1 --linux-menu-group grp -p m2 --app-image dir
> 
> Old error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> 
> 
> New error output:
> 
> Error: Option [--linux-shortcut] is not valid on this platform
> Error: Option [--mac-package-name] is not valid on this platform
> Error: Option [-p] is not valid with type [exe]
> Error: Option [--linux-menu-group] is not valid on this platform
> 
> 
>  2. Fix misleading error messages.
> 
> Command line (Windows): 
> 
> jpackage --input no --main-jar no.jar
> 
> Old error output:
> 
> jdk.jpackage.internal.model.ConfigException: The configured main jar does not exist no.jar in the input directory
> 
> 
> New error output:
> 
> The value "no" provided for parameter --input is not a directory
> 
> 
> 
> 
> ### Help output fixed
> 
> Options in the original help output were out of order. On macOS, options were placed in wrong sections. There were trailing whitespaces. 
> 
> The old help output is captured in the cd7bca2bb665556f314170c81129ef53de91f135 commit.
> 
> The reordered and filtered old help output is captured in the 10dc3792e6896cfa4bbe8693ee33e4c5df45d952 commit.
> 
> Help output in this PR is captured in the 58c2d944e2e14b1cf35786162ad2a5f9a8ccfee6 commit. Use it to see the diff between the new and old filtered and reordered help output.
> 
> ### Functional changes
> 
> Old tool provider implementation [jdk.jpackage.internal.JPackageToolProvider](https://github.com/openjdk/jdk/blob/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java#L48) had lousy thread-safety protection that didn't work when multiple instances of jpackage tool provider are created and invoked asynchronously. This patch fixes this issue. It is safe to invoke the same jpackage tool provider instance asynchronously, and also safe to invoke multiple instances of jpackage tool provider.
> 
> Like other JDK tools, jpackage will print help output if the `-?` option is specified on the command line.
> 
> In addition to `--opt...

This pull request has now been integrated.

Changeset: a8901858
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a89018582160a9d876f66925618c8b8f93190e67
Stats:     25028 lines in 170 files changed: 18176 ins; 6341 del; 511 mod

8333727: Use JOpt in jpackage to parse command line
8371384: libapplauncher.so is copied to a wrong location in two step packaging when --install-dir=/usr

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28163

From sgehwolf at openjdk.org  Thu Nov 20 15:24:21 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Nov 2025 15:24:21 GMT
Subject: RFR: 8372155: ReleaseInfoPlugin doesn't handle input file as UTF-8
 properly [v4]
In-Reply-To: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
Message-ID: <ZoTNBHIsGNTInIqUkjjf_TTbWaIh8-T7Zi1cYTKDkBk=.ed7e30ec-1a11-49ed-9409-4de906d1eecf@github.com>

> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
> 
> Testing:
> - [x] GHA
> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Copyright updates.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28399/files
  - new: https://git.openjdk.org/jdk/pull/28399/files/580b4b13..65e57118

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28399&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28399&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28399/head:pull/28399

PR: https://git.openjdk.org/jdk/pull/28399

From rriggs at openjdk.org  Thu Nov 20 15:41:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Nov 2025 15:41:16 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v25]
In-Reply-To: <rVuZKbQQxPiMh8z38HtlAu-jz4ZMnePr_jdnffmWEko=.baa3b7df-f5b8-4acd-858c-7f91f3986ca2@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <rVuZKbQQxPiMh8z38HtlAu-jz4ZMnePr_jdnffmWEko=.baa3b7df-f5b8-4acd-858c-7f91f3986ca2@github.com>
Message-ID: <pADj8ZTXJAzrE7KdnmELbBjyX4rwxz7codSJ0o8AdW0=.4d1417db-e863-4db0-a2c0-4f973e2c010d@github.com>

On Sat, 15 Nov 2025 14:45:48 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove DecimalDigitsTest

Looks good; a few suggestions on comments in DecimalDigits.

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 482:

> 480:      * values from 10 to 99 become three leading zeros (e.g., 25 becomes "0025"),
> 481:      * values from 100 to 999 become two leading zeros (e.g., 123 becomes "0123"),
> 482:      * and values from 1000 to 9999 become one leading zero or no leading zeros.

Minor correction to comment:
Suggestion:

     * values from 10 to 99 add two leading zeros (e.g., 25 becomes "0025"),
     * values from 100 to 999 add one leading zero (e.g., 123 becomes "0123"),
     * and values from 1000 to 9999 have no leading zeros.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26911#pullrequestreview-3488402521
PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2546472219

From jvernee at openjdk.org  Thu Nov 20 15:45:25 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 15:45:25 GMT
Subject: RFR: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
In-Reply-To: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
References: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
Message-ID: <PloxT6HF8oe0ETuadYwFOKa59vjDa5MoY-hFuvSLQ6s=.329d2878-bd4a-459b-a2b3-6930b394c381@github.com>

On Fri, 31 Oct 2025 00:00:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There were a few other holes in the recent migration of BytecodeDescriptor, most notably:
> 
> 1. BytecodeDescriptor is missing checks for `.`, `[` characters, leading, trailing, consecutive `/`, or empty name.
> 2. EnclosingMethod is only validated by hotspot to carry either field or method type. We still need to check for field types
> 
> I have written up the behavioral changes in the CSR. In addition, I have added a few more tests to ensure the failure case behaviors of the migrated use sites.

src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 160:

> 158:             | (1L << ('/' - CHECK_OFFSET))
> 159:             | (1L << (';' - CHECK_OFFSET))
> 160:             | (1L << ('[' - CHECK_OFFSET));

Are we sure that these are the only 4 non-identifier chars we can see in the string?

src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 166:

> 164:             int check = str.charAt(index) - CHECK_OFFSET;
> 165:             if ((check & -Long.SIZE) == 0 && (NON_IDENTIFIER_MASK & (1L << check)) != 0) {
> 166:                 break;

Maybe this is a little clearer:
Suggestion:

            if (check < 64 && (NON_IDENTIFIER_MASK & (1L << check)) != 0) {
                break;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28079#discussion_r2546556027
PR Review Comment: https://git.openjdk.org/jdk/pull/28079#discussion_r2546501723

From jvernee at openjdk.org  Thu Nov 20 15:45:26 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 15:45:26 GMT
Subject: RFR: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
In-Reply-To: <PloxT6HF8oe0ETuadYwFOKa59vjDa5MoY-hFuvSLQ6s=.329d2878-bd4a-459b-a2b3-6930b394c381@github.com>
References: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
 <PloxT6HF8oe0ETuadYwFOKa59vjDa5MoY-hFuvSLQ6s=.329d2878-bd4a-459b-a2b3-6930b394c381@github.com>
Message-ID: <QncMS-o2kNggimh-iL1siCd_kjNROQQQcazMsPDl2IM=.9e28a41c-561a-4ec9-89f7-58c4af916072@github.com>

On Thu, 20 Nov 2025 15:34:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> There were a few other holes in the recent migration of BytecodeDescriptor, most notably:
>> 
>> 1. BytecodeDescriptor is missing checks for `.`, `[` characters, leading, trailing, consecutive `/`, or empty name.
>> 2. EnclosingMethod is only validated by hotspot to carry either field or method type. We still need to check for field types
>> 
>> I have written up the behavioral changes in the CSR. In addition, I have added a few more tests to ensure the failure case behaviors of the migrated use sites.
>
> src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 160:
> 
>> 158:             | (1L << ('/' - CHECK_OFFSET))
>> 159:             | (1L << (';' - CHECK_OFFSET))
>> 160:             | (1L << ('[' - CHECK_OFFSET));
> 
> Are we sure that these are the only 4 non-identifier chars we can see in the string?

Could you add a test for something like `"Ljava#/lang/Object;"`?

> src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 166:
> 
>> 164:             int check = str.charAt(index) - CHECK_OFFSET;
>> 165:             if ((check & -Long.SIZE) == 0 && (NON_IDENTIFIER_MASK & (1L << check)) != 0) {
>> 166:                 break;
> 
> Maybe this is a little clearer:
> Suggestion:
> 
>             if (check < 64 && (NON_IDENTIFIER_MASK & (1L << check)) != 0) {
>                 break;

These generate similar code (`test` vs `cmp` on x64)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28079#discussion_r2546565467
PR Review Comment: https://git.openjdk.org/jdk/pull/28079#discussion_r2546547498

From jvernee at openjdk.org  Thu Nov 20 16:07:24 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 16:07:24 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
Message-ID: <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>

On Thu, 20 Nov 2025 08:59:11 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Thanks for working on this! I've left some inline comments.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1339:

> 1337:      * @param charset the charset used to {@linkplain Charset#newDecoder() decode} the
> 1338:      *                string bytes
> 1339:      * @param length  length to be used for string conversion, in bytes

Please keep the same format
Suggestion:

     * @param length  length in bytes of the string to read

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1341:

> 1339:      * @param length  length to be used for string conversion, in bytes
> 1340:      * @return a Java string constructed from the bytes read from the given starting
> 1341:      *         address reading the given length of characters

Suggestion:

     *         address reading the given length of bytes

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2662:

> 2660:      *         are {@code < 0}
> 2661:      * @throws IndexOutOfBoundsException if the {@code endIndex} is larger than the length of
> 2662:      *         this {@code String} object, or {@code beginIndex} is larger than {@code endIndex}.

There's no `beginIndex` and `endIndex`?

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 157:

> 155: 
> 156:     /**
> 157:      * Converts a Java string into a null-terminated C string using the provided charset,

Not null-terminated, right?

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 177:

> 175:      * @return a new native segment containing the converted C string
> 176:      * @throws IllegalArgumentException if {@code charset} is not a
> 177:      *         {@linkplain StandardCharsets standard charset}

Same here, I don't think we have this limitation.

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 180:

> 178:      * @throws IndexOutOfBoundsException if either {@code srcIndex} or {@code numChars} are {@code < 0}
> 179:      * @throws IndexOutOfBoundsException  if the {@code endIndex} is larger than the length of
> 180:      *         this {@code String} object, or {@code beginIndex} is larger than {@code endIndex}.

There is no 'endIndext'?

src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 68:

> 66:     @ForceInline
> 67:     public static String readBytes(AbstractMemorySegmentImpl segment, long offset, Charset charset, long length) {
> 68:         final int lengthBytes = (int) length;

I think we should do something more here than just ignore the upper bits. We probably need to throw an exception when the value is > Integer.MAX_VALUE

test/jdk/java/foreign/TestStringEncoding.java line 135:

> 133:         }
> 134:     }
> 135: 

We need some more tests for the other new methods as well. Also, it would be nice to test non-standard charsets.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3488572591
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2546633357
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2546635587
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2546650214
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2546610473
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2546614368
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2546616502
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2546607537
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2546628459

From jvernee at openjdk.org  Thu Nov 20 16:07:26 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 16:07:26 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
 <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>
Message-ID: <Q8JPn8XfKrQW61v0SOk8lv13gkDPkpeJ2hgy5aZZUQ0=.b0d7fcfa-ef44-4b06-87e5-c98198a7b2db@github.com>

On Thu, 20 Nov 2025 15:47:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 68:
> 
>> 66:     @ForceInline
>> 67:     public static String readBytes(AbstractMemorySegmentImpl segment, long offset, Charset charset, long length) {
>> 68:         final int lengthBytes = (int) length;
> 
> I think we should do something more here than just ignore the upper bits. We probably need to throw an exception when the value is > Integer.MAX_VALUE

Looks like we are already specified to throw IAE if 'the size of the string is greater than the largest string supported by the platform'

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2546639764

From kfarrell at openjdk.org  Thu Nov 20 16:20:45 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 20 Nov 2025 16:20:45 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID
Message-ID: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>

Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-334015.

-------------

Commit messages:
 - spec update

Changes: https://git.openjdk.org/jdk/pull/28435/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28435&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370910
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28435.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28435/head:pull/28435

PR: https://git.openjdk.org/jdk/pull/28435

From duke at openjdk.org  Thu Nov 20 16:30:56 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Thu, 20 Nov 2025 16:30:56 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v9]
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28226/files
  - new: https://git.openjdk.org/jdk/pull/28226/files/9452d747..e9e38155

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28226&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28226&range=07-08

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28226/head:pull/28226

PR: https://git.openjdk.org/jdk/pull/28226

From duke at openjdk.org  Thu Nov 20 16:34:32 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 20 Nov 2025 16:34:32 GMT
Subject: RFR: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
In-Reply-To: <QncMS-o2kNggimh-iL1siCd_kjNROQQQcazMsPDl2IM=.9e28a41c-561a-4ec9-89f7-58c4af916072@github.com>
References: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
 <PloxT6HF8oe0ETuadYwFOKa59vjDa5MoY-hFuvSLQ6s=.329d2878-bd4a-459b-a2b3-6930b394c381@github.com>
 <QncMS-o2kNggimh-iL1siCd_kjNROQQQcazMsPDl2IM=.9e28a41c-561a-4ec9-89f7-58c4af916072@github.com>
Message-ID: <gtv-ZXpvF--q3qQHHAt4WGJk44lD1aDya4SwSZih854=.4c276ca3-158b-41e3-84b7-d02538032152@github.com>

On Thu, 20 Nov 2025 15:37:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 160:
>> 
>>> 158:             | (1L << ('/' - CHECK_OFFSET))
>>> 159:             | (1L << (';' - CHECK_OFFSET))
>>> 160:             | (1L << ('[' - CHECK_OFFSET));
>> 
>> Are we sure that these are the only 4 non-identifier chars we can see in the string?
>
> Could you add a test for something like `"Ljava#/lang/Object;"`?

That?is a?valid **JVM** [field?descriptor] (but?not a?denotable?type in?**Java**).

--------------------------------------------------------------------------------

These 4 are?the?only characters which are?forbidden from?appearing in?identifiers by?the?[JVMS ??4.2.1].

[JVMS ??4.2.1]: https://docs.oracle.com/javase/specs/jvms/se25/html/jvms-4.html#jvms-4.2.1
[field?descriptor]: https://docs.oracle.com/javase/specs/jvms/se25/html/jvms-4.html#jvms-4.3.2

>> src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 166:
>> 
>>> 164:             int check = str.charAt(index) - CHECK_OFFSET;
>>> 165:             if ((check & -Long.SIZE) == 0 && (NON_IDENTIFIER_MASK & (1L << check)) != 0) {
>>> 166:                 break;
>> 
>> Maybe this is a little clearer:
>> Suggestion:
>> 
>>             if (check < 64 && (NON_IDENTIFIER_MASK & (1L << check)) != 0) {
>>                 break;
>
> These generate similar code (`test` vs `cmp` on x64)

No?because `check` can?be?negative:
https://github.com/openjdk/jdk/blob/c51f542914955d0034b18be7e5d40ae97e93baca/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java#L164

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28079#discussion_r2546770116
PR Review Comment: https://git.openjdk.org/jdk/pull/28079#discussion_r2546753516

From asemenyuk at openjdk.org  Thu Nov 20 16:38:04 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 16:38:04 GMT
Subject: RFR: 8360571: Description of launchers is lost in two phase packaging
Message-ID: <srjHSD9rQhnejeucQseTaTCwToSCvFfSkXBy1nJWv4U=.8129632d-a469-412b-8aaf-6858cfca83d5@github.com>

Store launcher descriptions in `.jpackage.xml` file so that they don't get lost in two-step packaging

-------------

Commit messages:
 - 8360571: Description of launchers is lost in two phase packaging

Changes: https://git.openjdk.org/jdk/pull/28436/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28436&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360571
  Stats: 97 lines in 6 files changed: 74 ins; 12 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28436/head:pull/28436

PR: https://git.openjdk.org/jdk/pull/28436

From liach at openjdk.org  Thu Nov 20 16:58:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Nov 2025 16:58:48 GMT
Subject: RFR: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
In-Reply-To: <gtv-ZXpvF--q3qQHHAt4WGJk44lD1aDya4SwSZih854=.4c276ca3-158b-41e3-84b7-d02538032152@github.com>
References: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
 <PloxT6HF8oe0ETuadYwFOKa59vjDa5MoY-hFuvSLQ6s=.329d2878-bd4a-459b-a2b3-6930b394c381@github.com>
 <QncMS-o2kNggimh-iL1siCd_kjNROQQQcazMsPDl2IM=.9e28a41c-561a-4ec9-89f7-58c4af916072@github.com>
 <gtv-ZXpvF--q3qQHHAt4WGJk44lD1aDya4SwSZih854=.4c276ca3-158b-41e3-84b7-d02538032152@github.com>
Message-ID: <weVmnOqlHXDKVhYkauJ5wEaDXpY4ndwxLNNgyXktUW4=.c392d80b-7ec2-4090-9ea3-8dfa2a7d07e6@github.com>

On Thu, 20 Nov 2025 16:25:50 GMT, ExE Boss <duke at openjdk.org> wrote:

>> These generate similar code (`test` vs `cmp` on x64)
>
> No?because `check` can?be?negative:
> https://github.com/openjdk/jdk/blob/c51f542914955d0034b18be7e5d40ae97e93baca/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java#L164

Indeed as ExE-Boss pointed out, I unfortunately have to use this 32 CHECK_OFFSET so all the illegal character fall in the 64-bit range of 32 to 95, mainly due to `[`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28079#discussion_r2546860226

From rriggs at openjdk.org  Thu Nov 20 17:01:23 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Nov 2025 17:01:23 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID
In-Reply-To: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
Message-ID: <jqqqb3bQYh9-pJxUySpCN3ip3sfwC28uBzWeGeI8xxU=.38094ca3-5769-4e4e-b8e2-fb453ce71ec0@github.com>

On Thu, 20 Nov 2025 16:07:36 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-334015.

Looks straight-forward. 
There is a typo in the PR description of the earlier issue, should be 8334025.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28435#issuecomment-3559092207

From liach at openjdk.org  Thu Nov 20 17:03:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Nov 2025 17:03:29 GMT
Subject: RFR: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
In-Reply-To: <gtv-ZXpvF--q3qQHHAt4WGJk44lD1aDya4SwSZih854=.4c276ca3-158b-41e3-84b7-d02538032152@github.com>
References: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
 <PloxT6HF8oe0ETuadYwFOKa59vjDa5MoY-hFuvSLQ6s=.329d2878-bd4a-459b-a2b3-6930b394c381@github.com>
 <QncMS-o2kNggimh-iL1siCd_kjNROQQQcazMsPDl2IM=.9e28a41c-561a-4ec9-89f7-58c4af916072@github.com>
 <gtv-ZXpvF--q3qQHHAt4WGJk44lD1aDya4SwSZih854=.4c276ca3-158b-41e3-84b7-d02538032152@github.com>
Message-ID: <scYJptR2fT0Qecu0kllPBX3a9zxyMPp-yJab2CluIz0=.f37b94ff-5f8d-496f-90ea-4bb3ff950b55@github.com>

On Thu, 20 Nov 2025 16:30:32 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Could you add a test for something like `"Ljava#/lang/Object;"`?
>
> That?is a?valid **JVM** [field?descriptor] (but?not a?denotable?type in?**Java**).
> 
> --------------------------------------------------------------------------------
> 
> These 4 are?the?only characters which are?forbidden from?appearing in?identifiers by?the?[JVMS ??4.2.1].
> 
> [JVMS ??4.2.1]: https://docs.oracle.com/javase/specs/jvms/se25/html/jvms-4.html#jvms-4.2.1
> [field?descriptor]: https://docs.oracle.com/javase/specs/jvms/se25/html/jvms-4.html#jvms-4.3.2

Yep, the 4 chars are listed by JVMS 4.2.2, close enough.

This is also in line with the behavior of [ClassFileParser::verify_unqualified_name](https://github.com/openjdk/jdk/blob/ea19ad2ac8a1fa9d4124be9a8e05cf4c6f6231bd/src/hotspot/share/classfile/classFileParser.cpp#L4544C5-L4544C46).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28079#discussion_r2546880778

From kfarrell at openjdk.org  Thu Nov 20 17:05:35 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 20 Nov 2025 17:05:35 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID
In-Reply-To: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
Message-ID: <zfVpWlGX55KfEgCt_lRTYxrNPPK2-ai-gHkQqDa9K5k=.c18dad75-cef8-4e6b-8ca9-ff271b561d31@github.com>

On Thu, 20 Nov 2025 16:07:36 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015.

PR description edited to include correct Bug ID

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28435#issuecomment-3559112018

From liach at openjdk.org  Thu Nov 20 17:23:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Nov 2025 17:23:15 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v9]
In-Reply-To: <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
Message-ID: <mcH0QHjG_e6HMUONyNe31QqEkBbSe4bTcqblbVMRDvU=.0cfcd887-7306-457b-a1a1-839b075a1805@github.com>

On Thu, 20 Nov 2025 16:30:56 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Copyright year updates look good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28226#pullrequestreview-3489015212

From mcimadamore at openjdk.org  Thu Nov 20 17:33:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Nov 2025 17:33:15 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <qeqZOflyFvuT6CGD_xSJm1GqChAfZf9OLKsBQ8ub1gc=.8387b4a5-cf65-457a-afd6-6e48d5e6ae5d@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
 <7GPlLrIKdco0l6GK-Ez6IleE3CLvCnCdlF_kekTvDqo=.1745539c-dd1a-4db3-a121-319e5c74fe04@github.com>
 <_G_KO4wYar6SMQ9-kbYDQ6Iw1W8O_Tgx3IxvdQxcwLA=.0e2c607f-60b5-4111-9a22-bb6b4bb25c4c@github.com>
 <i1OMPFfxQBHnK3k1Ly3h7R6-JrqIqAfPdwceoCrM2QU=.d326a919-c61a-4f28-b4f4-e45b45c5b0f8@github.com>
 <qeqZOflyFvuT6CGD_xSJm1GqChAfZf9OLKsBQ8ub1gc=.8387b4a5-cf65-457a-afd6-6e48d5e6ae5d@github.com>
Message-ID: <wZvgGVxlxuVrb5T8g1yC_eUEGm7AOEqigjmeQJnvCZ8=.bbdf20a9-6e2e-463f-8928-cf397415ef00@github.com>

On Thu, 20 Nov 2025 14:42:47 GMT, Almaz <duke at openjdk.org> wrote:

> > Yes, because I think that's where this "trick" came from in the first place.
> 
> Doesn't existence of this PR implies that hotspot is running in GNU libc non-conformant environments? With this patch applied `MAX_MALLOC_ALIGN` will assume GNU libc and at the same time there will be `allocationSize = Math.max(alignedSize, byteAlignment);` which is a workaround for cases where GNU libc guarantess do not hold.
> 
> Wouldn't it be safer to code against WG14's version?

Note that WG14 still defines a max alignment:

`max_align_t`

> which is an object type whose alignment is the greatest fundamental alignment;

So the question is: what is the greatest fundamental alignment? If you follow the rules for fundamental alignment, I think it you end up in the same place -- e.g. fundamental alignment in C is same as "natural" layout in out layout API, and it's ultimately driven by the alignment of the scalar types. So we're back to "what is the biggest scalar type we can express in that platform" ?

The difference between libc and WG14 is not in the fact that some max guaranteed alignment exists. It's in the fact that libc guarantees that _all malloc calls will be aligned to that max alignment_ whereas WG14 does not (unless when you hold it at a certain angle ;-) )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3559241856

From asemenyuk at openjdk.org  Thu Nov 20 18:08:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 18:08:15 GMT
Subject: RFR: 8360571: Description of launchers is lost in two phase
 packaging [v2]
In-Reply-To: <srjHSD9rQhnejeucQseTaTCwToSCvFfSkXBy1nJWv4U=.8129632d-a469-412b-8aaf-6858cfca83d5@github.com>
References: <srjHSD9rQhnejeucQseTaTCwToSCvFfSkXBy1nJWv4U=.8129632d-a469-412b-8aaf-6858cfca83d5@github.com>
Message-ID: <xx1p3IaHCSBuCyL9N_neiVUvOQ3vR6UQZyO6lnqSawU=.a9968544-f8a5-40ca-97f3-e932a3a30633@github.com>

> Store launcher descriptions in `.jpackage.xml` file so that they don't get lost in two-step packaging

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  AppImageFile: fix exception message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28436/files
  - new: https://git.openjdk.org/jdk/pull/28436/files/8d7c0b7c..183f88f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28436&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28436&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28436/head:pull/28436

PR: https://git.openjdk.org/jdk/pull/28436

From asemenyuk at openjdk.org  Thu Nov 20 18:08:17 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 18:08:17 GMT
Subject: RFR: 8360571: Description of launchers is lost in two phase
 packaging
In-Reply-To: <srjHSD9rQhnejeucQseTaTCwToSCvFfSkXBy1nJWv4U=.8129632d-a469-412b-8aaf-6858cfca83d5@github.com>
References: <srjHSD9rQhnejeucQseTaTCwToSCvFfSkXBy1nJWv4U=.8129632d-a469-412b-8aaf-6858cfca83d5@github.com>
Message-ID: <tzyWs0s6r6Dj_6OSF9pmgUHTcYX8Z-QqwZIo66fJrkQ=.661ab739-87bb-4214-b55a-006fb8f59dcd@github.com>

On Thu, 20 Nov 2025 16:28:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Store launcher descriptions in `.jpackage.xml` file so that they don't get lost in two-step packaging

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28436#issuecomment-3559363719

From asemenyuk at openjdk.org  Thu Nov 20 18:40:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 18:40:56 GMT
Subject: RFR: 8372290: jpackage test lib improvements
Message-ID: <_f599S8PCkL9NCWW_vneS0Ir3TkseSq2Va2ddL_gWk8=.173b1497-b522-4796-969b-8fb808994fb3@github.com>

Collect updates to jpackage test lib from different work-in-progress fixes:

 - ConfigFilesStasher: fix "ServiceTest.testAddLFromAppImage" test failure on Linux
 - Move PropertyFile class to the package level and make it not throw IOException
 - Update test/jdk/tools/jpackage/clean_stashed_files.sh and test/jdk/tools/jpackage/clean_test_output.sh scripts
 - CannedFormattedString: make it implement CannedArgument; add `addPrefix()`, and `mapArgs()`
 - JPackageCommand: add `makeError()` and `makeAdvice()`

Additionally, add a test case to the AppImagePackageTest test to test that jpackage placed launcher .so in the correct location when using the predefined app image and installing the "/usr" tree on Linux.

-------------

Commit messages:
 - CannedArgument: fix the copyright year
 - ErrorTest: fix the merge
 - JPackageCommand: add makeError() and makeAdvice() functions
 - CannedFormattedString: make it implement CannedArgument; add addPrefix(), and mapArgs()
 - Fix cleanup scripts
 - Move PropertyFile to the package level and make it not throw IOException.
 - 8371384: libapplauncher.so is copied to a wrong location in two step packaging when --install-dir=/usr
 - LauncherAsServiceVerifier: reduce copy/paste code in launcherAsService()
 - ConfigFilesStasher: fix ServiceTest.testAddLFromAppImage test failure on Linux

Changes: https://git.openjdk.org/jdk/pull/28439/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28439&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372290
  Stats: 210 lines in 14 files changed: 145 ins; 48 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/28439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28439/head:pull/28439

PR: https://git.openjdk.org/jdk/pull/28439

From duke at openjdk.org  Thu Nov 20 18:44:46 2025
From: duke at openjdk.org (Almaz)
Date: Thu, 20 Nov 2025 18:44:46 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <wZvgGVxlxuVrb5T8g1yC_eUEGm7AOEqigjmeQJnvCZ8=.bbdf20a9-6e2e-463f-8928-cf397415ef00@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
 <7GPlLrIKdco0l6GK-Ez6IleE3CLvCnCdlF_kekTvDqo=.1745539c-dd1a-4db3-a121-319e5c74fe04@github.com>
 <_G_KO4wYar6SMQ9-kbYDQ6Iw1W8O_Tgx3IxvdQxcwLA=.0e2c607f-60b5-4111-9a22-bb6b4bb25c4c@github.com>
 <i1OMPFfxQBHnK3k1Ly3h7R6-JrqIqAfPdwceoCrM2QU=.d326a919-c61a-4f28-b4f4-e45b45c5b0f8@github.com>
 <qeqZOflyFvuT6CGD_xSJm1GqChAfZf9OLKsBQ8ub1gc=.8387b4a5-cf65-457a-afd6-6e48d5e6ae5d@github.com>
 <wZvgGVxlxuVrb5T8g1yC_eUEGm7AOEqigjmeQJnvCZ8=.bbdf20a9-6e2e-463f-8928-cf397415ef00@github.com>
Message-ID: <TYiAbraPlBQOnG9szCnSQZdYN3GE9BPDGvK466XHw5s=.1e249521-07df-46f3-bd78-7907c30cb9e0@github.com>

On Thu, 20 Nov 2025 17:30:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Note that WG14 still defines a max alignment:
> > max_align_t

Can `MAX_MALLOC_ALIGN` be set to `alignof(max_align_t)`?

> It's in the fact that libc guarantees that all malloc calls will be aligned to that max alignment whereas WG14 does not (unless when you hold it at a certain angle ;-) )

I think this comes back to https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3559516639

From asemenyuk at openjdk.org  Thu Nov 20 18:48:29 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 18:48:29 GMT
Subject: RFR: 8372290: jpackage test lib improvements [v2]
In-Reply-To: <_f599S8PCkL9NCWW_vneS0Ir3TkseSq2Va2ddL_gWk8=.173b1497-b522-4796-969b-8fb808994fb3@github.com>
References: <_f599S8PCkL9NCWW_vneS0Ir3TkseSq2Va2ddL_gWk8=.173b1497-b522-4796-969b-8fb808994fb3@github.com>
Message-ID: <fXo1W999mokfYKlk-ir8qNyRd7mNwmiXgxyIPTq_WWo=.640213ad-5377-4e1d-ba93-f8af14e0713d@github.com>

> Collect updates to jpackage test lib from different work-in-progress fixes:
> 
>  - ConfigFilesStasher: fix "ServiceTest.testAddLFromAppImage" test failure on Linux
>  - Move PropertyFile class to the package level and make it not throw IOException
>  - Update test/jdk/tools/jpackage/clean_stashed_files.sh and test/jdk/tools/jpackage/clean_test_output.sh scripts
>  - CannedFormattedString: make it implement CannedArgument; add `addPrefix()`, and `mapArgs()`
>  - JPackageCommand: add `makeError()` and `makeAdvice()`
> 
> Additionally:
>  - Add a test case to the AppImagePackageTest test to test that jpackage placed launcher .so in the correct location when using the predefined app image and installing the "/usr" tree on Linux
>  - Reduce code duplication in LauncherAsServiceVerifier.java

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  AdditionalLauncher: use Slot class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28439/files
  - new: https://git.openjdk.org/jdk/pull/28439/files/33cee1b0..b974de7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28439&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28439&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28439/head:pull/28439

PR: https://git.openjdk.org/jdk/pull/28439

From naoto at openjdk.org  Thu Nov 20 18:57:38 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Nov 2025 18:57:38 GMT
Subject: RFR: 8372117: Correct the misleading comment in
 Character.UnicodeBlock
In-Reply-To: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
References: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
Message-ID: <EvShRneq9KTY8waytupYnbKIvkYEVSiqeZtpChaCZJg=.29d44895-582d-4f46-9d27-7daa1718b572@github.com>

On Wed, 19 Nov 2025 19:45:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial comment fix in `Character.UnicodeBlock`

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28401#issuecomment-3559565354

From naoto at openjdk.org  Thu Nov 20 18:57:39 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Nov 2025 18:57:39 GMT
Subject: Integrated: 8372117: Correct the misleading comment in
 Character.UnicodeBlock
In-Reply-To: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
References: <qMiHeWkNUo2ofzSv_ZHmfsBdpkZWY9mgeDQckchCe5Q=.8bb493c7-8e13-4f7a-bd4e-26f4a2821f76@github.com>
Message-ID: <B6d1eOdGgxpaSji6rHN1Cj5B3SMwKCyYAI2UNuprpU8=.ec305a83-afc6-4389-a1e5-de184b7d01f7@github.com>

On Wed, 19 Nov 2025 19:45:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial comment fix in `Character.UnicodeBlock`

This pull request has now been integrated.

Changeset: 41d6dc3a
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41d6dc3a15fd3041aaee7b9b7f7980ede5f7940d
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8372117: Correct the misleading comment in Character.UnicodeBlock

Reviewed-by: bpb, joehw, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/28401

From asemenyuk at openjdk.org  Thu Nov 20 19:05:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 19:05:54 GMT
Subject: RFR: 8372292: Remove redundant "throws ConfigException"
Message-ID: <PpW5aDpOFEN1YV5zLOdzR7Vzdj4AvOChV8bg6P4-NQs=.0302657a-697c-4c34-a7e4-c4d14e38901c@github.com>

- Remove redundant "throws ConfigException"
 - Remove redundant `toSupplier(...)`, `toConsumer(...)`, etc calls.

-------------

Commit messages:
 - Remove redundant "throws ConfigException"

Changes: https://git.openjdk.org/jdk/pull/28440/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28440&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372292
  Stats: 173 lines in 23 files changed: 11 ins; 87 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/28440.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28440/head:pull/28440

PR: https://git.openjdk.org/jdk/pull/28440

From henryjen at openjdk.org  Thu Nov 20 19:07:38 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 20 Nov 2025 19:07:38 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v8]
In-Reply-To: <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com>
 <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com>
Message-ID: <pT6T_HoX-Y0JvzU6j9arMfln_uWiWSGg97Zu6xkMSzE=.08fecfd4-48f5-4c07-9b3f-912be7c50d2d@github.com>

On Wed, 19 Nov 2025 12:47:14 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adapt review feedbacks
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 259:
> 
>> 257: 
>> 258:             try (var r = new BufferedReader(new InputStreamReader(release.get()))) {
>> 259:                 return Optional.of(r.readLine());
> 
> As suggested on the CSR we should read the entire file, not just the first line and treat the entire content as a string in a specific encoding. While I wasn't able to get the JDK build a vendor name with new lines (due to jrt-fs.jar putting `COMPANYNAME` in the MANIFEST.MF) it's conceivable that some `release.txt` file might have more than one line.
> 
> Alternatively we need to specify that the file must not contain line breaks or unusual encodings.

The proposal is to have a one line release signature set up by the build, briefly discussed the possibility to use a java properties file format as the current release file distributed with JDK, but then a simplified approach of one signature is preferred.

I'll update the PR once we come to conclusion with the CSR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2547306781

From asemenyuk at openjdk.org  Thu Nov 20 19:12:33 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 19:12:33 GMT
Subject: RFR: 8372292: Remove redundant "throws ConfigException" [v2]
In-Reply-To: <PpW5aDpOFEN1YV5zLOdzR7Vzdj4AvOChV8bg6P4-NQs=.0302657a-697c-4c34-a7e4-c4d14e38901c@github.com>
References: <PpW5aDpOFEN1YV5zLOdzR7Vzdj4AvOChV8bg6P4-NQs=.0302657a-697c-4c34-a7e4-c4d14e38901c@github.com>
Message-ID: <xjZk_QFPWirT_SPAw8tC5Fg_lpVgS7lpZMLRjcfzpHE=.eb63f626-85b1-4b4a-963c-9be9b51c3b6a@github.com>

> - Remove redundant "throws ConfigException"
>  - Remove redundant `toSupplier(...)`, `toConsumer(...)`, etc calls.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  ApplicationBuilder: fix formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28440/files
  - new: https://git.openjdk.org/jdk/pull/28440/files/c020a440..87a4f374

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28440&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28440&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28440.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28440/head:pull/28440

PR: https://git.openjdk.org/jdk/pull/28440

From asemenyuk at openjdk.org  Thu Nov 20 19:31:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 19:31:50 GMT
Subject: RFR: 8372290: jpackage test lib improvements [v2]
In-Reply-To: <fXo1W999mokfYKlk-ir8qNyRd7mNwmiXgxyIPTq_WWo=.640213ad-5377-4e1d-ba93-f8af14e0713d@github.com>
References: <_f599S8PCkL9NCWW_vneS0Ir3TkseSq2Va2ddL_gWk8=.173b1497-b522-4796-969b-8fb808994fb3@github.com>
 <fXo1W999mokfYKlk-ir8qNyRd7mNwmiXgxyIPTq_WWo=.640213ad-5377-4e1d-ba93-f8af14e0713d@github.com>
Message-ID: <bcAC3v4zReoDtvvVH7_xhe4ina9godnPutil8tjQfoE=.f18e3889-ce3e-4def-b16f-0dc889de6ead@github.com>

On Thu, 20 Nov 2025 18:48:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Collect updates to jpackage test lib from different work-in-progress fixes:
>> 
>>  - ConfigFilesStasher: fix "ServiceTest.testAddLFromAppImage" test failure on Linux
>>  - Move PropertyFile class to the package level and make it not throw IOException
>>  - Update test/jdk/tools/jpackage/clean_stashed_files.sh and test/jdk/tools/jpackage/clean_test_output.sh scripts
>>  - CannedFormattedString: make it implement CannedArgument; add `addPrefix()`, and `mapArgs()`
>>  - JPackageCommand: add `makeError()` and `makeAdvice()`
>> 
>> Additionally:
>>  - Add a test case to the AppImagePackageTest test to test that jpackage placed launcher .so in the correct location when using the predefined app image and installing the "/usr" tree on Linux
>>  - Reduce code duplication in LauncherAsServiceVerifier.java
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AdditionalLauncher: use Slot class

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28439#issuecomment-3559696628

From asemenyuk at openjdk.org  Thu Nov 20 19:31:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Nov 2025 19:31:52 GMT
Subject: RFR: 8372292: Remove redundant "throws ConfigException" [v2]
In-Reply-To: <xjZk_QFPWirT_SPAw8tC5Fg_lpVgS7lpZMLRjcfzpHE=.eb63f626-85b1-4b4a-963c-9be9b51c3b6a@github.com>
References: <PpW5aDpOFEN1YV5zLOdzR7Vzdj4AvOChV8bg6P4-NQs=.0302657a-697c-4c34-a7e4-c4d14e38901c@github.com>
 <xjZk_QFPWirT_SPAw8tC5Fg_lpVgS7lpZMLRjcfzpHE=.eb63f626-85b1-4b4a-963c-9be9b51c3b6a@github.com>
Message-ID: <NIykNIbBI-x8AKhI7jymgnNJiZYK6NC_gLaEbrgBs-E=.d97746f8-929f-48fa-ae8a-b359b27eecdc@github.com>

On Thu, 20 Nov 2025 19:12:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Remove redundant "throws ConfigException"
>>  - Remove redundant `toSupplier(...)`, `toConsumer(...)`, etc calls.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ApplicationBuilder: fix formatting

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28440#issuecomment-3559698680

From bchristi at openjdk.org  Thu Nov 20 20:19:24 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 20 Nov 2025 20:19:24 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method [v2]
In-Reply-To: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
Message-ID: <C4Lav-m1suffL73W1cvA9p0iA5AsA9i_svdiHToaeHk=.02d770b6-cd95-4106-94db-95f9198e068d@github.com>

> From the bug report:
> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to
> "[invoke] shutdown() when this executor is no longer referenced and it has no threads."
> 
> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)).
> 
> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)).
> 
> The finalize() method can safely be removed from ThreadPoolExecutor.

Brent Christian 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 8371748-TPE.f10n
 - Remove ThreadPoolExecutor.finalize()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28311/files
  - new: https://git.openjdk.org/jdk/pull/28311/files/f166b51a..1984cd4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28311&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28311&range=00-01

  Stats: 62613 lines in 849 files changed: 42714 ins; 14030 del; 5869 mod
  Patch: https://git.openjdk.org/jdk/pull/28311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28311/head:pull/28311

PR: https://git.openjdk.org/jdk/pull/28311

From haraldei at openjdk.org  Thu Nov 20 21:08:10 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Thu, 20 Nov 2025 21:08:10 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v7]
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <chi0zbK0l5dbsluU9VP-fVq-z-hmth2yBBO_gjv8ztc=.35e4a325-ca10-4998-9731-f685c2253bab@github.com>

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:

  Add explanatory comment
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28235/files
  - new: https://git.openjdk.org/jdk/pull/28235/files/d5232988..8b3080ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=05-06

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28235/head:pull/28235

PR: https://git.openjdk.org/jdk/pull/28235

From jvernee at openjdk.org  Thu Nov 20 21:45:22 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 21:45:22 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v7]
In-Reply-To: <chi0zbK0l5dbsluU9VP-fVq-z-hmth2yBBO_gjv8ztc=.35e4a325-ca10-4998-9731-f685c2253bab@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <chi0zbK0l5dbsluU9VP-fVq-z-hmth2yBBO_gjv8ztc=.35e4a325-ca10-4998-9731-f685c2253bab@github.com>
Message-ID: <JNmQKA9H23_W3UkbOuGVQtk8ELcmsU8p_-6yIFltni4=.30058769-e2f5-473d-96a7-8f1ad187af7a@github.com>

On Thu, 20 Nov 2025 21:08:10 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explanatory comment
>   
>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28235#pullrequestreview-3490047858

From jvernee at openjdk.org  Thu Nov 20 21:49:20 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Nov 2025 21:49:20 GMT
Subject: RFR: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
In-Reply-To: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
References: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
Message-ID: <qn9NesnFjdQee82dXeDA-o55M5lilyyqKxbDAi_PPd4=.8a4b722b-30a4-4465-a193-f247de9e06e1@github.com>

On Fri, 31 Oct 2025 00:00:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There were a few other holes in the recent migration of BytecodeDescriptor, most notably:
> 
> 1. BytecodeDescriptor is missing checks for `.`, `[` characters, leading, trailing, consecutive `/`, or empty name.
> 2. EnclosingMethod is only validated by hotspot to carry either field or method type. We still need to check for field types
> 
> I have written up the behavioral changes in the CSR. In addition, I have added a few more tests to ensure the failure case behaviors of the migrated use sites.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28079#pullrequestreview-3490060733

From dholmes at openjdk.org  Thu Nov 20 22:08:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 22:08:40 GMT
Subject: RFR: 8333871: Check sysinfo return values [v6]
In-Reply-To: <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
Message-ID: <atjB0q71hgsP6wOWok55Tn_86RnKB19LPan8BAUiDVE=.61d7ea56-0481-4678-bf3c-1a3793bc6a4b@github.com>

On Thu, 20 Nov 2025 08:27:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better assert messages

LGTM. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28317#pullrequestreview-3490151681

From jlu at openjdk.org  Thu Nov 20 23:03:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Nov 2025 23:03:50 GMT
Subject: RFR: 8368001: java/text/Format/NumberFormat/NumberRoundTrip.java timed
 out
Message-ID: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>

JDK-8260555 exposed test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java as being susceptible to timeouts.
While the timeout factor is reverted, this test was testing too many inputs, and should be changed. 
Originally, it was testing (~1000 locales * 4 factories) against ~30 numeric inputs. The test does not need to be exhaustive to this degree.

The total amount of locales is changed to sample around a 1/4 of those provided by the provider. The numeric inputs are reduced to about ~20. (The fixed ones remain, and the random ones are cut in half.)

Locally, I observe average execution for this test to be about ~1.3 seconds, compared to ~3.4 seconds previously. The PR also does a drive-by clean up of the test, i.e. getting rid of the unnecessary escaping + string manipulation/printing and separating the test inputs from the actual testing work done.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/28443/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28443&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368001
  Stats: 225 lines in 1 file changed: 54 ins; 131 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/28443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28443/head:pull/28443

PR: https://git.openjdk.org/jdk/pull/28443

From swen at openjdk.org  Thu Nov 20 23:46:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 20 Nov 2025 23:46:57 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v26]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <_3xcrMGOjqrYJZEGYKxk6whoWbKXC9eYo_VA5DcTir8=.1f5c30dc-ba19-46c1-a510-bb16ddcee79a@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
  
  Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/50602632..d689cbb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=24-25

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911

PR: https://git.openjdk.org/jdk/pull/26911

From liach at openjdk.org  Fri Nov 21 00:41:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Nov 2025 00:41:00 GMT
Subject: RFR: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
In-Reply-To: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
References: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
Message-ID: <K5Bijj4QcDV_qA6XxBwn0yqd_5HyX9d3JPmNYb0EHTM=.9408ee4a-3808-4652-a926-2b4665327a6c@github.com>

On Fri, 31 Oct 2025 00:00:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There were a few other holes in the recent migration of BytecodeDescriptor, most notably:
> 
> 1. BytecodeDescriptor is missing checks for `.`, `[` characters, leading, trailing, consecutive `/`, or empty name.
> 2. EnclosingMethod is only validated by hotspot to carry either field or method type. We still need to check for field types
> 
> I have written up the behavioral changes in the CSR. In addition, I have added a few more tests to ensure the failure case behaviors of the migrated use sites.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28079#issuecomment-3560797970

From liach at openjdk.org  Fri Nov 21 00:41:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Nov 2025 00:41:00 GMT
Subject: Integrated: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
In-Reply-To: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
References: <ObcqrsH3KexbJTzWvjUAItJvxGVWOC9ORYB0izajhUo=.ab08a99b-95b1-4aec-b8da-8f94a54672bb@github.com>
Message-ID: <J54D6K75YJ8fpn35EKigCFNJk984YGrvJI_5vkbYGpM=.fb66355b-0ece-4edc-9299-1a64fafcf4c4@github.com>

On Fri, 31 Oct 2025 00:00:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> There were a few other holes in the recent migration of BytecodeDescriptor, most notably:
> 
> 1. BytecodeDescriptor is missing checks for `.`, `[` characters, leading, trailing, consecutive `/`, or empty name.
> 2. EnclosingMethod is only validated by hotspot to carry either field or method type. We still need to check for field types
> 
> I have written up the behavioral changes in the CSR. In addition, I have added a few more tests to ensure the failure case behaviors of the migrated use sites.

This pull request has now been integrated.

Changeset: d887359b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d887359b5a8bffedcbf1b3ca6f0eae13b7636add
Stats:     152 lines in 7 files changed: 115 ins; 15 del; 22 mod

8370976: Review the behavioral changes of core reflection descriptor parsing migration

Reviewed-by: rriggs, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/28079

From liach at openjdk.org  Fri Nov 21 00:48:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Nov 2025 00:48:55 GMT
Subject: RFR: 8371953: Document null handling in core reflection APIs [v6]
In-Reply-To: <nysoMM1Km4ZFbBWMWXAP6mDwSgK5xyavtB3F2I4Hx-I=.6ec98d2b-cf23-426d-b3a3-01e3fe881550@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
 <nysoMM1Km4ZFbBWMWXAP6mDwSgK5xyavtB3F2I4Hx-I=.6ec98d2b-cf23-426d-b3a3-01e3fe881550@github.com>
Message-ID: <qzyFgR-N5mxOmynYDBTRbsr65S1bYNBPhzjFiCCjuvY=.dd8695da-c551-4d03-8dca-d96c5c5a80c0@github.com>

On Wed, 19 Nov 2025 15:39:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
>> 
>> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Redundant extra sentences

Thanks for the reviews, Alan and David!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28336#issuecomment-3560817523

From liach at openjdk.org  Fri Nov 21 00:48:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Nov 2025 00:48:57 GMT
Subject: Integrated: 8371953: Document null handling in core reflection APIs
In-Reply-To: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
References: <sCg8YRIXZ4gcJPI7gIhCIVmFvj6BJraODhNENCRI7Ig=.e03c6802-3dd1-46b5-ad77-572e269d493b@github.com>
Message-ID: <JWCu2qjfVYMIlIy6KWsv453rMYK2dPrV0QKg3HgX2dA=.d25267ce-c3b1-4cd5-a236-26237295ae6b@github.com>

On Sat, 15 Nov 2025 23:04:53 GMT, Chen Liang <liach at openjdk.org> wrote:

> A lot of core reflection APIs are from antique times, which have their own null handling behavior. Such behaviors are often not documented in the specification; we should document rejected null arguments and accepted null arguments (including array elements) explicitly.
> 
> In the investigation, I found `Class.isNestmateOf` (inconsistent) and `AnnotatedType`'s implementation of `AnnotatedElement` methods (required by specification) are missing null checks. I consider these unlikely to be a user dependency and added new null checks.

This pull request has now been integrated.

Changeset: 2358d40c
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2358d40cbcafb851425176cacf65cc3be1ae12a2
Stats:     456 lines in 16 files changed: 405 ins; 16 del; 35 mod

8371953: Document null handling in core reflection APIs

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/28336

From almatvee at openjdk.org  Fri Nov 21 00:58:47 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 21 Nov 2025 00:58:47 GMT
Subject: RFR: 8360571: Description of launchers is lost in two phase
 packaging [v2]
In-Reply-To: <xx1p3IaHCSBuCyL9N_neiVUvOQ3vR6UQZyO6lnqSawU=.a9968544-f8a5-40ca-97f3-e932a3a30633@github.com>
References: <srjHSD9rQhnejeucQseTaTCwToSCvFfSkXBy1nJWv4U=.8129632d-a469-412b-8aaf-6858cfca83d5@github.com>
 <xx1p3IaHCSBuCyL9N_neiVUvOQ3vR6UQZyO6lnqSawU=.a9968544-f8a5-40ca-97f3-e932a3a30633@github.com>
Message-ID: <z3_0YckdEUyu5a-60TDrltl5_hCIG1l-1D5nlAL8nyY=.74ad0413-4fee-4f0c-879f-ca8d6312fe4e@github.com>

On Thu, 20 Nov 2025 18:08:15 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Store launcher descriptions in `.jpackage.xml` file so that they don't get lost in two-step packaging
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AppImageFile: fix exception message

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28436#pullrequestreview-3490710582

From asemenyuk at openjdk.org  Fri Nov 21 02:52:45 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 02:52:45 GMT
Subject: Integrated: 8360571: Description of launchers is lost in two phase
 packaging
In-Reply-To: <srjHSD9rQhnejeucQseTaTCwToSCvFfSkXBy1nJWv4U=.8129632d-a469-412b-8aaf-6858cfca83d5@github.com>
References: <srjHSD9rQhnejeucQseTaTCwToSCvFfSkXBy1nJWv4U=.8129632d-a469-412b-8aaf-6858cfca83d5@github.com>
Message-ID: <37Ocr0eO-jwh6_0c78-JOoiQhGTyYRwILF1jFXBeJLY=.f4087bd6-7689-47bf-9cd8-d4d00753a9a6@github.com>

On Thu, 20 Nov 2025 16:28:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Store launcher descriptions in `.jpackage.xml` file so that they don't get lost in two-step packaging

This pull request has now been integrated.

Changeset: df24b901
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df24b901768599ac7111655b87dfeedbe0e66f9d
Stats:     101 lines in 6 files changed: 74 ins; 12 del; 15 mod

8360571: Description of launchers is lost in two phase packaging

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28436

From fyang at openjdk.org  Fri Nov 21 03:41:46 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 21 Nov 2025 03:41:46 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v5]
In-Reply-To: <ny8egKqL-RZlT-kK96j2sFcF-O7TG3G30Gdp6EVWwvc=.a1d4ecd4-8765-424b-bd86-bee4a1136ba5@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <ny8egKqL-RZlT-kK96j2sFcF-O7TG3G30Gdp6EVWwvc=.a1d4ecd4-8765-424b-bd86-bee4a1136ba5@github.com>
Message-ID: <e-cr2nWjEbroDXpPIQWcc7UbPPXJ7jH-DxSeaxb3l8k=.52137cfa-a26f-45a5-97c0-2e7b76fe47ca@github.com>

On Tue, 18 Nov 2025 09:27:44 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> 
>> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
>> 
>> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
>> 
>> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
>> 
>> # Test
>> ## Jtreg
>> 
>> in progress...
>> 
>> ## Performance
>> 
>> Column names meanings:
>> * p: with patch
>> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> * m: without patch
>> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> 
>> #### Average improvement
>> 
>> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
>> 
>> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
>> -- | -- | -- | --
>> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
>> 
>> </google-sheets-html-origin>
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace assert with log_warning

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1590:

> 1588:     // jump if cmp1 < cmp2 or either is NaN
> 1589:     // not jump (i.e. move src to dst) if cmp1 >= cmp2
> 1590:     float_blt(cmp1, cmp2, no_set);

I compared this with the existing `MacroAssembler::cmov_cmp_fp_ge` [1] and I witnessed some difference in the case of `NaN` handling. In `MacroAssembler::cmov_cmp_fp_ge`, we set the `is_unordered` param to true when calling `float_blt` or `double_blt`, which is not the case here. I assume we need similar handling here as well, right?

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L1338

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1636:

> 1634:     // jump if cmp1 <= cmp2 or either is NaN
> 1635:     // not jump (i.e. move src to dst) if cmp1 > cmp2
> 1636:     float_ble(cmp1, cmp2, no_set);

Same question here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2548424215
PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2548424568

From almatvee at openjdk.org  Fri Nov 21 04:23:26 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 21 Nov 2025 04:23:26 GMT
Subject: RFR: 8372290: jpackage test lib improvements [v2]
In-Reply-To: <fXo1W999mokfYKlk-ir8qNyRd7mNwmiXgxyIPTq_WWo=.640213ad-5377-4e1d-ba93-f8af14e0713d@github.com>
References: <_f599S8PCkL9NCWW_vneS0Ir3TkseSq2Va2ddL_gWk8=.173b1497-b522-4796-969b-8fb808994fb3@github.com>
 <fXo1W999mokfYKlk-ir8qNyRd7mNwmiXgxyIPTq_WWo=.640213ad-5377-4e1d-ba93-f8af14e0713d@github.com>
Message-ID: <c8bFyC2Qoem5spUl9nXQulvQSD-86X2_AqsZ7mO6CWk=.390a6fa7-c3c9-4c6e-b799-b0dccc18dd25@github.com>

On Thu, 20 Nov 2025 18:48:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Collect updates to jpackage test lib from different work-in-progress fixes:
>> 
>>  - ConfigFilesStasher: fix "ServiceTest.testAddLFromAppImage" test failure on Linux
>>  - Move PropertyFile class to the package level and make it not throw IOException
>>  - Update test/jdk/tools/jpackage/clean_stashed_files.sh and test/jdk/tools/jpackage/clean_test_output.sh scripts
>>  - CannedFormattedString: make it implement CannedArgument; add `addPrefix()`, and `mapArgs()`
>>  - JPackageCommand: add `makeError()` and `makeAdvice()`
>> 
>> Additionally:
>>  - Add a test case to the AppImagePackageTest test to test that jpackage placed launcher .so in the correct location when using the predefined app image and installing the "/usr" tree on Linux
>>  - Reduce code duplication in LauncherAsServiceVerifier.java
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AdditionalLauncher: use Slot class

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28439#pullrequestreview-3491134615

From jpai at openjdk.org  Fri Nov 21 05:10:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Nov 2025 05:10:23 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID
In-Reply-To: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
Message-ID: <AbOZsSsUJ_R2mYcqxzr9RohHIPB3p-0BPY8NoushhN0=.6dd8d448-9925-460a-8e7d-d348e3057c62@github.com>

On Thu, 20 Nov 2025 16:07:36 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015.

Looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28435#pullrequestreview-3491207787

From almatvee at openjdk.org  Fri Nov 21 05:16:26 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 21 Nov 2025 05:16:26 GMT
Subject: RFR: 8372292: Remove redundant "throws ConfigException" [v2]
In-Reply-To: <xjZk_QFPWirT_SPAw8tC5Fg_lpVgS7lpZMLRjcfzpHE=.eb63f626-85b1-4b4a-963c-9be9b51c3b6a@github.com>
References: <PpW5aDpOFEN1YV5zLOdzR7Vzdj4AvOChV8bg6P4-NQs=.0302657a-697c-4c34-a7e4-c4d14e38901c@github.com>
 <xjZk_QFPWirT_SPAw8tC5Fg_lpVgS7lpZMLRjcfzpHE=.eb63f626-85b1-4b4a-963c-9be9b51c3b6a@github.com>
Message-ID: <JAyiGfTQv-7sOYDxs1VV26B4s47eq4uFsqn9uOIuFQ0=.2b89fabd-149e-4dcc-a4d1-d26ba8102e40@github.com>

On Thu, 20 Nov 2025 19:12:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Remove redundant "throws ConfigException"
>>  - Remove redundant `toSupplier(...)`, `toConsumer(...)`, etc calls.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ApplicationBuilder: fix formatting

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28440#pullrequestreview-3491220329

From alan.bateman at oracle.com  Fri Nov 21 06:37:25 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Nov 2025 06:37:25 +0000
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and Verona
 projects
Message-ID: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>


I hereby propose that the Core Libraries group withdraw sponsorship of 
the Device I/O [1], Kona [2], Penrose [3], and Verona [4] projects. 
These projects have been inactive for a long time:

- Device I/O has been inactive since 2018.
- Project Kona had some activity in 2015 but nothing since.
- Project Penrose had some activity in 2012 but nothing since.
- Project Verona defined the version-string scheme that integrated into 
main line in 2015 for JDK 9 (JEP 223), its work is complete.

These projects have only one group sponsor. A consequence of withdrawing 
sponsorship is that these projects will be dissolved [5]. Votes are due 
by December 5, 2025, 23.59 UTC. Only current Core Libraries group 
members [6] are eligible to vote on this motion. Votes must be cast in 
the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [7].
-Alan
[1] https://openjdk.org/projects/dio
[2] https://openjdk.org/projects/kona
[3] https://openjdk.org/projects/penrose
[4] https://openjdk.org/projects/verona
[5] https://openjdk.org/bylaws#sponsor
[6] https://openjdk.org/census#core-libs
[7] https://openjdk.org/bylaws#lazy-consensus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251121/dc862130/attachment.htm>

From alanb at openjdk.org  Fri Nov 21 07:39:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 07:39:44 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID
In-Reply-To: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
Message-ID: <1XECShQyDDyY2ROPUT6Af0LFEwFrltHEIzD_8sH6HpA=.b6545c57-aac3-4874-9b78-e0a7f7cfd837@github.com>

On Thu, 20 Nov 2025 16:07:36 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015.

src/java.base/share/classes/java/util/UUID.java line 35:

> 33: 
> 34: /**
> 35:  * A class that represents an immutable universally unique identifier (UUID).

Maybe change this to "Universally Unique IDentifier (UUID)" too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28435#discussion_r2548816352

From duke at openjdk.org  Fri Nov 21 08:12:38 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Fri, 21 Nov 2025 08:12:38 GMT
Subject: RFR: 8372307: Update comments to mention native.encoding instead of
 file.encoding
Message-ID: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>

The `file.encoding` system property is no longer used by the JDK.
Updated code comments to reference the correct replacement: `native.encoding`.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into fix-inaccuracy-in-comments
 - Fix inaccuracy in comments

Changes: https://git.openjdk.org/jdk/pull/27004/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27004&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372307
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27004/head:pull/27004

PR: https://git.openjdk.org/jdk/pull/27004

From jpai at openjdk.org  Fri Nov 21 08:12:38 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Nov 2025 08:12:38 GMT
Subject: RFR: 8372307: Update comments to mention native.encoding instead
 of file.encoding
In-Reply-To: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
References: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
Message-ID: <SsWwLj7wKOJAfRZWHP78dT5nEwdHqBs7QIGvgf6zdLA=.e86bba31-90db-4ebe-9b54-89e93caf07c9@github.com>

On Fri, 29 Aug 2025 14:25:25 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> The `file.encoding` system property is no longer used by the JDK.
> Updated code comments to reference the correct replacement: `native.encoding`.

Hello Igor @hextriclosan, I have created a JBS issue to address this https://bugs.openjdk.org/browse/JDK-8372307. Please update the title of your PR to `8372307: Clean up the leftover code comment references to file.encoding in java_props_md.c` so that it initiates the formal review process of this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27004#issuecomment-3560925023

From mbaesken at openjdk.org  Fri Nov 21 08:12:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Nov 2025 08:12:55 GMT
Subject: RFR: 8333871: Check sysinfo return values [v6]
In-Reply-To: <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
Message-ID: <naTzek-VOr2EfA16_y4KPrae7FNmSA6vQbO91qaYs8E=.d27d9372-045d-4d62-9986-63dea3baf116@github.com>

On Thu, 20 Nov 2025 08:27:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better assert messages

Hi David and Alan, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3561894485

From duke at openjdk.org  Fri Nov 21 08:24:43 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Fri, 21 Nov 2025 08:24:43 GMT
Subject: RFR: 8372307: Clean up the leftover code comment references to
 file.encoding in java_props_md.c
In-Reply-To: <SsWwLj7wKOJAfRZWHP78dT5nEwdHqBs7QIGvgf6zdLA=.e86bba31-90db-4ebe-9b54-89e93caf07c9@github.com>
References: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
 <SsWwLj7wKOJAfRZWHP78dT5nEwdHqBs7QIGvgf6zdLA=.e86bba31-90db-4ebe-9b54-89e93caf07c9@github.com>
Message-ID: <ziE1MSUlDgjIUg8FYTCw8-JS27N13qTsxkJsz2ddtyk=.077f5905-9ecd-48d5-93a7-5392722cc95f@github.com>

On Fri, 21 Nov 2025 01:25:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The `file.encoding` system property is no longer used by the JDK.
>> Updated code comments to reference the correct replacement: `native.encoding`.
>
> Hello Igor @hextriclosan, I have created a JBS issue to address this https://bugs.openjdk.org/browse/JDK-8372307. Please update the title of your PR to `8372307: Clean up the leftover code comment references to file.encoding in java_props_md.c` so that it initiates the formal review process of this change.

@jaikiran 
Done, thank you for your help

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27004#issuecomment-3561930316

From mdoerr at openjdk.org  Fri Nov 21 09:33:22 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 21 Nov 2025 09:33:22 GMT
Subject: RFR: 8333871: Check sysinfo return values [v6]
In-Reply-To: <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
Message-ID: <9-x45TvgQNiceY29PMFo7SzGkbIpmw_zqd-u0zhkFy0=.ce905dd2-6966-4506-a966-dcd18da5b491@github.com>

On Thu, 20 Nov 2025 08:27:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better assert messages

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28317#pullrequestreview-3491880550

From pminborg at openjdk.org  Fri Nov 21 09:39:23 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 21 Nov 2025 09:39:23 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v7]
In-Reply-To: <chi0zbK0l5dbsluU9VP-fVq-z-hmth2yBBO_gjv8ztc=.35e4a325-ca10-4998-9731-f685c2253bab@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <chi0zbK0l5dbsluU9VP-fVq-z-hmth2yBBO_gjv8ztc=.35e4a325-ca10-4998-9731-f685c2253bab@github.com>
Message-ID: <iYTWNhuZ-zsNusvA10o5PCp9WPtB-yoATZwPMxzhBsg=.487315fe-cfa4-480c-9d18-fca71a62b713@github.com>

On Thu, 20 Nov 2025 21:08:10 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explanatory comment
>   
>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

Please note that there are white space warnings for the current commit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3562181166

From jpai at openjdk.org  Fri Nov 21 09:42:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Nov 2025 09:42:57 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <JSWnv-432jILEA8x1UmCkDXbS40hgNj0MggIBH_Hr6I=.ba870ff9-a6f7-41c4-ba70-615bc7421943@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
 <jJad_byg_l20nlbAZjHDUCadnTNL6FdNmGCTESHyRE0=.d1e86a93-6478-466c-83bf-595d304d7bb8@github.com>
 <WH3ecv0QGys2-QpqltzMyz2jQGi2ZBXOo23JX9PG3GU=.77c2d810-e693-4ec2-888f-41c82094120f@github.com>
 <JSWnv-432jILEA8x1UmCkDXbS40hgNj0MggIBH_Hr6I=.ba870ff9-a6f7-41c4-ba70-615bc7421943@github.com>
Message-ID: <qX7HHo1DwZMr_k6WQGzHwH-ARtJPDR5Ag08fuhPsmjE=.3003bbd1-f5af-423d-b089-0311a3e7f21e@github.com>

On Thu, 20 Nov 2025 14:49:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Good point. Thank you.
>
>> Nit - the use of square brackets is usually meant to imply "optional". Here it is mandatory to specify a digit between 0 and 9 following the "zip-" text. Perhaps using angular bracket would be better?
> 
> Hmmm,  square brackets in the shell are a regex indicating a wildcard.  I think that `[0-9]` reads better in the shell/command line context.

No objections from me to let it stay in the current form then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2549116902

From jpai at openjdk.org  Fri Nov 21 09:42:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Nov 2025 09:42:59 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
Message-ID: <M-h8a-ScUhbEmWwZBpV6CXnIeJJsM1ThrMUa-sTtFcU=.8ac37f4a-cbf7-42f7-9a96-7c599f9f2ab7@github.com>

On Thu, 20 Nov 2025 10:51:06 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove extra line.
>  - Align behavior of compression levels to the input received and sync help+documentation messages.

test/jdk/tools/jlink/TaskHelperTest.java line 226:

> 224:     }
> 225: 
> 226:     record CompressTestCase(String[] tokens, String expectedCompressValue, boolean expectedMainFlag) {}

Hello Ana, what is the `expectedMainFlag` meant for? I see that every usage of it initializes it to `false`.

test/jdk/tools/jlink/TaskHelperTest.java line 246:

> 244:                 new CompressTestCase(new String[] {"--compress=zip-7"}, "zip-7", false),
> 245:                 new CompressTestCase(new String[] {"--compress=zip-8"}, "zip-8", false),
> 246:                 new CompressTestCase(new String[] {"--compress=zip-9"}, "zip-9", false)

I think a few negative tests would also be useful. For example, `-c 3` `--compress=42`, `--compress=zip-`  should all fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2549124431
PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2549130094

From vklang at openjdk.org  Fri Nov 21 09:48:02 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Nov 2025 09:48:02 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v9]
In-Reply-To: <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
Message-ID: <QW2FZcdfEbMGyd_QXtYGaLKJ7YxboDM6VA4FKNnjFSY=.015c4aed-d2bb-4e92-bb41-de08ba9e82d7@github.com>

On Thu, 20 Nov 2025 16:30:56 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by vklang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28226#pullrequestreview-3491942070

From jpai at openjdk.org  Fri Nov 21 09:53:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Nov 2025 09:53:54 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
Message-ID: <VmNgqX-ARIh9TdotLspr40oDzfOFnCNbttxPj3Si7eU=.b17627b0-e536-4c30-bbbb-59735bec269d@github.com>

On Thu, 20 Nov 2025 10:51:06 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove extra line.
>  - Align behavior of compression levels to the input received and sync help+documentation messages.

The change overall looks reasonable to me.

Given that we ended up fixing the behaviour of `-c` option in this PR, I think we should rename the JBS issue to something like "jlink's compression plugin doesn't handle -c option correctly". It should then be OK to address the man page and the help text changes as part of this same fix. I believe a CSR will be needed for this change.

My knowledge of this tool is very limited, so please wait for Alan's input before doing the JBS issue change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28359#issuecomment-3562228861

From pminborg at openjdk.org  Fri Nov 21 09:59:25 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 21 Nov 2025 09:59:25 GMT
Subject: Integrated: 8372146: Follow-up changes to the Lazy Constants JEP
In-Reply-To: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
References: <3GBjVyvHEl0v8bHi29bah4I-Dgi1CSU5McJmyTgclv8=.ce66ef38-8c84-41ef-8f3d-114dbaccf7c5@github.com>
Message-ID: <1FjjDt7f-n4Y413B2eoeCuWSKlWg1RxkGLg3gKfiikU=.3103ca70-c957-49ad-a7b3-d9ba3bdd5708@github.com>

On Wed, 19 Nov 2025 11:54:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to implement minor comments from the original integration of "Implement JEP 528: Lazy Constants (second preview)" (https://bugs.openjdk.org/browse/JDK-8366178).

This pull request has now been integrated.

Changeset: 8a5c9e08
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a5c9e08c0605c28cac235129adff7bb248d0627
Stats:     26 lines in 6 files changed: 7 ins; 9 del; 10 mod

8372146: Follow-up changes to the Lazy Constants JEP

Reviewed-by: liach, mcimadamore, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/28388

From raffaello.giulietti at oracle.com  Fri Nov 21 10:04:23 2025
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 21 Nov 2025 10:04:23 +0000
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and
 Verona projects
In-Reply-To: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
References: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
Message-ID: <BLAPR10MB525100F3E319C069387C55D387D5A@BLAPR10MB5251.namprd10.prod.outlook.com>

Vote: yes


________________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Alan Bateman <alan.bateman at oracle.com>
Sent: Friday, November 21, 2025 07:37
To: 'core-libs-dev'
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and Verona projects


I hereby propose that the Core Libraries group withdraw sponsorship of the Device I/O [1], Kona [2], Penrose [3], and Verona [4] projects. These projects have been inactive for a long time:

From duke at openjdk.org  Fri Nov 21 10:07:23 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Fri, 21 Nov 2025 10:07:23 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <M-h8a-ScUhbEmWwZBpV6CXnIeJJsM1ThrMUa-sTtFcU=.8ac37f4a-cbf7-42f7-9a96-7c599f9f2ab7@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
 <M-h8a-ScUhbEmWwZBpV6CXnIeJJsM1ThrMUa-sTtFcU=.8ac37f4a-cbf7-42f7-9a96-7c599f9f2ab7@github.com>
Message-ID: <WAterG5DQyoOvlnYX7F_U6jB6PJBDY0PGiW5qelYgPI=.12f4d686-29ee-494a-b502-35635bfb5eb1@github.com>

On Fri, 21 Nov 2025 09:38:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove extra line.
>>  - Align behavior of compression levels to the input received and sync help+documentation messages.
>
> test/jdk/tools/jlink/TaskHelperTest.java line 226:
> 
>> 224:     }
>> 225: 
>> 226:     record CompressTestCase(String[] tokens, String expectedCompressValue, boolean expectedMainFlag) {}
> 
> Hello Ana, what is the `expectedMainFlag` meant for? I see that every usage of it initializes it to `false`.

Hi Jaikiran,

Thank you for spotting that! I guided myself from the previous tests done there and forgot this parameter. I actually do not need it and will remove it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2549216831

From duke at openjdk.org  Fri Nov 21 10:25:24 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Fri, 21 Nov 2025 10:25:24 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v4]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Add some negative tests for suggested values.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/2e6a3f18..fccce74b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=02-03

  Stats: 40 lines in 1 file changed: 23 ins; 2 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Fri Nov 21 10:32:17 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Fri, 21 Nov 2025 10:32:17 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <M-h8a-ScUhbEmWwZBpV6CXnIeJJsM1ThrMUa-sTtFcU=.8ac37f4a-cbf7-42f7-9a96-7c599f9f2ab7@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
 <M-h8a-ScUhbEmWwZBpV6CXnIeJJsM1ThrMUa-sTtFcU=.8ac37f4a-cbf7-42f7-9a96-7c599f9f2ab7@github.com>
Message-ID: <cg5-LojUDRyZXa53_QFelD-cvUdRvVhj0610-Eilo3Q=.3d710708-0534-4149-9c7a-abb19f33387f@github.com>

On Fri, 21 Nov 2025 09:40:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove extra line.
>>  - Align behavior of compression levels to the input received and sync help+documentation messages.
>
> test/jdk/tools/jlink/TaskHelperTest.java line 246:
> 
>> 244:                 new CompressTestCase(new String[] {"--compress=zip-7"}, "zip-7", false),
>> 245:                 new CompressTestCase(new String[] {"--compress=zip-8"}, "zip-8", false),
>> 246:                 new CompressTestCase(new String[] {"--compress=zip-9"}, "zip-9", false)
> 
> I think a few negative tests would also be useful. For example, `-c 3` `--compress=42`, `--compress=zip-`  should all fail.

Thank you for pointing out that part. I pushed a new commit to cover suggested values and more (I followed the previous example on testing for invalid values ?).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2549284063

From jpai at openjdk.org  Fri Nov 21 10:35:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Nov 2025 10:35:49 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v4]
In-Reply-To: <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>
Message-ID: <6oR0-EsCPFMZOLKgqklO8xmaZVsv9ot1Zlc3OPKq79I=.71261fd8-61e0-4924-88ff-793cc0efb33d@github.com>

On Fri, 21 Nov 2025 10:25:24 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some negative tests for suggested values.

test/jdk/tools/jlink/TaskHelperTest.java line 275:

> 273:         );
> 274: 
> 275:         for (var args : invalidOptValues) {

Nit - might be better to rename `args` to `testCase`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2549298299

From jpai at openjdk.org  Fri Nov 21 10:38:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Nov 2025 10:38:51 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v4]
In-Reply-To: <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>
Message-ID: <qmt-s-ZxvxacHTzWpZvMQY9-8TGJMUIQFRcsipRnzek=.1348a9ba-66d4-4edd-ae0a-a9600382b455@github.com>

On Fri, 21 Nov 2025 10:25:24 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some negative tests for suggested values.

test/jdk/tools/jlink/TaskHelperTest.java line 279:

> 277:                 var remaining = optionsHelper.handleOptions(this, args.tokens);
> 278:                 assertTrue(remaining.isEmpty());
> 279:                 assertEquals(args.expectedCompressValue, compressArgValue);

I think these 2 asserts are an oversight. Since we expect `optionsHelper.handleOptions(...)` to always throw a `BadArgs` for these invalid option values, we should replace these 2 asserts with a:

fail("processing of " + Arrays.toString(testCase.tokens) + " was expected to fail, but didn't");

This will then rightly fail the test if the exception isn't thrown.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2549308889

From cushon at openjdk.org  Fri Nov 21 10:47:42 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 10:47:42 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v9]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <obW0a-3zxnqxX1Z4UDTbPa5yjVmbgSn7DOCaBU2gE5c=.ab561111-3123-4e9f-bf9b-9b604592bd4e@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:

 - Improve test coverage, and more fixes
 - Review feedback
   
   * document assertion to link to bytesCompatible
   * throw IAE for length > Integer.MAX_VALUE
   * javadoc fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/faa4c5b1..31df3a22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=07-08

  Stats: 185 lines in 5 files changed: 165 ins; 5 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From cushon at openjdk.org  Fri Nov 21 10:47:43 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 10:47:43 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
Message-ID: <QIkYPSMksgtolByQx7m7f4KmQAMs4m6Ns-0lKPDOyvE=.dfbbfdf9-d8e9-4d82-94f1-c2cba9fcb364@github.com>

On Thu, 20 Nov 2025 08:59:11 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Thanks for the review, I think I've responded to all of the comments.

I also added more test coverage, and made a couple more fixes:

* There was a mistake with `srcIndex`/`numChars` handling, `numChars` was being used as a an index instead of a length, I have fixed the implementation and also the javadoc
* I removed a couple more obsolete javadoc references to StandardCharsets

-------------

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3492155719

From cushon at openjdk.org  Fri Nov 21 10:47:48 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 10:47:48 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
 <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>
Message-ID: <SPl2aaYW1THoa-uEG-PiQ7vKwggH-UvGM84KhEQpueQ=.1936e0cf-8e5c-4216-a3f9-9742dc685f38@github.com>

On Thu, 20 Nov 2025 15:53:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1339:
> 
>> 1337:      * @param charset the charset used to {@linkplain Charset#newDecoder() decode} the
>> 1338:      *                string bytes
>> 1339:      * @param length  length to be used for string conversion, in bytes
> 
> Please keep the same format
> Suggestion:
> 
>      * @param length  length in bytes of the string to read

Done

> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1341:
> 
>> 1339:      * @param length  length to be used for string conversion, in bytes
>> 1340:      * @return a Java string constructed from the bytes read from the given starting
>> 1341:      *         address reading the given length of characters
> 
> Suggestion:
> 
>      *         address reading the given length of bytes

Done

> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2662:
> 
>> 2660:      *         are {@code < 0}
>> 2661:      * @throws IndexOutOfBoundsException if the {@code endIndex} is larger than the length of
>> 2662:      *         this {@code String} object, or {@code beginIndex} is larger than {@code endIndex}.
> 
> There's no `beginIndex` and `endIndex`?

Done

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 157:
> 
>> 155: 
>> 156:     /**
>> 157:      * Converts a Java string into a null-terminated C string using the provided charset,
> 
> Not null-terminated, right?

It is not, thanks, fixed

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 177:
> 
>> 175:      * @return a new native segment containing the converted C string
>> 176:      * @throws IllegalArgumentException if {@code charset} is not a
>> 177:      *         {@linkplain StandardCharsets standard charset}
> 
> Same here, I don't think we have this limitation.

Done

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 180:
> 
>> 178:      * @throws IndexOutOfBoundsException if either {@code srcIndex} or {@code numChars} are {@code < 0}
>> 179:      * @throws IndexOutOfBoundsException  if the {@code endIndex} is larger than the length of
>> 180:      *         this {@code String} object, or {@code beginIndex} is larger than {@code endIndex}.
> 
> There is no 'endIndext'?

Done

> test/jdk/java/foreign/TestStringEncoding.java line 135:
> 
>> 133:         }
>> 134:     }
>> 135: 
> 
> We need some more tests for the other new methods as well. Also, it would be nice to test non-standard charsets.

I added more tests to cover regular and exception cases for the three new methods. I'm happy to take suggestions on additional test coverage, or if there's a better location for any of the tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549306779
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549306993
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549311600
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549314628
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549315486
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549315650
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549319466

From cushon at openjdk.org  Fri Nov 21 10:47:50 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 10:47:50 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <Q8JPn8XfKrQW61v0SOk8lv13gkDPkpeJ2hgy5aZZUQ0=.b0d7fcfa-ef44-4b06-87e5-c98198a7b2db@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
 <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>
 <Q8JPn8XfKrQW61v0SOk8lv13gkDPkpeJ2hgy5aZZUQ0=.b0d7fcfa-ef44-4b06-87e5-c98198a7b2db@github.com>
Message-ID: <G1K8qYx7YJ0UPUAMFnLt9_IAjcctuAbMMDBcroPXWqg=.af828881-bb49-421a-b60f-90df648a2fc4@github.com>

On Thu, 20 Nov 2025 15:55:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 68:
>> 
>>> 66:     @ForceInline
>>> 67:     public static String readBytes(AbstractMemorySegmentImpl segment, long offset, Charset charset, long length) {
>>> 68:         final int lengthBytes = (int) length;
>> 
>> I think we should do something more here than just ignore the upper bits. We probably need to throw an exception when the value is > Integer.MAX_VALUE
>
> Looks like we are already specified to throw IAE if 'the size of the string is greater than the largest string supported by the platform'

Done, and I added a test to cover the IAE

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549317693

From kfarrell at openjdk.org  Fri Nov 21 11:03:43 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Fri, 21 Nov 2025 11:03:43 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID [v2]
In-Reply-To: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
Message-ID: <Cp7CYDu_RqOwsT680z2DrIp9CP02Rw7oWyAhKrD2PmI=.73bbb410-f076-4055-91be-c07d5051bfca@github.com>

> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  spec update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28435/files
  - new: https://git.openjdk.org/jdk/pull/28435/files/b068d6d7..90f93860

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28435&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28435&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28435.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28435/head:pull/28435

PR: https://git.openjdk.org/jdk/pull/28435

From alanb at openjdk.org  Fri Nov 21 11:15:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 11:15:37 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID [v2]
In-Reply-To: <Cp7CYDu_RqOwsT680z2DrIp9CP02Rw7oWyAhKrD2PmI=.73bbb410-f076-4055-91be-c07d5051bfca@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
 <Cp7CYDu_RqOwsT680z2DrIp9CP02Rw7oWyAhKrD2PmI=.73bbb410-f076-4055-91be-c07d5051bfca@github.com>
Message-ID: <45iBG28Q27wzrpT_1_DQc7EPhPpXEQB9fk3xP3OMgVk=.e574cf08-4695-49f0-b5f7-06a90db23b2f@github.com>

On Fri, 21 Nov 2025 11:03:43 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spec update

src/java.base/share/classes/java/util/UUID.java line 38:

> 36:  * A UUID represents a 128-bit value.
> 37:  *
> 38:  * <p> There exist different variants of these UUIDs.  The methods

What would you think about replacing this paragraph with this: 

"This class is primarily designed for manipulating Leach-Salz variant UUIDs, but it also supports the creation of UUIDs of other variants."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28435#discussion_r2549413435

From mbaesken at openjdk.org  Fri Nov 21 11:22:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Nov 2025 11:22:58 GMT
Subject: Integrated: 8333871: Check return values of sysinfo
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <ixPnp23g7xbEELsL7FsWt9DnEhhky6kv9E1B9rMe1z8=.c58fd8e6-8aa5-468f-82ba-06ddc995c245@github.com>

On Fri, 14 Nov 2025 10:33:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

This pull request has now been integrated.

Changeset: 30410fe2
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30410fe265d8d32fb41bae88ab882115271cdf75
Stats:     15 lines in 2 files changed: 8 ins; 0 del; 7 mod

8333871: Check return values of sysinfo

Reviewed-by: dholmes, mdoerr, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/28317

From haraldei at openjdk.org  Fri Nov 21 12:08:40 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Fri, 21 Nov 2025 12:08:40 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v8]
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <YpmmQyTak50BdUkBPoZGKyRchAzGfZRhlZqxnNsoLlE=.203a8643-0d2b-44ba-8ac6-8ee567f235d2@github.com>

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace error
  
  This work was sponsored by: The FreeBSD Foundation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28235/files
  - new: https://git.openjdk.org/jdk/pull/28235/files/8b3080ea..bcdbbec0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28235&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28235/head:pull/28235

PR: https://git.openjdk.org/jdk/pull/28235

From jvernee at openjdk.org  Fri Nov 21 12:59:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Nov 2025 12:59:52 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v9]
In-Reply-To: <obW0a-3zxnqxX1Z4UDTbPa5yjVmbgSn7DOCaBU2gE5c=.ab561111-3123-4e9f-bf9b-9b604592bd4e@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <obW0a-3zxnqxX1Z4UDTbPa5yjVmbgSn7DOCaBU2gE5c=.ab561111-3123-4e9f-bf9b-9b604592bd4e@github.com>
Message-ID: <-7BC6dasdXzwM5tY6sfyLZ1GEj4TWZyl5aORRTcCSH4=.f63cf512-d105-4b0e-9fec-61817d84e5bc@github.com>

On Fri, 21 Nov 2025 10:47:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve test coverage, and more fixes
>  - Review feedback
>    
>    * document assertion to link to bytesCompatible
>    * throw IAE for length > Integer.MAX_VALUE
>    * javadoc fixes

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2660:

> 2658:      *         are {@code < 0}
> 2659:      * @throws IndexOutOfBoundsException if the {@code numChars + srcIndex} is larger than the length of
> 2660:      *         this {@code String} object.

I think this leaves the question: what happens is `srcIndex + numChars` overflows and becomes negative? It will be less than the length of the string for sure, but not right either.

This is why the other method's javadoc write down e.g. `srcIndex > srcArray.length - elementCount`. Assuming all positive numbers, it avoids the overflow issue.

test/jdk/java/foreign/TestStringEncoding.java line 108:

> 106:     @Test(dataProvider = "strings")
> 107:     public void testStringsLength(String testString) {
> 108:         Set<String> excluded = Set.of("yen");

I know the yen character is translated to `/` in some encodings when doing a round trip. Maybe we should just avoid this issue by switching it out for e.g. `"section \u00A7"`, which is `?` and doesn't have the same problem.

test/jdk/java/foreign/TestStringEncoding.java line 180:

> 178:             assertThrows(IndexOutOfBoundsException.class, () ->
> 179:                     MemorySegment.copy(testString, StandardCharsets.UTF_8, 0, text, 0, testString.length() + 1));
> 180:             // dstOffset > byteSize() + B

Suggestion:

            // dstOffset > byteSize() - B

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549653853
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549626703
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549635887

From jvernee at openjdk.org  Fri Nov 21 12:59:54 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Nov 2025 12:59:54 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <SPl2aaYW1THoa-uEG-PiQ7vKwggH-UvGM84KhEQpueQ=.1936e0cf-8e5c-4216-a3f9-9742dc685f38@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
 <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>
 <SPl2aaYW1THoa-uEG-PiQ7vKwggH-UvGM84KhEQpueQ=.1936e0cf-8e5c-4216-a3f9-9742dc685f38@github.com>
Message-ID: <K60o8ZtQN58__j1voq1wUrMPXDB79Wmp73cxV8T0nFE=.8f6fc688-1428-4bb4-865d-8eb53542712b@github.com>

On Fri, 21 Nov 2025 10:38:40 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> test/jdk/java/foreign/TestStringEncoding.java line 135:
>> 
>>> 133:         }
>>> 134:     }
>>> 135: 
>> 
>> We need some more tests for the other new methods as well. Also, it would be nice to test non-standard charsets.
>
> I added more tests to cover regular and exception cases for the three new methods. I'm happy to take suggestions on additional test coverage, or if there's a better location for any of the tests.

Thanks, these look great!

I think another test that tests the case where `srcIndex + numChars` overflows for `copy` and `allocateFrom`, with different char sets (one that takes the internal `bytesCompatible == true`, and one that takes the `bytesCompatible == false` route) would be good to have.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549679121

From rgiulietti at openjdk.org  Fri Nov 21 13:10:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 21 Nov 2025 13:10:53 GMT
Subject: RFR: 8368001: java/text/Format/NumberFormat/NumberRoundTrip.java
 timed out
In-Reply-To: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
References: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
Message-ID: <0KRtSwwkeSYFhfOzbHgRyl1M_1tG4lCdVfCt0tm_UF8=.0a88331a-2385-4c1b-abbb-a84757bd1fa6@github.com>

On Thu, 20 Nov 2025 22:55:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> JDK-8260555 exposed test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java as being susceptible to timeouts.
> While the timeout factor is reverted, this test was testing too many inputs, and should be changed. 
> Originally, it was testing (~1000 locales * 4 factories) against ~30 numeric inputs. The test does not need to be exhaustive to this degree.
> 
> The total amount of locales is changed to sample around a 1/4 of those provided by the provider. The numeric inputs are reduced to about ~20. (The fixed ones remain, and the random ones are cut in half.)
> 
> Locally, I observe average execution for this test to be about ~1.3 seconds, compared to ~3.4 seconds previously. The PR also does a drive-by clean up of the test, i.e. getting rid of the unnecessary escaping + string manipulation/printing and separating the test inputs from the actual testing work done.

test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java line 143:

> 141:     // Return a random value from -range..+range.
> 142:     private static double randomDouble(double range) {
> 143:         double a = Math.random();

I would suggest using `jdk.test.lib.RandomFactory`, as this supports reproducible values in case of a randomised test failure.


import jdk.test.lib.RandomFactory;
...
 * @library /test/lib
 * @build jdk.test.lib.RandomFactory
...
    private static final Random RANDOM = RandomFactory.getRandom();
...
    private static double randomDouble(double range) {
        double a = RANDOM.nextDouble();
...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28443#discussion_r2549709717

From roger.riggs at oracle.com  Fri Nov 21 13:32:58 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 21 Nov 2025 08:32:58 -0500
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and
 Verona projects
In-Reply-To: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
References: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
Message-ID: <fb0ae354-732c-4107-a29c-b4f228f98315@oracle.com>

Vote: Yes

On 11/21/25 1:37 AM, Alan Bateman wrote:
> I hereby propose that the Core Libraries group withdraw sponsorship of 
> the Device I/O [1], Kona [2], Penrose [3], and Verona [4] projects. 
> These projects have been inactive for a long time:


From cushon at openjdk.org  Fri Nov 21 13:48:53 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 13:48:53 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v10]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <chbKzgns6suaigViQ3pgqq5Tono0UWkBuShfPlBr8yc=.3b855b56-53f0-4e84-a581-144094b706ab@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback
  
  * handle numChars + srcIndex overflow, and add tests
  * replace yen with a character that round trips

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/31df3a22..489bf150

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=08-09

  Stats: 35 lines in 5 files changed: 22 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From dl at openjdk.org  Fri Nov 21 13:50:54 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Nov 2025 13:50:54 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3]
In-Reply-To: <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
Message-ID: <VlAq2Q61T2hRpqjjueeoA7GRttajxd6EdD8tRfxQMWQ=.12e877ce-262b-40fa-b710-1af3a0d10e11@github.com>

On Wed, 22 Oct 2025 21:06:04 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> The goal of the PR is to improve both, sequential and parallel, sorting of primitives.
>> 
>> **The main achievements**
>> 
>> - introduced Radix in parallel sorting which shows several times boost of performance and has linear complexity instead of n*ln(n)
>> - improved mixed insertion sort (makes whole sorting faster)
>> - improved merging sort for almost sorted data
>> - optimized parallel sorting
>> - improved step for pivot candidates and pivot partitioning
>> - suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError
>> - minor javadoc and comment changes
>> 
>> - extended existing tests
>> - added tests for radix sort, heap sort, insertion sort
>> - added benchmarking JMH tests
>> - improved test coverage
>> 
>> **The summary of benchmarking:**
>> 
>> **Sequential sorting (Arrays.sort)**
>> 
>> byte: up to 50% faster
>> char: 4-7 times faster
>> short: 2-6 times faster
>> int: 1.2-5 times faster
>> long: 1.2-5 times faster
>> float: 1.2-5 times faster
>> double: 1.2-4 times faster
>> 
>> **Parallel sorting (Arrays.parallelSort)**
>> 
>> int: 1.2-9 times faster
>> long: 1.2-9 times faster
>> float: 1.2-4 times faster
>> double: 1.2-4 times faster
>> 
>> **AVX512 support**
>> 
>> Vamsi Parasa suggested faster sort routines by taking advantage of AVX512 instructions, see https://github.com/openjdk/jdk/pull/14227, sources of sorting were modified. Therefore, I performed benchmarking of the final version (which includes optimizations by Vamsi Parasa and optimizations from my side) on a server with CPUs supported AVX512 instructions, no regression of performance was found, see detailed benchmarking results.
>> 
>> **High-level chart showing how the actual sorting algorithm is selected
>> based on parallel/sequential and input size**
>> 
>> **int/long/float/double**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => [ mixed ] insertion sort
>> if array is almost sorted and size > MIN_MERGING_SORT_SIZE(=512) => merging sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => heap sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **byte**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> else => counting sort
>> 
>> **char/short**
>> 
>> if size > MIN_COUNTING_SORT_SIZE(640) => counting sort
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => counting sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **parallel sorting (int/lo...
>
> Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements
>   
>   * Added @java.io.Serial
>   * Added information about the best data types for thresholds of sorting
>   * Added comments about native implementation based on AVX512 instructions

Some general comments:

The structure  intrinsically gets more complicated and harder to read as  options and sub-options increase -- 6 kinds of sorts, some with parallel and/or SIMD, some only applying to some element types,  almost all of them with incremental improvements. I think the attempts to better organize these is OK, but the main DualPiviotQuicksort should include a brief account similar to the wording in the PR intro to better explain how the dispatching criteria and logic.  And perhaps a summary of constants and thresholds, with notes on sensitivity of values.

The changes related to parallel sorting all look good to me. I didn't read the other parts in detail

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3563098723

From cushon at openjdk.org  Fri Nov 21 13:54:36 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 13:54:36 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v9]
In-Reply-To: <obW0a-3zxnqxX1Z4UDTbPa5yjVmbgSn7DOCaBU2gE5c=.ab561111-3123-4e9f-bf9b-9b604592bd4e@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <obW0a-3zxnqxX1Z4UDTbPa5yjVmbgSn7DOCaBU2gE5c=.ab561111-3123-4e9f-bf9b-9b604592bd4e@github.com>
Message-ID: <hyDmS_Vn1_E8LbiqlSQ13rorR5j2qzRDPF6uRQZCDnA=.4010c40a-984b-4e21-b801-85c0b9a9a9a2@github.com>

On Fri, 21 Nov 2025 10:47:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve test coverage, and more fixes
>  - Review feedback
>    
>    * document assertion to link to bytesCompatible
>    * throw IAE for length > Integer.MAX_VALUE
>    * javadoc fixes

Thanks again!

I have responded to the comments, and I have also started drafting the CSR: https://bugs.openjdk.org/browse/JDK-8372338

-------------

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3492688796

From cushon at openjdk.org  Fri Nov 21 13:54:38 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 13:54:38 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v9]
In-Reply-To: <-7BC6dasdXzwM5tY6sfyLZ1GEj4TWZyl5aORRTcCSH4=.f63cf512-d105-4b0e-9fec-61817d84e5bc@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <obW0a-3zxnqxX1Z4UDTbPa5yjVmbgSn7DOCaBU2gE5c=.ab561111-3123-4e9f-bf9b-9b604592bd4e@github.com>
 <-7BC6dasdXzwM5tY6sfyLZ1GEj4TWZyl5aORRTcCSH4=.f63cf512-d105-4b0e-9fec-61817d84e5bc@github.com>
Message-ID: <ircC-CSZNjoJ4xF3lrr3nLmmfSp53v-Vrpet9uTPKKQ=.d0c0d30c-916c-4e2b-847a-8093155210fa@github.com>

On Fri, 21 Nov 2025 12:35:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Improve test coverage, and more fixes
>>  - Review feedback
>>    
>>    * document assertion to link to bytesCompatible
>>    * throw IAE for length > Integer.MAX_VALUE
>>    * javadoc fixes
>
> test/jdk/java/foreign/TestStringEncoding.java line 108:
> 
>> 106:     @Test(dataProvider = "strings")
>> 107:     public void testStringsLength(String testString) {
>> 108:         Set<String> excluded = Set.of("yen");
> 
> I know the yen character is translated to `/` in some encodings when doing a round trip. Maybe we should just avoid this issue by switching it out for e.g. `"section \u00A7"`, which is `?` and doesn't have the same problem.

Thanks, sounds good! Done

> test/jdk/java/foreign/TestStringEncoding.java line 180:
> 
>> 178:             assertThrows(IndexOutOfBoundsException.class, () ->
>> 179:                     MemorySegment.copy(testString, StandardCharsets.UTF_8, 0, text, 0, testString.length() + 1));
>> 180:             // dstOffset > byteSize() + B
> 
> Suggestion:
> 
>             // dstOffset > byteSize() - B

Thanks for the catch, fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549704610
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549709383

From cushon at openjdk.org  Fri Nov 21 13:54:39 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 13:54:39 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <K60o8ZtQN58__j1voq1wUrMPXDB79Wmp73cxV8T0nFE=.8f6fc688-1428-4bb4-865d-8eb53542712b@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
 <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>
 <SPl2aaYW1THoa-uEG-PiQ7vKwggH-UvGM84KhEQpueQ=.1936e0cf-8e5c-4216-a3f9-9742dc685f38@github.com>
 <K60o8ZtQN58__j1voq1wUrMPXDB79Wmp73cxV8T0nFE=.8f6fc688-1428-4bb4-865d-8eb53542712b@github.com>
Message-ID: <Z3sSceTuAKAHzsI4Xfsmyk3Zh-SMCDxyBlvO3MZG8uQ=.ed85461a-ab7c-4ae8-abf4-ec5956ad6c3c@github.com>

On Fri, 21 Nov 2025 12:55:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I added more tests to cover regular and exception cases for the three new methods. I'm happy to take suggestions on additional test coverage, or if there's a better location for any of the tests.
>
> Thanks, these look great!
> 
> I think another test that tests the case where `srcIndex + numChars` overflows for `copy` and `allocateFrom`, with different char sets (one that takes the internal `bytesCompatible == true`, and one that takes the `bytesCompatible == false` route) would be good to have.

Thanks, I added coverage of `srcIndex + numChars` overflow for both `bytesCompatible` cases.

I think that in practice some of the cases were being caught later. I added ` Objects.checkFromIndexSize` assertions to `MemorySegment#copy` and `allocateFrom` to catch them immediately with a useful exception, instead of e.g. catching it in `String.substring`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549824444

From jvernee at openjdk.org  Fri Nov 21 14:18:37 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Nov 2025 14:18:37 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v10]
In-Reply-To: <chbKzgns6suaigViQ3pgqq5Tono0UWkBuShfPlBr8yc=.3b855b56-53f0-4e84-a581-144094b706ab@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <chbKzgns6suaigViQ3pgqq5Tono0UWkBuShfPlBr8yc=.3b855b56-53f0-4e84-a581-144094b706ab@github.com>
Message-ID: <sJIn50EiT0RGhV2WpayNp_gk3stCIcXS_VkEZRIoVWY=.687766ae-79d6-48c1-ad0f-e2c383194e55@github.com>

On Fri, 21 Nov 2025 13:48:53 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback
>   
>   * handle numChars + srcIndex overflow, and add tests
>   * replace yen with a character that round trips

Latest version looks good to me. Left one last suggestion inline.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 541:

> 539:     public String getString(long offset, Charset charset, long length) {
> 540:         if (length < 0) {
> 541:             throw new IllegalArgumentException();

Could we have an exception message here please?

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3492933707
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549893368

From cushon at openjdk.org  Fri Nov 21 14:26:00 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 14:26:00 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v11]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Use Utils.checkNonNegativeArgument

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/489bf150..903696b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From cushon at openjdk.org  Fri Nov 21 14:26:01 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 14:26:01 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v10]
In-Reply-To: <sJIn50EiT0RGhV2WpayNp_gk3stCIcXS_VkEZRIoVWY=.687766ae-79d6-48c1-ad0f-e2c383194e55@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <chbKzgns6suaigViQ3pgqq5Tono0UWkBuShfPlBr8yc=.3b855b56-53f0-4e84-a581-144094b706ab@github.com>
 <sJIn50EiT0RGhV2WpayNp_gk3stCIcXS_VkEZRIoVWY=.687766ae-79d6-48c1-ad0f-e2c383194e55@github.com>
Message-ID: <-H0z5dndOR5WkTAMFgiYJ6rN3aabhjOxDocmMlMYD6k=.8d1e8f01-fd6c-4cdb-a2d7-ae23c55f5dc6@github.com>

On Fri, 21 Nov 2025 14:13:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>>   
>>   * handle numChars + srcIndex overflow, and add tests
>>   * replace yen with a character that round trips
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 541:
> 
>> 539:     public String getString(long offset, Charset charset, long length) {
>> 540:         if (length < 0) {
>> 541:             throw new IllegalArgumentException();
> 
> Could we have an exception message here please?

Thanks, I switched to `Utils.checkNonNegativeArgument`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549915642

From mcimadamore at openjdk.org  Fri Nov 21 14:34:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Nov 2025 14:34:53 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v11]
In-Reply-To: <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
Message-ID: <fBY_0qwqGrzGtFr-dx8PEUdZQTA17iBANq2CcrGHMLk=.9fd5ad2b-8cca-465d-93d1-974d2c29942e@github.com>

On Fri, 21 Nov 2025 14:26:00 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Utils.checkNonNegativeArgument

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1333:

> 1331:      * sequences with this charset's default replacement string. The {@link
> 1332:      * java.nio.charset.CharsetDecoder} class should be used when more control
> 1333:      * over the decoding process is required.

Should we say here, as you did for `copy` that this method ignores `\0` ?

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2646:

> 2644:      * will appear truncated when read again.
> 2645:      *
> 2646:      * @param src      the Java string to be written into this segment

Suggestion:

     * @param src      the Java string to be written into the destination segment

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2649:

> 2647:      * @param dstEncoding the charset used to {@linkplain Charset#newEncoder() encode}
> 2648:      *                 the string bytes.
> 2649:      * @param srcIndex the starting index of the source string

Do we feel like saying words like "index" is good enough to say what we mean? E.g. by index we mean something that is compatible with `length` and `charAt`. I wonder if using a qualifier e.g. `character index` might help? (open to suggestions here, I'm not 100% sure)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549950855
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549953662
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549945644

From mcimadamore at openjdk.org  Fri Nov 21 14:34:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Nov 2025 14:34:54 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <eiIAMcBsxOZEjzzcQEdUUhu5a8AEmOFv_31NRmGsPrc=.6cb5374b-bb28-46a8-a496-daf7e8dc9c0e@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
 <98Nvh8i9sL6mKa_NPS72wQhnmr3juct9GzVu358lXu4=.0999db1b-806e-43b2-b77c-681c9e8d243f@github.com>
 <eiIAMcBsxOZEjzzcQEdUUhu5a8AEmOFv_31NRmGsPrc=.6cb5374b-bb28-46a8-a496-daf7e8dc9c0e@github.com>
Message-ID: <tdrMcVCtbGZg_PsJFNCWBq4xV4B_kIHjpprRVSTVAC4=.4b78d4b1-c9d3-4f69-ad3b-49d3415202ba@github.com>

On Thu, 20 Nov 2025 08:31:12 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2649:
>> 
>>> 2647:      *
>>> 2648:      * @param src      the Java string to be written into this segment
>>> 2649:      * @param dstEncoding the charset used to {@linkplain Charset#newEncoder() encode}
>> 
>> I'm not sure we have a dependency on the charset being standard?
>
> We do not, thanks, fixed.
> 
> Although I think the existing `allocateFrom(String, Charset)` method does have an undocumented dependency, because it uses `CharsetKind` to get the terminator char length, which only supports standard Charsets. If we add a fast path for UTF-16 that may need a dependency on a standard Charset (or a standard way to get the code unit size of a charset, if it has one).

Note sure I follow -- the method you mention says this:

    * @throws IllegalArgumentException if {@code charset} is not a
     *         {@linkplain StandardCharsets standard charset}


What do you mean by "undocumented dependency"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549932198

From cushon at openjdk.org  Fri Nov 21 14:34:55 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 14:34:55 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <tdrMcVCtbGZg_PsJFNCWBq4xV4B_kIHjpprRVSTVAC4=.4b78d4b1-c9d3-4f69-ad3b-49d3415202ba@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
 <98Nvh8i9sL6mKa_NPS72wQhnmr3juct9GzVu358lXu4=.0999db1b-806e-43b2-b77c-681c9e8d243f@github.com>
 <eiIAMcBsxOZEjzzcQEdUUhu5a8AEmOFv_31NRmGsPrc=.6cb5374b-bb28-46a8-a496-daf7e8dc9c0e@github.com>
 <tdrMcVCtbGZg_PsJFNCWBq4xV4B_kIHjpprRVSTVAC4=.4b78d4b1-c9d3-4f69-ad3b-49d3415202ba@github.com>
Message-ID: <pkbZbt08ISzG1EyhoT_rn711_D9eHko0RCjfMeIIqm0=.be12fc47-8cb5-4888-8b37-b378deb321d1@github.com>

On Fri, 21 Nov 2025 14:26:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> We do not, thanks, fixed.
>> 
>> Although I think the existing `allocateFrom(String, Charset)` method does have an undocumented dependency, because it uses `CharsetKind` to get the terminator char length, which only supports standard Charsets. If we add a fast path for UTF-16 that may need a dependency on a standard Charset (or a standard way to get the code unit size of a charset, if it has one).
>
> Note sure I follow -- the method you mention says this:
> 
>     * @throws IllegalArgumentException if {@code charset} is not a
>      *         {@linkplain StandardCharsets standard charset}
> 
> 
> What do you mean by "undocumented dependency"?

Sorry, you're right, it is documented. It's documented differently than e.g. `MemorySegment#getString`, which mentions it in both the `@param` and `@throws` doc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549946334

From vklang at openjdk.org  Fri Nov 21 14:45:53 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Nov 2025 14:45:53 GMT
Subject: RFR: 8372256 : ClassCastException in `ConcurrentHashMap#equals`
Message-ID: <skahHn9VJqGmNYf3x8voICY0zCtgaITwAnu3XmkO-So=.50dcd45b-2434-4330-bf3b-77b1056a89f6@github.com>

Adding logic to handle CCEs and NPEs (the latter cannot logically occur as CHM does not support null keys) as per [AbstractMap::equals](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/AbstractMap.java#L474)

-------------

Commit messages:
 - Addressing 8372256 by catching CCE and NPE during invocation to Map::get in CHM::equals

Changes: https://git.openjdk.org/jdk/pull/28453/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28453&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372256
  Stats: 32 lines in 2 files changed: 27 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28453.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28453/head:pull/28453

PR: https://git.openjdk.org/jdk/pull/28453

From vklang at openjdk.org  Fri Nov 21 14:45:54 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Nov 2025 14:45:54 GMT
Subject: RFR: 8372256 : ClassCastException in `ConcurrentHashMap#equals`
In-Reply-To: <skahHn9VJqGmNYf3x8voICY0zCtgaITwAnu3XmkO-So=.50dcd45b-2434-4330-bf3b-77b1056a89f6@github.com>
References: <skahHn9VJqGmNYf3x8voICY0zCtgaITwAnu3XmkO-So=.50dcd45b-2434-4330-bf3b-77b1056a89f6@github.com>
Message-ID: <eA_7blNHODeVOD-BvX_X4MElrAtgbne_jRuyF18MJPw=.455acc42-6549-473b-b1c8-5bce7519965e@github.com>

On Fri, 21 Nov 2025 14:37:57 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adding logic to handle CCEs and NPEs (the latter cannot logically occur as CHM does not support null keys) as per [AbstractMap::equals](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/AbstractMap.java#L474)

Tagging @DougLea & @AlanBateman

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28453#issuecomment-3563294965

From mcimadamore at openjdk.org  Fri Nov 21 14:46:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Nov 2025 14:46:01 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v11]
In-Reply-To: <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
Message-ID: <uPDq2Z5mHEHqim-ea9ieuvIw0bScSyX2jy-OSsUxwIc=.8a4cd399-877d-4646-856d-342123ccb12a@github.com>

On Fri, 21 Nov 2025 14:26:00 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Utils.checkNonNegativeArgument

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1341:

> 1339:      * @param length  length in bytes of the string to read
> 1340:      * @return a Java string constructed from the bytes read from the given starting
> 1341:      *         address reading the given length of bytes

Maybe:


a Java string constructed from the bytes read from the given starting address up to the given length


(that seems to match the existing `getString` a bit more, and avoids the reading/read repetition)

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 157:

> 155: 
> 156:     /**
> 157:      * Converts a Java string into a C string using the provided charset,

I think using the term `C string` here is misleading. 

I suggest:


Encodes a Java string using the provided charset and stores the resulting byte array into a memory segment.

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 170:

> 168:      * will appear truncated when read again.
> 169:      *
> 170:      * @param str      the Java string to be converted into a C string

Suggestion:

     * @param str      the Java string to be encoded

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 175:

> 173:      * @param srcIndex the starting index of the source string
> 174:      * @param numChars the number of characters to be copied
> 175:      * @return a new native segment containing the converted C string

Watch out for C string again

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549976060
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549982704
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549985304
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549990113

From mcimadamore at openjdk.org  Fri Nov 21 14:51:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Nov 2025 14:51:15 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v11]
In-Reply-To: <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
Message-ID: <IEoLCdqxX3ofiu8y5Wz1OxG41ZAuzoSTnUaPOxkhcBw=.0cf97ced-9b99-497f-8e3a-4599bb2c00c6@github.com>

On Fri, 21 Nov 2025 14:26:00 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Utils.checkNonNegativeArgument

Looks good -- left some more javadoc comments

-------------

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3493072174

From dl at openjdk.org  Fri Nov 21 14:53:18 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Nov 2025 14:53:18 GMT
Subject: RFR: 8372256 : ClassCastException in `ConcurrentHashMap#equals`
In-Reply-To: <skahHn9VJqGmNYf3x8voICY0zCtgaITwAnu3XmkO-So=.50dcd45b-2434-4330-bf3b-77b1056a89f6@github.com>
References: <skahHn9VJqGmNYf3x8voICY0zCtgaITwAnu3XmkO-So=.50dcd45b-2434-4330-bf3b-77b1056a89f6@github.com>
Message-ID: <47BDAMELVQmpZyNF_iUpWX0P7Ync6K_VuHbGTnVe-xk=.d0f4bec5-c907-450e-b3a3-162c46eb7099@github.com>

On Fri, 21 Nov 2025 14:37:57 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adding logic to handle CCEs and NPEs (the latter cannot logically occur as CHM does not support null keys) as per [AbstractMap::equals](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/AbstractMap.java#L474)

Looks good. Thanks for doing this!

-------------

Marked as reviewed by dl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28453#pullrequestreview-3493078800

From mcimadamore at openjdk.org  Fri Nov 21 14:53:20 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Nov 2025 14:53:20 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v8]
In-Reply-To: <YpmmQyTak50BdUkBPoZGKyRchAzGfZRhlZqxnNsoLlE=.203a8643-0d2b-44ba-8ac6-8ee567f235d2@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <YpmmQyTak50BdUkBPoZGKyRchAzGfZRhlZqxnNsoLlE=.203a8643-0d2b-44ba-8ac6-8ee567f235d2@github.com>
Message-ID: <2wZCAYrudMg-I_3QVd-OZP1yWDgN0LG4tYVVx10I_eI=.585c4545-4c47-4420-89e7-d926e1b855d2@github.com>

On Fri, 21 Nov 2025 12:08:40 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace error
>   
>   This work was sponsored by: The FreeBSD Foundation

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28235#pullrequestreview-3493078474

From mcimadamore at openjdk.org  Fri Nov 21 14:53:22 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Nov 2025 14:53:22 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <TYiAbraPlBQOnG9szCnSQZdYN3GE9BPDGvK466XHw5s=.1e249521-07df-46f3-bd78-7907c30cb9e0@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
 <7GPlLrIKdco0l6GK-Ez6IleE3CLvCnCdlF_kekTvDqo=.1745539c-dd1a-4db3-a121-319e5c74fe04@github.com>
 <_G_KO4wYar6SMQ9-kbYDQ6Iw1W8O_Tgx3IxvdQxcwLA=.0e2c607f-60b5-4111-9a22-bb6b4bb25c4c@github.com>
 <i1OMPFfxQBHnK3k1Ly3h7R6-JrqIqAfPdwceoCrM2QU=.d326a919-c61a-4f28-b4f4-e45b45c5b0f8@github.com>
 <qeqZOflyFvuT6CGD_xSJm1GqChAfZf9OLKsBQ8ub1gc=.8387b4a5-cf65-457a-afd6-6e48d5e6ae5d@github.com>
 <wZvgGVxlxuVrb5T8g1yC_eUEGm7AOEqigjmeQJnvCZ8=.bbdf20a9-6e2e-463f-8928-cf397415ef00@github.com>
 <TYiAbraPlBQOnG9szCnSQZdYN3GE9BPDGvK466XHw5s=.1e249521-07df-46f3-bd78-7907c30cb9e0@github.com>
Message-ID: <B297ONSqS7HEdxJrgaMb3cxtCCZoQIhK4smswIsaogU=.15fe8cb5-ac2b-42c3-a3e7-2606a808f04d@github.com>

On Thu, 20 Nov 2025 18:40:57 GMT, Almaz <duke at openjdk.org> wrote:

> > Note that WG14 still defines a max alignment:
> > > max_align_t
> 
> Can `MAX_MALLOC_ALIGN` be set to `alignof(max_align_t)`?
> 
> > It's in the fact that libc guarantees that all malloc calls will be aligned to that max alignment whereas WG14 does not (unless when you hold it at a certain angle ;-) )
> 
> I think this comes back to https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm.

That would be best, I think, but can also be addressed in a separate PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3563330369

From cushon at openjdk.org  Fri Nov 21 14:57:37 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 14:57:37 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v12]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <Azw8uh7ppASBsB3OOjdLj-98TJazhBZ3pvfzwSyfAW4=.2f5e8473-bcfa-4771-8b21-db396abc75e3@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  More javadoc updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/903696b1..3b206ec0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=10-11

  Stats: 9 lines in 2 files changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From cushon at openjdk.org  Fri Nov 21 14:57:38 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 14:57:38 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v11]
In-Reply-To: <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
Message-ID: <0_blq80sfZri57xjD66yEsN8ofqD3qL9vq4c26yqoJI=.dc03891e-6e25-4cfb-af94-15fcc31bef28@github.com>

On Fri, 21 Nov 2025 14:26:00 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Utils.checkNonNegativeArgument

Thanks again, I updated the javadoc

-------------

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3493033989

From cushon at openjdk.org  Fri Nov 21 14:57:43 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 21 Nov 2025 14:57:43 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v11]
In-Reply-To: <fBY_0qwqGrzGtFr-dx8PEUdZQTA17iBANq2CcrGHMLk=.9fd5ad2b-8cca-465d-93d1-974d2c29942e@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
 <fBY_0qwqGrzGtFr-dx8PEUdZQTA17iBANq2CcrGHMLk=.9fd5ad2b-8cca-465d-93d1-974d2c29942e@github.com>
Message-ID: <1iGr9i4koDfRqZd7WdgnfZPHB6eTmThU3j6377eAYGc=.c3ef4b69-8c2c-4b1e-ae0d-f981e18a81db@github.com>

On Fri, 21 Nov 2025 14:30:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Utils.checkNonNegativeArgument
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1333:
> 
>> 1331:      * sequences with this charset's default replacement string. The {@link
>> 1332:      * java.nio.charset.CharsetDecoder} class should be used when more control
>> 1333:      * over the decoding process is required.
> 
> Should we say here, as you did for `copy` that this method ignores `\0` ?

I added:

> If the string contains any {@code '\0'} characters, they will be read as well.

I suppose it might also make sense to update those warnings in `setString` and `allocateFrom` to mention that if you want to avoid truncating null-terminated strings, `getString(long, Charset, long)` could be used instead of `getString(long)`. What do you think?

> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1341:
> 
>> 1339:      * @param length  length in bytes of the string to read
>> 1340:      * @return a Java string constructed from the bytes read from the given starting
>> 1341:      *         address reading the given length of bytes
> 
> Maybe:
> 
> 
> a Java string constructed from the bytes read from the given starting address up to the given length
> 
> 
> (that seems to match the existing `getString` a bit more, and avoids the reading/read repetition)

Done

> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2646:
> 
>> 2644:      * will appear truncated when read again.
>> 2645:      *
>> 2646:      * @param src      the Java string to be written into this segment
> 
> Suggestion:
> 
>      * @param src      the Java string to be written into the destination segment

Done

> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2649:
> 
>> 2647:      * @param dstEncoding the charset used to {@linkplain Charset#newEncoder() encode}
>> 2648:      *                 the string bytes.
>> 2649:      * @param srcIndex the starting index of the source string
> 
> Do we feel like saying words like "index" is good enough to say what we mean? E.g. by index we mean something that is compatible with `length` and `charAt`. I wonder if using a qualifier e.g. `character index` might help? (open to suggestions here, I'm not 100% sure)

Thanks, I think 'character index' is probably better than just index, since there are both character and byte positions in this API. The docs for numChars also mentions characters. I don't have a better idea for avoiding confusion here.

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 157:
> 
>> 155: 
>> 156:     /**
>> 157:      * Converts a Java string into a C string using the provided charset,
> 
> I think using the term `C string` here is misleading. 
> 
> I suggest:
> 
> 
> Encodes a Java string using the provided charset and stores the resulting byte array into a memory segment.

Thanks, done

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 170:
> 
>> 168:      * will appear truncated when read again.
>> 169:      *
>> 170:      * @param str      the Java string to be converted into a C string
> 
> Suggestion:
> 
>      * @param str      the Java string to be encoded

Done

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 175:
> 
>> 173:      * @param srcIndex the starting index of the source string
>> 174:      * @param numChars the number of characters to be copied
>> 175:      * @return a new native segment containing the converted C string
> 
> Watch out for C string again

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549972828
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549994262
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549973821
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549982045
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2549987338
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2550014277
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2550015835

From asemenyuk at openjdk.org  Fri Nov 21 15:01:07 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 15:01:07 GMT
Subject: Integrated: 8372290: jpackage test lib improvements
In-Reply-To: <_f599S8PCkL9NCWW_vneS0Ir3TkseSq2Va2ddL_gWk8=.173b1497-b522-4796-969b-8fb808994fb3@github.com>
References: <_f599S8PCkL9NCWW_vneS0Ir3TkseSq2Va2ddL_gWk8=.173b1497-b522-4796-969b-8fb808994fb3@github.com>
Message-ID: <k4HAYPbkYBTtnOHqm205i84nbxYCaJTkBxfDi9nm1Sk=.a7c79585-8be0-4403-8685-c0b68cc694c8@github.com>

On Thu, 20 Nov 2025 18:34:08 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Collect updates to jpackage test lib from different work-in-progress fixes:
> 
>  - ConfigFilesStasher: fix "ServiceTest.testAddLFromAppImage" test failure on Linux
>  - Move PropertyFile class to the package level and make it not throw IOException
>  - Update test/jdk/tools/jpackage/clean_stashed_files.sh and test/jdk/tools/jpackage/clean_test_output.sh scripts
>  - CannedFormattedString: make it implement CannedArgument; add `addPrefix()`, and `mapArgs()`
>  - JPackageCommand: add `makeError()` and `makeAdvice()`
> 
> Additionally:
>  - Add a test case to the AppImagePackageTest test to test that jpackage placed launcher .so in the correct location when using the predefined app image and installing the "/usr" tree on Linux
>  - Reduce code duplication in LauncherAsServiceVerifier.java

This pull request has now been integrated.

Changeset: f9127720
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9127720459017bb250327dcd3e5c51316536068
Stats:     213 lines in 14 files changed: 146 ins; 48 del; 19 mod

8372290: jpackage test lib improvements

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28439

From asemenyuk at openjdk.org  Fri Nov 21 15:02:37 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 15:02:37 GMT
Subject: Integrated: 8372292: Remove redundant "throws ConfigException"
In-Reply-To: <PpW5aDpOFEN1YV5zLOdzR7Vzdj4AvOChV8bg6P4-NQs=.0302657a-697c-4c34-a7e4-c4d14e38901c@github.com>
References: <PpW5aDpOFEN1YV5zLOdzR7Vzdj4AvOChV8bg6P4-NQs=.0302657a-697c-4c34-a7e4-c4d14e38901c@github.com>
Message-ID: <_QQi2efxbXAoUigw318pgvkL0qCmRX21UUyDq6o5p2I=.2231816f-3531-4529-a204-134a63975d83@github.com>

On Thu, 20 Nov 2025 18:58:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Remove redundant "throws ConfigException"
>  - Remove redundant `toSupplier(...)`, `toConsumer(...)`, etc calls.

This pull request has now been integrated.

Changeset: e439909b
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e439909b7d3ee8db3a09c3d3354ead56dd5397d7
Stats:     175 lines in 23 files changed: 13 ins; 87 del; 75 mod

8372292: Remove redundant "throws ConfigException"

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28440

From alanb at openjdk.org  Fri Nov 21 15:22:24 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 15:22:24 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v8]
In-Reply-To: <pT6T_HoX-Y0JvzU6j9arMfln_uWiWSGg97Zu6xkMSzE=.08fecfd4-48f5-4c07-9b3f-912be7c50d2d@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com>
 <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com>
 <pT6T_HoX-Y0JvzU6j9arMfln_uWiWSGg97Zu6xkMSzE=.08fecfd4-48f5-4c07-9b3f-912be7c50d2d@github.com>
Message-ID: <Zbb4Ga_0KUrIjDmlC_3r-9q-pkzzKw5h7eJQWDu_DOk=.0d6d52e9-3358-47c0-a7f0-a68c91ab4740@github.com>

On Thu, 20 Nov 2025 19:01:53 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 259:
>> 
>>> 257: 
>>> 258:             try (var r = new BufferedReader(new InputStreamReader(release.get()))) {
>>> 259:                 return Optional.of(r.readLine());
>> 
>> As suggested on the CSR we should read the entire file, not just the first line and treat the entire content as a string in a specific encoding. While I wasn't able to get the JDK build a vendor name with new lines (due to jrt-fs.jar putting `COMPANYNAME` in the MANIFEST.MF) it's conceivable that some `release.txt` file might have more than one line.
>> 
>> Alternatively we need to specify that the file must not contain line breaks or unusual encodings.
>
> The proposal is to have a one line release signature set up by the build, briefly discussed the possibility to use a java properties file format as the current release file distributed with JDK, but then a simplified approach of one signature is preferred.
> 
> I'll update the PR once we come to conclusion with the CSR.

It might be useful to see what breaks if a JDK were built with a newline in the vendor name, I assume other things will break.

Overall I think the changes are looking good, the main thing is that the error message is clear.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2550103816

From liach at openjdk.org  Fri Nov 21 15:39:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Nov 2025 15:39:18 GMT
Subject: RFR: 8367585: Prevent creation of unrepresentable Utf8Entry [v3]
In-Reply-To: <lKAEDkjEZd7M2snPwoXp5LjO5QffNN3m-QYyenqwvq4=.58becf07-3f94-4a41-b224-cabb3c4aa340@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
 <lKAEDkjEZd7M2snPwoXp5LjO5QffNN3m-QYyenqwvq4=.58becf07-3f94-4a41-b224-cabb3c4aa340@github.com>
Message-ID: <mk8WfIyWz-XhktKrIEKPMgA4eC58XFD7-f0Ql6blbrU=.415131c0-a79a-441b-a1b1-6a4abf9e1660@github.com>

On Fri, 14 Nov 2025 21:43:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> John Rose suggests in https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that ClassFile API should validate Utf8Entry length eagerly upon construction. Currently we validate upon writing to bytes, which avoids validation overhead. However, given that most class file utf8 data are shorter than 1/3 of the max length, which is always an encodable length, the performance impact should be low.
>> 
>> Preventing the creation of unrepresentable UTF8 entries can prevent passing such invalid instances around, making such problems easier to debug than a failure at building.
>> 
>> Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of the regularly run transformation benchmarks seems neutral, less than 5% perturbations.
>> 
>> I will update docs to reflect this change, given how widespread this is across JDK - it seems the only exempt classes are Signature, ClassSignature, and MethodSignature.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27281#issuecomment-3563544876

From liach at openjdk.org  Fri Nov 21 15:42:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Nov 2025 15:42:01 GMT
Subject: Integrated: 8367585: Prevent creation of unrepresentable Utf8Entry
In-Reply-To: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
Message-ID: <hQirHOnnjIbvKMqKZc6BTjXw3ziVdUZUq8BeMREkj8Q=.29e2df98-3578-4d9f-93db-041b32604748@github.com>

On Mon, 15 Sep 2025 05:43:43 GMT, Chen Liang <liach at openjdk.org> wrote:

> John Rose suggests in https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that ClassFile API should validate Utf8Entry length eagerly upon construction. Currently we validate upon writing to bytes, which avoids validation overhead. However, given that most class file utf8 data are shorter than 1/3 of the max length, which is always an encodable length, the performance impact should be low.
> 
> Preventing the creation of unrepresentable UTF8 entries can prevent passing such invalid instances around, making such problems easier to debug than a failure at building.
> 
> Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of the regularly run transformation benchmarks seems neutral, less than 5% perturbations.
> 
> I will update docs to reflect this change, given how widespread this is across JDK - it seems the only exempt classes are Signature, ClassSignature, and MethodSignature.

This pull request has now been integrated.

Changeset: 3b1eb762
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b1eb7623180ac1b1d69622481589c43749dbbfc
Stats:     380 lines in 10 files changed: 210 ins; 53 del; 117 mod

8367585: Prevent creation of unrepresentable Utf8Entry

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/27281

From sgehwolf at openjdk.org  Fri Nov 21 15:42:59 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 21 Nov 2025 15:42:59 GMT
Subject: RFR: 8347831: Re-examine version check when cross linking [v8]
In-Reply-To: <Zbb4Ga_0KUrIjDmlC_3r-9q-pkzzKw5h7eJQWDu_DOk=.0d6d52e9-3358-47c0-a7f0-a68c91ab4740@github.com>
References: <zZ7QS9gezFMNjvCbe_66MSvNJWsckHAvFocNcu6RdaU=.e6a52c4b-fc73-4a14-9c60-5eaf9850a729@github.com>
 <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com>
 <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com>
 <pT6T_HoX-Y0JvzU6j9arMfln_uWiWSGg97Zu6xkMSzE=.08fecfd4-48f5-4c07-9b3f-912be7c50d2d@github.com>
 <Zbb4Ga_0KUrIjDmlC_3r-9q-pkzzKw5h7eJQWDu_DOk=.0d6d52e9-3358-47c0-a7f0-a68c91ab4740@github.com>
Message-ID: <W7XGiMG0Nl5bcywFwu7EcB9s0JWqA3pLCmcSCCsV5ls=.a4f5970b-77a1-4b96-b8f8-6ebf80d5f5a9@github.com>

On Fri, 21 Nov 2025 15:18:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It might be useful to see what breaks if a JDK were built with a newline in the vendor name, I assume other things will break.

Writhing the manifest entries for `jrt-fs.jar` break (header validation fails). Since the vendor populates to that jar file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2550173160

From jvernee at openjdk.org  Fri Nov 21 15:46:38 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Nov 2025 15:46:38 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v11]
In-Reply-To: <1iGr9i4koDfRqZd7WdgnfZPHB6eTmThU3j6377eAYGc=.c3ef4b69-8c2c-4b1e-ae0d-f981e18a81db@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
 <fBY_0qwqGrzGtFr-dx8PEUdZQTA17iBANq2CcrGHMLk=.9fd5ad2b-8cca-465d-93d1-974d2c29942e@github.com>
 <1iGr9i4koDfRqZd7WdgnfZPHB6eTmThU3j6377eAYGc=.c3ef4b69-8c2c-4b1e-ae0d-f981e18a81db@github.com>
Message-ID: <cE0UvaUjkyVNNGUd3FcfmJXK1DIijk3rIr-sEqER2kg=.7420d4ce-c240-4ba8-8631-cfc42186c34f@github.com>

On Fri, 21 Nov 2025 14:39:59 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2649:
>> 
>>> 2647:      * @param dstEncoding the charset used to {@linkplain Charset#newEncoder() encode}
>>> 2648:      *                 the string bytes.
>>> 2649:      * @param srcIndex the starting index of the source string
>> 
>> Do we feel like saying words like "index" is good enough to say what we mean? E.g. by index we mean something that is compatible with `length` and `charAt`. I wonder if using a qualifier e.g. `character index` might help? (open to suggestions here, I'm not 100% sure)
>
> Thanks, I think 'character index' is probably better than just index, since there are both character and byte positions in this API. The docs for numChars also mentions characters. I don't have a better idea for avoiding confusion here.

I thought this would be clear enough since it's talking about an index of a string, where 'index' has a pretty well understood meaning.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2550188629

From alanb at openjdk.org  Fri Nov 21 15:49:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 15:49:18 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v4]
In-Reply-To: <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>
Message-ID: <0C0KLOhgwQPTJRYDkH2G6Ier-f7sJ2LteLPbZgnr0lI=.8fbfaee6-e467-400c-a76b-e8a005fb8766@github.com>

On Fri, 21 Nov 2025 10:25:24 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some negative tests for suggested values.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 371:

> 369:                                         ? arg
> 370:                                         :"zip-6";
> 371:                                 m.put(plugin.getName(), level);

Thanks for fixing this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2550196893

From alanb at openjdk.org  Fri Nov 21 15:49:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 15:49:20 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <qX7HHo1DwZMr_k6WQGzHwH-ARtJPDR5Ag08fuhPsmjE=.3003bbd1-f5af-423d-b089-0311a3e7f21e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
 <jJad_byg_l20nlbAZjHDUCadnTNL6FdNmGCTESHyRE0=.d1e86a93-6478-466c-83bf-595d304d7bb8@github.com>
 <WH3ecv0QGys2-QpqltzMyz2jQGi2ZBXOo23JX9PG3GU=.77c2d810-e693-4ec2-888f-41c82094120f@github.com>
 <JSWnv-432jILEA8x1UmCkDXbS40hgNj0MggIBH_Hr6I=.ba870ff9-a6f7-41c4-ba70-615bc7421943@github.com>
 <qX7HHo1DwZMr_k6WQGzHwH-ARtJPDR5Ag08fuhPsmjE=.3003bbd1-f5af-423d-b089-0311a3e7f21e@github.com>
Message-ID: <D3aZt0yz_FYuIygHxf6-HbiomMHwvGn-nd-xW64_aNk=.b82f2796-bfa3-4b3c-b750-e257770dec04@github.com>

On Fri, 21 Nov 2025 09:35:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Nit - the use of square brackets is usually meant to imply "optional". Here it is mandatory to specify a digit between 0 and 9 following the "zip-" text. Perhaps using angular bracket would be better?
>> 
>> Hmmm,  square brackets in the shell are a regex indicating a wildcard.  I think that `[0-9]` reads better in the shell/command line context.
>
> No objections from me to let it stay in the current form then.

`{  }` is use in some man pages pick one from the items from inside the braces.  Maybe `zip-{0..9}` would work here as the `jlink` man page already uses `[ ]` for optional items.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2550195657

From rriggs at openjdk.org  Fri Nov 21 16:26:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Nov 2025 16:26:00 GMT
Subject: RFR: 8372307: Clean up the leftover code comment references to
 file.encoding in java_props_md.c
In-Reply-To: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
References: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
Message-ID: <it-Euw03m-a0UukXvX2kaYqiQVYYqCqqpjqyd9P0nGE=.dc1a7454-e0c6-4ecc-9a2d-92a56227c2c6@github.com>

On Fri, 29 Aug 2025 14:25:25 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> The `file.encoding` system property is no longer used by the JDK.
> Updated code comments to reference the correct replacement: `native.encoding`.

You may find it useful to read the [OpenJDK Developers Guide](https://openjdk.org/guide/#contributing-to-an-openjdk-project).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27004#issuecomment-3563759311

From duke at openjdk.org  Fri Nov 21 16:38:44 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 21 Nov 2025 16:38:44 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch
Message-ID: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>

Adds a semantic reason for failure which can be optionally interrogated by calling code.
Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask.

I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers.

We can use this approach to provide translated messages for all the distinct failure reasons if needed.

-------------

Commit messages:
 - remove path inference
 - change error message for version mismatch

Changes: https://git.openjdk.org/jdk/pull/28456/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28456&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372301
  Stats: 56 lines in 3 files changed: 38 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28456/head:pull/28456

PR: https://git.openjdk.org/jdk/pull/28456

From rriggs at openjdk.org  Fri Nov 21 16:46:20 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Nov 2025 16:46:20 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch
In-Reply-To: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
Message-ID: <Q1GSLvyrU7dETPAjPo81BjxfCw7lU66y7nAE6T7g2eY=.4d0bb07d-ffd0-4e4f-bc29-36cd62f98c9d@github.com>

On Fri, 21 Nov 2025 16:32:49 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adds a semantic reason for failure which can be optionally interrogated by calling code.
> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask.
> 
> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers.
> 
> We can use this approach to provide translated messages for all the distinct failure reasons if needed.

src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 469:

> 467:      * semantic reason for failure and allow better user-facing error messages.
> 468:      */
> 469:     public final static class ImageError extends IOException {

Exception names ending in "Error" are usually fatal to the VM, this seems more like a normal exception.
Generally, we don't add single purpose exceptions, they are little used and just contribute to bloat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28456#discussion_r2550365590

From asemenyuk at openjdk.org  Fri Nov 21 16:50:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 16:50:52 GMT
Subject: RFR: 8372359: Clean jpackage error messages
Message-ID: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>

Some jpackage error messages have "Error: " prefix. Some don't. The prefix is redundant as jpackage assembles the error message from the localized "Error: " prefix and localized message body [1]. The prefix was removed. 

There are error messages specific to jpackage options that duplicate generic error messages. They are:

**ERR_BuildRootInvalid**
It duplicates a generic "error.parameter-not-empty-directory" error message.

| Specialized error message | Generic error message | 
| --- | --- |
| Error: temp (foo) must be non-existent or empty directory | The value "foo" provided for parameter --temp is not an empty directory or non existent path |

**ERR_AppImageNotExist**
It duplicates a generic "error.parameter-not-directory" error message.

| Specialized error message | Generic error message | 
| --- | --- |
| Error: App image directory "foo" does not exist | The value "foo" provided for parameter --app-image is not a directory |

**ERR_BothMainJarAndModule**
It duplicates a generic "ERR_MutuallyExclusiveOptions" error message.

| Specialized error message | Generic error message | 
| --- | --- |
| Error: Cannot have both --main-jar and --module Options | Mutually exclusive options [--main-jar] and [--module] |

**ERR_NoAddLauncherName**
It duplicates a generic "error.parameter-add-launcher-malformed" error message.

| Specialized error message | Generic error message | 
| --- | --- |
| Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |

Specialized error messages duplicating generic error messages were removed to simplify maintenance.

Also, ERR_MissingArgument is not referenced in the implementation, but mistakenly referenced in the tests. It was replaced with ERR_MissingArgument2, and ERR_MissingArgument was removed.

There are error messages that are not referenced in the code. They are:

| ID | Note |
| -------- | -------- |
| message.creating-association-with-null-extension | FA with null extensions are not supported starting from jdk25: https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/jdk.jpackage/share/classes/jdk/jpackage/internal/FileAssociationGroup.java#L93. https://github.com/openjdk/jdk21u/blob/485ced0d5b240d45640906a4a101ec94c18820ba/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java#L519 |
| error.must-sign-app-store | Latest referenced from [jdk16/MacAppStoreBundler.java](https://github.com/openjdk/jdk16/blob/4de3a6be9e60b9676f2199cd18eadb54a9d6e3fe/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppStoreBundler.java#L213). It was removed, the key is a leftover. |
| error.must-sign-app-store.advice | same as "error.must-sign-app-store" |
| message.ignoring.symlink | Last referenced from [jdk24u/MacAppImageBuilder.java](https://github.com/openjdk/jdk24u/blob/b42f146edb8324bbb164bb706e8ad39d60aaf25b/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java#L817). The file was deleted in [JDK-8333664](https://bugs.openjdk.org/browse/JDK-8333664). |
| message.already.signed | Last refernced from [jdk16/MacAppImageBuilder.java](https://github.com/openjdk/jdk16/blob/4de3a6be9e60b9676f2199cd18eadb54a9d6e3fe/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java#L657). The reference was removed in [JDK-8248904](https://bugs.openjdk.org/browse/JDK-8248904). |
| message.running-script | Last refernced from [jdk14/MacDmgBundler.java](https://github.com/openjdk/jdk14/blob/abc56193174dd6a11a8453bd5036fc8618ecca61/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacDmgBundler.java#L70). The reference was removed in [JDK-8230652](https://bugs.openjdk.org/browse/JDK-8230652). |
| message.module-class | Last refernced from [jdk14/JLinkBundlerHelper.java](https://github.com/openjdk/jdk14/blob/abc56193174dd6a11a8453bd5036fc8618ecca61/src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/JLinkBundlerHelper.java#L110). The reference was removed in [JDK-8246624](https://bugs.openjdk.org/browse/JDK-8246624). |
| resource.setup-icon | Referenced from [jfx11u/WinExeBundler.java](https://github.com/openjdk/jfx11u/blob/1bc63c025ce4c7fddba28755e7ddb3c2cb4018ec/modules/jdk.packager/src/main/java/com/oracle/tools/packager/windows/WinExeBundler.java#L667). Not referenced from any JDK repo. |
| message.invalid.install.dir | Was referenced from WixAppImageFragmentBuilder.java until [JDK-8333664](https://bugs.openjdk.org/browse/JDK-8333664). Duplicates "error.invalid-install-dir" referenced from [jdk/PackageBuilder](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackageBuilder.java#L213). |
| resource.bundle-config-file | Found only in .property files accross all repos in the "openjdk" org. Was never referenced. |

Unreferenced error messages were removed.

Additionally, reworked ErrorTest to differentiate between error and advice messages in the jpackage output.

[1] https://github.com/openjdk/jdk/blob/5f806e7f8b66c14954a07005be3bceb2f812fbff/src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java#L176

-------------

Commit messages:
 - Get rid of old error IDs
 - *Resources.properties: remove unreferenced keys
 - OptionsValidationFailTest.excludes: follow up for ErrorTest update
 - ErrorTest: differentiate between errors and advices in the expected output
 - Remove "Error: " prefix from error messages

Changes: https://git.openjdk.org/jdk/pull/28457/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372359
  Stats: 197 lines in 11 files changed: 30 ins; 44 del; 123 mod
  Patch: https://git.openjdk.org/jdk/pull/28457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28457/head:pull/28457

PR: https://git.openjdk.org/jdk/pull/28457

From asemenyuk at openjdk.org  Fri Nov 21 17:00:32 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 17:00:32 GMT
Subject: RFR: 8372359: Clean jpackage error messages
In-Reply-To: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
References: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
Message-ID: <XAjSWTZ7crk6qaI2eINYdn7Eaj1CfWFxTnQpTq-sWH4=.552a0ff5-d2a9-4847-b625-8b71fd180c21@github.com>

On Fri, 21 Nov 2025 16:45:31 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Some jpackage error messages have "Error: " prefix. Some don't. The prefix is redundant as jpackage assembles the error message from the localized "Error: " prefix and localized message body [1]. The prefix was removed. 
> 
> There are error messages specific to jpackage options that duplicate generic error messages. They are:
> 
> **ERR_BuildRootInvalid**
> It duplicates a generic "error.parameter-not-empty-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: temp (foo) must be non-existent or empty directory | The value "foo" provided for parameter --temp is not an empty directory or non existent path |
> 
> **ERR_AppImageNotExist**
> It duplicates a generic "error.parameter-not-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: App image directory "foo" does not exist | The value "foo" provided for parameter --app-image is not a directory |
> 
> **ERR_BothMainJarAndModule**
> It duplicates a generic "ERR_MutuallyExclusiveOptions" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Cannot have both --main-jar and --module Options | Mutually exclusive options [--main-jar] and [--module] |
> 
> **ERR_NoAddLauncherName**
> It duplicates a generic "error.parameter-add-launcher-malformed" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |
> 
> Specialized error messages duplicating generic error messages were removed to simplify maintenance.
> 
> Also, ERR_MissingArgument is not referenced in the implementation, but mistakenly referenced in the tests. It was replaced with ERR_MissingArgument2, and ERR_MissingArgument was removed.
> 
> There are error messages that are not referenced in the code. They are:
> 
> | ID | Note |
> | -------- | -------- |
> | message.creating-association-with-null-extension | FA with null extensions are not supported starting from jdk25: https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/jdk.jpackage/share/classes/jdk/jpackage/internal/FileAssociationGroup.java#L93. https://github.com/openjdk/jdk21u/blob/485ced0d5b240d45640906a4a101ec94c18820ba/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java#L519 |
> | error.must-sign-app-store | Latest referen...

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28457#issuecomment-3563875323

From duke at openjdk.org  Fri Nov 21 17:01:43 2025
From: duke at openjdk.org (Trevor Bond)
Date: Fri, 21 Nov 2025 17:01:43 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all Utf8
 CP entries
Message-ID: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>

Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.

I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.

I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.

| Version | Avg Time (ns/op) | ? vs Before |
|--------|------------------:|-------------|
| **Before** | 1,483,671.539 ? 3,477.744 | ? |
| **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |

-------------

Commit messages:
 - JDK-8350938

Changes: https://git.openjdk.org/jdk/pull/28458/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28458&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350938
  Stats: 28 lines in 1 file changed: 3 ins; 19 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28458/head:pull/28458

PR: https://git.openjdk.org/jdk/pull/28458

From duke at openjdk.org  Fri Nov 21 17:06:45 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 21 Nov 2025 17:06:45 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch
In-Reply-To: <Q1GSLvyrU7dETPAjPo81BjxfCw7lU66y7nAE6T7g2eY=.4d0bb07d-ffd0-4e4f-bc29-36cd62f98c9d@github.com>
References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
 <Q1GSLvyrU7dETPAjPo81BjxfCw7lU66y7nAE6T7g2eY=.4d0bb07d-ffd0-4e4f-bc29-36cd62f98c9d@github.com>
Message-ID: <c3KVxqVPzf0mVJBmQ9SCmx0ME1g9bB3VXvEZXnUNyUc=.8db9024e-7189-4081-a85f-1a20f573268b@github.com>

On Fri, 21 Nov 2025 16:43:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Adds a semantic reason for failure which can be optionally interrogated by calling code.
>> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask.
>> 
>> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers.
>> 
>> We can use this approach to provide translated messages for all the distinct failure reasons if needed.
>
> src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 469:
> 
>> 467:      * semantic reason for failure and allow better user-facing error messages.
>> 468:      */
>> 469:     public final static class ImageError extends IOException {
> 
> Exception names ending in "Error" are usually fatal to the VM, this seems more like a normal exception.
> Generally, we don't add single purpose exceptions, they are little used and just contribute to bloat.

How else do you think it best to reliably detect the semantic difference for the JImageTool while keeping the non-tool usage as it was? This new exception has a vital role for doing that which, if it, or something like it, didn't exist would be done via unsatisfying heuristics on the debug message string.

An alternate version would be to refactor things to have an "open()" method that returns a failure-reason type of some sort. And this approach would pave the way to properly translated strings for all the failure modes (though the others aren't actionable in as distinct a way).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28456#discussion_r2550413423

From duke at openjdk.org  Fri Nov 21 17:26:59 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Fri, 21 Nov 2025 17:26:59 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v10]
In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
Message-ID: <ZEVS93Aiipf_5N4nh9o0xMejv9yZmnkrBM5C9wjqxtg=.880c1d7a-2e51-4f5f-99b3-5aa90ac353ab@github.com>

> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach

Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:

  implement re-throwing approach according to reviewer recomandation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28124/files
  - new: https://git.openjdk.org/jdk/pull/28124/files/1095cf6e..57b94806

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=08-09

  Stats: 46 lines in 1 file changed: 13 ins; 27 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28124/head:pull/28124

PR: https://git.openjdk.org/jdk/pull/28124

From mcimadamore at openjdk.org  Fri Nov 21 17:29:12 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Nov 2025 17:29:12 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v11]
In-Reply-To: <1iGr9i4koDfRqZd7WdgnfZPHB6eTmThU3j6377eAYGc=.c3ef4b69-8c2c-4b1e-ae0d-f981e18a81db@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <xw3iHVaGEGwNv6ASjjbqgZYAKloDcuXH0UCzN-6PYnk=.fe7e11d5-1660-4c8d-be36-4e399311fbd5@github.com>
 <fBY_0qwqGrzGtFr-dx8PEUdZQTA17iBANq2CcrGHMLk=.9fd5ad2b-8cca-465d-93d1-974d2c29942e@github.com>
 <1iGr9i4koDfRqZd7WdgnfZPHB6eTmThU3j6377eAYGc=.c3ef4b69-8c2c-4b1e-ae0d-f981e18a81db@github.com>
Message-ID: <z2ZrbHRiVoF7iPzAXdGdGvb1xyO_nMEuNsgJwvTH9uM=.a481c075-be0d-4165-8c80-14f3c57ee40b@github.com>

On Fri, 21 Nov 2025 14:36:44 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1333:
>> 
>>> 1331:      * sequences with this charset's default replacement string. The {@link
>>> 1332:      * java.nio.charset.CharsetDecoder} class should be used when more control
>>> 1333:      * over the decoding process is required.
>> 
>> Should we say here, as you did for `copy` that this method ignores `\0` ?
>
> I added:
> 
>> If the string contains any {@code '\0'} characters, they will be read as well.
> 
> I suppose it might also make sense to update those warnings in `setString` and `allocateFrom` to mention that if you want to avoid truncating null-terminated strings, `getString(long, Charset, long)` could be used instead of `getString(long)`. What do you think?

Could be a good idea, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2550485334

From mcimadamore at openjdk.org  Fri Nov 21 17:32:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Nov 2025 17:32:48 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v12]
In-Reply-To: <Azw8uh7ppASBsB3OOjdLj-98TJazhBZ3pvfzwSyfAW4=.2f5e8473-bcfa-4771-8b21-db396abc75e3@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Azw8uh7ppASBsB3OOjdLj-98TJazhBZ3pvfzwSyfAW4=.2f5e8473-bcfa-4771-8b21-db396abc75e3@github.com>
Message-ID: <WUj-p4EmBPp9JSs22i-j-QpTrroPxQD77whOoiWr0Zw=.268d36a7-8ded-49c6-9b97-b0602d8b36e2@github.com>

On Fri, 21 Nov 2025 14:57:37 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More javadoc updates

Looks great -- thanks!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3493740705

From naoto.sato at oracle.com  Fri Nov 21 17:34:29 2025
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 21 Nov 2025 09:34:29 -0800
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and
 Verona projects
In-Reply-To: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
References: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
Message-ID: <6a6d1a8d-a1ec-4632-ac63-5eab00199331@oracle.com>

Vote: yes

Naoto

On 11/20/25 10:37 PM, Alan Bateman wrote:
> 
> I hereby propose that the Core Libraries group withdraw sponsorship of 
> the Device I/O [1], Kona [2], Penrose [3], and Verona [4] projects. 
> These projects have been inactive for a long time:
> 
> - Device I/O has been inactive since 2018.
> - Project Kona had some activity in 2015 but nothing since.
> - Project Penrose had some activity in 2012 but nothing since.
> - Project Verona defined the version-string scheme that integrated into 
> main line in 2015 for JDK 9 (JEP 223), its work is complete.
> 
> These projects have only one group sponsor. A consequence of withdrawing 
> sponsorship is that these projects will be dissolved [5]. Votes are due 
> by December 5, 2025, 23.59 UTC. Only current Core Libraries group 
> members [6] are eligible to vote on this motion. Votes must be cast in 
> the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [7].
> -Alan
> [1] https://openjdk.org/projects/dio
> [2] https://openjdk.org/projects/kona
> [3] https://openjdk.org/projects/penrose
> [4] https://openjdk.org/projects/verona
> [5] https://openjdk.org/bylaws#sponsor
> [6] https://openjdk.org/census#core-libs
> [7] https://openjdk.org/bylaws#lazy-consensus


From jlu at openjdk.org  Fri Nov 21 17:47:43 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 21 Nov 2025 17:47:43 GMT
Subject: RFR: 8368001: java/text/Format/NumberFormat/NumberRoundTrip.java
 timed out [v2]
In-Reply-To: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
References: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
Message-ID: <_7ucLGYWHQwIJ8KPWgpamZ19-VkYxbsc-eLiMKom2js=.ccc81eab-7be0-4d6d-98f5-b315ab4c05a5@github.com>

> JDK-8260555 exposed test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java as being susceptible to timeouts.
> While the timeout factor is reverted, this test was testing too many inputs, and should be changed. 
> Originally, it was testing (~1000 locales * 4 factories) against ~30 numeric inputs. The test does not need to be exhaustive to this degree.
> 
> The total amount of locales is changed to sample around a 1/4 of those provided by the provider. The numeric inputs are reduced to about ~20. (The fixed ones remain, and the random ones are cut in half.)
> 
> Locally, I observe average execution for this test to be about ~1.3 seconds, compared to ~3.4 seconds previously. The PR also does a drive-by clean up of the test, i.e. getting rid of the unnecessary escaping + string manipulation/printing and separating the test inputs from the actual testing work done.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Use jdk.test.lib.RandomFactory

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28443/files
  - new: https://git.openjdk.org/jdk/pull/28443/files/bf14ea50..dca988e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28443&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28443&range=00-01

  Stats: 9 lines in 1 file changed: 6 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28443/head:pull/28443

PR: https://git.openjdk.org/jdk/pull/28443

From jlu at openjdk.org  Fri Nov 21 17:47:44 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 21 Nov 2025 17:47:44 GMT
Subject: RFR: 8368001: java/text/Format/NumberFormat/NumberRoundTrip.java
 timed out [v2]
In-Reply-To: <0KRtSwwkeSYFhfOzbHgRyl1M_1tG4lCdVfCt0tm_UF8=.0a88331a-2385-4c1b-abbb-a84757bd1fa6@github.com>
References: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
 <0KRtSwwkeSYFhfOzbHgRyl1M_1tG4lCdVfCt0tm_UF8=.0a88331a-2385-4c1b-abbb-a84757bd1fa6@github.com>
Message-ID: <v5vOUFvasTFkkxHxAonOoEwmivmb8AxTun0ST7Q-8Io=.e11f9741-e1b2-4735-9e25-c825753f112f@github.com>

On Fri, 21 Nov 2025 13:07:26 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use jdk.test.lib.RandomFactory
>
> test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java line 143:
> 
>> 141:     // Return a random value from -range..+range.
>> 142:     private static double randomDouble(double range) {
>> 143:         double a = Math.random();
> 
> I would suggest using `jdk.test.lib.RandomFactory`, as this supports reproducible values in case of a randomised test failure.
> 
> 
> import jdk.test.lib.RandomFactory;
> ...
>  * @library /test/lib
>  * @build jdk.test.lib.RandomFactory
> ...
>     private static final Random RANDOM = RandomFactory.getRandom();
> ...
>     private static double randomDouble(double range) {
>         double a = RANDOM.nextDouble();
> ...

Thanks for the improvement, updated in https://github.com/openjdk/jdk/pull/28443/commits/dca988e7ddb51306c2f791eae5e9071c85796eb7.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28443#discussion_r2550523057

From per-ake.minborg at oracle.com  Fri Nov 21 17:56:42 2025
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Fri, 21 Nov 2025 17:56:42 +0000
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and
 Verona projects
In-Reply-To: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
References: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
Message-ID: <SA1PR10MB783216A35AE30CB5F242F80CDAD5A@SA1PR10MB7832.namprd10.prod.outlook.com>

Vote: yes

- Per

Confidential- Oracle Internal
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Alan Bateman <alan.bateman at oracle.com>
Sent: Friday, November 21, 2025 7:37 AM
To: 'core-libs-dev' <core-libs-dev at openjdk.org>
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and Verona projects


I hereby propose that the Core Libraries group withdraw sponsorship of the Device I/O [1], Kona [2], Penrose [3], and Verona [4] projects. These projects have been inactive for a long time:

- Device I/O has been inactive since 2018.
- Project Kona had some activity in 2015 but nothing since.
- Project Penrose had some activity in 2012 but nothing since.
- Project Verona defined the version-string scheme that integrated into main line in 2015 for JDK 9 (JEP 223), its work is complete.

These projects have only one group sponsor. A consequence of withdrawing sponsorship is that these projects will be dissolved [5]. Votes are due by December 5, 2025, 23.59 UTC. Only current Core Libraries group members [6] are eligible to vote on this motion. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [7].
-Alan
[1] https://openjdk.org/projects/dio
[2] https://openjdk.org/projects/kona
[3] https://openjdk.org/projects/penrose
[4] https://openjdk.org/projects/verona
[5] https://openjdk.org/bylaws#sponsor
[6] https://openjdk.org/census#core-libs
[7] https://openjdk.org/bylaws#lazy-consensus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251121/cd06601f/attachment-0001.htm>

From alanb at openjdk.org  Fri Nov 21 17:58:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 17:58:50 GMT
Subject: RFR: 8372256 : ClassCastException in `ConcurrentHashMap#equals`
In-Reply-To: <skahHn9VJqGmNYf3x8voICY0zCtgaITwAnu3XmkO-So=.50dcd45b-2434-4330-bf3b-77b1056a89f6@github.com>
References: <skahHn9VJqGmNYf3x8voICY0zCtgaITwAnu3XmkO-So=.50dcd45b-2434-4330-bf3b-77b1056a89f6@github.com>
Message-ID: <EocWzQfbfZPQ2CbrDfq7hMy_KeBnrj-Nq5sTcq5hVTE=.8ac26535-e3f0-46c2-ba33-f3395ed41e63@github.com>

On Fri, 21 Nov 2025 14:37:57 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adding logic to handle CCEs and NPEs (the latter cannot logically occur as CHM does not support null keys) as per [AbstractMap::equals](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/AbstractMap.java#L474)

Okay although another random usage of get(Object) with an key for the wrong type will also fail with CCE.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28453#pullrequestreview-3493819494

From asemenyuk at openjdk.org  Fri Nov 21 17:59:06 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 17:59:06 GMT
Subject: RFR: 8372359: Clean jpackage error messages [v2]
In-Reply-To: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
References: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
Message-ID: <61MofhAMHiQ_GwvyzVrKB39jXyoJqRsCuNmoq5XX5Yg=.824c63fe-3509-4e1f-9c62-9ac337459f37@github.com>

> Some jpackage error messages have "Error: " prefix. Some don't. The prefix is redundant as jpackage assembles the error message from the localized "Error: " prefix and localized message body [1]. The prefix was removed. 
> 
> There are error messages specific to jpackage options that duplicate generic error messages. They are:
> 
> **ERR_BuildRootInvalid**
> It duplicates a generic "error.parameter-not-empty-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: temp (foo) must be non-existent or empty directory | The value "foo" provided for parameter --temp is not an empty directory or non existent path |
> 
> **ERR_AppImageNotExist**
> It duplicates a generic "error.parameter-not-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: App image directory "foo" does not exist | The value "foo" provided for parameter --app-image is not a directory |
> 
> **ERR_BothMainJarAndModule**
> It duplicates a generic "ERR_MutuallyExclusiveOptions" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Cannot have both --main-jar and --module Options | Mutually exclusive options [--main-jar] and [--module] |
> 
> **ERR_NoAddLauncherName**
> It duplicates a generic "error.parameter-add-launcher-malformed" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |
> 
> Specialized error messages duplicating generic error messages were removed to simplify maintenance.
> 
>  **ERR_MissingArgument**
> ERR_MissingArgument was not referenced in the implementation, but was mistakenly referenced in the tests. It was replaced with ERR_MissingArgument2, and ERR_MissingArgument was removed.
> 
> **error.invalid-option-value**
> "error.invalid-option-value" was used for errors in shortcut launcher options (--win-shortcut, --linux-shortcut), but it is not descriptive. For this reason, it was replaced with the "error.parameter-not-launcher-shortcut-dir".
> 
> | Old error message | New error message ...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Fix bad merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28457/files
  - new: https://git.openjdk.org/jdk/pull/28457/files/be1664af..36a2267f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28457/head:pull/28457

PR: https://git.openjdk.org/jdk/pull/28457

From duke at openjdk.org  Fri Nov 21 17:59:51 2025
From: duke at openjdk.org (duke)
Date: Fri, 21 Nov 2025 17:59:51 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v9]
In-Reply-To: <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
Message-ID: <Eq-E1mrdqajKe0IX2S8piluuqYBM8ygEHOqn8TtFNNg=.32916b43-b427-44de-9e6d-2c2983e9fdae@github.com>

On Thu, 20 Nov 2025 16:30:56 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

@kilink 
Your change (at version e9e381552d1eabf06320005ba2b2b33d03499cac) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3564075647

From dlsmith at openjdk.org  Fri Nov 21 18:26:47 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Fri, 21 Nov 2025 18:26:47 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries
In-Reply-To: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
Message-ID: <v-vH6hhYjBkUqLKs-lOs8OH6dCjUwWzFk68nxkHf6jo=.15bfa28a-4b05-454f-8239-25a44abf276b@github.com>

On Fri, 21 Nov 2025 16:54:48 GMT, Trevor Bond <duke at openjdk.org> wrote:

> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
> 
> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
> 
> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
> 
> | Version | Avg Time (ns/op) | ? vs Before |
> |--------|------------------:|-------------|
> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |

I'm available as a sponsor when we get this reviewed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28458#issuecomment-3564160007

From duke at openjdk.org  Fri Nov 21 18:37:02 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Fri, 21 Nov 2025 18:37:02 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v9]
In-Reply-To: <QW2FZcdfEbMGyd_QXtYGaLKJ7YxboDM6VA4FKNnjFSY=.015c4aed-d2bb-4e92-bb41-de08ba9e82d7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
 <QW2FZcdfEbMGyd_QXtYGaLKJ7YxboDM6VA4FKNnjFSY=.015c4aed-d2bb-4e92-bb41-de08ba9e82d7@github.com>
Message-ID: <YW9PLMYknZjNjSBRXVasXba4IpKExGaIgOvBhMEaWmo=.f7a0875d-738f-4742-8d5c-991f4090a516@github.com>

On Fri, 21 Nov 2025 09:44:55 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> Marked as reviewed by vklang (Reviewer).

Thanks for the reviews, @viktorklang-ora or @liach would either of you be able to sponsor the change? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3564186333

From duke at openjdk.org  Fri Nov 21 18:45:58 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Fri, 21 Nov 2025 18:45:58 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v4]
In-Reply-To: <qmt-s-ZxvxacHTzWpZvMQY9-8TGJMUIQFRcsipRnzek=.1348a9ba-66d4-4edd-ae0a-a9600382b455@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>
 <qmt-s-ZxvxacHTzWpZvMQY9-8TGJMUIQFRcsipRnzek=.1348a9ba-66d4-4edd-ae0a-a9600382b455@github.com>
Message-ID: <e59d6l5z44yP7YxiXJv2fosB9eiLC198lGWKlv-Z9BI=.31d211c2-0f7f-476e-93a5-419b04dcf892@github.com>

On Fri, 21 Nov 2025 10:35:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add some negative tests for suggested values.
>
> test/jdk/tools/jlink/TaskHelperTest.java line 279:
> 
>> 277:                 var remaining = optionsHelper.handleOptions(this, args.tokens);
>> 278:                 assertTrue(remaining.isEmpty());
>> 279:                 assertEquals(args.expectedCompressValue, compressArgValue);
> 
> I think these 2 asserts are an oversight. Since we expect `optionsHelper.handleOptions(...)` to always throw a `BadArgs` for these invalid option values, we should replace these 2 asserts with a:
> 
> fail("processing of " + Arrays.toString(testCase.tokens) + " was expected to fail, but didn't");
> 
> This will then rightly fail the test if the exception isn't thrown.

To my understanding, for compression plugin the validation of the actual value is performed in `DefaultCompressPlugin` (https://github.com/openjdk/jdk/blob/d57fc1b6dc313eb004892b180960ebcee1cb04c7/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java#L118 and https://github.com/openjdk/jdk/blob/d57fc1b6dc313eb004892b180960ebcee1cb04c7/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java#L115). 

At the moment, [`optionsHelper.handleOptions`](https://github.com/openjdk/jdk/blob/3a45e615973727446c9081b5affbbe7ffe7c3bea/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java#L527) seems to set up `TaskHelper`'s internal state and it shouldn't throw exceptions for syntactically correct options. In my opinion, this fix is not that much related to the value allowed, but to the syntax allowed for the option. I noticed that there is another test class [`JLinkTest`](https://github.com/openjdk/jdk/blob/master/test/jdk/tools/jlink/JLinkTest.java) that tests for actual values. When I tested locally my build of this modified `jlink`, for invalid values I did get that `IllegalArgumentException`. 

However, I am very new to the testing framework and am welcoming more thoughts/ideas ? .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2550661428

From naoto at openjdk.org  Fri Nov 21 18:49:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Nov 2025 18:49:56 GMT
Subject: RFR: 8368001: java/text/Format/NumberFormat/NumberRoundTrip.java
 timed out [v2]
In-Reply-To: <_7ucLGYWHQwIJ8KPWgpamZ19-VkYxbsc-eLiMKom2js=.ccc81eab-7be0-4d6d-98f5-b315ab4c05a5@github.com>
References: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
 <_7ucLGYWHQwIJ8KPWgpamZ19-VkYxbsc-eLiMKom2js=.ccc81eab-7be0-4d6d-98f5-b315ab4c05a5@github.com>
Message-ID: <mZfMjPi-IVdtDTwEW6sCdlYEYNEzKBf32XNMtLcJhyM=.8574fcdf-7f7d-4961-a70b-9fc6ec7a370c@github.com>

On Fri, 21 Nov 2025 17:47:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK-8260555 exposed test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java as being susceptible to timeouts.
>> While the timeout factor is reverted, this test was testing too many inputs, and should be changed. 
>> Originally, it was testing (~1000 locales * 4 factories) against ~30 numeric inputs. The test does not need to be exhaustive to this degree.
>> 
>> The total amount of locales is changed to sample around a 1/4 of those provided by the provider. The numeric inputs are reduced to about ~20. (The fixed ones remain, and the random ones are cut in half.)
>> 
>> Locally, I observe average execution for this test to be about ~1.3 seconds, compared to ~3.4 seconds previously. The PR also does a drive-by clean up of the test, i.e. getting rid of the unnecessary escaping + string manipulation/printing and separating the test inputs from the actual testing work done.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jdk.test.lib.RandomFactory

Good refactoring. One minor comment below

test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java line 29:

> 27:  * @summary NumberFormat round trip testing of parsing and formatting.
> 28:  *      This test checks 4 factory instances per locale against ~20 numeric inputs.
> 29:  *      Samples ~1/4 of the available locales from NumberFormat SPI.

Nit: it is not using SPI

-------------

PR Review: https://git.openjdk.org/jdk/pull/28443#pullrequestreview-3493973259
PR Review Comment: https://git.openjdk.org/jdk/pull/28443#discussion_r2550667418

From duke at openjdk.org  Fri Nov 21 18:50:16 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Fri, 21 Nov 2025 18:50:16 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v5]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <skAaPOoGeAFiKH4wJtnS-iF7qmhHp9W2tTIzkLT4Vco=.708b6ade-17db-4ac9-b054-84e7031d4ea2@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Refactor variable name.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/fccce74b..82f4e8d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Fri Nov 21 18:59:25 2025
From: duke at openjdk.org (Almaz)
Date: Fri, 21 Nov 2025 18:59:25 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v6]
In-Reply-To: <B297ONSqS7HEdxJrgaMb3cxtCCZoQIhK4smswIsaogU=.15fe8cb5-ac2b-42c3-a3e7-2606a808f04d@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <K3K-dy19k0SErPRsdIbEQb-F5IIZdQGFBaH4XWtKUGg=.a70e16aa-3b68-447b-b5e9-b1ee5635e7d2@github.com>
 <UA0mEJqtnXN0VPzYfgBQGd1nLvvLhadpTFUymILI1yA=.a719354d-79cc-41e6-a64b-b7f1520f13bb@github.com>
 <7GPlLrIKdco0l6GK-Ez6IleE3CLvCnCdlF_kekTvDqo=.1745539c-dd1a-4db3-a121-319e5c74fe04@github.com>
 <_G_KO4wYar6SMQ9-kbYDQ6Iw1W8O_Tgx3IxvdQxcwLA=.0e2c607f-60b5-4111-9a22-bb6b4bb25c4c@github.com>
 <i1OMPFfxQBHnK3k1Ly3h7R6-JrqIqAfPdwceoCrM2QU=.d326a919-c61a-4f28-b4f4-e45b45c5b0f8@github.com>
 <qeqZOflyFvuT6CGD_xSJm1GqChAfZf9OLKsBQ8ub1gc=.8387b4a5-cf65-457a-afd6-6e48d5e6ae5d@github.com>
 <wZvgGVxlxuVrb5T8g1yC_eUEGm7AOEqigjmeQJnvCZ8=.bbdf20a9-6e2e-463f-8928-cf397415ef00@github.com>
 <TYiAbraPlBQOnG9szCnSQZdYN3GE9BPDGvK466XHw5s=.1e249521-07df-46f3-bd78-7907c30cb9e0@github.com>
 <B297ONSqS7HEdxJrgaMb3cxtCCZoQIhK4smswIsaogU=.15fe8cb5-ac2b-42c3-a3e7-2606a808f04d@github.com>
Message-ID: <5pKOOtUKZWd26LoPhJMz3dyvXWZtUFMAvfZ2t4rdW2s=.eaa53b3e-f248-46a9-a8ad-cbf0f065203c@github.com>

On Fri, 21 Nov 2025 14:48:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Note that WG14 still defines a max alignment:
>>> > max_align_t
>> 
>> Can `MAX_MALLOC_ALIGN` be set to `alignof(max_align_t)`?
>> 
>>> It's in the fact that libc guarantees that all malloc calls will be aligned to that max alignment whereas WG14 does not (unless when you hold it at a certain angle ;-) )
>> 
>> I think this comes back to https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm.
>
>> > Note that WG14 still defines a max alignment:
>> > > max_align_t
>> 
>> Can `MAX_MALLOC_ALIGN` be set to `alignof(max_align_t)`?
>> 
>> > It's in the fact that libc guarantees that all malloc calls will be aligned to that max alignment whereas WG14 does not (unless when you hold it at a certain angle ;-) )
>> 
>> I think this comes back to https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm.
> 
> That would be best, I think, but can also be addressed in a separate PR.

@mcimadamore 

> but can also be addressed in a separate PR.

Do you want me to send a patch? Will that need an entry in JBS?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3564244255

From duke at openjdk.org  Fri Nov 21 18:59:39 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Fri, 21 Nov 2025 18:59:39 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v6]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <1-W3zRqu-7ISZrCV0B1qUVQr8kmKGu1os6vEGlyGQd8=.842c93d9-3348-417f-81cc-3bbe10f3c2bc@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:

 - Fix typo in man page too.
 - Fix typo in dependencies.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/82f4e8d1..d0684384

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Fri Nov 21 18:59:39 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Fri, 21 Nov 2025 18:59:39 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v3]
In-Reply-To: <D3aZt0yz_FYuIygHxf6-HbiomMHwvGn-nd-xW64_aNk=.b82f2796-bfa3-4b3c-b750-e257770dec04@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
 <jJad_byg_l20nlbAZjHDUCadnTNL6FdNmGCTESHyRE0=.d1e86a93-6478-466c-83bf-595d304d7bb8@github.com>
 <WH3ecv0QGys2-QpqltzMyz2jQGi2ZBXOo23JX9PG3GU=.77c2d810-e693-4ec2-888f-41c82094120f@github.com>
 <JSWnv-432jILEA8x1UmCkDXbS40hgNj0MggIBH_Hr6I=.ba870ff9-a6f7-41c4-ba70-615bc7421943@github.com>
 <qX7HHo1DwZMr_k6WQGzHwH-ARtJPDR5Ag08fuhPsmjE=.3003bbd1-f5af-423d-b089-0311a3e7f21e@github.com>
 <D3aZt0yz_FYuIygHxf6-HbiomMHwvGn-nd-xW64_aNk=.b82f2796-bfa3-4b3c-b750-e257770dec04@github.com>
Message-ID: <wXVhp99QB7kchpzHfphICqaOBiUFXHgnv1cCWBgfORA=.072b0edb-0e56-4d6f-a097-ab1396ba4c3f@github.com>

On Fri, 21 Nov 2025 15:46:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> No objections from me to let it stay in the current form then.
>
> `{  }` is use in some man pages pick one from the items from inside the braces.  Maybe `zip-{0..9}` would work here as the `jlink` man page already uses `[ ]` for optional items.

The message showed when running `jlink --help` option mentions `zip-[0-9]`. In my current approach, I kept that implementation aligned with what help would show when running the `jlink --help` command (same approach regarding `jlink --list-plugins` output). 


jlink --help

Possible options include:
      --add-modules <mod>[,<mod>...]    Root modules to resolve in addition to the
                                        initial modules. <mod> can also be ALL-MODULE-PATH.
      --bind-services                   Link in service provider modules and
                                        their dependencies
      --compress <compress>             Compression to use in compressing resources:
                                        Accepted values are:
                                        zip-[0-9], where zip-0 provides no compression,
                                        and zip-9 provides the best compression.
                                        Default is zip-6.
                                        Deprecated values to be removed in a future release:
                                        0:  No compression. Use zip-0 instead.
                                        1:  Constant String Sharing
                                        2:  ZIP. Use zip-6 instead.


I did not intervene over the output of `jlink -- list-plugins`.


jlink --list-plugins

List of available plugins:
  --add-options <options>   Prepend the specified <options> string, which may
                            include whitespace before any other options when
                            invoking the virtual machine in the resulting image.
  --compress <compress>     Compression to use in compressing resources:
                            Accepted values are:
                            zip-[0-9], where zip-0 provides no compression,
                            and zip-9 provides the best compression.
                            Default is zip-6.

Given the situations mentioned above, what do you believe to be the best way forward? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2550691303

From brian.burkhalter at oracle.com  Fri Nov 21 19:08:00 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 21 Nov 2025 19:08:00 +0000
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and
 Verona projects
In-Reply-To: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
References: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
Message-ID: <8D8EA848-AD1B-4C9C-B770-EC12F3AF3223@oracle.com>

Vote: yes

On Nov 20, 2025, at 10:37?PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

I hereby propose that the Core Libraries group withdraw sponsorship of the Device I/O [1], Kona [2], Penrose [3], and Verona [4] projects. These projects have been inactive for a long time:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251121/def38482/attachment.htm>

From jlu at openjdk.org  Fri Nov 21 19:07:26 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 21 Nov 2025 19:07:26 GMT
Subject: RFR: 8368001: java/text/Format/NumberFormat/NumberRoundTrip.java
 timed out [v3]
In-Reply-To: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
References: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
Message-ID: <ckhueDsS5CWPqBr7vgsEj8f3WTFo0QGO89TjJJsyW4c=.ca127cbe-52ec-424f-9f09-fd3ace64ba45@github.com>

> JDK-8260555 exposed test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java as being susceptible to timeouts.
> While the timeout factor is reverted, this test was testing too many inputs, and should be changed. 
> Originally, it was testing (~1000 locales * 4 factories) against ~30 numeric inputs. The test does not need to be exhaustive to this degree.
> 
> The total amount of locales is changed to sample around a 1/4 of those provided by the provider. The numeric inputs are reduced to about ~20. (The fixed ones remain, and the random ones are cut in half.)
> 
> Locally, I observe average execution for this test to be about ~1.3 seconds, compared to ~3.4 seconds previously. The PR also does a drive-by clean up of the test, i.e. getting rid of the unnecessary escaping + string manipulation/printing and separating the test inputs from the actual testing work done.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  terminology correction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28443/files
  - new: https://git.openjdk.org/jdk/pull/28443/files/dca988e7..271dfc78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28443&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28443&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28443/head:pull/28443

PR: https://git.openjdk.org/jdk/pull/28443

From naoto at openjdk.org  Fri Nov 21 19:34:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Nov 2025 19:34:09 GMT
Subject: RFR: 8368001: java/text/Format/NumberFormat/NumberRoundTrip.java
 timed out [v3]
In-Reply-To: <ckhueDsS5CWPqBr7vgsEj8f3WTFo0QGO89TjJJsyW4c=.ca127cbe-52ec-424f-9f09-fd3ace64ba45@github.com>
References: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
 <ckhueDsS5CWPqBr7vgsEj8f3WTFo0QGO89TjJJsyW4c=.ca127cbe-52ec-424f-9f09-fd3ace64ba45@github.com>
Message-ID: <1aQpcTDphKqw4_dfhCdh_lNgT6WSvcZLDmXAjtwIat0=.91bd3b7d-526b-4a2b-ad40-d8b913d39250@github.com>

On Fri, 21 Nov 2025 19:07:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK-8260555 exposed test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java as being susceptible to timeouts.
>> While the timeout factor is reverted, this test was testing too many inputs, and should be changed. 
>> Originally, it was testing (~1000 locales * 4 factories) against ~30 numeric inputs. The test does not need to be exhaustive to this degree.
>> 
>> The total amount of locales is changed to sample around a 1/4 of those provided by the provider. The numeric inputs are reduced to about ~20. (The fixed ones remain, and the random ones are cut in half.)
>> 
>> Locally, I observe average execution for this test to be about ~1.3 seconds, compared to ~3.4 seconds previously. The PR also does a drive-by clean up of the test, i.e. getting rid of the unnecessary escaping + string manipulation/printing and separating the test inputs from the actual testing work done.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   terminology correction

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28443#pullrequestreview-3494104119

From asemenyuk at openjdk.org  Fri Nov 21 19:36:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 19:36:48 GMT
Subject: RFR: 8372359: Clean jpackage error messages [v3]
In-Reply-To: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
References: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
Message-ID: <r1LePAQ1DhAjs0ZgEgMEv0dEjCg7ouDs3Pfc8HVPPIM=.0abce525-986d-41f6-b26b-1949660bcf43@github.com>

> Some jpackage error messages have "Error: " prefix. Some don't. The prefix is redundant as jpackage assembles the error message from the localized "Error: " prefix and localized message body [1]. The prefix was removed. 
> 
> There are error messages specific to jpackage options that duplicate generic error messages. They are:
> 
> **ERR_BuildRootInvalid**
> It duplicates a generic "error.parameter-not-empty-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: temp (foo) must be non-existent or empty directory | The value "foo" provided for parameter --temp is not an empty directory or non existent path |
> 
> **ERR_AppImageNotExist**
> It duplicates a generic "error.parameter-not-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: App image directory "foo" does not exist | The value "foo" provided for parameter --app-image is not a directory |
> 
> **ERR_LicenseFileNotExit**
> It duplicates a generic "error.parameter-not-file" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Specified license file does not exist | The value "foo" provided for parameter --license-file is not a file |
> 
> **ERR_BothMainJarAndModule**
> It duplicates a generic "ERR_MutuallyExclusiveOptions" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Cannot have both --main-jar and --module Options | Mutually exclusive options [--main-jar] and [--module] |
> 
> **ERR_NoAddLauncherName**
> It duplicates a generic "error.parameter-add-launcher-malformed" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |
> 
> Specialized error messages duplicating generic error messages were removed to simplify maintenance.
> 
>  **ERR_MissingArgument**
> ERR_MissingArgument was not referenced in the implementation, but was mistakenly referenced in the tests. It was replaced with ERR_MissingArgument2, and ERR_MissingArgument was removed.
> 
> **error.invalid-option-value**
> "error.invalid-option-value" was used for errors in shortcut launcher options (--win-shortcut, --linux-shortcut), but it is not descriptive. For this reason, it was replaced with the "error.parameter-not-launcher-shortcut-dir".
> 
> | Old error message | New erro...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  OptionsProcessorTest: bugfix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28457/files
  - new: https://git.openjdk.org/jdk/pull/28457/files/36a2267f..39938ec8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28457/head:pull/28457

PR: https://git.openjdk.org/jdk/pull/28457

From naoto at openjdk.org  Fri Nov 21 19:44:18 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Nov 2025 19:44:18 GMT
Subject: RFR: 8372307: Clean up the leftover code comment references to
 file.encoding in java_props_md.c
In-Reply-To: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
References: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
Message-ID: <HrmdtkQmXIRXM_qA9sVE-k6xVp-fQVYUQfB8ATSyuQI=.7d7a746e-7c48-423e-90e4-048fefcc9e21@github.com>

On Fri, 29 Aug 2025 14:25:25 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> The `file.encoding` system property is no longer used by the JDK.
> Updated code comments to reference the correct replacement: `native.encoding`.

The change looks good. However, the description in the PR text:

The file.encoding system property is no longer used by the JDK.

is not correct. `file.encoding` system property is still used. Please correct it.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27004#pullrequestreview-3494130431

From duke at openjdk.org  Fri Nov 21 20:52:14 2025
From: duke at openjdk.org (duke)
Date: Fri, 21 Nov 2025 20:52:14 GMT
Subject: RFR: 8372307: Clean up the leftover code comment references to
 file.encoding in java_props_md.c
In-Reply-To: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
References: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
Message-ID: <boZfWt6zTcSS07LHoRkneMeJEytC5SqBA7uRmA2Q5Lc=.531dc473-9c93-4a4a-a739-be2ffd0a9343@github.com>

On Fri, 29 Aug 2025 14:25:25 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> The `file.encoding` system property is effectively replaced on `native.encoding` (refer [changes](https://github.com/openjdk/jdk/commit/83c7d3bbe860656ee403fa29df6a9e0aae962839))
> Updated code comments to reference the correct replacement: `native.encoding`.

@hextriclosan 
Your change (at version d25c23cca2b4e717daf47403b4963ed5ff26a00b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27004#issuecomment-3564550183

From asemenyuk at openjdk.org  Fri Nov 21 21:15:20 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 21:15:20 GMT
Subject: RFR: 8372359: Clean jpackage error messages [v4]
In-Reply-To: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
References: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
Message-ID: <c9fQE8Nw871xn9GswRpB0ffnc0VkwguFiQBMT6DAy_U=.0d43abb8-e32b-4b54-a238-16f7d07cb183@github.com>

> Some jpackage error messages have "Error: " prefix. Some don't. The prefix is redundant as jpackage assembles the error message from the localized "Error: " prefix and localized message body [1]. The prefix was removed. 
> 
> There are error messages specific to jpackage options that duplicate generic error messages. They are:
> 
> **ERR_BuildRootInvalid**
> It duplicates a generic "error.parameter-not-empty-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: temp (foo) must be non-existent or empty directory | The value "foo" provided for parameter --temp is not an empty directory or non existent path |
> 
> **ERR_AppImageNotExist**
> It duplicates a generic "error.parameter-not-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: App image directory "foo" does not exist | The value "foo" provided for parameter --app-image is not a directory |
> 
> **ERR_LicenseFileNotExit**
> It duplicates a generic "error.parameter-not-file" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Specified license file does not exist | The value "foo" provided for parameter --license-file is not a file |
> 
> **ERR_BothMainJarAndModule**
> It duplicates a generic "ERR_MutuallyExclusiveOptions" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Cannot have both --main-jar and --module Options | Mutually exclusive options [--main-jar] and [--module] |
> 
> **ERR_NoAddLauncherName**
> It duplicates a generic "error.parameter-add-launcher-malformed" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |
> 
> Specialized error messages duplicating generic error messages were removed to simplify maintenance.
> 
>  **ERR_MissingArgument**
> ERR_MissingArgument was not referenced in the implementation, but was mistakenly referenced in the tests. It was replaced with ERR_MissingArgument2, and ERR_MissingArgument was removed.
> 
> **error.invalid-option-value**
> "error.invalid-option-value" was used for errors in shortcut launcher options (--win-shortcut, --linux-shortcut), but it is not descriptive. For this reason, it was replaced with the "error.parameter-not-launcher-shortcut-dir".
> 
> | Old error message | New erro...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Fix unit tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28457/files
  - new: https://git.openjdk.org/jdk/pull/28457/files/39938ec8..750fdeda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=02-03

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28457/head:pull/28457

PR: https://git.openjdk.org/jdk/pull/28457

From asemenyuk at openjdk.org  Fri Nov 21 21:16:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 21:16:53 GMT
Subject: RFR: 8372359: Clean jpackage error messages [v5]
In-Reply-To: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
References: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
Message-ID: <SsJ5qo_ra86Y09gFb3LTmxmJQISvCySHKtY5gfqgXLw=.24b0158d-0904-4466-ad81-1e41ca9c1282@github.com>

> Some jpackage error messages have "Error: " prefix. Some don't. The prefix is redundant as jpackage assembles the error message from the localized "Error: " prefix and localized message body [1]. The prefix was removed. 
> 
> There are error messages specific to jpackage options that duplicate generic error messages. They are:
> 
> **ERR_BuildRootInvalid**
> It duplicates a generic "error.parameter-not-empty-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: temp (foo) must be non-existent or empty directory | The value "foo" provided for parameter --temp is not an empty directory or non existent path |
> 
> **ERR_AppImageNotExist**
> It duplicates a generic "error.parameter-not-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: App image directory "foo" does not exist | The value "foo" provided for parameter --app-image is not a directory |
> 
> **ERR_LicenseFileNotExit**
> It duplicates a generic "error.parameter-not-file" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Specified license file does not exist | The value "foo" provided for parameter --license-file is not a file |
> 
> **ERR_BothMainJarAndModule**
> It duplicates a generic "ERR_MutuallyExclusiveOptions" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Cannot have both --main-jar and --module Options | Mutually exclusive options [--main-jar] and [--module] |
> 
> **ERR_NoAddLauncherName**
> It duplicates a generic "error.parameter-add-launcher-malformed" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |
> 
> Specialized error messages duplicating generic error messages were removed to simplify maintenance.
> 
>  **ERR_MissingArgument**
> ERR_MissingArgument was not referenced in the implementation, but was mistakenly referenced in the tests. It was replaced with ERR_MissingArgument2, and ERR_MissingArgument was removed.
> 
> **error.invalid-option-value**
> "error.invalid-option-value" was used for errors in shortcut launcher options (--win-shortcut, --linux-shortcut), but it is not descriptive. For this reason, it was replaced with the "error.parameter-not-launcher-shortcut-dir".
> 
> | Old error message | New erro...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  StandardOptionTest: remove trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28457/files
  - new: https://git.openjdk.org/jdk/pull/28457/files/750fdeda..591509e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28457/head:pull/28457

PR: https://git.openjdk.org/jdk/pull/28457

From asemenyuk at openjdk.org  Fri Nov 21 21:35:13 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 21 Nov 2025 21:35:13 GMT
Subject: RFR: 8372359: Clean jpackage error messages [v6]
In-Reply-To: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
References: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
Message-ID: <uwzXAlLk-vR2raoQ7TVix_NL_jI9IXLLIYyOhQcbr48=.3222391c-fa06-471c-a44f-23161b5699e0@github.com>

> Some jpackage error messages have "Error: " prefix. Some don't. The prefix is redundant as jpackage assembles the error message from the localized "Error: " prefix and localized message body [1]. The prefix was removed. 
> 
> There are error messages specific to jpackage options that duplicate generic error messages. They are:
> 
> **ERR_BuildRootInvalid**
> It duplicates a generic "error.parameter-not-empty-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: temp (foo) must be non-existent or empty directory | The value "foo" provided for parameter --temp is not an empty directory or non existent path |
> 
> **ERR_AppImageNotExist**
> It duplicates a generic "error.parameter-not-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: App image directory "foo" does not exist | The value "foo" provided for parameter --app-image is not a directory |
> 
> **ERR_LicenseFileNotExit**
> It duplicates a generic "error.parameter-not-file" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Specified license file does not exist | The value "foo" provided for parameter --license-file is not a file |
> 
> **ERR_BothMainJarAndModule**
> It duplicates a generic "ERR_MutuallyExclusiveOptions" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Cannot have both --main-jar and --module Options | Mutually exclusive options [--main-jar] and [--module] |
> 
> **ERR_NoAddLauncherName**
> It duplicates a generic "error.parameter-add-launcher-malformed" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |
> 
> Specialized error messages duplicating generic error messages were removed to simplify maintenance.
> 
>  **ERR_MissingArgument**
> ERR_MissingArgument was not referenced in the implementation, but was mistakenly referenced in the tests. It was replaced with ERR_MissingArgument2, and ERR_MissingArgument was removed.
> 
> **error.invalid-option-value**
> "error.invalid-option-value" was used for errors in shortcut launcher options (--win-shortcut, --linux-shortcut), but it is not descriptive. For this reason, it was replaced with the "error.parameter-not-launcher-shortcut-dir".
> 
> | Old error message | New erro...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  StandardOptionValueExceptionFactory: remove unused code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28457/files
  - new: https://git.openjdk.org/jdk/pull/28457/files/591509e8..6a43d514

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28457&range=04-05

  Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28457/head:pull/28457

PR: https://git.openjdk.org/jdk/pull/28457

From duke at openjdk.org  Fri Nov 21 21:48:26 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Fri, 21 Nov 2025 21:48:26 GMT
Subject: Integrated: 8372307: Clean up the leftover code comment references to
 file.encoding in java_props_md.c
In-Reply-To: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
References: <hrxz_hdGuaVGspuMeWZN-6OLB9Hiq48JK6FAy46PW4U=.f04d25e8-8093-46a1-aa2e-8b3d02123c28@github.com>
Message-ID: <IbUiafH_8mOdAZZ9U5ELIBRAM3kqNxFN4QMdDK0D7Gc=.fa6efca2-e8ed-4c4b-9a53-ab625bfabe10@github.com>

On Fri, 29 Aug 2025 14:25:25 GMT, Igor Rudenko <duke at openjdk.org> wrote:

> The `file.encoding` system property is effectively replaced on `native.encoding` (refer [changes](https://github.com/openjdk/jdk/commit/83c7d3bbe860656ee403fa29df6a9e0aae962839))
> Updated code comments to reference the correct replacement: `native.encoding`.

This pull request has now been integrated.

Changeset: ee9d553e
Author:    Igor Rudenko <iostream64 at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee9d553e51c01529495b8ca34b296b6e684e905d
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8372307: Clean up the leftover code comment references to file.encoding in java_props_md.c

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/27004

From bchristi at openjdk.org  Fri Nov 21 22:08:01 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 21 Nov 2025 22:08:01 GMT
Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize()
 method
In-Reply-To: <PR9ANUi7n23h8pl0rPRa3m45QLAztZlpeBTyUAeQ4QQ=.4b787b72-bea2-4f62-9d60-9a24e4f84125@github.com>
References: <etyYuNVI0YKx9Og84zghOHnxCCX-M7cbqbz2qPPuOPU=.08e04c24-585a-4fc8-9df7-c1c9bc2cb580@github.com>
 <PR9ANUi7n23h8pl0rPRa3m45QLAztZlpeBTyUAeQ4QQ=.4b787b72-bea2-4f62-9d60-9a24e4f84125@github.com>
Message-ID: <hu5qcb7MUH01YUNaBMbGM0CAO8EaNAPCDNE7OvKqDuU=.7659a0c1-371e-457b-83ca-fbdd7f485d14@github.com>

On Fri, 14 Nov 2025 19:39:47 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> From the bug report:
>> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to
>> "[invoke] shutdown() when this executor is no longer referenced and it has no threads."
>> 
>> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)).
>> 
>> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)).
>> 
>> The finalize() method can safely be removed from ThreadPoolExecutor.
>
> Thank you, reviewers. :)
> Can I also get a review on the [CSR](https://bugs.openjdk.org/browse/JDK-8371856)? TIA.

> @bchristi-git Have you done corpus searches yet to see if there are cases that extend TPE and invoke super.finalize?

My Corpus searches found quite a few TPE subclasses, but none of them override finalize or invoke finalize.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3564761293

From sherman at openjdk.org  Fri Nov 21 23:56:05 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 21 Nov 2025 23:56:05 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v10]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <_VpQ_oPGP6BR3DP_ZfSDtevk2cwePjo95duU3NQloOk=.5d80b35b-fc4b-441d-8a0e-9e038047fff5@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:

  doc update - add spec tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/057ea814..0aafb674

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=08-09

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 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 brent.christian at oracle.com  Sat Nov 22 00:20:38 2025
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 21 Nov 2025 16:20:38 -0800
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and
 Verona projects
In-Reply-To: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
References: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
Message-ID: <3f1d9ad2-02d3-48e0-84b2-48fb37d29b26@oracle.com>

Vote: Yes

On 11/20/25 10:37 PM, Alan Bateman wrote:
> 
> I hereby propose that the Core Libraries group withdraw sponsorship of the Device I/O [1], Kona [2], 
> Penrose [3], and Verona [4] projects.

From almatvee at openjdk.org  Sat Nov 22 01:10:55 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 22 Nov 2025 01:10:55 GMT
Subject: RFR: 8372359: Clean jpackage error messages [v6]
In-Reply-To: <uwzXAlLk-vR2raoQ7TVix_NL_jI9IXLLIYyOhQcbr48=.3222391c-fa06-471c-a44f-23161b5699e0@github.com>
References: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
 <uwzXAlLk-vR2raoQ7TVix_NL_jI9IXLLIYyOhQcbr48=.3222391c-fa06-471c-a44f-23161b5699e0@github.com>
Message-ID: <BGr_UJC-nG0wb8GrOxiKg-ymqF2U1ZC4bIzQtpNu7CQ=.a88dcac5-b6cf-4895-b26b-2fa350547807@github.com>

On Fri, 21 Nov 2025 21:35:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Some jpackage error messages have "Error: " prefix. Some don't. The prefix is redundant as jpackage assembles the error message from the localized "Error: " prefix and localized message body [1]. The prefix was removed. 
>> 
>> There are error messages specific to jpackage options that duplicate generic error messages. They are:
>> 
>> **ERR_BuildRootInvalid**
>> It duplicates a generic "error.parameter-not-empty-directory" error message.
>> 
>> | Specialized error message | Generic error message | 
>> | --- | --- |
>> | Error: temp (foo) must be non-existent or empty directory | The value "foo" provided for parameter --temp is not an empty directory or non existent path |
>> 
>> **ERR_AppImageNotExist**
>> It duplicates a generic "error.parameter-not-directory" error message.
>> 
>> | Specialized error message | Generic error message | 
>> | --- | --- |
>> | Error: App image directory "foo" does not exist | The value "foo" provided for parameter --app-image is not a directory |
>> 
>> **ERR_LicenseFileNotExit**
>> It duplicates a generic "error.parameter-not-file" error message.
>> 
>> | Specialized error message | Generic error message | 
>> | --- | --- |
>> | Error: Specified license file does not exist | The value "foo" provided for parameter --license-file is not a file |
>> 
>> **ERR_BothMainJarAndModule**
>> It duplicates a generic "ERR_MutuallyExclusiveOptions" error message.
>> 
>> | Specialized error message | Generic error message | 
>> | --- | --- |
>> | Error: Cannot have both --main-jar and --module Options | Mutually exclusive options [--main-jar] and [--module] |
>> 
>> **ERR_NoAddLauncherName**
>> It duplicates a generic "error.parameter-add-launcher-malformed" error message.
>> 
>> | Specialized error message | Generic error message | 
>> | --- | --- |
>> | Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |
>> 
>> Specialized error messages duplicating generic error messages were removed to simplify maintenance.
>> 
>>  **ERR_MissingArgument**
>> ERR_MissingArgument was not referenced in the implementation, but was mistakenly referenced in the tests. It was replaced with ERR_MissingArgument2, and ERR_MissingArgument was removed.
>> 
>> **error.invalid-option-value**
>> "error.invalid-option-value" was used for errors in shortcut launcher options (--win-shortcut, --linux-shortcut), but it is not descriptive. For this reason, it was re...
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   StandardOptionValueExceptionFactory: remove unused code

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28457#pullrequestreview-3495007676

From huizhe.wang at oracle.com  Sat Nov 22 01:12:53 2025
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 21 Nov 2025 17:12:53 -0800
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and
 Verona projects
In-Reply-To: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
References: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
Message-ID: <0bf8c97a-fc3b-4ec8-b52e-764a43a1f559@oracle.com>

Vote: Yes

On 11/20/25 10:37 PM, Alan Bateman wrote:
> I hereby propose that the Core Libraries group withdraw sponsorship of 
> the Device I/O [1], Kona [2], Penrose [3], and Verona [4] projects.

From syan at openjdk.org  Sat Nov 22 03:59:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Nov 2025 03:59:11 GMT
Subject: RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS
In-Reply-To: <4nOVxCCsXQea7cXWT98OiMZDiK9x9qmu0n19qyuj_eg=.4123cb44-ea93-4d2f-8618-76d3273d5b76@github.com>
References: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>
 <4nOVxCCsXQea7cXWT98OiMZDiK9x9qmu0n19qyuj_eg=.4123cb44-ea93-4d2f-8618-76d3273d5b76@github.com>
Message-ID: <-1KokFdbtaCRAUmRfRhqg6AX-TtFz6EdI_SRTI3UP-s=.c6f83b65-9d2c-4488-b889-212ff204ecdc@github.com>

On Tue, 18 Nov 2025 10:03:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello @sendaoYan, the failure here is because the extracted date/time on the directory does not match the one in the JAR file's entry for that directory (due to the underlying filesystem). Would it be possible to see which part of the JDK code is setting this date on that directory to the Unix epoch time? I haven't had a chance to go over the JAR tool's code in detail.

The JAR file's entry save the correct date/time. 'jar --extract' create the directory through method `void extract(String fname, String[] files)` in jdk.jartool/sun/tools/jar/Main.java:1434, then `ZipEntry extractFile(InputStream is, ZipEntry e)` will call `File.setLastModified(long time)` to change the modify time.  The call shows below.


void extract(String fname, String[] files)
->
ZipEntry extractFile(InputStream is, ZipEntry e)
->
File.setLastModified(long time)
->
java.io.UnixFileSystem.setLastModifiedTime(File f, long time)
->
private native boolean setLastModifiedTime0(File f, long time)
->
Java_java_io_UnixFileSystem_setLastModifiedTime0(JNIEnv *env, jobject this,jobject file, jlong time)
->
linux system call utimes


The linux system call utimes get the correct 64bit modified date/time, but the file system only support 32bit data/time. So the system call utimes set the directory to the Unix epoch time.

The jdk.jartool/sun/tools/jar/Main.java:1524 call File.setLastModified(long time), but do not check the return value. Do this should be improved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3565508983

From duke at openjdk.org  Sat Nov 22 09:59:32 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 22 Nov 2025 09:59:32 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries
In-Reply-To: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
Message-ID: <nvwYppYzUhwlU6YxfsA6D1-NgLM2o2weUhJKvvGU_PU=.d2260e24-5e6c-4804-bada-34ab20f64d8c@github.com>

On Fri, 21 Nov 2025 16:54:48 GMT, Trevor Bond <duke at openjdk.org> wrote:

> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
> 
> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
> 
> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
> 
> | Version | Avg Time (ns/op) | ? vs Before |
> |--------|------------------:|-------------|
> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |

It?might be?better to?make the?previous version?lazy, as?the?new?version requires?pre?parsing the?whole?input, whereas?the?old?version would?only?read the?classfile?header.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28458#issuecomment-3566366203

From duke at openjdk.org  Sat Nov 22 10:20:11 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 22 Nov 2025 10:20:11 GMT
Subject: RFR: 8372258: Improve TypeVariable support
In-Reply-To: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
References: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
Message-ID: <qenWQ1dZUFX1TDmZLbPROVzCpBtOjmJTYDJYW8bFlp4=.ca39c235-5c86-4e99-aef5-ede5021d3fc1@github.com>

On Thu, 20 Nov 2025 13:06:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate.

src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java line 142:

> 140:                 genericDeclaration instanceof Method ||
> 141:                 genericDeclaration instanceof Constructor : "Unexpected kind of GenericDeclaration";
> 142:         // If the `genericDeclaration` instance is mutable, we need to make a copy.

Additionally, the?old?version would?leak the?internal root?`Method` and?`Constructor`?objects.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28429#discussion_r2552861038

From duke at openjdk.org  Sat Nov 22 11:02:50 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Sat, 22 Nov 2025 11:02:50 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries
In-Reply-To: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
Message-ID: <ufbuKUzQ2aPB4fpELwbwjgPO1jXSjgXEaIpHwE19GYA=.b3e90f72-7c0f-4cd8-9672-4ad8aaf4a391@github.com>

On Fri, 21 Nov 2025 16:54:48 GMT, Trevor Bond <duke at openjdk.org> wrote:

> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
> 
> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
> 
> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
> 
> | Version | Avg Time (ns/op) | ? vs Before |
> |--------|------------------:|-------------|
> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |

The new version would always read all classfile bytes, the old one in chunks of 8192 bytes, both stop parsing at this_class position (with or without inflating constant pool entries). 
Maybe the benchmark would not show much difference for typical classfiles (not having thousands of strings). 
But in my eyes removing the logic to parse the constant pool and instead reuse ClassReader is a good thing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28458#issuecomment-3566528520

From syan at openjdk.org  Sat Nov 22 13:28:29 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Nov 2025 13:28:29 GMT
Subject: RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS
In-Reply-To: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>
References: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>
Message-ID: <xeN8f3Bbu5iqQCLSKNuoz7iX2SeFrXhx2pZfgJQqArY=.12ec2ed6-8295-4d55-bee3-3ebd871860fe@github.com>

On Tue, 18 Nov 2025 08:24:13 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test tools/jar/ReproducibleJar.java fails when running on a file system that only supports to 2038(e.g. XFS).
> 
> Before this PR, test check if the input test time after "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to "2038-01-19T03:14:07Z", then test will skip that check.
> 
> But the extraced time created by jar equal to "1970-01-01T00:00:00Z" actually. I think the extracted time set to unix epoch time is acceptable, so this PR fix the test make test check skip when the extracted time is unix epoch time.
> 
> Change has been verified locally on XFS file system and ext4 file system.

I create a demo to explain what utimes linux system call works on XFS file system.

When the time value bigger or equals the maximum of signed integer, then the time will set to UNIX epoch time.


#include <stdio.h>
#include <sys/time.h>
#include <time.h>
#include <stdlib.h>

int main(int argc, char** argv) {
    if (argc != 3) {
        printf("usage: ./a.out file seconds\n");
        return 1;
    }
    const char *filename = argv[1];
    struct timeval times[2];
    long time = atol(argv[2]);

    times[0].tv_sec = time;  // atime
    times[0].tv_usec = 0;
    
    times[1].tv_sec = time;  // mtime
    times[1].tv_usec = 0;
    
    int ret = utimes(filename, times);
    printf("utimes to file %s as %ld return code is %d\n", filename, time, ret);
    
    return 0;
}


Test command and result:


> gcc -Wall -Wextra ~/compiler-test/zzkk/utimes-test.c ; ./a.out a.out 2147483646 ; stat --format %y a.out
utimes to file a.out as 2147483646 return code is 0
2038-01-19 11:14:06.000000000 +0800
> gcc -Wall -Wextra ~/compiler-test/zzkk/utimes-test.c ; ./a.out a.out 2147483647 ; stat --format %y a.out
utimes to file a.out as 2147483647 return code is 0
1970-01-01 08:00:00.000000000 +0800

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3566713777

From shaojin.wensj at alibaba-inc.com  Sat Nov 22 16:03:07 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Sun, 23 Nov 2025 00:03:07 +0800
Subject: =?UTF-8?B?SW1wcm92ZSBEYXRlVGltZUZvcm1hdHRlciBwZXJmb3JtYW5jZSBieSB1bnJvbGxpbmcgZm9y?=
 =?UTF-8?B?bWF0dGluZy9wYXJzaW5nIGxvb3Bz?=
Message-ID: <9a1879ac-36b1-4485-a3da-acaae0097cc3.shaojin.wensj@alibaba-inc.com>

When we run the format and parse of java.time.DateTimeFormatter using `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining`, we can see the following output:
```
@ 40 j.t.f.DTFB$CompositePrinterParser::format (116 bytes) inline (hot)
 @ 1 f.l.StringBuilder::length (5 bytes) inline (hot)
 @ 1 j.l.AbstractStringBuilder::length (5 bytes) accessor
 @ 48 f.t.f.DTFB$DateTimePrinterParser::format (0 bytes) failed to inline: virtual call
```
```
@ 37 j.t.f.DTFB$CompositePrinterParser::parse (135 bytes) inline (hot)
 @ 114 j.t.f.DTFB$DateTimePrinterParser::parse (0 bytes) failed to inline: virtual call
```
As seen in this log, both the DateTimeFormatterBuilder$CompositePrinterParser::format and DateTimeFormatterBuilder$CompositePrinterParser::parse methods are `failed to inline: virtual call`. We can eliminate this inline failure by manually unrolling the loop.
Once manually unrolled, inline optimizations can work, enabling optimizations like TypeProfile to take effect and thus improve performance.
Below is the log output after manually unrolling the loop:
```
@ 41 j.t.f.DTFB$CompositePrinterParser::format (40 bytes) inline (hot)
 @ 1 j.l.StringBuilder::length (5 bytes) inline (hot)
 @ 1 j.l.AbstractStringBuilder::length (5 bytes) accessor
 @ 22 j.t.f.DateTimePrinterParserFactory$$Lambda/0x00000ff801009df8::format (11 bytes) inline (hot) 
 callee changed to j.t.f.DTFB$CompositePrinterParser::format (40 bytes)
 \-> TypeProfile (6212/6212 counts) = j/t/f/DateTimePrinterParserFactory$$Lambda+0x00000ff801009df8
 @ 7 j.t.f.DateTimePrinterParserFactory::lambda$createFormatter$11 (195 bytes) inline (hot)
 @ 6 j.t.f.DTFB$NumberPrinterParser::format (399 bytes) failed to inline: hot method too big 
 callee changed to j.t.f.DateTimePrinterParserFactory::lambda$createFormatter$11 (195 bytes) 
 \-> TypeProfile (7170/7170 counts) = j/t/f/DTFB$NumberPrinterParser
 @ 20 j.t.f.DTFB$CharLiteralPrinterParser::format (11 bytes) inline (hot) 
 callee changed to j.t.f.DateTimePrinterParserFactory::lambda$createFormatter$11 (195 bytes) 
 \-> TypeProfile (7170/7170 counts) = j/t/f/DateTimeFormatterBuilder$CharLiteralPrinterParser
```
```
 @ 37 j.t.f.DTFB$CompositePrinterParser::parse (13 bytes) inline (hot)
 @ 7 j.t.f.DateTimePrinterParserFactory$$Lambda/0x000000800100a950::parse (11 bytes) inline (hot)
 callee changed to j.t.f.DTFB$CompositePrinterParser::parse (13 bytes) 
 \-> TypeProfile (130649/130649 counts) = j/t/f/DateTimePrinterParserFactory$$Lambda+0x000000800100a950
 @ 7 j.t.f.DateTimePrinterParserFactory::lambda$createParser$9 (217 bytes) inline (hot)
 @ 6 j.t.f.DTFB$NumberPrinterParser::parse (609 bytes) failed to inline: hot method too big
 callee changed to j.t.f.DateTimePrinterParserFactory::lambda$createParser$9 (217 bytes)
 \-> TypeProfile (130884/130884 counts) = j/t/f/DTFB$NumberPrinterParser
 @ 26 j.t.f.DTFB$CharLiteralPrinterParser::parse (91 bytes) inline (hot)
 callee changed to j.t.f.DateTimePrinterParserFactory::lambda$createParser$9 (217 bytes) 
 \-> TypeProfile (130884/130884 counts) = j/t/f/DTFB$CharLiteralPrinterParser
```
We see that the format and parse methods of both NumberPrinterParser and CharLiteralPrinterParser trigger TypeProfile optimization. 
We can choose to generate the code for the unrolling loop based on MethodHandle, the ClassFile API, or Gensrc.gmk. Using MethodHandle or the ClassFile API will make the code obscure and difficult to understand. I recommend using Gensrc.gmk. One advantage of Gensrc.gmk is that the initial performance is better than other implementations.
To better express my ideas, I submitted a draft PR: https://github.com/openjdk/jdk/pull/28465 <https://github.com/openjdk/jdk/pull/28465 >, and I hope you can give me feedback.
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251123/8d04a450/attachment.htm>

From duke at openjdk.org  Sat Nov 22 23:04:00 2025
From: duke at openjdk.org (Piotr Tarsa)
Date: Sat, 22 Nov 2025 23:04:00 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3]
In-Reply-To: <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
Message-ID: <mujB3n7hJNyuspKCEmPUU8dpPyY4lsKX0wP879CdwcM=.467c327e-f211-48df-a558-92772023c57d@github.com>

On Wed, 22 Oct 2025 21:06:04 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> The goal of the PR is to improve both, sequential and parallel, sorting of primitives.
>> 
>> **The main achievements**
>> 
>> - introduced Radix in parallel sorting which shows several times boost of performance and has linear complexity instead of n*ln(n)
>> - improved mixed insertion sort (makes whole sorting faster)
>> - improved merging sort for almost sorted data
>> - optimized parallel sorting
>> - improved step for pivot candidates and pivot partitioning
>> - suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError
>> - minor javadoc and comment changes
>> 
>> - extended existing tests
>> - added tests for radix sort, heap sort, insertion sort
>> - added benchmarking JMH tests
>> - improved test coverage
>> 
>> **The summary of benchmarking:**
>> 
>> **Sequential sorting (Arrays.sort)**
>> 
>> byte: up to 50% faster
>> char: 4-7 times faster
>> short: 2-6 times faster
>> int: 1.2-5 times faster
>> long: 1.2-5 times faster
>> float: 1.2-5 times faster
>> double: 1.2-4 times faster
>> 
>> **Parallel sorting (Arrays.parallelSort)**
>> 
>> int: 1.2-9 times faster
>> long: 1.2-9 times faster
>> float: 1.2-4 times faster
>> double: 1.2-4 times faster
>> 
>> **AVX512 support**
>> 
>> Vamsi Parasa suggested faster sort routines by taking advantage of AVX512 instructions, see https://github.com/openjdk/jdk/pull/14227, sources of sorting were modified. Therefore, I performed benchmarking of the final version (which includes optimizations by Vamsi Parasa and optimizations from my side) on a server with CPUs supported AVX512 instructions, no regression of performance was found, see detailed benchmarking results.
>> 
>> **High-level chart showing how the actual sorting algorithm is selected
>> based on parallel/sequential and input size**
>> 
>> **int/long/float/double**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => [ mixed ] insertion sort
>> if array is almost sorted and size > MIN_MERGING_SORT_SIZE(=512) => merging sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => heap sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **byte**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> else => counting sort
>> 
>> **char/short**
>> 
>> if size > MIN_COUNTING_SORT_SIZE(640) => counting sort
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => counting sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **parallel sorting (int/lo...
>
> Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements
>   
>   * Added @java.io.Serial
>   * Added information about the best data types for thresholds of sorting
>   * Added comments about native implementation based on AVX512 instructions

Could the duplication be reasonably reduced by using code templates like the ones in Vector API https://github.com/search?q=repo%3Aopenjdk%2Fjdk+path%3A*.java.template+path%3Asrc%2Fjdk.incubator.vector&type=code ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3567122123

From liach at openjdk.org  Sun Nov 23 02:28:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 23 Nov 2025 02:28:50 GMT
Subject: RFR: 8372258: Improve TypeVariable support
In-Reply-To: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
References: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
Message-ID: <aDWU6OoH--T_foWqmb1MtV5mDFe_1-Tdo7222HdNOLk=.9a5637b9-fa9a-4148-8f0e-82c70640fe20@github.com>

On Thu, 20 Nov 2025 13:06:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate.

The CSR should address the specification change on `java.lang.reflect.TypeVariable` instead of on `TypeVariableImpl`.

-------------

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28429#pullrequestreview-3497324775

From jbhateja at openjdk.org  Sun Nov 23 11:50:08 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 23 Nov 2025 11:50:08 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v2]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <LReM4-4El55LtXux3Oz2JEVfoIw3p_aGX7fOJrPNKRs=.a64a0d0b-ad33-4fd5-95d3-74f318d61cc3@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added HalffloatVector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Cleaning up interface as per review suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/c60d533c..ea3ef19b

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=00-01

  Stats: 162997 lines in 187 files changed: 75266 ins; 74548 del; 13183 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From duke at openjdk.org  Sun Nov 23 21:08:40 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Sun, 23 Nov 2025 21:08:40 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3]
In-Reply-To: <mujB3n7hJNyuspKCEmPUU8dpPyY4lsKX0wP879CdwcM=.467c327e-f211-48df-a558-92772023c57d@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
 <mujB3n7hJNyuspKCEmPUU8dpPyY4lsKX0wP879CdwcM=.467c327e-f211-48df-a558-92772023c57d@github.com>
Message-ID: <_YDFCCzBRUrC3HxSy_20UstPMqJXJbq3LHS6dFrzVJs=.f0081713-fde2-42f5-9495-9d8b23cdb6b3@github.com>

On Sat, 22 Nov 2025 23:00:44 GMT, Piotr Tarsa <duke at openjdk.org> wrote:

> Could the duplication be reasonably reduced by using code templates like the ones in Vector API https://github.com/search?q=repo%3Aopenjdk%2Fjdk+path%3A*.java.template+path%3Asrc%2Fjdk.incubator.vector&type=code ?

Hi [tarsa](https://github.com/tarsa),
Thank you for your advice, it should really help to easier support and modify the sorting class.
Could you please point to the documentation related to templates?
For example, if I use $type$ in code, how can I specify that $type$ is one of int, long, float, double only?
How can I generate sources from the template?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3568335648

From duke at openjdk.org  Sun Nov 23 21:13:47 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Sun, 23 Nov 2025 21:13:47 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3]
In-Reply-To: <VlAq2Q61T2hRpqjjueeoA7GRttajxd6EdD8tRfxQMWQ=.12e877ce-262b-40fa-b710-1af3a0d10e11@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
 <VlAq2Q61T2hRpqjjueeoA7GRttajxd6EdD8tRfxQMWQ=.12e877ce-262b-40fa-b710-1af3a0d10e11@github.com>
Message-ID: <No8nJU-h14fnd78eGGvkUZAbQX5zivMeCmAhX7yrZXI=.738403bd-113e-4f19-9f4a-55ba142eab2b@github.com>

On Fri, 21 Nov 2025 13:47:16 GMT, Doug Lea <dl at openjdk.org> wrote:

> The structure intrinsically gets more complicated and harder to read as options and sub-options increase -- 6 kinds of sorts, some with parallel and/or SIMD, some only applying to some element types, almost all of them with incremental improvements. I think the attempts to better organize these is OK, but the main DualPiviotQuicksort should include a brief account similar to the wording in the PR intro to better explain how the dispatching criteria and logic. And perhaps a summary of constants and thresholds, with notes on sensitivity of values.

Hello, @DougLea!
I will add more words about the logic of sorting into the javadoc of DualPivotQuicksort class. Thank you for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3568341081

From dl at openjdk.org  Sun Nov 23 22:26:34 2025
From: dl at openjdk.org (Doug Lea)
Date: Sun, 23 Nov 2025 22:26:34 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v18]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <tWFCp6qeGScdt8Ht0pd9G98TTasBk1JYHm_dRbPUTBQ=.21a27bb1-619c-4655-ac08-f47c88b1802a@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Drop added Contended region; simplify accordingly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/40a624e1..891eff05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=16-17

  Stats: 74 lines in 1 file changed: 12 ins; 7 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From duke at openjdk.org  Mon Nov 24 00:00:45 2025
From: duke at openjdk.org (Piotr Tarsa)
Date: Mon, 24 Nov 2025 00:00:45 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3]
In-Reply-To: <_YDFCCzBRUrC3HxSy_20UstPMqJXJbq3LHS6dFrzVJs=.f0081713-fde2-42f5-9495-9d8b23cdb6b3@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
 <mujB3n7hJNyuspKCEmPUU8dpPyY4lsKX0wP879CdwcM=.467c327e-f211-48df-a558-92772023c57d@github.com>
 <_YDFCCzBRUrC3HxSy_20UstPMqJXJbq3LHS6dFrzVJs=.f0081713-fde2-42f5-9495-9d8b23cdb6b3@github.com>
Message-ID: <EHN0b15uTcMzVurZAS2vz1mhXtHkY-I-6KjhnT3ImiY=.fb736235-43dc-495e-866b-ef54334da3ca@github.com>

On Sun, 23 Nov 2025 21:05:19 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

> > Could the duplication be reasonably reduced by using code templates like the ones in Vector API https://github.com/search?q=repo%3Aopenjdk%2Fjdk+path%3A*.java.template+path%3Asrc%2Fjdk.incubator.vector&type=code ?
> 
> Hi [tarsa](https://github.com/tarsa), Thank you for your advice, it should really help to easier support and modify the sorting class. Could you please point to the documentation related to templates? For example, if I use t y p e in code, how can I specify that t y p e is one of int, long, float, double only? How can I generate sources from the template?

it seems that the templates are based on [build.tools.spp.Spp](https://github.com/openjdk/jdk/blob/master/make/jdk/src/classes/build/tools/spp/Spp.java) tool. usage examples can be found on: https://github.com/search?q=repo%3Aopenjdk%2Fjdk+%22spp.Spp%22&type=code

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3568481841

From duke at openjdk.org  Mon Nov 24 09:13:09 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 24 Nov 2025 09:13:09 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries
In-Reply-To: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
Message-ID: <jL_pQyxfoNV2p-jrWmDDaKsFkkBkhM7u8tnkRmmWGX4=.eda3f887-61e3-46f4-b749-a2db53999358@github.com>

On Fri, 21 Nov 2025 16:54:48 GMT, Trevor Bond <duke at openjdk.org> wrote:

> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
> 
> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
> 
> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
> 
> | Version | Avg Time (ns/op) | ? vs Before |
> |--------|------------------:|-------------|
> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |

Maybe?`ClassReader` could?be?updated to?have a?version which?lazily?uses an?`InputStream`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28458#issuecomment-3569660591

From galder at openjdk.org  Mon Nov 24 09:28:33 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 24 Nov 2025 09:28:33 GMT
Subject: Integrated: 8372119: Missing copyright header in MinMaxVector
In-Reply-To: <QgQzaCpP8hWV8jnYHb-asJJFASYygMjGdiZdwEJ-0pg=.8671d8ed-82ae-4fc8-ba3f-02966666fc28@github.com>
References: <QgQzaCpP8hWV8jnYHb-asJJFASYygMjGdiZdwEJ-0pg=.8671d8ed-82ae-4fc8-ba3f-02966666fc28@github.com>
Message-ID: <ug7gqbCoSNHBPBBdrJeTLLFs5z2z3Jrwf0UE7uUB94c=.e1bae5f6-1f91-4fae-9be5-0fb1adc62554@github.com>

On Wed, 19 Nov 2025 09:07:22 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> Trivial PR to add missing copyright header in JMH benchmark.

This pull request has now been integrated.

Changeset: a7bb99ed
Author:    Galder Zamarre?o <galder at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7bb99ed007f593783ff8ca00b26f48d9ad632d2
Stats:     23 lines in 1 file changed: 23 ins; 0 del; 0 mod

8372119: Missing copyright header in MinMaxVector

Reviewed-by: chagedorn, thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/28387

From sgehwolf at openjdk.org  Mon Nov 24 09:47:24 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 24 Nov 2025 09:47:24 GMT
Subject: RFR: 8372155: ReleaseInfoPlugin doesn't handle input file as UTF-8
 properly [v4]
In-Reply-To: <ZoTNBHIsGNTInIqUkjjf_TTbWaIh8-T7Zi1cYTKDkBk=.ed7e30ec-1a11-49ed-9409-4de906d1eecf@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <ZoTNBHIsGNTInIqUkjjf_TTbWaIh8-T7Zi1cYTKDkBk=.ed7e30ec-1a11-49ed-9409-4de906d1eecf@github.com>
Message-ID: <J8e-cEZcSAyCzHg1WZ6MViEsRhqDRkjG0rrx0z_OqA8=.517a66f1-c96e-47bb-b68e-6014205770b0@github.com>

On Thu, 20 Nov 2025 15:24:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
>> 
>> Testing:
>> - [x] GHA
>> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright updates.

Any more input on this one? I'd appreciate a review. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3569801799

From cushon at openjdk.org  Mon Nov 24 09:51:42 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 24 Nov 2025 09:51:42 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v13]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <OxFkXFJpY0zj0jVvcx99tWlV06eG-4GVDvrfRrVdUFQ=.eeea6b4a-3cc9-439d-b6ba-22ae87b2f7fd@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:

 - Update discussion of truncated reads of strings containing \0
 - Return the number of copied bytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/3b206ec0..396f9426

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=11-12

  Stats: 27 lines in 5 files changed: 9 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From cushon at openjdk.org  Mon Nov 24 09:51:43 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 24 Nov 2025 09:51:43 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v12]
In-Reply-To: <Azw8uh7ppASBsB3OOjdLj-98TJazhBZ3pvfzwSyfAW4=.2f5e8473-bcfa-4771-8b21-db396abc75e3@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Azw8uh7ppASBsB3OOjdLj-98TJazhBZ3pvfzwSyfAW4=.2f5e8473-bcfa-4771-8b21-db396abc75e3@github.com>
Message-ID: <9jQNB8VUwW6jC53uBwp5x8awio3_X1kQ48QkfQHHHsM=.daf137ab-7f85-4378-bd33-144addb93d1e@github.com>

On Fri, 21 Nov 2025 14:57:37 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More javadoc updates

I'd like to suggest some additional changes:

I updated the warnings about truncated reads of strings containing `\0` to mention `MemorySegment#getString(long, Charset, long)` (see discussion here: https://github.com/openjdk/jdk/pull/28043#discussion_r2549972828)

I realized `StringSupport#copyBytes` was returning the wrong number of written bytes (`string.length()` vs. `numChars`), but also the return value wasn't being used anywhere.

I consolidated the copies of `copyBytes` in `StringSupport`. This means that for the case that doesn't need `srcIndex`/`numChars` there's a call to `String#substring`, but substring has a fast path to return the entire string, and I think that probably isn't worth micro-optimizing away.

I have tentatively updated the new `MemorySegment#copy` to return the number of bytes that were written. As we have discussed, the encoded length of a string isn't trivial to compute. Since `MemorySegment#copy` has to find out the length anyways, I think this is valuable information to return to the caller. The uses of the underlying `copyBytes` method in `StringSupport` are evidence of this, it needs to know the number of bytes written to write the null terminator at the correct position. Returning a length from the new copy method isn't consistent with existing overloads of `copy`, though. For many of those the number of bytes written is obvious, so although it's inconsistent I think it's defensible. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3569807201

From jpai at openjdk.org  Mon Nov 24 09:57:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Nov 2025 09:57:18 GMT
Subject: RFR: 8372155: ReleaseInfoPlugin doesn't handle input file as UTF-8
 properly [v4]
In-Reply-To: <ZoTNBHIsGNTInIqUkjjf_TTbWaIh8-T7Zi1cYTKDkBk=.ed7e30ec-1a11-49ed-9409-4de906d1eecf@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <ZoTNBHIsGNTInIqUkjjf_TTbWaIh8-T7Zi1cYTKDkBk=.ed7e30ec-1a11-49ed-9409-4de906d1eecf@github.com>
Message-ID: <tdWsZsL0wMHLTvxuf2OyZ8qAoljX1VhSwmHOLb0fByk=.0d76e732-d5df-42df-98c9-ff6e7828d531@github.com>

On Thu, 20 Nov 2025 15:24:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
>> 
>> Testing:
>> - [x] GHA
>> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright updates.

Please wait for Alan's/Roger's review before integrating.

Hello Severin, the changes this PR looks good to me. Should anything be specified/noted for the encoding of the key/value of the release-info plugin?


--release-info <key1>=<value1>

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28399#pullrequestreview-3499404923
PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3569844081

From pminborg at openjdk.org  Mon Nov 24 10:03:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 24 Nov 2025 10:03:16 GMT
Subject: RFR: 8372258: Improve TypeVariable support [v2]
In-Reply-To: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
References: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
Message-ID: <Rr2yCD1TNZBzl3FEpHmhH5EJSomZndcuJHTTtxEQf5w=.1fedc059-3cc3-433a-ad3b-7c277cf3457a@github.com>

> The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Change docs for TypeVaiable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28429/files
  - new: https://git.openjdk.org/jdk/pull/28429/files/ebe0b8aa..ba7f093f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28429&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28429&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28429/head:pull/28429

PR: https://git.openjdk.org/jdk/pull/28429

From sgehwolf at openjdk.org  Mon Nov 24 10:22:42 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 24 Nov 2025 10:22:42 GMT
Subject: RFR: 8372155: ReleaseInfoPlugin doesn't handle input file as UTF-8
 properly [v4]
In-Reply-To: <tdWsZsL0wMHLTvxuf2OyZ8qAoljX1VhSwmHOLb0fByk=.0d76e732-d5df-42df-98c9-ff6e7828d531@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <ZoTNBHIsGNTInIqUkjjf_TTbWaIh8-T7Zi1cYTKDkBk=.ed7e30ec-1a11-49ed-9409-4de906d1eecf@github.com>
 <tdWsZsL0wMHLTvxuf2OyZ8qAoljX1VhSwmHOLb0fByk=.0d76e732-d5df-42df-98c9-ff6e7828d531@github.com>
Message-ID: <l5SL8HuXooEHGOAjL7-f6ayrGDHwnHJQrNJ7Q6g0sjk=.55e9d44a-3863-4279-b57b-34176a8cc6e8@github.com>

On Mon, 24 Nov 2025 09:54:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Should anything be specified/noted for the encoding of the key/value of the release-info plugin?
> 
> ```
> --release-info <key1>=<value1>
> ```

I don't think so. In my testing on Linux with `en_US.UTF-8` `LANG` those are working fine:


$ ./jdk/bin/jlink --add-modules java.base --output ./build/testme --release-info 'add:myval=??a?? oy'
$ grep myval ./build/testme/release 
myval=??a?? oy
$ locale | grep LANG
LANG=en_US.UTF-8

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28399#issuecomment-3569958109

From vklang at openjdk.org  Mon Nov 24 10:33:39 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 10:33:39 GMT
Subject: Integrated: 8372256 : ClassCastException in `ConcurrentHashMap#equals`
In-Reply-To: <skahHn9VJqGmNYf3x8voICY0zCtgaITwAnu3XmkO-So=.50dcd45b-2434-4330-bf3b-77b1056a89f6@github.com>
References: <skahHn9VJqGmNYf3x8voICY0zCtgaITwAnu3XmkO-So=.50dcd45b-2434-4330-bf3b-77b1056a89f6@github.com>
Message-ID: <9YpUUYvqx1b_NOVnteNO_dinHquhO9-WQRXVDpwM8EA=.6978310e-2f21-4c71-bc19-890ebbf137d1@github.com>

On Fri, 21 Nov 2025 14:37:57 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adding logic to handle CCEs and NPEs (the latter cannot logically occur as CHM does not support null keys) as per [AbstractMap::equals](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/AbstractMap.java#L474)

This pull request has now been integrated.

Changeset: 0c1ef366
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c1ef366686b7ff1b461e2617f7f3b7a71467c04
Stats:     32 lines in 2 files changed: 27 ins; 0 del; 5 mod

8372256: ClassCastException in `ConcurrentHashMap#equals`

Reviewed-by: dl, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/28453

From mli at openjdk.org  Mon Nov 24 11:56:26 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 24 Nov 2025 11:56:26 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v6]
In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
Message-ID: <7kh5C9nj7bf6432cG35kDDvV6zhnKEspe8AcYetJ1do=.e1d9ebd3-d80d-4621-8c1e-c77dc721d0df@github.com>

> Hi,
> 
> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
> 
> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
> 
> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
> 
> # Test
> ## Jtreg
> 
> in progress...
> 
> ## Performance
> 
> Column names meanings:
> * p: with patch
> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> * m: without patch
> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> 
> #### Average improvement
> 
> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
> 
> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
> -- | -- | -- | --
> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
> 
> </google-sheets-html-origin>

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  fix is_unordered

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28309/files
  - new: https://git.openjdk.org/jdk/pull/28309/files/572a7b74..46b32186

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28309/head:pull/28309

PR: https://git.openjdk.org/jdk/pull/28309

From mli at openjdk.org  Mon Nov 24 11:56:31 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 24 Nov 2025 11:56:31 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v5]
In-Reply-To: <e-cr2nWjEbroDXpPIQWcc7UbPPXJ7jH-DxSeaxb3l8k=.52137cfa-a26f-45a5-97c0-2e7b76fe47ca@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <ny8egKqL-RZlT-kK96j2sFcF-O7TG3G30Gdp6EVWwvc=.a1d4ecd4-8765-424b-bd86-bee4a1136ba5@github.com>
 <e-cr2nWjEbroDXpPIQWcc7UbPPXJ7jH-DxSeaxb3l8k=.52137cfa-a26f-45a5-97c0-2e7b76fe47ca@github.com>
Message-ID: <iIVMwIJeTXArOamGpOzUmRzWiyWnFHJoBCm3BZXc8zg=.ddeddd66-49b0-41a7-a965-1d2ec5ac5873@github.com>

On Fri, 21 Nov 2025 03:35:03 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   replace assert with log_warning
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1590:
> 
>> 1588:     // jump if cmp1 < cmp2 or either is NaN
>> 1589:     // not jump (i.e. move src to dst) if cmp1 >= cmp2
>> 1590:     float_blt(cmp1, cmp2, no_set);
> 
> I compared this with the existing `MacroAssembler::cmov_cmp_fp_ge` [1] and I witnessed some difference in the case of `NaN` handling. In `MacroAssembler::cmov_cmp_fp_ge`, we set the `is_unordered` param to true when calling `float_blt` or `double_blt`, which is not the case here. I assume we need similar handling here as well, right?
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L1338

Make sense, fixed.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1636:
> 
>> 1634:     // jump if cmp1 <= cmp2 or either is NaN
>> 1635:     // not jump (i.e. move src to dst) if cmp1 > cmp2
>> 1636:     float_ble(cmp1, cmp2, no_set);
> 
> Same question here.

Make sense, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2556004073
PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2556004423

From ssarathi at openjdk.org  Mon Nov 24 12:40:10 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Mon, 24 Nov 2025 12:40:10 GMT
Subject: RFR: 8372399: Add missing CPE statements
Message-ID: <lv0BZ7RURfvASy1O-YjegG6_dbjRUmeNvzh2w56qQhU=.b24de879-ade7-4439-951c-625e07d7e0c8@github.com>

Adds missing Classpath Exception statements
JDK Issue: [JDK-8372399](https://bugs.openjdk.org/browse/JDK-8372399)

-------------

Commit messages:
 - Adds missing CPE statement

Changes: https://git.openjdk.org/jdk/pull/28474/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28474&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372399
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28474/head:pull/28474

PR: https://git.openjdk.org/jdk/pull/28474

From duke at openjdk.org  Mon Nov 24 13:26:30 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 24 Nov 2025 13:26:30 GMT
Subject: RFR: 8372410: VarHandle wrongly uses int parameter on VirtualThread
 creation
Message-ID: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>

This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)

The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068

which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):

Benchmark                                                                Mode  Cnt   Score   Error  Units
VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op

where the `right` indy shows:
<img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />

vs the `wrong` one:
<img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />

-------------

Commit messages:
 - VarHandle wrongly uses int parameter on VirtualThread creation

Changes: https://git.openjdk.org/jdk/pull/28475/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372410
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28475/head:pull/28475

PR: https://git.openjdk.org/jdk/pull/28475

From alanb at openjdk.org  Mon Nov 24 13:46:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Nov 2025 13:46:25 GMT
Subject: RFR: 8372410: VarHandle wrongly uses int parameter on
 VirtualThread creation
In-Reply-To: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
Message-ID: <52oXiLrPla0VCDBhsK2GN-A6JdN7Cx7Wz1DkPxDcaEk=.7f2c9011-3fd1-4e1e-a503-8016199e7db0@github.com>

On Mon, 24 Nov 2025 13:05:40 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
> 
> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
> 
> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
> 
> Benchmark                                                                Mode  Cnt   Score   Error  Units
> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
> 
> where the `right` indy shows:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
> 
> vs the `wrong` one:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />

Good find, the bug has been removed to the right now, can you update the title on the PR to match the JBS issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3570854291

From rriggs at openjdk.org  Mon Nov 24 14:25:41 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Nov 2025 14:25:41 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v10]
In-Reply-To: <_VpQ_oPGP6BR3DP_ZfSDtevk2cwePjo95duU3NQloOk=.5d80b35b-fc4b-441d-8a0e-9e038047fff5@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <_VpQ_oPGP6BR3DP_ZfSDtevk2cwePjo95duU3NQloOk=.5d80b35b-fc4b-441d-8a0e-9e038047fff5@github.com>
Message-ID: <hdJ7_AF_oph9PIJ5LEKVxm2u8Dp0x8zOPg9mMUZcEx0=.5fbf794d-01ef-46fa-80eb-24e06fabdf9b@github.com>

On Fri, 21 Nov 2025 23:56:05 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:
> 
>   doc update - add spec tag

Looks good, a couple of javadoc formatting changes would clean up the formatted javadoc.

src/java.base/share/classes/java/lang/String.java line 2243:

> 2241:      * per-character mapping performed by {@code equalsIgnoreCase}.
> 2242:      * For example:
> 2243:      * <pre>{@snippet lang=java :

<pre> and </pre> are unnecessary, @snippet handles the formatting.

src/java.base/share/classes/java/lang/String.java line 2445:

> 2443:      * {@code compareToIgnoreCase}.
> 2444:      * For example:
> 2445:      * <pre>{@snippet lang=java :

<pre> and </pre> are redundant and should be removed.  @snippet handles all the formatting.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3500569860
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2556436806
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2556430920

From alanb at openjdk.org  Mon Nov 24 14:36:24 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Nov 2025 14:36:24 GMT
Subject: RFR: 8370887: DelayScheduler.replace method may break the 4-ary heap
 in certain scenarios
Message-ID: <_veOR6nBK5qZz30ocpfk3ue0Kc2NwzO-0K2WlBZ4a54=.f6976469-a984-42e0-83a3-a48e8312f3f3@github.com>

DelayScheduler.replace missing check to sift up when replaced with smaller value. checkHeap checks invariants when replacing. Executing tests with make run-test or other targets runs tests with -esa so assume is enabled.

New regression test to ensure delayed tests executes in expected delay order.

-------------

Commit messages:
 - Test improvements
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/28469/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370887
  Stats: 199 lines in 2 files changed: 181 ins; 8 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28469/head:pull/28469

PR: https://git.openjdk.org/jdk/pull/28469

From vklang at openjdk.org  Mon Nov 24 14:36:29 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 14:36:29 GMT
Subject: RFR: 8370887: DelayScheduler.replace method may break the 4-ary
 heap in certain scenarios
In-Reply-To: <_veOR6nBK5qZz30ocpfk3ue0Kc2NwzO-0K2WlBZ4a54=.f6976469-a984-42e0-83a3-a48e8312f3f3@github.com>
References: <_veOR6nBK5qZz30ocpfk3ue0Kc2NwzO-0K2WlBZ4a54=.f6976469-a984-42e0-83a3-a48e8312f3f3@github.com>
Message-ID: <kIG4yLuj3KoynrtyiNJIsJ-z21Ziu0U1LdCCZ6Nrs6A=.4addf7ff-d3ff-4fa4-83dc-dee5e62a4368@github.com>

On Sun, 23 Nov 2025 08:08:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> DelayScheduler.replace missing check to sift up when replaced with smaller value. checkHeap checks invariants when replacing. Executing tests with make run-test or other targets runs tests with -esa so assume is enabled.
> 
> New regression test to ensure delayed tests executes in expected delay order.

src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 401:

> 399:             }
> 400:         }
> 401:         assert checkHeap(h, n);

It's great to have this run during debug builds ?

test/jdk/java/util/concurrent/DelayScheduler/AscendingOrderAfterReplace.java line 43:

> 41:     public static void main(String[] args) throws Exception {
> 42:         String delays = IntStream.of(DELAYS)
> 43:                 .mapToObj(i -> Integer.valueOf(i).toString())

Suggestion:

                .mapToObj(i -> Integer.toString(i))

test/jdk/java/util/concurrent/DelayScheduler/AscendingOrderAfterReplace.java line 45:

> 43:                 .mapToObj(i -> Integer.valueOf(i).toString())
> 44:                 .collect(Collectors.joining(", "));
> 45:         System.out.println("Delays: " + delays);

I presume this is to be removed.

test/jdk/java/util/concurrent/DelayScheduler/AscendingOrderAfterReplace.java line 60:

> 58:      */
> 59:     private static boolean testCancel(int indexToCancel) throws Exception {
> 60:         System.out.println("=== Test cancel " + DELAYS[indexToCancel] + " ===");

I presume this is to be removed.

test/jdk/java/util/concurrent/DelayScheduler/AscendingOrderAfterReplace.java line 82:

> 80: 
> 81:         // delayed tasks should have executed in ascending order of their delay
> 82:         System.out.println(queue);

I presume this is to be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28469#discussion_r2553944932
PR Review Comment: https://git.openjdk.org/jdk/pull/28469#discussion_r2553941776
PR Review Comment: https://git.openjdk.org/jdk/pull/28469#discussion_r2553942028
PR Review Comment: https://git.openjdk.org/jdk/pull/28469#discussion_r2553942533
PR Review Comment: https://git.openjdk.org/jdk/pull/28469#discussion_r2553943281

From alanb at openjdk.org  Mon Nov 24 14:36:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Nov 2025 14:36:30 GMT
Subject: RFR: 8370887: DelayScheduler.replace method may break the 4-ary
 heap in certain scenarios
In-Reply-To: <kIG4yLuj3KoynrtyiNJIsJ-z21Ziu0U1LdCCZ6Nrs6A=.4addf7ff-d3ff-4fa4-83dc-dee5e62a4368@github.com>
References: <_veOR6nBK5qZz30ocpfk3ue0Kc2NwzO-0K2WlBZ4a54=.f6976469-a984-42e0-83a3-a48e8312f3f3@github.com>
 <kIG4yLuj3KoynrtyiNJIsJ-z21Ziu0U1LdCCZ6Nrs6A=.4addf7ff-d3ff-4fa4-83dc-dee5e62a4368@github.com>
Message-ID: <CZDzPytMazJZsu7lhRNJgHVZCFya6XdIK_Ekz0N_G_c=.5b10225d-ba18-4f31-ac93-58029dec7856@github.com>

On Sun, 23 Nov 2025 09:56:57 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> DelayScheduler.replace missing check to sift up when replaced with smaller value. checkHeap checks invariants when replacing. Executing tests with make run-test or other targets runs tests with -esa so assume is enabled.
>> 
>> New regression test to ensure delayed tests executes in expected delay order.
>
> src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 401:
> 
>> 399:             }
>> 400:         }
>> 401:         assert checkHeap(h, n);
> 
> It's great to have this run during debug builds ?

The tests runs are done with -esa so the assert is always enabled in test runs. So all good.

> test/jdk/java/util/concurrent/DelayScheduler/AscendingOrderAfterReplace.java line 45:
> 
>> 43:                 .mapToObj(i -> Integer.valueOf(i).toString())
>> 44:                 .collect(Collectors.joining(", "));
>> 45:         System.out.println("Delays: " + delays);
> 
> I presume this is to be removed.

The trace messages are there to help diagnose in the event of a failure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28469#discussion_r2554800800
PR Review Comment: https://git.openjdk.org/jdk/pull/28469#discussion_r2554797410

From vklang at openjdk.org  Mon Nov 24 14:43:36 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 14:43:36 GMT
Subject: RFR: 8370887: DelayScheduler.replace method may break the 4-ary
 heap in certain scenarios
In-Reply-To: <_veOR6nBK5qZz30ocpfk3ue0Kc2NwzO-0K2WlBZ4a54=.f6976469-a984-42e0-83a3-a48e8312f3f3@github.com>
References: <_veOR6nBK5qZz30ocpfk3ue0Kc2NwzO-0K2WlBZ4a54=.f6976469-a984-42e0-83a3-a48e8312f3f3@github.com>
Message-ID: <z2d4D0YxDwvgMvKYezGyFltdeKgI5IIAMkHpZjWHZZ4=.02ade799-eb04-4e5d-b075-4b9aa0e11189@github.com>

On Sun, 23 Nov 2025 08:08:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> DelayScheduler.replace missing check to sift up when replaced with smaller value. checkHeap checks invariants when replacing. Executing tests with make run-test or other targets runs tests with -esa so assume is enabled.
> 
> New regression test to ensure delayed tests executes in expected delay order.

Nice work @AlanBateman & @DougLea ?

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28469#pullrequestreview-3500764927

From alanb at openjdk.org  Mon Nov 24 15:01:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Nov 2025 15:01:58 GMT
Subject: RFR: 8372155: ReleaseInfoPlugin doesn't handle input file as UTF-8
 properly [v4]
In-Reply-To: <ZoTNBHIsGNTInIqUkjjf_TTbWaIh8-T7Zi1cYTKDkBk=.ed7e30ec-1a11-49ed-9409-4de906d1eecf@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <ZoTNBHIsGNTInIqUkjjf_TTbWaIh8-T7Zi1cYTKDkBk=.ed7e30ec-1a11-49ed-9409-4de906d1eecf@github.com>
Message-ID: <cCNjKR0C4URqzymh8mrmCvRQND8aJPuIdp-2ZDIZ1EU=.75b607ec-6256-452b-b8ae-0a08f05c779a@github.com>

On Thu, 20 Nov 2025 15:24:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it an `InputStreamReader` with `UTF-8` encoding.
>> 
>> Testing:
>> - [x] GHA
>> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright updates.

All okay, just a minor comment on a var usage in the test.

test/jdk/tools/jlink/plugins/ReleaseInfoPluginTest.java line 71:

> 69:         // release file produced should have IMPLEMENTOR in
> 70:         // UTF-8 encoding
> 71:         var release = image.resolve("release");

I probably wouldn't use `var` here because it's not clear because "release" or the method gives no indication that the type is Path here.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28399#pullrequestreview-3500848816
PR Review Comment: https://git.openjdk.org/jdk/pull/28399#discussion_r2556633821

From dl at openjdk.org  Mon Nov 24 15:09:40 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 24 Nov 2025 15:09:40 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v19]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <UwWZ8HG9_uFVRwBN0cXBuI1oBu2Z-BXml0s1H-Koo-4=.927210d7-e45b-4c04-846c-bcaa52cdbd66@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea 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 29 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8360046
 - Signal on setParallelism
 - Drop added Contended region; simplify accordingly
 - Tweaks
 - Merge branch 'openjdk:master' into JDK-8360046
 - Seperate repolling policies
 - Faster quiescent termination
 - Fix push, refactor deactivate
 - Use absolute timed waits
 - Reduce deactivate/reactivate and cancelled timeout rates
 - ... and 19 more: https://git.openjdk.org/jdk/compare/04687de2...383f9238

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/891eff05..383f9238

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=17-18

  Stats: 80875 lines in 1160 files changed: 54702 ins; 18645 del; 7528 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From mcimadamore at openjdk.org  Mon Nov 24 15:10:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Nov 2025 15:10:00 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v12]
In-Reply-To: <9jQNB8VUwW6jC53uBwp5x8awio3_X1kQ48QkfQHHHsM=.daf137ab-7f85-4378-bd33-144addb93d1e@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Azw8uh7ppASBsB3OOjdLj-98TJazhBZ3pvfzwSyfAW4=.2f5e8473-bcfa-4771-8b21-db396abc75e3@github.com>
 <9jQNB8VUwW6jC53uBwp5x8awio3_X1kQ48QkfQHHHsM=.daf137ab-7f85-4378-bd33-144addb93d1e@github.com>
Message-ID: <PXLm1mCIddfyhSr2fvsl8-z50pBkzqz9SuonfyzmeIQ=.312e695c-197d-4171-b55c-c6523bf4d435@github.com>

On Mon, 24 Nov 2025 09:45:45 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> I have tentatively updated the new `MemorySegment#copy` to return the number of bytes that were written. 

I think I understand the use case. E.g. say a client wants to write a bunch of variable length string to a segment, where the string is prefixed by length (a la protobuf). So what they can do is:

* write length at offset S
* write string at offset S + 4, this writes N bytes
* write next length at offset S + 4 + N
* write next string at offset S + 4 + N + 4, this writes M bytes
* ...

Effectively, this unifies `copy` with `setString` -- in the sense that now `setString` is just a string-based copy + a terminator write (at the correct offset) -- the size of the terminator is charset dependent.

I think overall it makes sense -- I believe @JornVernee proposed something similar in the past. It's true it's inconsistent with other `copy` method and, in hindsight, it would have perhaps been useful to always return a length (given that in other cases length is expressed in "elements" -- either array elements, or elements expressed in a given layout) -- although in the other cases the copy length can usually be computed using a shift operation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3571253487

From sgehwolf at openjdk.org  Mon Nov 24 15:13:30 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 24 Nov 2025 15:13:30 GMT
Subject: RFR: 8372155: ReleaseInfoPlugin doesn't handle input file as UTF-8
 properly [v5]
In-Reply-To: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
Message-ID: <qP4GY694DUJkLRIGi3Gbpugz2ardTrf3N0jVJigdUE0=.36676ba9-d8cc-44a6-8afd-fae08230e59e@github.com>

> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it a `Reader` with `UTF-8` encoding (using nio API).
> 
> Testing:
> - [x] GHA
> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Reduce 'var' usage in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28399/files
  - new: https://git.openjdk.org/jdk/pull/28399/files/65e57118..b05d1f68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28399&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28399&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28399/head:pull/28399

PR: https://git.openjdk.org/jdk/pull/28399

From sgehwolf at openjdk.org  Mon Nov 24 15:13:33 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 24 Nov 2025 15:13:33 GMT
Subject: RFR: 8372155: ReleaseInfoPlugin doesn't handle input file as UTF-8
 properly [v4]
In-Reply-To: <cCNjKR0C4URqzymh8mrmCvRQND8aJPuIdp-2ZDIZ1EU=.75b607ec-6256-452b-b8ae-0a08f05c779a@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <ZoTNBHIsGNTInIqUkjjf_TTbWaIh8-T7Zi1cYTKDkBk=.ed7e30ec-1a11-49ed-9409-4de906d1eecf@github.com>
 <cCNjKR0C4URqzymh8mrmCvRQND8aJPuIdp-2ZDIZ1EU=.75b607ec-6256-452b-b8ae-0a08f05c779a@github.com>
Message-ID: <7_wsxq9DqXfRdfmIbhmAixxCpS25APjYXd1X14PuxlI=.0b2bed8b-4313-43fb-bbaa-7b142e97111a@github.com>

On Mon, 24 Nov 2025 14:58:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright updates.
>
> test/jdk/tools/jlink/plugins/ReleaseInfoPluginTest.java line 71:
> 
>> 69:         // release file produced should have IMPLEMENTOR in
>> 70:         // UTF-8 encoding
>> 71:         var release = image.resolve("release");
> 
> I probably wouldn't use `var` here because it's not clear because "release" or the method gives no indication that the type is Path here.

OK. I've changed it to use `Path` instead. Did the same for `image` variable where it's not clear either.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28399#discussion_r2556669843

From asemenyuk at openjdk.org  Mon Nov 24 15:14:23 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Nov 2025 15:14:23 GMT
Subject: Integrated: 8372359: Clean jpackage error messages
In-Reply-To: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
References: <gDOxAomIr9piMdlwoGMTV0Ujdhjm24XhbYqmRUhEovc=.7a5365ed-807d-4ebd-b1b8-373a4bd2937b@github.com>
Message-ID: <8AQBVwpFZpnk9ESq1ghPG8HvsI4HIxP_H9rteNoNJTs=.9d76eb7a-e5f4-4b0e-98a7-77b5f1f58306@github.com>

On Fri, 21 Nov 2025 16:45:31 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Some jpackage error messages have "Error: " prefix. Some don't. The prefix is redundant as jpackage assembles the error message from the localized "Error: " prefix and localized message body [1]. The prefix was removed. 
> 
> There are error messages specific to jpackage options that duplicate generic error messages. They are:
> 
> **ERR_BuildRootInvalid**
> It duplicates a generic "error.parameter-not-empty-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: temp (foo) must be non-existent or empty directory | The value "foo" provided for parameter --temp is not an empty directory or non existent path |
> 
> **ERR_AppImageNotExist**
> It duplicates a generic "error.parameter-not-directory" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: App image directory "foo" does not exist | The value "foo" provided for parameter --app-image is not a directory |
> 
> **ERR_LicenseFileNotExit**
> It duplicates a generic "error.parameter-not-file" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Specified license file does not exist | The value "foo" provided for parameter --license-file is not a file |
> 
> **ERR_BothMainJarAndModule**
> It duplicates a generic "ERR_MutuallyExclusiveOptions" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: Cannot have both --main-jar and --module Options | Mutually exclusive options [--main-jar] and [--module] |
> 
> **ERR_NoAddLauncherName**
> It duplicates a generic "error.parameter-add-launcher-malformed" error message.
> 
> | Specialized error message | Generic error message | 
> | --- | --- |
> | Error: --add-launcher option requires a name and a file path (--add-launcher <name>=<file path>) | The value "foo" provided for parameter --add-launcher does not match the pattern <name>=<file path> |
> 
> Specialized error messages duplicating generic error messages were removed to simplify maintenance.
> 
>  **ERR_MissingArgument**
> ERR_MissingArgument was not referenced in the implementation, but was mistakenly referenced in the tests. It was replaced with ERR_MissingArgument2, and ERR_MissingArgument was removed.
> 
> **error.invalid-option-value**
> "error.invalid-option-value" was used for errors in shortcut launcher options (--win-shortcut, --linux-shortcut), but it is not descriptive. For this reason, it was replaced with the "error.parameter-not-launcher-shortcut-dir".
> 
> | Old error message | New erro...

This pull request has now been integrated.

Changeset: c12389d0
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c12389d006c94d619da69b81ece317b878c0c1bb
Stats:     223 lines in 14 files changed: 31 ins; 60 del; 132 mod

8372359: Clean jpackage error messages

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28457

From mcimadamore at openjdk.org  Mon Nov 24 15:17:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Nov 2025 15:17:52 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v10]
In-Reply-To: <sJIn50EiT0RGhV2WpayNp_gk3stCIcXS_VkEZRIoVWY=.687766ae-79d6-48c1-ad0f-e2c383194e55@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <chbKzgns6suaigViQ3pgqq5Tono0UWkBuShfPlBr8yc=.3b855b56-53f0-4e84-a581-144094b706ab@github.com>
 <sJIn50EiT0RGhV2WpayNp_gk3stCIcXS_VkEZRIoVWY=.687766ae-79d6-48c1-ad0f-e2c383194e55@github.com>
Message-ID: <k8uqTXnipd145eEJtpdkaoCzMpbrqGhrANUCVukBGMI=.a3d6b7f2-d268-4b87-b8a2-91d8e18d5373@github.com>

On Fri, 21 Nov 2025 14:14:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>>   
>>   * handle numChars + srcIndex overflow, and add tests
>>   * replace yen with a character that round trips
>
> Latest version looks good to me. Left one last suggestion inline.

> I think overall it makes sense -- I believe @JornVernee proposed something similar in the past. It's true it's inconsistent with other `copy` method and, in hindsight, it would have perhaps been useful to always return a length (given that in other cases length is expressed in "elements" -- either array elements, or elements expressed in a given layout) -- although in the other cases the copy length can usually be computed using a shift operation.

Also, I believe the need for returning a copy length is probably driven by the fact that we have dropped the `MemorySegment::ofString(String, Charset)` view that we originally anticipated. If we had that method, returning a length wouldn't have been as important -- although perhaps, to compensate fully, we would also have needed a view that took a char index and a char length -- e.g. to view a _substring_ as a memory segment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3571270973

From mcimadamore at openjdk.org  Mon Nov 24 15:17:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Nov 2025 15:17:54 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v12]
In-Reply-To: <PXLm1mCIddfyhSr2fvsl8-z50pBkzqz9SuonfyzmeIQ=.312e695c-197d-4171-b55c-c6523bf4d435@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Azw8uh7ppASBsB3OOjdLj-98TJazhBZ3pvfzwSyfAW4=.2f5e8473-bcfa-4771-8b21-db396abc75e3@github.com>
 <9jQNB8VUwW6jC53uBwp5x8awio3_X1kQ48QkfQHHHsM=.daf137ab-7f85-4378-bd33-144addb93d1e@github.com>
 <PXLm1mCIddfyhSr2fvsl8-z50pBkzqz9SuonfyzmeIQ=.312e695c-197d-4171-b55c-c6523bf4d435@github.com>
Message-ID: <8CgTEkC7e7tH5rjLYp390E7G71xcjmN0JVf0DcazEvs=.9f1fe903-797c-4036-b7af-3d6acbeb5f70@github.com>

On Mon, 24 Nov 2025 15:07:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I have tentatively updated the new MemorySegment#copy to return the number of bytes that were written.

Also, if in the future we also enhance encoders to return the length of a string w/o encoding it, it might still be useful to have `copy` return the length (to avoid scanning the string chars twice).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3571278579

From alanb at openjdk.org  Mon Nov 24 15:33:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Nov 2025 15:33:40 GMT
Subject: RFR: 8372155: ReleaseInfoPlugin doesn't handle input file as UTF-8
 properly [v5]
In-Reply-To: <qP4GY694DUJkLRIGi3Gbpugz2ardTrf3N0jVJigdUE0=.36676ba9-d8cc-44a6-8afd-fae08230e59e@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
 <qP4GY694DUJkLRIGi3Gbpugz2ardTrf3N0jVJigdUE0=.36676ba9-d8cc-44a6-8afd-fae08230e59e@github.com>
Message-ID: <5heIWLjLP3dLzYMUTNYkIIQ_kiITM1w0uT18fyhGRFU=.b9a4e102-07da-4963-b782-36804c0d3508@github.com>

On Mon, 24 Nov 2025 15:13:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it a `Reader` with `UTF-8` encoding (using nio API).
>> 
>> Testing:
>> - [x] GHA
>> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce 'var' usage in test

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28399#pullrequestreview-3501003380

From duke at openjdk.org  Mon Nov 24 15:36:09 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 24 Nov 2025 15:36:09 GMT
Subject: RFR: 8372410: VarHandle wrongly uses int parameter on
 VirtualThread creation
In-Reply-To: <52oXiLrPla0VCDBhsK2GN-A6JdN7Cx7Wz1DkPxDcaEk=.7f2c9011-3fd1-4e1e-a503-8016199e7db0@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
 <52oXiLrPla0VCDBhsK2GN-A6JdN7Cx7Wz1DkPxDcaEk=.7f2c9011-3fd1-4e1e-a503-8016199e7db0@github.com>
Message-ID: <ol279m6npzzIuTLZFDGH1JXJ6sJsNO_tiMTRBKXXS0g=.9f7bdde5-ae06-4333-a184-ef5d0db4a50d@github.com>

On Mon, 24 Nov 2025 13:43:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
>> 
>> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
>> 
>> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
>> 
>> Benchmark                                                                Mode  Cnt   Score   Error  Units
>> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
>> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
>> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
>> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
>> 
>> where the `right` indy shows:
>> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
>> 
>> vs the `wrong` one:
>> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />
>
> Good find, the bug has been move to the right place now, can you update the title on the PR to match the JBS issue?

Thanks @AlanBateman 

> can you update the title on the PR to match the JBS issue?

where's the new one? I cannot see any reference here on Github (this is my very first contribution :) )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3571414488

From alanb at openjdk.org  Mon Nov 24 15:39:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Nov 2025 15:39:16 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should
 use non-optimal VarHandle
In-Reply-To: <ol279m6npzzIuTLZFDGH1JXJ6sJsNO_tiMTRBKXXS0g=.9f7bdde5-ae06-4333-a184-ef5d0db4a50d@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
 <52oXiLrPla0VCDBhsK2GN-A6JdN7Cx7Wz1DkPxDcaEk=.7f2c9011-3fd1-4e1e-a503-8016199e7db0@github.com>
 <ol279m6npzzIuTLZFDGH1JXJ6sJsNO_tiMTRBKXXS0g=.9f7bdde5-ae06-4333-a184-ef5d0db4a50d@github.com>
Message-ID: <lUhdXZW7up278Bw0Lw5lppxB-0W_aMtVGSk-PTmTIds=.8b720252-e624-4524-96c7-a5c8efd5c11a@github.com>

On Mon, 24 Nov 2025 15:32:51 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> where's the new one? I cannot see any reference here on Github (this is my very first contribution :) )

Here it is:
https://bugs.openjdk.org/browse/JDK-8372410

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3571432676

From alanb at openjdk.org  Mon Nov 24 15:53:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Nov 2025 15:53:03 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should
 use non-optimal VarHandle
In-Reply-To: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
Message-ID: <S2cb8KXOjpuWhV9oN3nREkttLSAIjeOXZNlYgx3ag4Y=.527ecb8b-4cf3-4a11-8b4a-f46616bd0f24@github.com>

On Mon, 24 Nov 2025 13:05:40 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
> 
> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
> 
> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
> 
> Benchmark                                                                Mode  Cnt   Score   Error  Units
> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
> 
> where the `right` indy shows:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
> 
> vs the `wrong` one:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28475#pullrequestreview-3501089682

From duke at openjdk.org  Mon Nov 24 15:53:05 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 24 Nov 2025 15:53:05 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should
 use non-optimal VarHandle
In-Reply-To: <lUhdXZW7up278Bw0Lw5lppxB-0W_aMtVGSk-PTmTIds=.8b720252-e624-4524-96c7-a5c8efd5c11a@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
 <52oXiLrPla0VCDBhsK2GN-A6JdN7Cx7Wz1DkPxDcaEk=.7f2c9011-3fd1-4e1e-a503-8016199e7db0@github.com>
 <ol279m6npzzIuTLZFDGH1JXJ6sJsNO_tiMTRBKXXS0g=.9f7bdde5-ae06-4333-a184-ef5d0db4a50d@github.com>
 <lUhdXZW7up278Bw0Lw5lppxB-0W_aMtVGSk-PTmTIds=.8b720252-e624-4524-96c7-a5c8efd5c11a@github.com>
Message-ID: <JbpRhUBx6bQIyFSzl-X5rFi3m_JGVShV31dvgvzzOgQ=.80fd3c8d-eef6-4dda-875c-99b5f3827d19@github.com>

On Mon, 24 Nov 2025 15:36:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks @AlanBateman 
>> 
>>> can you update the title on the PR to match the JBS issue?
>> 
>> where's the new one? I cannot see any reference here on Github (this is my very first contribution :) )
>
>> where's the new one? I cannot see any reference here on Github (this is my very first contribution :) )
> 
> Here it is:
> https://bugs.openjdk.org/browse/JDK-8372410

Done @AlanBateman thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3571486956

From vklang at openjdk.org  Mon Nov 24 16:06:03 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 16:06:03 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should
 use non-optimal VarHandle
In-Reply-To: <JbpRhUBx6bQIyFSzl-X5rFi3m_JGVShV31dvgvzzOgQ=.80fd3c8d-eef6-4dda-875c-99b5f3827d19@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
 <52oXiLrPla0VCDBhsK2GN-A6JdN7Cx7Wz1DkPxDcaEk=.7f2c9011-3fd1-4e1e-a503-8016199e7db0@github.com>
 <ol279m6npzzIuTLZFDGH1JXJ6sJsNO_tiMTRBKXXS0g=.9f7bdde5-ae06-4333-a184-ef5d0db4a50d@github.com>
 <lUhdXZW7up278Bw0Lw5lppxB-0W_aMtVGSk-PTmTIds=.8b720252-e624-4524-96c7-a5c8efd5c11a@github.com>
 <JbpRhUBx6bQIyFSzl-X5rFi3m_JGVShV31dvgvzzOgQ=.80fd3c8d-eef6-4dda-875c-99b5f3827d19@github.com>
Message-ID: <6JofW710T2ddV16rIa7AGtPtV8B2DaUZfLgyattqNBQ=.0f35ab2f-0daa-4eda-ac53-bf168198acdd@github.com>

On Mon, 24 Nov 2025 15:49:05 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>>> where's the new one? I cannot see any reference here on Github (this is my very first contribution :) )
>> 
>> Here it is:
>> https://bugs.openjdk.org/browse/JDK-8372410
>
> Done @AlanBateman thanks

Great catch, @franz1981!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3571546619

From vklang at openjdk.org  Mon Nov 24 16:17:04 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 16:17:04 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v17]
In-Reply-To: <U3F2QHXV7Onf7wOejfGj1L77PzZ5LOFWeCa4LKGLjlE=.614d39c5-0439-47ad-a516-878a37c200e9@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <U3F2QHXV7Onf7wOejfGj1L77PzZ5LOFWeCa4LKGLjlE=.614d39c5-0439-47ad-a516-878a37c200e9@github.com>
Message-ID: <aArNJbC8I_WZEMOHh_rW1GBGdr9s8gfQaWNKjV2-THI=.09ca3235-eb3e-49b5-9d75-49f3faf1dcd1@github.com>

On Tue, 18 Nov 2025 22:27:46 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaks

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1261:

> 1259:             if ((a = array) != null && (cap = a.length) > 0) { // else disabled
> 1260:                 int k = (m = cap - 1) & s;
> 1261:                 if ((room = m - (s - b)) >= 0) {

Not that I think it'd make much of a difference, but it would be possible to do the following:

Suggestion:

                int k;
                if ((room = (k = (m = cap - 1) & s) - (s - b)) >= 0) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2546508029

From vklang at openjdk.org  Mon Nov 24 16:17:12 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 16:17:12 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v19]
In-Reply-To: <UwWZ8HG9_uFVRwBN0cXBuI1oBu2Z-BXml0s1H-Koo-4=.927210d7-e45b-4c04-846c-bcaa52cdbd66@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <UwWZ8HG9_uFVRwBN0cXBuI1oBu2Z-BXml0s1H-Koo-4=.927210d7-e45b-4c04-846c-bcaa52cdbd66@github.com>
Message-ID: <PH1trEh_C69BlePF6uJszjlZzS2uGGNqzpxNSYbhlRs=.81a74f3f-8805-493d-8b74-206ee88459cb@github.com>

On Mon, 24 Nov 2025 15:09:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea 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 29 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8360046
>  - Signal on setParallelism
>  - Drop added Contended region; simplify accordingly
>  - Tweaks
>  - Merge branch 'openjdk:master' into JDK-8360046
>  - Seperate repolling policies
>  - Faster quiescent termination
>  - Fix push, refactor deactivate
>  - Use absolute timed waits
>  - Reduce deactivate/reactivate and cancelled timeout rates
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/34194ee8...383f9238

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3339:

> 3337:             throw new UnsupportedOperationException("Cannot override System property");
> 3338:         if ((prevSize = getAndSetParallelism(size)) < size)
> 3339:             signalWork(null, 0);

Suggestion:

            signalWork(null, 0); // trigger worker activation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2556901461

From asemenyuk at openjdk.org  Mon Nov 24 17:01:46 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Nov 2025 17:01:46 GMT
Subject: RFR: 8372399: Add missing CPE statements
In-Reply-To: <lv0BZ7RURfvASy1O-YjegG6_dbjRUmeNvzh2w56qQhU=.b24de879-ade7-4439-951c-625e07d7e0c8@github.com>
References: <lv0BZ7RURfvASy1O-YjegG6_dbjRUmeNvzh2w56qQhU=.b24de879-ade7-4439-951c-625e07d7e0c8@github.com>
Message-ID: <H9h8b78z13WeQZgn0rVwqvU7Dqljg6ucwyetBcWKvQM=.462332fe-ad1c-4554-ac33-d713846e1424@github.com>

On Mon, 24 Nov 2025 12:00:24 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> Adds missing Classpath Exception statements
> JDK Issue: [JDK-8372399](https://bugs.openjdk.org/browse/JDK-8372399)

Marked as reviewed by asemenyuk (Reviewer).

Thank you for the fix!

-------------

PR Review: https://git.openjdk.org/jdk/pull/28474#pullrequestreview-3501388683
PR Comment: https://git.openjdk.org/jdk/pull/28474#issuecomment-3571804478

From iris.clark at oracle.com  Mon Nov 24 17:05:11 2025
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 24 Nov 2025 17:05:11 +0000
Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and
 Verona projects
In-Reply-To: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
References: <c03f0ecf-b0cb-4ff1-942e-2d2cadae6e95@oracle.com>
Message-ID: <SJ2PR10MB761770AB41EE4CA93467E0F1FBD0A@SJ2PR10MB7617.namprd10.prod.outlook.com>

Vote: yes

Iris


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251124/003c357c/attachment.htm>

From adinn at openjdk.org  Mon Nov 24 17:01:46 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 24 Nov 2025 17:01:46 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should
 use non-optimal VarHandle
In-Reply-To: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
Message-ID: <mZbKzvbQRmKj78QkK_7l5bI357B34FPKgZLyT3ptQ7c=.c589e04c-81a7-4a2f-b4e7-07cdf1558864@github.com>

On Mon, 24 Nov 2025 13:05:40 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
> 
> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
> 
> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
> 
> Benchmark                                                                Mode  Cnt   Score   Error  Units
> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
> 
> where the `right` indy shows:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
> 
> vs the `wrong` one:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />

Nice work!

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28475#pullrequestreview-3501381400

From adinn at openjdk.org  Mon Nov 24 17:07:23 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 24 Nov 2025 17:07:23 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should
 use non-optimal VarHandle
In-Reply-To: <JbpRhUBx6bQIyFSzl-X5rFi3m_JGVShV31dvgvzzOgQ=.80fd3c8d-eef6-4dda-875c-99b5f3827d19@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
 <52oXiLrPla0VCDBhsK2GN-A6JdN7Cx7Wz1DkPxDcaEk=.7f2c9011-3fd1-4e1e-a503-8016199e7db0@github.com>
 <ol279m6npzzIuTLZFDGH1JXJ6sJsNO_tiMTRBKXXS0g=.9f7bdde5-ae06-4333-a184-ef5d0db4a50d@github.com>
 <lUhdXZW7up278Bw0Lw5lppxB-0W_aMtVGSk-PTmTIds=.8b720252-e624-4524-96c7-a5c8efd5c11a@github.com>
 <JbpRhUBx6bQIyFSzl-X5rFi3m_JGVShV31dvgvzzOgQ=.80fd3c8d-eef6-4dda-875c-99b5f3827d19@github.com>
Message-ID: <m3bH-_HzQgTSN__R4qe1ifauvNO6wSoM2DXDOt-tajw=.b9d17247-bbe6-4d97-8383-65244e05c443@github.com>

On Mon, 24 Nov 2025 15:49:05 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>>> where's the new one? I cannot see any reference here on Github (this is my very first contribution :) )
>> 
>> Here it is:
>> https://bugs.openjdk.org/browse/JDK-8372410
>
> Done @AlanBateman thanks

@franz1981 You need to edit this PR's title so it says

  8372410: ThreadFactory used by Thread.Builder::factory uses non-optimal VarHandle

That will make it match the title of [JDK-8372410](https://bugs.openjdk.org/browse/JDK-8372410).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3571814066

From duke at openjdk.org  Mon Nov 24 17:10:31 2025
From: duke at openjdk.org (duke)
Date: Mon, 24 Nov 2025 17:10:31 GMT
Subject: RFR: 8372399: Add missing CPE statements
In-Reply-To: <lv0BZ7RURfvASy1O-YjegG6_dbjRUmeNvzh2w56qQhU=.b24de879-ade7-4439-951c-625e07d7e0c8@github.com>
References: <lv0BZ7RURfvASy1O-YjegG6_dbjRUmeNvzh2w56qQhU=.b24de879-ade7-4439-951c-625e07d7e0c8@github.com>
Message-ID: <a6_NoWwItfZH83rcGINzvp9OUynDDv3CAbZqLaW6q00=.08cad5da-8703-4872-a5d8-bad24c5d10ba@github.com>

On Mon, 24 Nov 2025 12:00:24 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> Adds missing Classpath Exception statements
> JDK Issue: [JDK-8372399](https://bugs.openjdk.org/browse/JDK-8372399)

@Sorna-Sarathi 
Your change (at version df6a1ccba2e5de7d5d6b73252979a81bbc469abb) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28474#issuecomment-3571839090

From liach at openjdk.org  Mon Nov 24 17:20:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Nov 2025 17:20:09 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should
 use non-optimal VarHandle
In-Reply-To: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
Message-ID: <5FRhEijv2BzqGiDJtgOLRcSvyJtDka0GttpAIvTnVW8=.f7c44c42-fefb-4b87-98df-ae8f37939402@github.com>

On Mon, 24 Nov 2025 13:05:40 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
> 
> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
> 
> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
> 
> Benchmark                                                                Mode  Cnt   Score   Error  Units
> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
> 
> where the `right` indy shows:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
> 
> vs the `wrong` one:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />

This is not the first time this VarHandle problem is hit - see #16451

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28475#pullrequestreview-3501454383

From dl at openjdk.org  Mon Nov 24 17:39:08 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 24 Nov 2025 17:39:08 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v17]
In-Reply-To: <aArNJbC8I_WZEMOHh_rW1GBGdr9s8gfQaWNKjV2-THI=.09ca3235-eb3e-49b5-9d75-49f3faf1dcd1@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <U3F2QHXV7Onf7wOejfGj1L77PzZ5LOFWeCa4LKGLjlE=.614d39c5-0439-47ad-a516-878a37c200e9@github.com>
 <aArNJbC8I_WZEMOHh_rW1GBGdr9s8gfQaWNKjV2-THI=.09ca3235-eb3e-49b5-9d75-49f3faf1dcd1@github.com>
Message-ID: <QFuxGZDe90B3rmHJ5o5z3JKJHnVfukvSt7DCFFM2S-Q=.5eb6e7e1-edc1-4d03-8ef9-e833c21138b0@github.com>

On Thu, 20 Nov 2025 15:21:36 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweaks
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1261:
> 
>> 1259:             if ((a = array) != null && (cap = a.length) > 0) { // else disabled
>> 1260:                 int k = (m = cap - 1) & s;
>> 1261:                 if ((room = m - (s - b)) >= 0) {
> 
> Not that I think it'd make much of a difference, but it would be possible to do the following:
> 
> Suggestion:
> 
>                 int k;
>                 if ((room = (k = (m = cap - 1) & s) - (s - b)) >= 0) {

Yes, but no: javac doesn't understand that the use of k in signalWork isn't reached, so it seems better to just assign it anyway (an optimizer might figure out when to avoid it .)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2557168322

From dl at openjdk.org  Mon Nov 24 17:39:14 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 24 Nov 2025 17:39:14 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v19]
In-Reply-To: <PH1trEh_C69BlePF6uJszjlZzS2uGGNqzpxNSYbhlRs=.81a74f3f-8805-493d-8b74-206ee88459cb@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <UwWZ8HG9_uFVRwBN0cXBuI1oBu2Z-BXml0s1H-Koo-4=.927210d7-e45b-4c04-846c-bcaa52cdbd66@github.com>
 <PH1trEh_C69BlePF6uJszjlZzS2uGGNqzpxNSYbhlRs=.81a74f3f-8805-493d-8b74-206ee88459cb@github.com>
Message-ID: <xWJuYGVcEf9nPI4_JB19KPnH2ZtFk7OAIShIvbZdsQw=.fd14e329-de17-4b21-a764-b9e5b402b458@github.com>

On Mon, 24 Nov 2025 16:13:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea 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 29 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8360046
>>  - Signal on setParallelism
>>  - Drop added Contended region; simplify accordingly
>>  - Tweaks
>>  - Merge branch 'openjdk:master' into JDK-8360046
>>  - Seperate repolling policies
>>  - Faster quiescent termination
>>  - Fix push, refactor deactivate
>>  - Use absolute timed waits
>>  - Reduce deactivate/reactivate and cancelled timeout rates
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/7edd4d73...383f9238
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3339:
> 
>> 3337:             throw new UnsupportedOperationException("Cannot override System property");
>> 3338:         if ((prevSize = getAndSetParallelism(size)) < size)
>> 3339:             signalWork(null, 0);
> 
> Suggestion:
> 
>             signalWork(null, 0); // trigger worker activation

thanks; done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2557168773

From vklang at openjdk.org  Mon Nov 24 17:39:40 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 17:39:40 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
Message-ID: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>

Adds the patch by @DougLea

-------------

Commit messages:
 - 8371740 - removes the risk of missed polls in LinkedTransferQueue

Changes: https://git.openjdk.org/jdk/pull/28479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371740
  Stats: 80 lines in 2 files changed: 73 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28479/head:pull/28479

PR: https://git.openjdk.org/jdk/pull/28479

From duke at openjdk.org  Mon Nov 24 17:50:05 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 24 Nov 2025 17:50:05 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses
 non-optimal VarHandle
In-Reply-To: <5FRhEijv2BzqGiDJtgOLRcSvyJtDka0GttpAIvTnVW8=.f7c44c42-fefb-4b87-98df-ae8f37939402@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
 <5FRhEijv2BzqGiDJtgOLRcSvyJtDka0GttpAIvTnVW8=.f7c44c42-fefb-4b87-98df-ae8f37939402@github.com>
Message-ID: <jQmoev66yS4H3lQp6WB4dlZWr642xZo6ccejPmunz6I=.b840ff67-eb7c-464e-ac61-4a75c9f13d9f@github.com>

On Mon, 24 Nov 2025 17:17:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
>> 
>> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
>> 
>> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
>> 
>> Benchmark                                                                Mode  Cnt   Score   Error  Units
>> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
>> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
>> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
>> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
>> 
>> where the `right` indy shows:
>> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
>> 
>> vs the `wrong` one:
>> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />
>
> This is not the first time this VarHandle problem is hit - see #16451

This has bitten me lot of times @liach ? 
Including others while reading/writing oop fields into arrays too; it would be nice to get an option to fail fast with an exception enabled via diagnostic args eg EnableStrictPolymorphicSignature
Although Javac should be able to detect it too, thinking about it twice

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3572001102

From duke at openjdk.org  Mon Nov 24 17:54:41 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 24 Nov 2025 17:54:41 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
Message-ID: <8IBVjNHV8qol1wF_vBoHizhm61MGpj1twB84ea8fwwY=.ffc667ca-f6c4-4628-9fdb-ffb25e95a948@github.com>

On Mon, 24 Nov 2025 17:31:20 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adds the patch by @DougLea

Would you like me to add some test code to make sure something like this does not happen again?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28479#issuecomment-3572026766

From jvernee at openjdk.org  Mon Nov 24 18:10:35 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Nov 2025 18:10:35 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v13]
In-Reply-To: <OxFkXFJpY0zj0jVvcx99tWlV06eG-4GVDvrfRrVdUFQ=.eeea6b4a-3cc9-439d-b6ba-22ae87b2f7fd@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <OxFkXFJpY0zj0jVvcx99tWlV06eG-4GVDvrfRrVdUFQ=.eeea6b4a-3cc9-439d-b6ba-22ae87b2f7fd@github.com>
Message-ID: <6gFaJgZioVb6yGFVRWx4l0gWh1UhrQXVYIvkqFt7rhU=.80c899f3-65a9-41c3-acdd-f5b1e612b385@github.com>

On Mon, 24 Nov 2025 09:51:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update discussion of truncated reads of strings containing \0
>  - Return the number of copied bytes

I think returning the amount of copied bytes makes sense. The amount of bytes that is written is something that is currently hidden inside the implementation of `copy`, and the user has to guess how many bytes are written.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3572081379

From jvernee at openjdk.org  Mon Nov 24 18:21:07 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Nov 2025 18:21:07 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v10]
In-Reply-To: <ZEVS93Aiipf_5N4nh9o0xMejv9yZmnkrBM5C9wjqxtg=.880c1d7a-2e51-4f5f-99b3-5aa90ac353ab@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <ZEVS93Aiipf_5N4nh9o0xMejv9yZmnkrBM5C9wjqxtg=.880c1d7a-2e51-4f5f-99b3-5aa90ac353ab@github.com>
Message-ID: <SLbsO_AB3BA58JMzmCWCJx0TP-zKC0DY1hAJv3NI-yg=.58a5bc2c-df19-461a-91dc-d88fa4efceb2@github.com>

On Fri, 21 Nov 2025 17:26:59 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
>> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
>> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach
>
> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implement re-throwing approach according to reviewer recomandation

Thanks for the changes, that looks like what I had in mind. I like how this patch splits the uses of the access check into plain access and slice as well.

WRT catching and re-throwing: I don't think performance matters here, since an OOB access is likely to be on the slow path any way.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28124#pullrequestreview-3501663540

From jvernee at openjdk.org  Mon Nov 24 18:27:47 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Nov 2025 18:27:47 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v4]
In-Reply-To: <GcvvycqD2ndZ6ZIGKQYI7QPalpsu4k6A8a2-t3ysqUc=.b01257b0-e866-4470-aa10-501aabaad590@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <GcvvycqD2ndZ6ZIGKQYI7QPalpsu4k6A8a2-t3ysqUc=.b01257b0-e866-4470-aa10-501aabaad590@github.com>
Message-ID: <Iaqn6kBMU9cKCBezcwxVThurvEisCfutZvdYPJThNRA=.e6e24179-0937-4c1b-bed0-c46193fe0b4f@github.com>

On Fri, 14 Nov 2025 12:47:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add loop variant for mismatch

Sorry, this fell of my radar.

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkMismatch.java line 148:

> 146:             }
> 147:             return -1;
> 148:         }

Should we have the `IntInt` and `IntLong` variants as well?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28260#pullrequestreview-3501692240
PR Review Comment: https://git.openjdk.org/jdk/pull/28260#discussion_r2557295857

From alanb at openjdk.org  Mon Nov 24 18:49:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Nov 2025 18:49:18 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
Message-ID: <o82wuwZJj3xXiroeRqHiKuKZ-MiL6nPZ2QNOrLa9kL0=.2a7627c5-bc99-4f74-bc31-e0aafeea14fb@github.com>

On Mon, 24 Nov 2025 17:31:20 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adds the patch by @DougLea

Marked as reviewed by alanb (Reviewer).

test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 67:

> 65:             for (var future : futures) {
> 66:                 if (future.get() != 0)
> 67:                     throw new Error();

Good test, maybe change this to RuntimeException that includes the error count.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28479#pullrequestreview-3501755098
PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2557343595

From jvernee at openjdk.org  Mon Nov 24 19:06:43 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Nov 2025 19:06:43 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v4]
In-Reply-To: <GcvvycqD2ndZ6ZIGKQYI7QPalpsu4k6A8a2-t3ysqUc=.b01257b0-e866-4470-aa10-501aabaad590@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <GcvvycqD2ndZ6ZIGKQYI7QPalpsu4k6A8a2-t3ysqUc=.b01257b0-e866-4470-aa10-501aabaad590@github.com>
Message-ID: <J6-dov6gFJ3HWx8A0E0I41uGFs0f4FGHKTTJsTt7nAY=.3f569784-f4bd-4712-9c47-f9f4cf0a8892@github.com>

On Fri, 14 Nov 2025 12:47:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add loop variant for mismatch

Looking at this again, it looks like the results of `SegmentBulkCopy.Array.bufferCopy` you posted above don't scale with the size? Is the benchmark code correct?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28260#issuecomment-3572282927

From dl at openjdk.org  Mon Nov 24 19:10:27 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 24 Nov 2025 19:10:27 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v20]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <8Lxqb2cx2dxRRB4f9K2t02Yfrk9NxOTVGTkmBQZQmJM=.a897f197-325c-4eac-b085-87214609bd40@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Add comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/383f9238..9f130030

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=18-19

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From jvernee at openjdk.org  Mon Nov 24 19:26:14 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Nov 2025 19:26:14 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses
 non-optimal VarHandle
In-Reply-To: <5FRhEijv2BzqGiDJtgOLRcSvyJtDka0GttpAIvTnVW8=.f7c44c42-fefb-4b87-98df-ae8f37939402@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
 <5FRhEijv2BzqGiDJtgOLRcSvyJtDka0GttpAIvTnVW8=.f7c44c42-fefb-4b87-98df-ae8f37939402@github.com>
Message-ID: <dehcNf9NOPaLmX8d1z0yfzbUMbiMWguCbtHDj-Gj0ls=.fb7b70f0-3abe-48fd-bbed-d1e6735a7ff0@github.com>

On Mon, 24 Nov 2025 17:17:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
>> 
>> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
>> 
>> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
>> 
>> Benchmark                                                                Mode  Cnt   Score   Error  Units
>> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
>> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
>> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
>> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
>> 
>> where the `right` indy shows:
>> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
>> 
>> vs the `wrong` one:
>> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />
>
> This is not the first time this VarHandle problem is hit - see #16451

> This has bitten me lot of times @liach ? Including others while reading/writing oop fields into arrays too; it would be nice to get an option to fail fast with an exception enabled via diagnostic args eg EnableStrictPolymorphicSignature Although Javac should be able to detect it too, thinking about it twice

This can be done using [`VarHandle::withInvokeExactBehavior`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#withInvokeExactBehavior()) on a per var handle basis. C2 can constant fold the type-check away as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3572364123

From dfuchs at openjdk.org  Mon Nov 24 19:29:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 19:29:15 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v3]
In-Reply-To: <15AReOBUAseO-BiCWHW7N-OSOcknDc0Box3c90cXRZU=.5d7341db-94ea-4cdf-b3cd-fabe414dd88d@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <15AReOBUAseO-BiCWHW7N-OSOcknDc0Box3c90cXRZU=.5d7341db-94ea-4cdf-b3cd-fabe414dd88d@github.com>
Message-ID: <_SMDMjDoXuDI_Sujt62HD_YewzTQQlvqMSkpffJKq3A=.64a03981-30d1-48e5-a767-d4121c617296@github.com>

On Thu, 13 Nov 2025 09:27:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > > Some quick comments.
>>> > > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
>>> > 
>>> > 
>>> > I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
>>> 
>>> There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.
>> 
>> Maybe we move the shape to the end e.g., `Float16Vector128`, `IntVector128`, `IntVectorMax`?
>
>> > > > Some quick comments.
>> > > > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
>> > > 
>> > > 
>> > > I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
>> > 
>> > 
>> > There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.
>> 
>> Maybe we move the shape to the end e.g., `Float16Vector128`, `IntVector128`, `IntVectorMax`?
> 
> This looks good, since all these are concrete vector classes not exposed to users.

@jatin-bhateja it looks like you should be merging latest changes from master; Some changes shown in the diff obviously do not belong to this fix:
https://github.com/openjdk/jdk/pull/28002/files#diff-7798f606ce2bbf96fd99999c8c0ef9a4bb0455c128dd7e1249dea8db23d35402
Hopefully merging latest changes from master will make them go away?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3571013379

From jbhateja at openjdk.org  Mon Nov 24 19:29:17 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 24 Nov 2025 19:29:17 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v3]
In-Reply-To: <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
 <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
Message-ID: <ej2VU_26IZZBDgiGvry6djiDTMbjxH6XdqfgC0uuggc=.3e410400-d552-4721-8277-60eda5db7524@github.com>

On Thu, 13 Nov 2025 19:47:52 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
>
>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
> 
> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.

Hi @PaulSandoz, I have addressed your comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3572377706

From jbhateja at openjdk.org  Mon Nov 24 19:29:14 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 24 Nov 2025 19:29:14 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v3]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <6ma1bZs5YmEe_PtNmR69pVoJ_YAWy5fUQrsnnk8nH9M=.0594b623-f494-4af3-8e1c-f88120c53aca@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
 - Cleaning up interface as per review suggestions
 - Some cleanups
 - Fix some JTREG failures
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Revamped JTreg test generation and bug fixes
 - Cleanups
 - Removing redundant warmup constraint
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8bafc2f0...f34d324f

-------------

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 509516 lines in 232 files changed: 281237 ins; 226539 del; 1740 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From davidalayachew at gmail.com  Mon Nov 24 19:38:44 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 24 Nov 2025 14:38:44 -0500
Subject: Add better exception message to FileTreeIterator.hasNext()?
Message-ID: <CAA9v-_O+9vNXWRDSLu7Ct=EXueybtaVzPY8g9+sxVopxSCFX=g@mail.gmail.com>

Hello @core-libs-dev <core-libs-dev at openjdk.org>,

I was writing a simple script today -- find how many Java files are in each
of my top level folders of my current directory.

So, I ran the following code.

Files
    list(Path.of("."))
    filter(Files::isDirectory)
    collect

        Collectors.groupingBy(
        Function.<Path>identity(),
        Collectors
            .flatMapping
            (
                (final Path root) ->
                {
                    try (final Stream<Path> streamWalker = Files.walk(root))
                    {
                        return
                            streamWalker
                                .filter(Files::isRegularFile)
                                .filter(file ->
file.toString().endsWith(".java"))
                                ;
                    }
                    catch (final Exception exception)
                    {
                        throw new RuntimeException(exception);
                    }
                },
                Collectors.counting()
            )
        )
        ;

Now, there is a not-so-obvious bug -- when using a flatMapping Collector,
no need for try-with-resources.

The above code threw the below stack trace.

|  Exception java.lang.IllegalStateException
|        at FileTreeIterator.hasNext (FileTreeIterator.java:100)
|        at Iterator.forEachRemaining (Iterator.java:132)
|        at Spliterators$IteratorSpliterator.forEachRemaining
(Spliterators.java:1939)
|        at AbstractPipeline.copyInto (AbstractPipeline.java:570)
|        at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
|        at ForEachOps$ForEachOp.evaluateSequential (ForEachOps.java:153)
|        at ForEachOps$ForEachOp$OfRef.evaluateSequential
(ForEachOps.java:176)
|        at AbstractPipeline.evaluate (AbstractPipeline.java:265)
|        at ReferencePipeline.forEach (ReferencePipeline.java:632)
|        at Collectors.lambda$flatMapping$0 (Collectors.java:483)
|        at Collectors.lambda$groupingBy$0 (Collectors.java:1113)
|        at ReduceOps$3ReducingSink.accept (ReduceOps.java:169)
|        at ReferencePipeline$2$1.accept (ReferencePipeline.java:197)
|        at Iterator.forEachRemaining (Iterator.java:133)
|        at Spliterators$IteratorSpliterator.forEachRemaining
(Spliterators.java:1939)
|        at AbstractPipeline.copyInto (AbstractPipeline.java:570)
|        at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
|        at ReduceOps$ReduceOp.evaluateSequential (ReduceOps.java:921)
|        at AbstractPipeline.evaluate (AbstractPipeline.java:265)
|        at ReferencePipeline.collect (ReferencePipeline.java:723)
|        at (#4:5)


Not obvious what is wrong here.

Now, the exception message is being thrown by the hasNext() method of the
FileTreeIterator class. After looking at the source code of that class,
it's clear what the problem is.

https://github.com/openjdk/jdk/blob/jdk-26%2B25/src/java.base/share/classes/java/nio/file/FileTreeIterator.java#L98

It throws an exception because the FileTreeWalker contained within the
FileTreeIterator is closed (presumably by the try-with-resources). However,
the thrown exception message is empty. This exact same check-then-throw
logic is duplicated all over FileTreeIterator.

I propose that all such instances of check-then-throw be provided with
exception messages along the lines of "Cannot check for more elements
because the file walker is already closed!". I am not picky on the wording.
Just something to inform me that the issue is something is closed, as
opposed to just a generic IllegalStateException. I would even accept an
empty message body if the exception type communicated the issue.

Thank you for your time.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251124/9333bca3/attachment-0001.htm>

From duke at openjdk.org  Mon Nov 24 20:51:09 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 24 Nov 2025 20:51:09 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
Message-ID: <C9BEegFGUar9spiYTLDfVTLPs3OPXLrbdReFcSJu7ko=.0bc39b9f-7a95-403f-88a5-a9e5a16f67ee@github.com>

On Mon, 24 Nov 2025 17:31:20 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adds the patch by @DougLea

Good work everyone :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28479#issuecomment-3572663953

From duke at openjdk.org  Mon Nov 24 20:53:45 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Mon, 24 Nov 2025 20:53:45 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place
Message-ID: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>

The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.

This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.

Changes:
- Added new FieldUpdaterUtil class with static utility methods:
  * validateField() - validates field type, volatile, and static checks
  * computeAccessClass() - determines correct class for access checks
  * isSamePackage() - checks if two classes are in same package
  * isAncestor() - checks classloader delegation chain

- Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
  * Simplified constructor to use validateField() and computeAccessClass()
  * Removed duplicate isAncestor() and isSamePackage() methods

- Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
  * Simplified constructor to use validateField() and computeAccessClass()
  * Removed duplicate isAncestor() and isSamePackage() methods

- Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
  * Simplified constructor to use validateField() and computeAccessClass()
  * Removed duplicate isAncestor() and isSamePackage() methods

Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.

-------------

Commit messages:
 - 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place

Changes: https://git.openjdk.org/jdk/pull/28464/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28464&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364544
  Stats: 263 lines in 4 files changed: 134 ins; 122 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28464/head:pull/28464

PR: https://git.openjdk.org/jdk/pull/28464

From duke at openjdk.org  Mon Nov 24 20:53:48 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 24 Nov 2025 20:53:48 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place
In-Reply-To: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
Message-ID: <O6DDTQK4HwmBXVqD5GQ3bR1Jt7oTjWPtST06pBiESp0=.d092c506-ba8d-4e72-9b66-a0e90ec5e338@github.com>

On Sat, 22 Nov 2025 07:37:01 GMT, Steve Armstrong <duke at openjdk.org> wrote:

> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
> 
> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
> 
> Changes:
> - Added new FieldUpdaterUtil class with static utility methods:
>   * validateField() - validates field type, volatile, and static checks
>   * computeAccessClass() - determines correct class for access checks
>   * isSamePackage() - checks if two classes are in same package
>   * isAncestor() - checks classloader delegation chain
> 
> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.

This?can also?get?rid of?the?last remaining?uses of?the?legacy `sun.reflect.misc.ReflectUtil`:

--------------------------------------------------------------------------------

(`jdk.internal.reflect.Reflection` is?already?imported for?`Reflection?.getCallerClass()`)

src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 395:

> 393:                 modifiers = field.getModifiers();
> 394:                 sun.reflect.misc.ReflectUtil.ensureMemberAccess(
> 395:                     caller, tclass, null, modifiers);

Suggestion:

                Reflection.ensureMemberAccess(
                    caller, tclass, null, modifiers);

src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java line 390:

> 388:                 modifiers = field.getModifiers();
> 389:                 sun.reflect.misc.ReflectUtil.ensureMemberAccess(
> 390:                     caller, tclass, null, modifiers);

Suggestion:

                Reflection.ensureMemberAccess(
                    caller, tclass, null, modifiers);

src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java line 352:

> 350:                 modifiers = field.getModifiers();
> 351:                 sun.reflect.misc.ReflectUtil.ensureMemberAccess(
> 352:                     caller, tclass, null, modifiers);

Suggestion:

                Reflection.ensureMemberAccess(
                    caller, tclass, null, modifiers);

-------------

PR Review: https://git.openjdk.org/jdk/pull/28464#pullrequestreview-3498156901
PR Review Comment: https://git.openjdk.org/jdk/pull/28464#discussion_r2554468849
PR Review Comment: https://git.openjdk.org/jdk/pull/28464#discussion_r2554469008
PR Review Comment: https://git.openjdk.org/jdk/pull/28464#discussion_r2554469107

From jlu at openjdk.org  Mon Nov 24 21:25:09 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Nov 2025 21:25:09 GMT
Subject: Integrated: 8368001:
 java/text/Format/NumberFormat/NumberRoundTrip.java timed out
In-Reply-To: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
References: <jtugGWlfpEpak3eno0WL54XrJxEpC2_tcgjgtz2kKy8=.3c14bca3-7dd2-41c9-b32f-848a98d9acf7@github.com>
Message-ID: <7_obcIOpQ_NcANkYryTmj9TsYahuluoMPa4RwmI8r04=.77cecfa4-d60a-4f60-b608-b6776980825e@github.com>

On Thu, 20 Nov 2025 22:55:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> JDK-8260555 exposed test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java as being susceptible to timeouts.
> While the timeout factor is reverted, this test was testing too many inputs, and should be changed. 
> Originally, it was testing (~1000 locales * 4 factories) against ~30 numeric inputs. The test does not need to be exhaustive to this degree.
> 
> The total amount of locales is changed to sample around a 1/4 of those provided by the provider. The numeric inputs are reduced to about ~20. (The fixed ones remain, and the random ones are cut in half.)
> 
> Locally, I observe average execution for this test to be about ~1.3 seconds, compared to ~3.4 seconds previously. The PR also does a drive-by clean up of the test, i.e. getting rid of the unnecessary escaping + string manipulation/printing and separating the test inputs from the actual testing work done.

This pull request has now been integrated.

Changeset: 507a6d32
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/507a6d327f1c613a130273727ee4154b5b4d7ca4
Stats:     230 lines in 1 file changed: 60 ins; 132 del; 38 mod

8368001: java/text/Format/NumberFormat/NumberRoundTrip.java timed out

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/28443

From sgehwolf at openjdk.org  Mon Nov 24 22:18:47 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 24 Nov 2025 22:18:47 GMT
Subject: Integrated: 8372155: ReleaseInfoPlugin doesn't handle input file as
 UTF-8 properly
In-Reply-To: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
References: <bjQtampLAt5cAqq_BBjohv_jsDz8esA9xOZFW57CiCI=.47344f5b-153d-49ba-9604-53fcb6e5d437@github.com>
Message-ID: <nqH04KIxIA-K4SHfZt-nVO2qL7hFF5FXOScfWsmByzU=.777da723-099c-4cbd-b5a9-7aeaa14e899a@github.com>

On Wed, 19 Nov 2025 17:47:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple fix to `jlink`'s `--release-info` plugin to handle non-ASCII in vendor strings. The JDK build uses UTF-8 encoding for the produced `release` file that is being passed to `jlink` at build-time via the `--release-info` plugin. However, the plugin internally uses `java.util.Properties.load(InputStream)` API which assumes `ISO-8859-1` encoding of the input stream. The proposed fix is to use the `java.util.Prorperties.load(Reader)` API instead and pass it a `Reader` with `UTF-8` encoding (using nio API).
> 
> Testing:
> - [x] GHA
> - [x] `test/jdk/tools/jlink` tests including the new reg-test which fails prior and passes after the fix.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 42b108b4
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42b108b445b359e1d4b1043dbc1cbd42f551c19c
Stats:     93 lines in 3 files changed: 87 ins; 1 del; 5 mod

8372155: ReleaseInfoPlugin doesn't handle input file as UTF-8 properly

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/28399

From vklang at openjdk.org  Mon Nov 24 22:53:24 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 22:53:24 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <C9BEegFGUar9spiYTLDfVTLPs3OPXLrbdReFcSJu7ko=.0bc39b9f-7a95-403f-88a5-a9e5a16f67ee@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <C9BEegFGUar9spiYTLDfVTLPs3OPXLrbdReFcSJu7ko=.0bc39b9f-7a95-403f-88a5-a9e5a16f67ee@github.com>
Message-ID: <deP0xnjuB9CGlWd6RjYsmqzMVS8UjggfeMLnqpHQYLI=.a08cfc4a-80e4-470a-8782-3eae208ca849@github.com>

On Mon, 24 Nov 2025 20:47:19 GMT, kabutz <duke at openjdk.org> wrote:

>> Adds the patch by @DougLea
>
> Good work everyone :-)

Thanks for reporting, @kabutz!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28479#issuecomment-3573042033

From vklang at openjdk.org  Mon Nov 24 22:53:27 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 22:53:27 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
Message-ID: <-rtZkzC1IIATE_dxPtAwns1zZeT8Od3oDnvQemd7CAc=.da6577b5-7156-4d7b-a8b4-50a6fedf190b@github.com>

On Mon, 24 Nov 2025 17:31:20 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adds the patch by @DougLea

test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 46:

> 44:         try (var pool = Executors.newCachedThreadPool()) {
> 45:             var futures = new ArrayList<Future<Integer>>();
> 46:             var phaser = new Phaser(4);

@DougLea Would it make sense to do the following, and then only keep a single `phaser.arriveAndAwaitAdvance();` ? (and skip the explicit q.clear())

Suggestion:

            var phaser = new Phaser(4) {
                @Override
                protected boolean onAdvance(int phase, int registeredParties) {
                    q.clear();
                    return super.onAdvance(phase, registeredParties);
                }
            };

test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 68:

> 66:                 if (future.get() != 0)
> 67:                     throw new Error();
> 68:             }

@DougLea It might make sense to assert/verify that the queue is empty at the end of the test?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2557165668
PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2557168125

From vklang at openjdk.org  Mon Nov 24 22:53:28 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Nov 2025 22:53:28 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <o82wuwZJj3xXiroeRqHiKuKZ-MiL6nPZ2QNOrLa9kL0=.2a7627c5-bc99-4f74-bc31-e0aafeea14fb@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <o82wuwZJj3xXiroeRqHiKuKZ-MiL6nPZ2QNOrLa9kL0=.2a7627c5-bc99-4f74-bc31-e0aafeea14fb@github.com>
Message-ID: <-uzpPR5mM9zcBSMoUyv7mhmf6nr3XUsmlfChb_ZOwo8=.ef0455a7-feaa-4987-8675-a161c3b7e76f@github.com>

On Mon, 24 Nov 2025 18:46:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adds the patch by @DougLea
>
> test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 67:
> 
>> 65:             for (var future : futures) {
>> 66:                 if (future.get() != 0)
>> 67:                     throw new Error();
> 
> Good test, maybe change this to RuntimeException that includes the error count.

I'm not sure that the error count really helps

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2557957503

From duke at openjdk.org  Tue Nov 25 00:19:54 2025
From: duke at openjdk.org (James Yuzawa)
Date: Tue, 25 Nov 2025 00:19:54 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
Message-ID: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>

I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.

Here is a very simple reproducer:

ThreadLocalRandom r = ThreadLocalRandom.current();
// step into this call using a debugger
r.nextGaussian();


It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.

Sketch:

public interface RandomGenerator {
	default double nextGaussian() {
		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
		return RandomSupport.computeNextGaussian(this);
	}
}

public class Random implements RandomGenerator {
	@Override
	public synchronized double nextGaussian() {
		// synchronized version ...
	}
}

public class ThreadLocalRandom extends Random {

	// ADD THIS
	@Override
	public double nextGaussian() {
		return RandomSupport.computeNextGaussian(this);
	}
}


A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.

I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:


Set<String> tlrMethods = new HashSet<>();
for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
	int mod = method.getModifiers();
	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
		String desc =
				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
		tlrMethods.add(desc);
	}
}
for (Method method : java.util.Random.class.getDeclaredMethods()) {
	int mod = method.getModifiers();
	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
		String desc =
				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
		if (!tlrMethods.contains(desc)) {
			System.out.println(desc);
		}
	}
}


That prints

void nextBytes [byte[] arg0]
double nextGaussian []


The former safely calls `ThreadLocalRandom.nextInt()` internally. And the latter is fixed in this PR.

-------------

Commit messages:
 - 8372134: ThreadLocalRandom no longer overrides nextGaussian

Changes: https://git.openjdk.org/jdk/pull/28483/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28483&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372134
  Stats: 9 lines in 2 files changed: 8 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28483/head:pull/28483

PR: https://git.openjdk.org/jdk/pull/28483

From fyang at openjdk.org  Tue Nov 25 02:42:23 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 25 Nov 2025 02:42:23 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v6]
In-Reply-To: <7kh5C9nj7bf6432cG35kDDvV6zhnKEspe8AcYetJ1do=.e1d9ebd3-d80d-4621-8c1e-c77dc721d0df@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <7kh5C9nj7bf6432cG35kDDvV6zhnKEspe8AcYetJ1do=.e1d9ebd3-d80d-4621-8c1e-c77dc721d0df@github.com>
Message-ID: <UP9CeREEzOP9VnGnDOB26dIj_YiKAd5fpMG86s5SULI=.9f48cf4f-4c72-425e-a3fa-0e1e762632f4@github.com>

On Mon, 24 Nov 2025 11:56:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> 
>> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
>> 
>> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
>> 
>> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
>> 
>> # Test
>> ## Jtreg
>> 
>> in progress...
>> 
>> ## Performance
>> 
>> Column names meanings:
>> * p: with patch
>> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> * m: without patch
>> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> 
>> #### Average improvement
>> 
>> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
>> 
>> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
>> -- | -- | -- | --
>> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
>> 
>> </google-sheets-html-origin>
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix is_unordered

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2141:

> 2139:     case BoolTest::gt:
> 2140:       cmov_fp_cmp_fp_gt(op1, op2, dst, src, cmp_single, cmov_single);
> 2141:       log_warning(jit)("Float/Double BoolTest::gt path is not tested well, please report the test case!");

My local tests show this does happen. Try this:
`$ make test TEST="./test/jdk/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java" TEST_VM_OPTS="-XX:-TieredCompilation"`

I think this could be a good reference if you want to add some extra tests for the two cases here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2558363671

From duke at openjdk.org  Tue Nov 25 02:52:33 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Tue, 25 Nov 2025 02:52:33 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v2]
In-Reply-To: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
Message-ID: <IzhPq1cszIHiKzTfOJhyKTNkSWIlcUkf0Gb3NcebISo=.c23aae6c-617b-465d-af3c-b956f94062eb@github.com>

> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
> 
> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
> 
> Changes:
> - Added new FieldUpdaterUtil class with static utility methods:
>   * validateField() - validates field type, volatile, and static checks
>   * computeAccessClass() - determines correct class for access checks
>   * isSamePackage() - checks if two classes are in same package
>   * isAncestor() - checks classloader delegation chain
> 
> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.

Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:

  Replace legacy ReflectUtil with modern Reflection API
  
  Replaced sun.reflect.misc.ReflectUtil with jdk.internal.reflect.Reflection
  in atomic field updaters. Added getFieldWithAccess() method and
  FieldAndModifiers record to FieldUpdaterUtil to consolidate field
  access checking logic.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28464/files
  - new: https://git.openjdk.org/jdk/pull/28464/files/76a74fa2..72f27359

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28464&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28464&range=00-01

  Stats: 74 lines in 4 files changed: 30 ins; 28 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28464/head:pull/28464

PR: https://git.openjdk.org/jdk/pull/28464

From duke at openjdk.org  Tue Nov 25 02:52:34 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Tue, 25 Nov 2025 02:52:34 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v2]
In-Reply-To: <O6DDTQK4HwmBXVqD5GQ3bR1Jt7oTjWPtST06pBiESp0=.d092c506-ba8d-4e72-9b66-a0e90ec5e338@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <O6DDTQK4HwmBXVqD5GQ3bR1Jt7oTjWPtST06pBiESp0=.d092c506-ba8d-4e72-9b66-a0e90ec5e338@github.com>
Message-ID: <udOco5o9NroC-N10amjHFS8POu6TpSFelDWlvV0CRbo=.5397bffc-b8d8-4665-bdf1-f5cda4719a0b@github.com>

On Mon, 24 Nov 2025 01:18:41 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace legacy ReflectUtil with modern Reflection API
>>   
>>   Replaced sun.reflect.misc.ReflectUtil with jdk.internal.reflect.Reflection
>>   in atomic field updaters. Added getFieldWithAccess() method and
>>   FieldAndModifiers record to FieldUpdaterUtil to consolidate field
>>   access checking logic.
>
> This?can also?get?rid of?the?last remaining?uses of?the?legacy `sun.reflect.misc.ReflectUtil`:
> 
> --------------------------------------------------------------------------------
> 
> (`jdk.internal.reflect.Reflection` is?already?imported for?`Reflection?.getCallerClass()`)

Thanks @ExE-Boss for the review! I've updated the code to replace the legacy `sun.reflect.misc.ReflectUtil` with the modern `jdk.internal.reflect.Reflection` API. The changes consolidate the field access checking into `FieldUpdaterUtil.getFieldWithAccess()` and use a record for `FieldAndModifiers`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3573569169

From liach at openjdk.org  Tue Nov 25 03:08:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 03:08:13 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v2]
In-Reply-To: <IzhPq1cszIHiKzTfOJhyKTNkSWIlcUkf0Gb3NcebISo=.c23aae6c-617b-465d-af3c-b956f94062eb@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <IzhPq1cszIHiKzTfOJhyKTNkSWIlcUkf0Gb3NcebISo=.c23aae6c-617b-465d-af3c-b956f94062eb@github.com>
Message-ID: <ExD3pxR16prPU90oxulzNfTiQaYP9S4vFf5z4fmceko=.0e7697f6-1a53-42bf-8921-8d1c487da1f5@github.com>

On Tue, 25 Nov 2025 02:52:33 GMT, Steve Armstrong <duke at openjdk.org> wrote:

>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
>> 
>> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
>> 
>> Changes:
>> - Added new FieldUpdaterUtil class with static utility methods:
>>   * validateField() - validates field type, volatile, and static checks
>>   * computeAccessClass() - determines correct class for access checks
>>   * isSamePackage() - checks if two classes are in same package
>>   * isAncestor() - checks classloader delegation chain
>> 
>> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.
>
> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace legacy ReflectUtil with modern Reflection API
>   
>   Replaced sun.reflect.misc.ReflectUtil with jdk.internal.reflect.Reflection
>   in atomic field updaters. Added getFieldWithAccess() method and
>   FieldAndModifiers record to FieldUpdaterUtil to consolidate field
>   access checking logic.

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 391:

> 389:             FieldUpdaterUtil.FieldAndModifiers fam =
> 390:                 FieldUpdaterUtil.getFieldWithAccess(tclass, fieldName, caller);
> 391:             FieldUpdaterUtil.validateField(fam.field, int.class);

Consider using this code sequence:


Field field = FieldUpdaterUtil.findValidatedField(tclass, fieldName, caller, int.class);
this.cclass = FieldUpdaterUtil.computeAccessClass(tclass, caller, field.getModifiers());
this.tclass = tclass;
this.offset = U.objectFieldOffset(field);

-------------

PR Review: https://git.openjdk.org/jdk/pull/28464#pullrequestreview-3503100202
PR Review Comment: https://git.openjdk.org/jdk/pull/28464#discussion_r2558406263

From duke at openjdk.org  Tue Nov 25 03:42:43 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 25 Nov 2025 03:42:43 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses
 non-optimal VarHandle
In-Reply-To: <dehcNf9NOPaLmX8d1z0yfzbUMbiMWguCbtHDj-Gj0ls=.fb7b70f0-3abe-48fd-bbed-d1e6735a7ff0@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
 <5FRhEijv2BzqGiDJtgOLRcSvyJtDka0GttpAIvTnVW8=.f7c44c42-fefb-4b87-98df-ae8f37939402@github.com>
 <dehcNf9NOPaLmX8d1z0yfzbUMbiMWguCbtHDj-Gj0ls=.fb7b70f0-3abe-48fd-bbed-d1e6735a7ff0@github.com>
Message-ID: <ua4zXw_8WgO6OQSeDDG-iyMx1qVfaNJdZVEDTHAKrVM=.b0ddc4c1-bc46-468c-846d-8ed7885459fd@github.com>

On Mon, 24 Nov 2025 19:23:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This is not the first time this VarHandle problem is hit - see #16451
>
>> This has bitten me lot of times @liach ? Including others while reading/writing oop fields into arrays too; it would be nice to get an option to fail fast with an exception enabled via diagnostic args eg EnableStrictPolymorphicSignature Although Javac should be able to detect it too, thinking about it twice
> 
> This can be done using [`VarHandle::withInvokeExactBehavior`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#withInvokeExactBehavior()) on a per var handle basis. C2 can constant fold the type-check away as well.

@JornVernee thanks ? I admit it's the first time I see this method, wow

@JornVernee thanks ? I admit it's the first time I see this method, wow

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3573655519
PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3573655546

From chen.l.liang at oracle.com  Tue Nov 25 03:45:44 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 25 Nov 2025 03:45:44 +0000
Subject: Add better exception message to FileTreeIterator.hasNext()?
In-Reply-To: <CAA9v-_O+9vNXWRDSLu7Ct=EXueybtaVzPY8g9+sxVopxSCFX=g@mail.gmail.com>
References: <CAA9v-_O+9vNXWRDSLu7Ct=EXueybtaVzPY8g9+sxVopxSCFX=g@mail.gmail.com>
Message-ID: <SJ2PR10MB76695EF15E19C75F2531DC63A2D1A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hello, David,
I don't think this is necessary - the cause of the exception is already quite clear from the stack trace. I checked a few use sites of the no-arg constructor of IllegalStateException - many of them are in the same situation, that they are easy to understand once we see their location in code. I assume such a use of no-arg ISE constructor is widely accepted.

For error messages, sometimes it is not feasible to be too detailed - I would think if we do add any, something like "closed" would be sufficient. Printing too many details in exceptions and log messages can sometimes constitute security risks.

For the stream part, I believe both Files.walk and Stream.flatMap do their job - walk specifies you should close after use, and flatMap specifies the returned streams are closed once their elements are all taken. However, I do agree that there are possible documentation enhancements, that:
1. Stream factories should specify if their elements are still usable after the streams are closed, and
2. Stream should note that they should be closed after a terminal operation (which is the fault you made here)

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Monday, November 24, 2025 1:38 PM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Add better exception message to FileTreeIterator.hasNext()?

Hello @core-libs-dev<mailto:core-libs-dev at openjdk.org>,

I was writing a simple script today -- find how many Java files are in each of my top level folders of my current directory.

So, I ran the following code.

Files
    list(Path.of("."))
    filter(Files::isDirectory)
    collect

        Collectors.groupingBy(
        Function.<Path>identity(),
        Collectors
            .flatMapping
            (
                (final Path root) ->
                {
                    try (final Stream<Path> streamWalker = Files.walk(root))
                    {
                        return
                            streamWalker
                                .filter(Files::isRegularFile)
                                .filter(file -> file.toString().endsWith(".java"))
                                ;
                    }
                    catch (final Exception exception)
                    {
                        throw new RuntimeException(exception);
                    }
                },
                Collectors.counting()
            )
        )
        ;

Now, there is a not-so-obvious bug -- when using a flatMapping Collector, no need for try-with-resources.

The above code threw the below stack trace.

|  Exception java.lang.IllegalStateException
|        at FileTreeIterator.hasNext (FileTreeIterator.java:100)
|        at Iterator.forEachRemaining (Iterator.java:132)
|        at Spliterators$IteratorSpliterator.forEachRemaining (Spliterators.java:1939)
|        at AbstractPipeline.copyInto (AbstractPipeline.java:570)
|        at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
|        at ForEachOps$ForEachOp.evaluateSequential (ForEachOps.java:153)
|        at ForEachOps$ForEachOp$OfRef.evaluateSequential (ForEachOps.java:176)
|        at AbstractPipeline.evaluate (AbstractPipeline.java:265)
|        at ReferencePipeline.forEach (ReferencePipeline.java:632)
|        at Collectors.lambda$flatMapping$0 (Collectors.java:483)
|        at Collectors.lambda$groupingBy$0 (Collectors.java:1113)
|        at ReduceOps$3ReducingSink.accept (ReduceOps.java:169)
|        at ReferencePipeline$2$1.accept (ReferencePipeline.java:197)
|        at Iterator.forEachRemaining (Iterator.java:133)
|        at Spliterators$IteratorSpliterator.forEachRemaining (Spliterators.java:1939)
|        at AbstractPipeline.copyInto (AbstractPipeline.java:570)
|        at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
|        at ReduceOps$ReduceOp.evaluateSequential (ReduceOps.java:921)
|        at AbstractPipeline.evaluate (AbstractPipeline.java:265)
|        at ReferencePipeline.collect (ReferencePipeline.java:723)
|        at (#4:5)


Not obvious what is wrong here.

Now, the exception message is being thrown by the hasNext() method of the FileTreeIterator class. After looking at the source code of that class, it's clear what the problem is.

https://github.com/openjdk/jdk/blob/jdk-26%2B25/src/java.base/share/classes/java/nio/file/FileTreeIterator.java#L98

It throws an exception because the FileTreeWalker contained within the FileTreeIterator is closed (presumably by the try-with-resources). However, the thrown exception message is empty. This exact same check-then-throw logic is duplicated all over FileTreeIterator.

I propose that all such instances of check-then-throw be provided with exception messages along the lines of "Cannot check for more elements because the file walker is already closed!". I am not picky on the wording. Just something to inform me that the issue is something is closed, as opposed to just a generic IllegalStateException. I would even accept an empty message body if the exception type communicated the issue.

Thank you for your time.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251125/e371d5cc/attachment-0001.htm>

From duke at openjdk.org  Tue Nov 25 03:45:45 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Tue, 25 Nov 2025 03:45:45 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v2]
In-Reply-To: <ExD3pxR16prPU90oxulzNfTiQaYP9S4vFf5z4fmceko=.0e7697f6-1a53-42bf-8921-8d1c487da1f5@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <IzhPq1cszIHiKzTfOJhyKTNkSWIlcUkf0Gb3NcebISo=.c23aae6c-617b-465d-af3c-b956f94062eb@github.com>
 <ExD3pxR16prPU90oxulzNfTiQaYP9S4vFf5z4fmceko=.0e7697f6-1a53-42bf-8921-8d1c487da1f5@github.com>
Message-ID: <76XEq9FdSjGhdUyfxy9rEh48ycipus_3UrZzkijWEqY=.7ee77dd4-a34f-4a62-863f-b53db88000ea@github.com>

On Tue, 25 Nov 2025 03:06:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace legacy ReflectUtil with modern Reflection API
>>   
>>   Replaced sun.reflect.misc.ReflectUtil with jdk.internal.reflect.Reflection
>>   in atomic field updaters. Added getFieldWithAccess() method and
>>   FieldAndModifiers record to FieldUpdaterUtil to consolidate field
>>   access checking logic.
>
> Changes requested by liach (Reviewer).

Thanks @liach! Refactored to use `findValidatedField()` as suggested. Much cleaner API - eliminates the redundant record and combines everything into one call.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3573661859

From duke at openjdk.org  Tue Nov 25 03:56:10 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Tue, 25 Nov 2025 03:56:10 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v3]
In-Reply-To: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
Message-ID: <gcWZ-LkZtwr8thtMo5Blw08RVO_2gc5m3EYmjz9WbuQ=.d5b6d6fe-cb7e-4573-97ed-bb203750b1e0@github.com>

> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
> 
> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
> 
> Changes:
> - Added new FieldUpdaterUtil class with static utility methods:
>   * validateField() - validates field type, volatile, and static checks
>   * computeAccessClass() - determines correct class for access checks
>   * isSamePackage() - checks if two classes are in same package
>   * isAncestor() - checks classloader delegation chain
> 
> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.

Steve Armstrong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Refactor FieldUpdaterUtil API based on review feedback
  
  Simplified the API by combining field lookup and validation into a
  single findValidatedField() method, eliminating the need for the
  redundant FieldAndModifiers record since Field already provides
  getModifiers(). This makes the API more ergonomic and the caller
  code more concise.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28464/files
  - new: https://git.openjdk.org/jdk/pull/28464/files/72f27359..c9a98483

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28464&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28464&range=01-02

  Stats: 72 lines in 4 files changed: 7 ins; 34 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/28464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28464/head:pull/28464

PR: https://git.openjdk.org/jdk/pull/28464

From liach at openjdk.org  Tue Nov 25 04:01:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 04:01:54 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v9]
In-Reply-To: <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
Message-ID: <NKpEL3HGo3wwWc4gHC-O9TzBrpBGMKKPPlEU18XmnaY=.6a00ba80-f9c2-4fdc-b9f6-9835f02de060@github.com>

On Thu, 20 Nov 2025 16:30:56 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

I have submitted this patch with the latest mainline merged for CI testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28226#issuecomment-3573684224

From almatvee at openjdk.org  Tue Nov 25 04:06:04 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 25 Nov 2025 04:06:04 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
Message-ID: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>

Added following tests:
- Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
- `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
- `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

-------------

Commit messages:
 - 8351095: [macos] Add more jpackage tests for --mac-app-store option

Changes: https://git.openjdk.org/jdk/pull/28487/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351095
  Stats: 53 lines in 4 files changed: 35 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28487/head:pull/28487

PR: https://git.openjdk.org/jdk/pull/28487

From liach at openjdk.org  Tue Nov 25 04:08:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 04:08:21 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v3]
In-Reply-To: <gcWZ-LkZtwr8thtMo5Blw08RVO_2gc5m3EYmjz9WbuQ=.d5b6d6fe-cb7e-4573-97ed-bb203750b1e0@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <gcWZ-LkZtwr8thtMo5Blw08RVO_2gc5m3EYmjz9WbuQ=.d5b6d6fe-cb7e-4573-97ed-bb203750b1e0@github.com>
Message-ID: <LOoHudDUurifkiaziqTUtCV5SWOz1V7udKV0yp21OI4=.c121153d-794d-4005-bceb-6978f3d7f2bf@github.com>

On Tue, 25 Nov 2025 03:56:10 GMT, Steve Armstrong <duke at openjdk.org> wrote:

>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
>> 
>> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
>> 
>> Changes:
>> - Added new FieldUpdaterUtil class with static utility methods:
>>   * validateField() - validates field type, volatile, and static checks
>>   * computeAccessClass() - determines correct class for access checks
>>   * isSamePackage() - checks if two classes are in same package
>>   * isAncestor() - checks classloader delegation chain
>> 
>> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.
>
> Steve Armstrong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Refactor FieldUpdaterUtil API based on review feedback
>   
>   Simplified the API by combining field lookup and validation into a
>   single findValidatedField() method, eliminating the need for the
>   redundant FieldAndModifiers record since Field already provides
>   getModifiers(). This makes the API more ergonomic and the caller
>   code more concise.

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/util/concurrent/atomic/FieldUpdaterUtil.java line 65:

> 63:             Reflection.ensureMemberAccess(caller, tclass, null, modifiers);
> 64: 
> 65:             Class<?> fieldType = field.getType();

The try block must end right here. You are wrapping the IllegalArgumentException into RuntimeException incorrectly. Make sure you run

make test TEST="jdk/java/util/concurrent/tck jdk/java/util/concurrent/atomic"

tests for your changes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28464#pullrequestreview-3503179225
PR Review Comment: https://git.openjdk.org/jdk/pull/28464#discussion_r2558475923

From duke at openjdk.org  Tue Nov 25 04:26:08 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Tue, 25 Nov 2025 04:26:08 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v4]
In-Reply-To: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
Message-ID: <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>

> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
> 
> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
> 
> Changes:
> - Added new FieldUpdaterUtil class with static utility methods:
>   * validateField() - validates field type, volatile, and static checks
>   * computeAccessClass() - determines correct class for access checks
>   * isSamePackage() - checks if two classes are in same package
>   * isAncestor() - checks classloader delegation chain
> 
> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.

Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:

  Fix try-catch block to not wrap IllegalArgumentException
  
  The validation exceptions should be thrown directly to the caller,
  not wrapped in RuntimeException. Only the field lookup and access
  checking code should be in the try-catch block.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28464/files
  - new: https://git.openjdk.org/jdk/pull/28464/files/c9a98483..db099fe9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28464&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28464&range=02-03

  Stats: 31 lines in 1 file changed: 11 ins; 9 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28464/head:pull/28464

PR: https://git.openjdk.org/jdk/pull/28464

From duke at openjdk.org  Tue Nov 25 04:26:11 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Tue, 25 Nov 2025 04:26:11 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v3]
In-Reply-To: <gcWZ-LkZtwr8thtMo5Blw08RVO_2gc5m3EYmjz9WbuQ=.d5b6d6fe-cb7e-4573-97ed-bb203750b1e0@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <gcWZ-LkZtwr8thtMo5Blw08RVO_2gc5m3EYmjz9WbuQ=.d5b6d6fe-cb7e-4573-97ed-bb203750b1e0@github.com>
Message-ID: <2OHwLEhKCyt4sMbASrYWvBQg7AUqsSdX44Mt3C6wC40=.7e2ee503-02d3-4730-87a6-81318b53abdd@github.com>

On Tue, 25 Nov 2025 03:56:10 GMT, Steve Armstrong <duke at openjdk.org> wrote:

>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
>> 
>> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
>> 
>> Changes:
>> - Added new FieldUpdaterUtil class with static utility methods:
>>   * validateField() - validates field type, volatile, and static checks
>>   * computeAccessClass() - determines correct class for access checks
>>   * isSamePackage() - checks if two classes are in same package
>>   * isAncestor() - checks classloader delegation chain
>> 
>> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.
>
> Steve Armstrong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Refactor FieldUpdaterUtil API based on review feedback
>   
>   Simplified the API by combining field lookup and validation into a
>   single findValidatedField() method, eliminating the need for the
>   redundant FieldAndModifiers record since Field already provides
>   getModifiers(). This makes the API more ergonomic and the caller
>   code more concise.

Thanks for catching that! Fixed the try-catch block - validation exceptions are now thrown directly. Couldn't run the full test suite locally due to Xcode requirements, but verified the fix logic with a standalone test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3573721117

From liach at openjdk.org  Tue Nov 25 04:34:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 04:34:10 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries
In-Reply-To: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
Message-ID: <bFM8lu1TL_EVBacOz2in-Z2x1Ln1egd7YdA91Ka9a3M=.d5d4df5b-8457-47be-bb5a-f9f7eae137c2@github.com>

On Fri, 21 Nov 2025 16:54:48 GMT, Trevor Bond <duke at openjdk.org> wrote:

> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
> 
> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
> 
> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
> 
> | Version | Avg Time (ns/op) | ? vs Before |
> |--------|------------------:|-------------|
> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |

Looks good in principle. Even though people wonder about the buffering policy, I think it is negligible considering that we have caching mechanism. And the constant pool is flexible sized, so "only read the classfile header" might be an optimisitic assumption.

Also, the key to this patch is not performance - it is about the maintainability from a consistent way to parse class files, so in the future, we don't need to update this site any more if we have new constant pool entry type or other format expansions.

src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 171:

> 169:             if (ci == null) return null;
> 170:             try (ci) {
> 171:                 ClassReader reader = new ClassReaderImpl(ci.readAllBytes(), (ClassFileImpl) ClassFile.of());

Suggestion:

                var reader = new ClassReaderImpl(ci.readAllBytes(), ClassFileImpl.DEFAULT_CONTEXT);

And you can remove the 3 imports you have added.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28458#pullrequestreview-3503212041
PR Comment: https://git.openjdk.org/jdk/pull/28458#issuecomment-3573741129
PR Review Comment: https://git.openjdk.org/jdk/pull/28458#discussion_r2558503313

From liach at openjdk.org  Tue Nov 25 05:07:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 05:07:25 GMT
Subject: RFR: 8372258: Improve TypeVariable support [v2]
In-Reply-To: <Rr2yCD1TNZBzl3FEpHmhH5EJSomZndcuJHTTtxEQf5w=.1fedc059-3cc3-433a-ad3b-7c277cf3457a@github.com>
References: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
 <Rr2yCD1TNZBzl3FEpHmhH5EJSomZndcuJHTTtxEQf5w=.1fedc059-3cc3-433a-ad3b-7c277cf3457a@github.com>
Message-ID: <q68-XaAUDrqfopjY3PymOkVqfwxl66Ej1TGpWqnWWh8=.9f9f2a70-104e-4bc8-8e72-6e7d657ece9d@github.com>

On Mon, 24 Nov 2025 10:03:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change docs for TypeVaiable

This version looks better. Meanwhile you can update the copyright header of TypeVariable.java.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28429#pullrequestreview-3503281421

From shaojin.wensj at alibaba-inc.com  Tue Nov 25 05:12:59 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Tue, 25 Nov 2025 13:12:59 +0800
Subject: =?UTF-8?B?VXNlIEVudW1NYXAgaW5zdGVhZCBvZiBIYXNoTWFwIGZvciBEYXRlVGltZUZvcm1hdHRlciBw?=
 =?UTF-8?B?YXJzaW5nIHRvIGltcHJvdmUgcGVyZm9ybWFuY2U=?=
Message-ID: <2cee5113-783a-4dc7-b103-99ea39fa5df3.shaojin.wensj@alibaba-inc.com>

When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
Parsing scenarios show improvements from 12% to 95%.
To better express my ideas, I submitted a draft PR: https://github.com/openjdk/jdk/pull/28471 <https://github.com/openjdk/jdk/pull/28471 > , and I hope you can give me feedback.
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251125/de423335/attachment.htm>

From liach at openjdk.org  Tue Nov 25 05:49:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 05:49:02 GMT
Subject: RFR: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder() [v9]
In-Reply-To: <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
 <qiJyGDDXhz9dH9JzLDNP2i3_KJCn7TES_T0yVXaqQWc=.331e1f52-cd61-42ee-95bb-09c6bb098938@github.com>
Message-ID: <Awqx9vq4hDBfdPJaxaTmEfZvS3DICUwE8j3jSieL9CU=.59e6c700-fe12-4dac-bafb-c01d0e1f5328@github.com>

On Thu, 20 Nov 2025 16:30:56 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
>> 
>> Example:
>> 
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted().forEach(System.out::println);
>> 
>> or
>> 
>> TreeSet<Integer> sortedSet = new TreeSet<>();
>> sortedSet.add(1);
>> sortedSet.add(2);
>> // SortedOps.OfRef.opWrapSink is not a no-op
>> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
>> 
>> 
>> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

CI results look good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28226#pullrequestreview-3503351434

From chen.l.liang at oracle.com  Tue Nov 25 06:03:45 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 25 Nov 2025 06:03:45 +0000
Subject: Use EnumMap instead of HashMap for DateTimeFormatter parsing to
 improve performance
In-Reply-To: <2cee5113-783a-4dc7-b103-99ea39fa5df3.shaojin.wensj@alibaba-inc.com>
References: <2cee5113-783a-4dc7-b103-99ea39fa5df3.shaojin.wensj@alibaba-inc.com>
Message-ID: <SJ2PR10MB7669A2EFF540A9F6ADB81E54A2D1A@SJ2PR10MB7669.namprd10.prod.outlook.com>

I agree with this observation that most of the parsed or stored temporal fields are the built-in chrono fields. With this optimization, we might need to review our tests to ensure we won't run into crashes if we incorrectly assumed a parsing context has only chrono fields.
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of wenshao <shaojin.wensj at alibaba-inc.com>
Sent: Monday, November 24, 2025 11:12 PM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance

When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.

Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.

Parsing scenarios show improvements from 12% to 95%.

To better express my ideas, I submitted a draft PR: https://github.com/openjdk/jdk/pull/28471 , and I hope you can give me feedback.

-
Shaojin Wen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251125/0a279984/attachment.htm>

From liach at openjdk.org  Tue Nov 25 06:32:36 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 06:32:36 GMT
Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter
 parsing to improve performance
In-Reply-To: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
Message-ID: <CWI1mtJmSm-aGY8gOjHXGnmkoPQdUU8eMskPZA2BFVU=.bcb6455d-d04d-4cb9-96ab-6366db241f65@github.com>

On Mon, 24 Nov 2025 08:02:35 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
> 
> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
> 
> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
> 
> Parsing scenarios show improvements from 12% to 95%

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2593:

> 2591:             for (DateTimePrinterParser pp : printerParsers) {
> 2592:                 if ((pp instanceof NumberPrinterParser    npp && !(npp.field instanceof ChronoField))
> 2593:                  || (pp instanceof CompositePrinterParser cpp && !cpp.onlyChronoField())) {

Missing check for `TextPrinterParser`

src/java.base/share/classes/java/time/format/Parsed.java line 134:

> 132:         if (onlyChronoField) {
> 133:             return new HashMap<>();
> 134:         } else {

Is this condition inverted :thinking: seems like it but how do you get the performance numbers

-------------

PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3502735627
PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2558118611
PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2558120676

From swen at openjdk.org  Tue Nov 25 06:32:34 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 25 Nov 2025 06:32:34 GMT
Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter
 parsing to improve performance
Message-ID: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>

This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.

When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.

Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.

Parsing scenarios show improvements from 12% to 95%

-------------

Commit messages:
 - bug fix, form @liach
 - use EnumMap
 - add benchmark

Changes: https://git.openjdk.org/jdk/pull/28471/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372460
  Stats: 153 lines in 5 files changed: 149 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471

PR: https://git.openjdk.org/jdk/pull/28471

From swen at openjdk.org  Tue Nov 25 06:32:37 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 25 Nov 2025 06:32:37 GMT
Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter
 parsing to improve performance
In-Reply-To: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
Message-ID: <-1FtUeUFm9JM8dRl4kyOMwYASWBnVxKgAvLZclN480Q=.13cac2c7-f9b7-4397-8415-1a7fb3aec078@github.com>

On Mon, 24 Nov 2025 08:02:35 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
> 
> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
> 
> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
> 
> Parsing scenarios show improvements from 12% to 95%

# 1. Shell
We run the following Shell command

# master
git checkout b6495573e9dc5470df268b63f8e7a93f38406cd2
make test TEST="micro:java.time.format.DateTimeFormatterParse"

# this pr
git checkout d8742d7514abfe0e36f105fa7310fdb1755ae546
make test TEST="micro:java.time.format.DateTimeFormatterParse"



# 2. Raw Benchmark Data

Performance data running on a MacBook M1 Pro:


# b649557 (master)
Benchmark                                           Mode  Cnt     Score     Error   Units
DateTimeFormatterParse.parseInstant                thrpt   15  2066.130 ? 126.134  ops/ms
DateTimeFormatterParse.parseLocalDate              thrpt   15  5014.987 ? 424.759  ops/ms
DateTimeFormatterParse.parseLocalDateTime          thrpt   15  3821.083 ? 390.928  ops/ms
DateTimeFormatterParse.parseLocalDateTimeWithNano  thrpt   15  3529.090 ? 209.195  ops/ms
DateTimeFormatterParse.parseLocalTime              thrpt   15  4275.904 ? 335.752  ops/ms
DateTimeFormatterParse.parseLocalTimeWithNano      thrpt   15  4596.255 ? 195.175  ops/ms
DateTimeFormatterParse.parseOffsetDateTime         thrpt   15  2330.924 ? 152.061  ops/ms
DateTimeFormatterParse.parseZonedDateTime          thrpt   15  1837.753 ? 107.873  ops/ms

# d8742d7 (this pr)
Benchmark                                           Mode  Cnt     Score     Error   Units
DateTimeFormatterParse.parseInstant                thrpt   15  2900.168 ?  56.079  ops/ms
DateTimeFormatterParse.parseLocalDate              thrpt   15  9787.592 ? 384.437  ops/ms
DateTimeFormatterParse.parseLocalDateTime          thrpt   15  5046.838 ? 271.451  ops/ms
DateTimeFormatterParse.parseLocalDateTimeWithNano  thrpt   15  3963.050 ? 434.662  ops/ms
DateTimeFormatterParse.parseLocalTime              thrpt   15  8196.707 ? 329.547  ops/ms
DateTimeFormatterParse.parseLocalTimeWithNano      thrpt   15  8387.213 ? 652.292  ops/ms
DateTimeFormatterParse.parseOffsetDateTime         thrpt   15  3291.076 ? 294.889  ops/ms
DateTimeFormatterParse.parseZonedDateTime          thrpt   15  2069.595 ? 293.385  ops/ms


# 3. Performance Comparison


Performance Comparison: b6495573e9dc5470df268b63f8e7a93f38406cd2 vs d8742d7514abfe0e36f105fa7310fdb1755ae546

| Benchmark | b6495573e9dc5470df268b63f8e7a93f38406cd2 | d8742d7514abfe0e36f105fa7310fdb1755ae546 | Improvement Factor |
| --- | --- | --- | --- |
| DateTimeFormatterParse.parseInstant | 2066.130 ? 126.134 | 2900.168 ? 56.079 | 1.404x |
| DateTimeFormatterParse.parseLocalDate | 5014.987 ? 424.759 | 9787.592 ? 384.437 | 1.952x |
| DateTimeFormatterParse.parseLocalDateTime | 3821.083 ? 390.928 | 5046.838 ? 271.451 | 1.321x |
| DateTimeFormatterParse.parseLocalDateTimeWithNano | 3529.090 ? 209.195 | 3963.050 ? 434.662 | 1.123x |
| DateTimeFormatterParse.parseLocalTime | 4275.904 ? 335.752 | 8196.707 ? 329.547 | 1.919x |
| DateTimeFormatterParse.parseLocalTimeWithNano | 4596.255 ? 195.175 | 8387.213 ? 652.292 | 1.825x |
| DateTimeFormatterParse.parseOffsetDateTime | 2330.924 ? 152.061 | 3291.076 ? 294.889 | 1.412x |
| DateTimeFormatterParse.parseZonedDateTime | 1837.753 ? 107.873 | 2069.595 ? 293.385 | 1.126x |

java/time/tck/java/time/temporal/TCKWeekFields.java
java/time/tck/java/time/temporal/TCKIsoFields.java
java/time/tck/java/time/temporal/TCKJulianFields.java
java/time/tck/java/time/format/TCKDateTimeParseResolver.java
java/time/tck/java/time/format/TCKLocalizedFieldParser.java
java/time/tck/java/time/format/TCKDateTimeFormatters.java
java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java

The existing tests above can cover the cases where there are no non-ChronoFields, so no additional tests are needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3571582110
PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3573936930

From swen at openjdk.org  Tue Nov 25 06:32:38 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 25 Nov 2025 06:32:38 GMT
Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter
 parsing to improve performance
In-Reply-To: <CWI1mtJmSm-aGY8gOjHXGnmkoPQdUU8eMskPZA2BFVU=.bcb6455d-d04d-4cb9-96ab-6366db241f65@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <CWI1mtJmSm-aGY8gOjHXGnmkoPQdUU8eMskPZA2BFVU=.bcb6455d-d04d-4cb9-96ab-6366db241f65@github.com>
Message-ID: <lNiorLURFtechlx2q3Xf4jBorUrN-sAv_GKwdojbyvA=.6fdcf466-8cd1-4cc5-aa46-ab0a69398165@github.com>

On Tue, 25 Nov 2025 00:31:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
>> 
>> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
>> 
>> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
>> 
>> Parsing scenarios show improvements from 12% to 95%
>
> src/java.base/share/classes/java/time/format/Parsed.java line 134:
> 
>> 132:         if (onlyChronoField) {
>> 133:             return new HashMap<>();
>> 134:         } else {
> 
> Is this condition inverted :thinking: seems like it but how do you get the performance numbers

You're right, it's reversed, it's written incorrectly. And this should be in the constructor, not here. The placement is wrong, but it's still using EnumMap, so the performance is still improved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2558252666

From swen at openjdk.org  Tue Nov 25 06:44:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 25 Nov 2025 06:44:57 GMT
Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter
 parsing to improve performance [v2]
In-Reply-To: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
Message-ID: <QL431F7FEFZCl3ftcvvWq5pwLgbKBfEcQ6QFSRiKcFc=.1945b2f4-508b-467b-b073-1310d5f5ef79@github.com>

> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
> 
> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
> 
> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
> 
> Parsing scenarios show improvements from 12% to 95%

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28471/files
  - new: https://git.openjdk.org/jdk/pull/28471/files/5a050fe9..7137d9ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471

PR: https://git.openjdk.org/jdk/pull/28471

From alanb at openjdk.org  Tue Nov 25 07:08:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Nov 2025 07:08:59 GMT
Subject: Integrated: 8370887: DelayScheduler.replace method may break the 4-ary
 heap in certain scenarios
In-Reply-To: <_veOR6nBK5qZz30ocpfk3ue0Kc2NwzO-0K2WlBZ4a54=.f6976469-a984-42e0-83a3-a48e8312f3f3@github.com>
References: <_veOR6nBK5qZz30ocpfk3ue0Kc2NwzO-0K2WlBZ4a54=.f6976469-a984-42e0-83a3-a48e8312f3f3@github.com>
Message-ID: <POyBHXJep-Bj38KwK55oKldDfC2r5ROMhqlCy6KL56A=.182be276-687f-450d-a3da-3e93e1f88943@github.com>

On Sun, 23 Nov 2025 08:08:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> DelayScheduler.replace missing check to sift up when replaced with smaller value. checkHeap checks invariants when replacing. Executing tests with make run-test or other targets runs tests with -esa so assume is enabled.
> 
> New regression test to ensure delayed tests executes in expected delay order.

This pull request has now been integrated.

Changeset: cc5b35bf
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc5b35bf69dcf9e7e8037642c94e8d7e5847952d
Stats:     199 lines in 2 files changed: 181 ins; 8 del; 10 mod

8370887: DelayScheduler.replace method may break the 4-ary heap in certain scenarios

Co-authored-by: Doug Lea <dl at openjdk.org>
Reviewed-by: vklang

-------------

PR: https://git.openjdk.org/jdk/pull/28469

From alanb at openjdk.org  Tue Nov 25 07:51:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Nov 2025 07:51:38 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses
 non-optimal VarHandle
In-Reply-To: <ua4zXw_8WgO6OQSeDDG-iyMx1qVfaNJdZVEDTHAKrVM=.b0ddc4c1-bc46-468c-846d-8ed7885459fd@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
 <5FRhEijv2BzqGiDJtgOLRcSvyJtDka0GttpAIvTnVW8=.f7c44c42-fefb-4b87-98df-ae8f37939402@github.com>
 <dehcNf9NOPaLmX8d1z0yfzbUMbiMWguCbtHDj-Gj0ls=.fb7b70f0-3abe-48fd-bbed-d1e6735a7ff0@github.com>
 <ua4zXw_8WgO6OQSeDDG-iyMx1qVfaNJdZVEDTHAKrVM=.b0ddc4c1-bc46-468c-846d-8ed7885459fd@github.com>
Message-ID: <eJuAxEZ1bY0WXJM5DdwTrMWWZV-89hQG0wpiVa1H9bE=.cb6c30ff-449c-4f62-bfe4-41b61594b4c6@github.com>

On Tue, 25 Nov 2025 03:38:41 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>>> This has bitten me lot of times @liach ? Including others while reading/writing oop fields into arrays too; it would be nice to get an option to fail fast with an exception enabled via diagnostic args eg EnableStrictPolymorphicSignature Although Javac should be able to detect it too, thinking about it twice
>> 
>> This can be done using [`VarHandle::withInvokeExactBehavior`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#withInvokeExactBehavior()) on a per var handle basis. C2 can constant fold the type-check away as well.
>
> @JornVernee thanks ? I admit it's the first time I see this method, wow

@franz1981 You can type "/integrate" into a comment and I will sponsor. I ran tests with the change yesterday and all good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3574186718

From hgreule at openjdk.org  Tue Nov 25 07:55:24 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 25 Nov 2025 07:55:24 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses
 non-optimal VarHandle
In-Reply-To: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
Message-ID: <6UUK37Tl4q4W2siAx18JxIqdQ-K_TIg9ykmgodbaSM8=.11eefab7-3df7-4ff5-a063-e3e0b2bae4f9@github.com>

On Mon, 24 Nov 2025 13:05:40 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
> 
> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
> 
> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
> 
> Benchmark                                                                Mode  Cnt   Score   Error  Units
> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
> 
> where the `right` indy shows:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
> 
> vs the `wrong` one:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />

I wonder if `MhUtil.findVarHandle(...)` should make VarHandles with invokeExact behavior by default, to catch such problems earlier in the JDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3574208351

From duke at openjdk.org  Tue Nov 25 08:04:28 2025
From: duke at openjdk.org (duke)
Date: Tue, 25 Nov 2025 08:04:28 GMT
Subject: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses
 non-optimal VarHandle
In-Reply-To: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
Message-ID: <8hBw6evwLqAVfk-2K62z_ByRIZjpNg9WdicMEIaSY-8=.14f061e8-ed49-40f4-8fed-ca5812fa02e7@github.com>

On Mon, 24 Nov 2025 13:05:40 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
> 
> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
> 
> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
> 
> Benchmark                                                                Mode  Cnt   Score   Error  Units
> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
> 
> where the `right` indy shows:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
> 
> vs the `wrong` one:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />

@franz1981 
Your change (at version d0ce3174660f98f871b23ae55aa3fd57afdcd344) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28475#issuecomment-3574233772

From duke at openjdk.org  Tue Nov 25 08:10:03 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 25 Nov 2025 08:10:03 GMT
Subject: Integrated: 8372410: ThreadFactory used by Thread.Builder::factory
 uses non-optimal VarHandle
In-Reply-To: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
References: <afdDZ2E0j8GtTvtGHbCGwEebr2ji93ugXQuZ8GI-7yw=.ea4a5a46-9387-410d-bbdb-58d2f0966eae@github.com>
Message-ID: <73lKMLgBLmlrPJAez46-I99k4w632w7PwBHSYbypXWo=.f497cc81-f796-498f-882e-b7a5546ff9b2@github.com>

On Mon, 24 Nov 2025 13:05:40 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This is boosting VirtualThread allocations while using https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html#name(java.lang.String,long)
> 
> The pattern has been discovered on https://github.com/quarkusio/quarkus/issues/51201 and narrowed down in https://github.com/franz1981/java-puzzles/commit/5cb4216e8d56cdc6c3c23629419158550cbd9068
> 
> which, on my machine (Ryzen 7950 w fixed frequency at 4.2 GHz):
> 
> Benchmark                                                                Mode  Cnt   Score   Error  Units
> VarHandlePolymorphicSignatureSensitivity.rightVarHandle                  avgt   10   1.852 ? 0.007  ns/op
> VarHandlePolymorphicSignatureSensitivity.rightVarHandleConcatIndy        avgt   10   9.891 ? 0.103  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandle                  avgt   10  10.430 ? 0.045  ns/op
> VarHandlePolymorphicSignatureSensitivity.wrongVarHandleConcatIndy        avgt   10  19.312 ? 0.619  ns/op
> 
> where the `right` indy shows:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/4c836389-492b-4cc6-94a3-849f8cf6ea09" />
> 
> vs the `wrong` one:
> <img width="1915" height="469" alt="image" src="https://github.com/user-attachments/assets/73765060-8e95-42a2-a03a-4f53f927a8b8" />

This pull request has now been integrated.

Changeset: 1226873a
Author:    Francesco Nigro <nigro.fra at gmail.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1226873ab94d2cc341ddb7040aa60c3bf3614feb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8372410: ThreadFactory used by Thread.Builder::factory uses non-optimal VarHandle

Reviewed-by: alanb, adinn, liach

-------------

PR: https://git.openjdk.org/jdk/pull/28475

From jbhateja at openjdk.org  Tue Nov 25 09:05:54 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 25 Nov 2025 09:05:54 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v4]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <xSJ5MrtvVXuL5uGL22XIAp1drhp9o11Ou8ebWjMJTC4=.5875165a-8929-4f07-b7ca-129f758709d5@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Fix failing jtreg test in CI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/f34d324f..aca6cc5d

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From mli at openjdk.org  Tue Nov 25 09:42:46 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 25 Nov 2025 09:42:46 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v6]
In-Reply-To: <UP9CeREEzOP9VnGnDOB26dIj_YiKAd5fpMG86s5SULI=.9f48cf4f-4c72-425e-a3fa-0e1e762632f4@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <7kh5C9nj7bf6432cG35kDDvV6zhnKEspe8AcYetJ1do=.e1d9ebd3-d80d-4621-8c1e-c77dc721d0df@github.com>
 <UP9CeREEzOP9VnGnDOB26dIj_YiKAd5fpMG86s5SULI=.9f48cf4f-4c72-425e-a3fa-0e1e762632f4@github.com>
Message-ID: <NBWP0MpNLdz0fSedC4LUB6XhNehDPZXoSW1EXORwJ5s=.c7b9ac6e-fb76-499f-bad1-574560bb436f@github.com>

On Tue, 25 Nov 2025 02:38:52 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix is_unordered
>
> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2141:
> 
>> 2139:     case BoolTest::gt:
>> 2140:       cmov_fp_cmp_fp_gt(op1, op2, dst, src, cmp_single, cmov_single);
>> 2141:       log_warning(jit)("Float/Double BoolTest::gt path is not tested well, please report the test case!");
> 
> My local tests show this does happen. Try this:
> `$ make test TEST="./test/jdk/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java" TEST_VM_OPTS="-XX:-TieredCompilation"`
> 
> I think this could be a good reference if you want to add some extra tests for the two cases here.

Thanks, I'll check it later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2559281739

From cushon at openjdk.org  Tue Nov 25 09:51:39 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 25 Nov 2025 09:51:39 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v12]
In-Reply-To: <8CgTEkC7e7tH5rjLYp390E7G71xcjmN0JVf0DcazEvs=.9f1fe903-797c-4036-b7af-3d6acbeb5f70@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Azw8uh7ppASBsB3OOjdLj-98TJazhBZ3pvfzwSyfAW4=.2f5e8473-bcfa-4771-8b21-db396abc75e3@github.com>
 <9jQNB8VUwW6jC53uBwp5x8awio3_X1kQ48QkfQHHHsM=.daf137ab-7f85-4378-bd33-144addb93d1e@github.com>
 <PXLm1mCIddfyhSr2fvsl8-z50pBkzqz9SuonfyzmeIQ=.312e695c-197d-4171-b55c-c6523bf4d435@github.com>
 <8CgTEkC7e7tH5rjLYp390E7G71xcjmN0JVf0DcazEvs=.9f1fe903-797c-4036-b7af-3d6acbeb5f70@github.com>
Message-ID: <E7diHwpiDinFkJ35gY7_CA8zcpCSobP5EAHkqmWdpVA=.4344c90c-5687-43c0-a703-bfab38f0f728@github.com>

On Mon, 24 Nov 2025 15:13:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Also, if in the future we also enhance encoders to return the length of a string w/o encoding it, it might still be useful to have `copy` return the length (to avoid scanning the string chars twice).

I agree, I think there are use-cases for both: if you expect to have enough room in the destination, it's better to avoid scanning the string twice, even if there's a more efficient way to compute the encoded length in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3574725230

From duke at openjdk.org  Tue Nov 25 10:16:40 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 25 Nov 2025 10:16:40 GMT
Subject: Integrated: 8362958: Unnecessary copying / sorting in Streams using
 Comparator.naturalOrder()
In-Reply-To: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
References: <aF4cLbrJPtyi-8qFH_uIgKL5M5nf8Nf_eiSfbms9uq0=.a9aaddbd-0e03-455d-817b-57b4c9c018a7@github.com>
Message-ID: <udYG8_PGhpYjyY1c9gTkE3ZstberADmBGju8Yolshpg=.671eeff9-192d-4701-b785-5561dea775f5@github.com>

On Tue, 11 Nov 2025 02:43:14 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> When `Comparator.naturalOrder()` was explicitly supplied to a collection such as `TreeSet`, or passed into the `sorted` method of a stream, the sorted characteristic was not preserved, causing unnecessary buffering and duplicate sorting.
> 
> Example:
> 
> 
> TreeSet<Integer> sortedSet = new TreeSet<>(Comparator.naturalOrder());
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted().forEach(System.out::println);
> 
> or
> 
> TreeSet<Integer> sortedSet = new TreeSet<>();
> sortedSet.add(1);
> sortedSet.add(2);
> // SortedOps.OfRef.opWrapSink is not a no-op
> sortedSet.stream().sorted(Comparator.naturalOrder()).forEach(System.out::println);
> 
> 
> This PR updates `SortedOps.makeRef` and `StreamOpFlag.fromCharacteristics` to handle the above cases and avoid the unnecessary sort step.

This pull request has now been integrated.

Changeset: 67ef81eb
Author:    Patrick Strawderman <pstrawderman at netflix.com>
Committer: Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67ef81eb78b28e5dcdf91785b476dfd0858cbd16
Stats:     46 lines in 4 files changed: 16 ins; 4 del; 26 mod

8362958: Unnecessary copying / sorting in Streams using Comparator.naturalOrder()

Reviewed-by: vklang, liach

-------------

PR: https://git.openjdk.org/jdk/pull/28226

From vklang at openjdk.org  Tue Nov 25 10:34:22 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Nov 2025 10:34:22 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v4]
In-Reply-To: <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
Message-ID: <2mDIFgBr1Zpe9hQCOvXMYRKjwpEyCRWOWN215vv1liI=.e5576d80-7772-46e6-8e6d-8b17bff8cd20@github.com>

On Tue, 25 Nov 2025 04:26:08 GMT, Steve Armstrong <duke at openjdk.org> wrote:

>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
>> 
>> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
>> 
>> Changes:
>> - Added new FieldUpdaterUtil class with static utility methods:
>>   * validateField() - validates field type, volatile, and static checks
>>   * computeAccessClass() - determines correct class for access checks
>>   * isSamePackage() - checks if two classes are in same package
>>   * isAncestor() - checks classloader delegation chain
>> 
>> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.
>
> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix try-catch block to not wrap IllegalArgumentException
>   
>   The validation exceptions should be thrown directly to the caller,
>   not wrapped in RuntimeException. Only the field lookup and access
>   checking code should be in the try-catch block.

(Adding this comment here as well as the linked JBS issue)

Personally I think this isn't worth the effort?there's little-to-no updates to these classes/APIs and there's no clear benefit in terms of safety and/or performance.

My preference here would be to move to deprecate these classes and make sure that it is clearly documented that VarHandle is the intended successor API.

Tagging @DougLea  and Dr Deprecator @stuart-marks for their input.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3574932660

From vklang at openjdk.org  Tue Nov 25 10:58:16 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Nov 2025 10:58:16 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
In-Reply-To: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
Message-ID: <MMgchW7GGTDrqdYlEpNOtRBpwcVR8TcHL-BwuPmhojk=.8af7a323-c092-4f50-a7d4-67de2d92419b@github.com>

On Tue, 25 Nov 2025 00:13:03 GMT, James Yuzawa <duke at openjdk.org> wrote:

> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
> 
> Here is a very simple reproducer:
> 
> ThreadLocalRandom r = ThreadLocalRandom.current();
> // step into this call using a debugger
> r.nextGaussian();
> 
> 
> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
> 
> Sketch:
> 
> public interface RandomGenerator {
> 	default double nextGaussian() {
> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> public class Random implements RandomGenerator {
> 	@Override
> 	public synchronized double nextGaussian() {
> 		// synchronized version ...
> 	}
> }
> 
> public class ThreadLocalRandom extends Random {
> 
> 	// ADD THIS
> 	@Override
> 	public double nextGaussian() {
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> 
> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
> 
> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
> 
> 
> Set<String> tlrMethods = new HashSet<>();
> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		tlrMethods.add(desc);
> 	}
> }
> for (Method method : java.util.Random.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		if (!tlrMethods.contains(desc)) {
> 			System.out.println(desc);
> 		}
> 	}
> }
> 
> 
> That prints
> 
> void nextBytes [byte[] arg0]
> double nextGaussian []
> 
> 
> The former safely calls `Thread...

Tagging @rgiulietti

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28483#issuecomment-3575023323

From davidalayachew at gmail.com  Tue Nov 25 11:59:31 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 25 Nov 2025 06:59:31 -0500
Subject: Add better exception message to FileTreeIterator.hasNext()?
In-Reply-To: <SJ2PR10MB76695EF15E19C75F2531DC63A2D1A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CAA9v-_O+9vNXWRDSLu7Ct=EXueybtaVzPY8g9+sxVopxSCFX=g@mail.gmail.com>
 <SJ2PR10MB76695EF15E19C75F2531DC63A2D1A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_P3YwVN5bxW=-muHVY7=vzE59b3xbLFyx=zHJMh5R+4Uw@mail.gmail.com>

Hello @Chen Liang <chen.l.liang at oracle.com>,

Thanks. I can agree that, after pulling up the source code, it becomes
obvious what occurred. That said, I do like your suggestion of the simple
String "closed" to be used as the exception message. If you are ok with
that, I can start replacing once I get a JBS number.

As for the documentation, I think the documentation is fine. Looking at the
stack trace, I didn't think that the place to look was
Collectors.flatMapping and how it should be used. Had I realized that from
looking at that stack trace, I would have caught on quickly.


On Mon, Nov 24, 2025, 10:45?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hello, David,
> I don't think this is necessary - the cause of the exception is already
> quite clear from the stack trace. I checked a few use sites of the no-arg
> constructor of IllegalStateException - many of them are in the same
> situation, that they are easy to understand once we see their location in
> code. I assume such a use of no-arg ISE constructor is widely accepted.
>
> For error messages, sometimes it is not feasible to be too detailed - I
> would think if we do add any, something like "closed" would be sufficient.
> Printing too many details in exceptions and log messages can sometimes
> constitute security risks.
>
> For the stream part, I believe both Files.walk and Stream.flatMap do their
> job - walk specifies you should close after use, and flatMap specifies the
> returned streams are closed once their elements are all taken. However, I
> do agree that there are possible documentation enhancements, that:
> 1. Stream factories should specify if their elements are still usable
> after the streams are closed, and
> 2. Stream should note that they should be closed after a terminal
> operation (which is the fault you made here)
>
> Regards,
> Chen Liang
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, November 24, 2025 1:38 PM
> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Add better exception message to FileTreeIterator.hasNext()?
>
> Hello @core-libs-dev <core-libs-dev at openjdk.org>,
>
> I was writing a simple script today -- find how many Java files are in
> each of my top level folders of my current directory.
>
> So, I ran the following code.
>
> Files
>     list(Path.of("."))
>     filter(Files::isDirectory)
>     collect
>
>         Collectors.groupingBy(
>         Function.<Path>identity(),
>         Collectors
>             .flatMapping
>             (
>                 (final Path root) ->
>                 {
>                     try (final Stream<Path> streamWalker =
> Files.walk(root))
>                     {
>                         return
>                             streamWalker
>                                 .filter(Files::isRegularFile)
>                                 .filter(file ->
> file.toString().endsWith(".java"))
>                                 ;
>                     }
>                     catch (final Exception exception)
>                     {
>                         throw new RuntimeException(exception);
>                     }
>                 },
>                 Collectors.counting()
>             )
>         )
>         ;
>
> Now, there is a not-so-obvious bug -- when using a flatMapping Collector,
> no need for try-with-resources.
>
> The above code threw the below stack trace.
>
> |  Exception java.lang.IllegalStateException
> |        at FileTreeIterator.hasNext (FileTreeIterator.java:100)
> |        at Iterator.forEachRemaining (Iterator.java:132)
> |        at Spliterators$IteratorSpliterator.forEachRemaining
> (Spliterators.java:1939)
> |        at AbstractPipeline.copyInto (AbstractPipeline.java:570)
> |        at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
> |        at ForEachOps$ForEachOp.evaluateSequential (ForEachOps.java:153)
> |        at ForEachOps$ForEachOp$OfRef.evaluateSequential
> (ForEachOps.java:176)
> |        at AbstractPipeline.evaluate (AbstractPipeline.java:265)
> |        at ReferencePipeline.forEach (ReferencePipeline.java:632)
> |        at Collectors.lambda$flatMapping$0 (Collectors.java:483)
> |        at Collectors.lambda$groupingBy$0 (Collectors.java:1113)
> |        at ReduceOps$3ReducingSink.accept (ReduceOps.java:169)
> |        at ReferencePipeline$2$1.accept (ReferencePipeline.java:197)
> |        at Iterator.forEachRemaining (Iterator.java:133)
> |        at Spliterators$IteratorSpliterator.forEachRemaining
> (Spliterators.java:1939)
> |        at AbstractPipeline.copyInto (AbstractPipeline.java:570)
> |        at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
> |        at ReduceOps$ReduceOp.evaluateSequential (ReduceOps.java:921)
> |        at AbstractPipeline.evaluate (AbstractPipeline.java:265)
> |        at ReferencePipeline.collect (ReferencePipeline.java:723)
> |        at (#4:5)
>
>
> Not obvious what is wrong here.
>
> Now, the exception message is being thrown by the hasNext() method of the
> FileTreeIterator class. After looking at the source code of that class,
> it's clear what the problem is.
>
>
> https://github.com/openjdk/jdk/blob/jdk-26%2B25/src/java.base/share/classes/java/nio/file/FileTreeIterator.java#L98
>
> It throws an exception because the FileTreeWalker contained within the
> FileTreeIterator is closed (presumably by the try-with-resources). However,
> the thrown exception message is empty. This exact same check-then-throw
> logic is duplicated all over FileTreeIterator.
>
> I propose that all such instances of check-then-throw be provided with
> exception messages along the lines of "Cannot check for more elements
> because the file walker is already closed!". I am not picky on the wording.
> Just something to inform me that the issue is something is closed, as
> opposed to just a generic IllegalStateException. I would even accept an
> empty message body if the exception type communicated the issue.
>
> Thank you for your time.
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251125/5b9f831f/attachment.htm>

From duke at openjdk.org  Tue Nov 25 12:04:18 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Tue, 25 Nov 2025 12:04:18 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v4]
In-Reply-To: <2mDIFgBr1Zpe9hQCOvXMYRKjwpEyCRWOWN215vv1liI=.e5576d80-7772-46e6-8e6d-8b17bff8cd20@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
 <2mDIFgBr1Zpe9hQCOvXMYRKjwpEyCRWOWN215vv1liI=.e5576d80-7772-46e6-8e6d-8b17bff8cd20@github.com>
Message-ID: <ZktEFng7iJfqEgrYEmsZUaEi_BUBw2FWLYBP40E4WPo=.ba8a6ed8-5b56-4220-b472-b2a2d6283350@github.com>

On Tue, 25 Nov 2025 10:30:26 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix try-catch block to not wrap IllegalArgumentException
>>   
>>   The validation exceptions should be thrown directly to the caller,
>>   not wrapped in RuntimeException. Only the field lookup and access
>>   checking code should be in the try-catch block.
>
> (Adding this comment here as well as the linked JBS issue)
> 
> Personally I think this isn't worth the effort?there's little-to-no updates to these classes/APIs and there's no clear benefit in terms of safety and/or performance.
> 
> My preference here would be to move to deprecate these classes and make sure that it is clearly documented that VarHandle is the intended successor API.
> 
> Tagging @DougLea  and Dr Deprecator @stuart-marks for their input.

Thankyou @viktorklang-ora for letting me know your thoughts on this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3575306830

From dl at openjdk.org  Tue Nov 25 12:19:07 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Nov 2025 12:19:07 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <-rtZkzC1IIATE_dxPtAwns1zZeT8Od3oDnvQemd7CAc=.da6577b5-7156-4d7b-a8b4-50a6fedf190b@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <-rtZkzC1IIATE_dxPtAwns1zZeT8Od3oDnvQemd7CAc=.da6577b5-7156-4d7b-a8b4-50a6fedf190b@github.com>
Message-ID: <K5COCfB8ewOirlbviR0Z0Ooy6y3yEZ_y9OB8jK2mofU=.732db8f2-bb0c-44b7-ba4a-6ae12e5a7eec@github.com>

On Mon, 24 Nov 2025 17:34:21 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Adds the patch by @DougLea
>
> test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 46:
> 
>> 44:         try (var pool = Executors.newCachedThreadPool()) {
>> 45:             var futures = new ArrayList<Future<Integer>>();
>> 46:             var phaser = new Phaser(4);
> 
> @DougLea Would it make sense to do the following, and then only keep a single `phaser.arriveAndAwaitAdvance();` ? (and skip the explicit q.clear())
> 
> Suggestion:
> 
>             var phaser = new Phaser(4) {
>                 @Override
>                 protected boolean onAdvance(int phase, int registeredParties) {
>                     q.clear();
>                     return super.onAdvance(phase, registeredParties);
>                 }
>             };

Sure. I was just trying to minimally adapt the submitter's bug report as test, so left this as-is.

> test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 68:
> 
>> 66:                 if (future.get() != 0)
>> 67:                     throw new Error();
>> 68:             }
> 
> @DougLea It might make sense to assert/verify that the queue is empty at the end of the test?

OK, except that it would need further adjustment to force test to fail rather than getting stuck.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2559764751
PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2559772952

From dl at openjdk.org  Tue Nov 25 12:19:11 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Nov 2025 12:19:11 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <K5COCfB8ewOirlbviR0Z0Ooy6y3yEZ_y9OB8jK2mofU=.732db8f2-bb0c-44b7-ba4a-6ae12e5a7eec@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <-rtZkzC1IIATE_dxPtAwns1zZeT8Od3oDnvQemd7CAc=.da6577b5-7156-4d7b-a8b4-50a6fedf190b@github.com>
 <K5COCfB8ewOirlbviR0Z0Ooy6y3yEZ_y9OB8jK2mofU=.732db8f2-bb0c-44b7-ba4a-6ae12e5a7eec@github.com>
Message-ID: <CX96np_pZ2XNY2igistvaaE0qt4jrdTa1DTjH1vVrGg=.0b2faed8-0d49-45ac-9359-983bbf1bef25@github.com>

On Tue, 25 Nov 2025 12:13:20 GMT, Doug Lea <dl at openjdk.org> wrote:

>> test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 68:
>> 
>>> 66:                 if (future.get() != 0)
>>> 67:                     throw new Error();
>>> 68:             }
>> 
>> @DougLea It might make sense to assert/verify that the queue is empty at the end of the test?
>
> OK, except that it would need further adjustment to force test to fail rather than getting stuck.

Ignore previous comment. I was thinking you meant  assert inside tasks. At end is a good idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2559778561

From pminborg at openjdk.org  Tue Nov 25 12:22:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 25 Nov 2025 12:22:29 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v5]
In-Reply-To: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
Message-ID: <A0J-7O3cuq27oWY3tv2SIYkb3jF1DiA3B43x6xeBu7M=.a20582a5-5d23-478b-9bb6-5345712b5ef0@github.com>

> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
> 
> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
> 
> It should be noted that with this change, the running time for the benchmarks would increase significantly.

Per Minborg 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 nine additional commits since the last revision:

 - Update after comments
 - Merge branch 'master' into improved-bulk-benchmarks
 - Add loop variant for mismatch
 - Use other allocateFrom overload
 - Remove lingering comment
 - Refactor and use long arrays
 - Remove BulkOps
 - Fix copyright years
 - Improve BulkOp benchmarks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28260/files
  - new: https://git.openjdk.org/jdk/pull/28260/files/7f40672e..9dd24c1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28260&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28260&range=03-04

  Stats: 37510 lines in 674 files changed: 22232 ins; 10672 del; 4606 mod
  Patch: https://git.openjdk.org/jdk/pull/28260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28260/head:pull/28260

PR: https://git.openjdk.org/jdk/pull/28260

From pminborg at openjdk.org  Tue Nov 25 12:26:32 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 25 Nov 2025 12:26:32 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v5]
In-Reply-To: <A0J-7O3cuq27oWY3tv2SIYkb3jF1DiA3B43x6xeBu7M=.a20582a5-5d23-478b-9bb6-5345712b5ef0@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <A0J-7O3cuq27oWY3tv2SIYkb3jF1DiA3B43x6xeBu7M=.a20582a5-5d23-478b-9bb6-5345712b5ef0@github.com>
Message-ID: <70lBR1ik8AwdrLkekXpBRObByBWgj9gYTBr3PGn_75Q=.2d43db6f-bbfd-4d6c-81a7-0c8ddb06d1fb@github.com>

On Tue, 25 Nov 2025 12:22:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> Per Minborg 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 nine additional commits since the last revision:
> 
>  - Update after comments
>  - Merge branch 'master' into improved-bulk-benchmarks
>  - Add loop variant for mismatch
>  - Use other allocateFrom overload
>  - Remove lingering comment
>  - Refactor and use long arrays
>  - Remove BulkOps
>  - Fix copyright years
>  - Improve BulkOp benchmarks

Benchmark                            (size)  Mode  Cnt        Score       Error  Units
SegmentBulkCopy.Array.bufferCopy          2  avgt   30        3.028 ?     0.094  ns/op
SegmentBulkCopy.Array.bufferCopy          4  avgt   30        2.825 ?     0.047  ns/op
SegmentBulkCopy.Array.bufferCopy          8  avgt   30        2.694 ?     0.048  ns/op
SegmentBulkCopy.Array.bufferCopy         12  avgt   30        2.736 ?     0.019  ns/op
SegmentBulkCopy.Array.bufferCopy         16  avgt   30        2.705 ?     0.024  ns/op
SegmentBulkCopy.Array.bufferCopy         64  avgt   30        2.851 ?     0.017  ns/op
SegmentBulkCopy.Array.bufferCopy        512  avgt   30        7.329 ?     0.116  ns/op
SegmentBulkCopy.Array.bufferCopy       4096  avgt   30       51.591 ?     0.667  ns/op
SegmentBulkCopy.Array.bufferCopy      32768  avgt   30      626.952 ?    43.598  ns/op
SegmentBulkCopy.Array.bufferCopy     262144  avgt   30     3339.947 ?    16.218  ns/op
SegmentBulkCopy.Array.bufferCopy    2097152  avgt   30    26569.111 ?  1974.834  ns/op
SegmentBulkCopy.Array.bufferCopy   16777216  avgt   30   258056.303 ?  9005.471  ns/op
SegmentBulkCopy.Array.bufferCopy  134217728  avgt   30  2335005.220 ? 43871.900  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28260#issuecomment-3575400339

From vklang at openjdk.org  Tue Nov 25 12:30:16 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Nov 2025 12:30:16 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <K5COCfB8ewOirlbviR0Z0Ooy6y3yEZ_y9OB8jK2mofU=.732db8f2-bb0c-44b7-ba4a-6ae12e5a7eec@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <-rtZkzC1IIATE_dxPtAwns1zZeT8Od3oDnvQemd7CAc=.da6577b5-7156-4d7b-a8b4-50a6fedf190b@github.com>
 <K5COCfB8ewOirlbviR0Z0Ooy6y3yEZ_y9OB8jK2mofU=.732db8f2-bb0c-44b7-ba4a-6ae12e5a7eec@github.com>
Message-ID: <DMhMSOMlWalGS-DlIybQKR8d8vXZNb2QpWT1_oq2raA=.d414b761-85f5-4e00-95b4-de376177fc64@github.com>

On Tue, 25 Nov 2025 12:10:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 46:
>> 
>>> 44:         try (var pool = Executors.newCachedThreadPool()) {
>>> 45:             var futures = new ArrayList<Future<Integer>>();
>>> 46:             var phaser = new Phaser(4);
>> 
>> @DougLea Would it make sense to do the following, and then only keep a single `phaser.arriveAndAwaitAdvance();` ? (and skip the explicit q.clear())
>> 
>> Suggestion:
>> 
>>             var phaser = new Phaser(4) {
>>                 @Override
>>                 protected boolean onAdvance(int phase, int registeredParties) {
>>                     q.clear();
>>                     return super.onAdvance(phase, registeredParties);
>>                 }
>>             };
>
> Sure. I was just trying to minimally adapt the submitter's bug report as test, so left this as-is.

It was primarily to validate my own understanding of equivalence :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2559816428

From vklang at openjdk.org  Tue Nov 25 12:30:18 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Nov 2025 12:30:18 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty
In-Reply-To: <CX96np_pZ2XNY2igistvaaE0qt4jrdTa1DTjH1vVrGg=.0b2faed8-0d49-45ac-9359-983bbf1bef25@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <-rtZkzC1IIATE_dxPtAwns1zZeT8Od3oDnvQemd7CAc=.da6577b5-7156-4d7b-a8b4-50a6fedf190b@github.com>
 <K5COCfB8ewOirlbviR0Z0Ooy6y3yEZ_y9OB8jK2mofU=.732db8f2-bb0c-44b7-ba4a-6ae12e5a7eec@github.com>
 <CX96np_pZ2XNY2igistvaaE0qt4jrdTa1DTjH1vVrGg=.0b2faed8-0d49-45ac-9359-983bbf1bef25@github.com>
Message-ID: <xQAbhLOBiN1oKbicgCS0rDXfNAq7fRgZHYt51hJHbm8=.7713a145-8b3c-4042-a10b-68067f32e236@github.com>

On Tue, 25 Nov 2025 12:15:15 GMT, Doug Lea <dl at openjdk.org> wrote:

>> OK, except that it would need further adjustment to force test to fail rather than getting stuck.
>
> Ignore previous comment. I was thinking you meant  assert inside tasks. At end is a good idea.

Ok, I'll adjust

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2559814990

From vklang at openjdk.org  Tue Nov 25 12:51:07 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Nov 2025 12:51:07 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty [v2]
In-Reply-To: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
Message-ID: <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>

> Adds the patch by @DougLea

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Changes after code review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28479/files
  - new: https://git.openjdk.org/jdk/pull/28479/files/2b32c4fa..73c646ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28479&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28479&range=00-01

  Stats: 14 lines in 1 file changed: 9 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28479/head:pull/28479

PR: https://git.openjdk.org/jdk/pull/28479

From vklang at openjdk.org  Tue Nov 25 12:51:10 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Nov 2025 12:51:10 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty [v2]
In-Reply-To: <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
Message-ID: <tZE9mK5f46wDtcwJw1vngbWpwYJ5RgOh3PYLsOqZcWU=.c42901ed-914f-4506-8704-381aaa5d006d@github.com>

On Tue, 25 Nov 2025 12:47:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Adds the patch by @DougLea
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes after code review

test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 52:

> 50:                     return super.onAdvance(phase, registeredParties);
> 51:                 }
> 52:             };

@DougLea I decided to mod the phaser to have the clearing of the queue as a part of the advancement of the phaser

test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 72:

> 70:                 Integer res;
> 71:                 if ((res = future.get()) != 0)
> 72:                     throw new AssertionError("Expected 0 but got " + res);

@AlanBateman I added this

test/jdk/java/util/concurrent/BlockingQueue/MissedPoll.java line 76:

> 74:         }
> 75:         if (!q.isEmpty())
> 76:             throw new AssertionError("Queue is not empty: " + q);

@DougLea Added this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2559870829
PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2559868675
PR Review Comment: https://git.openjdk.org/jdk/pull/28479#discussion_r2559869325

From pminborg at openjdk.org  Tue Nov 25 13:18:40 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 25 Nov 2025 13:18:40 GMT
Subject: RFR: 8372258: Improve TypeVariable support [v3]
In-Reply-To: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
References: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
Message-ID: <44jkU5FPUq0F0vikw9mRrtHSc1YrhP69zJuV9O5drM8=.ab3b864a-dd9b-4121-a863-311e598d75ec@github.com>

> The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28429/files
  - new: https://git.openjdk.org/jdk/pull/28429/files/ba7f093f..7d3fee14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28429&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28429&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28429/head:pull/28429

PR: https://git.openjdk.org/jdk/pull/28429

From mcimadamore at openjdk.org  Tue Nov 25 14:03:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Nov 2025 14:03:35 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v13]
In-Reply-To: <OxFkXFJpY0zj0jVvcx99tWlV06eG-4GVDvrfRrVdUFQ=.eeea6b4a-3cc9-439d-b6ba-22ae87b2f7fd@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <OxFkXFJpY0zj0jVvcx99tWlV06eG-4GVDvrfRrVdUFQ=.eeea6b4a-3cc9-439d-b6ba-22ae87b2f7fd@github.com>
Message-ID: <mbV7Lytks5H07JmtFG5bas_kZNwP41FlTq_CZSipvBQ=.bb8d6f96-fed5-4bd3-87e0-256d20397ffe@github.com>

On Mon, 24 Nov 2025 09:51:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update discussion of truncated reads of strings containing \0
>  - Return the number of copied bytes

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2669:

> 2667:      * @throws IllegalArgumentException if {@code dst} is {@linkplain #isReadOnly() read-only}
> 2668:      * @throws IndexOutOfBoundsException if {@code dstOffset > dstSegment.byteSize() - B} where {@code B} is the size,
> 2669:      *         in bytes, of the string encoded using the given charset.

Nit pick: this says "the size... of the string... encoded..."... which string? It might suggest we're talking about `src`, but in reality we're talking about a *substring* of `src`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2560103242

From liach at openjdk.org  Tue Nov 25 14:13:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 14:13:21 GMT
Subject: RFR: 8372258: Improve TypeVariable support [v3]
In-Reply-To: <44jkU5FPUq0F0vikw9mRrtHSc1YrhP69zJuV9O5drM8=.ab3b864a-dd9b-4121-a863-311e598d75ec@github.com>
References: <D1HU8vdNVyrrtpMTUKFPa3-KNNY2qb44LDDGl3_w78o=.088bdbe2-57e7-40ed-9ad3-6bb61473c825@github.com>
 <44jkU5FPUq0F0vikw9mRrtHSc1YrhP69zJuV9O5drM8=.ab3b864a-dd9b-4121-a863-311e598d75ec@github.com>
Message-ID: <ylLvU2vO312l4DZ0NvEkSqz3wxkZwHfhv3aQcT2Ln_A=.4346e90b-a7c1-435c-af4e-885824911a37@github.com>

On Tue, 25 Nov 2025 13:18:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28429#pullrequestreview-3505264398

From mcimadamore at openjdk.org  Tue Nov 25 14:15:26 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Nov 2025 14:15:26 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <G1K8qYx7YJ0UPUAMFnLt9_IAjcctuAbMMDBcroPXWqg=.af828881-bb49-421a-b60f-90df648a2fc4@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
 <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>
 <Q8JPn8XfKrQW61v0SOk8lv13gkDPkpeJ2hgy5aZZUQ0=.b0d7fcfa-ef44-4b06-87e5-c98198a7b2db@github.com>
 <G1K8qYx7YJ0UPUAMFnLt9_IAjcctuAbMMDBcroPXWqg=.af828881-bb49-421a-b60f-90df648a2fc4@github.com>
Message-ID: <Q7iO-aoqoQnFFCCmwqLdG7Em2T26esJFkynPIaX4LHQ=.c174d1fe-2b93-4490-8d45-69e66f0e9064@github.com>

On Fri, 21 Nov 2025 10:38:05 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Looks like we are already specified to throw IAE if 'the size of the string is greater than the largest string supported by the platform'
>
> Done, and I added a test to cover the IAE

I think I'm confused here.

This method is called by `MemorySegment::getString` with an explicit length.

The question is -- what does the length represent? There's two options:

1. the length, in bytes, of the region of memory that needs to be _decoded_ into the final string bytes
2. the length of the final string bytes

IMHO, only (1) really makes sense -- as (2) involves some charset-specific guesswork.

But if (1) is (as I hope) what we mean, I think we should probably make that clearer in the javadoc. Then, the exception we throw here is related to the fact that we don't have a way to construct a string from something bigger than a byte[] -- which is, in a way, an impl specific issue (one can imagine manually decoding the segment bytes into a new char[], which is then used to create the string -- in which case it might be possible e.g. to read 4 * N UTF32 string bytes into a LATIN1 string backed by a byte array with size N).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2560145914

From mcimadamore at openjdk.org  Tue Nov 25 14:22:16 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Nov 2025 14:22:16 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v13]
In-Reply-To: <OxFkXFJpY0zj0jVvcx99tWlV06eG-4GVDvrfRrVdUFQ=.eeea6b4a-3cc9-439d-b6ba-22ae87b2f7fd@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <OxFkXFJpY0zj0jVvcx99tWlV06eG-4GVDvrfRrVdUFQ=.eeea6b4a-3cc9-439d-b6ba-22ae87b2f7fd@github.com>
Message-ID: <_tXDFe_4j0Ih20_v-BOwzgCAjmIcyBpeZU2ryKs13J4=.57cee08a-a034-4c4b-a72b-e378b3f96eef@github.com>

On Mon, 24 Nov 2025 09:51:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update discussion of truncated reads of strings containing \0
>  - Return the number of copied bytes

Still looks good -- added some more comments

test/micro/org/openjdk/bench/java/lang/foreign/FromJavaStringTest.java line 71:

> 69: 
> 70:     @Benchmark
> 71:     public void panama_setString() {

I'd suggest to maybe avoid "panama" here and in the other benchmark. Maybe:
* segment_setString
* segment_copyStringRaw
* segment_copyStringBytes

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3505298945
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2560162300

From jpai at openjdk.org  Tue Nov 25 14:37:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Nov 2025 14:37:43 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v4]
In-Reply-To: <e59d6l5z44yP7YxiXJv2fosB9eiLC198lGWKlv-Z9BI=.31d211c2-0f7f-476e-93a5-419b04dcf892@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>
 <qmt-s-ZxvxacHTzWpZvMQY9-8TGJMUIQFRcsipRnzek=.1348a9ba-66d4-4edd-ae0a-a9600382b455@github.com>
 <e59d6l5z44yP7YxiXJv2fosB9eiLC198lGWKlv-Z9BI=.31d211c2-0f7f-476e-93a5-419b04dcf892@github.com>
Message-ID: <iSdWIucP-ZCsjXO2lVLRy8rOCG8nv73IQRUqX_eTfjU=.14159fea-3234-4002-8ed8-bf9dea628122@github.com>

On Fri, 21 Nov 2025 18:43:21 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> test/jdk/tools/jlink/TaskHelperTest.java line 279:
>> 
>>> 277:                 var remaining = optionsHelper.handleOptions(this, args.tokens);
>>> 278:                 assertTrue(remaining.isEmpty());
>>> 279:                 assertEquals(args.expectedCompressValue, compressArgValue);
>> 
>> I think these 2 asserts are an oversight. Since we expect `optionsHelper.handleOptions(...)` to always throw a `BadArgs` for these invalid option values, we should replace these 2 asserts with a:
>> 
>> fail("processing of " + Arrays.toString(testCase.tokens) + " was expected to fail, but didn't");
>> 
>> This will then rightly fail the test if the exception isn't thrown.
>
> To my understanding, for compression plugin the validation of the actual value is performed in `DefaultCompressPlugin` (https://github.com/openjdk/jdk/blob/d57fc1b6dc313eb004892b180960ebcee1cb04c7/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java#L118 and https://github.com/openjdk/jdk/blob/d57fc1b6dc313eb004892b180960ebcee1cb04c7/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java#L115). 
> 
> At the moment, [`optionsHelper.handleOptions`](https://github.com/openjdk/jdk/blob/3a45e615973727446c9081b5affbbe7ffe7c3bea/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java#L527) seems to set up `TaskHelper`'s internal state and it shouldn't throw exceptions for syntactically correct options. In my opinion, this fix is not that much related to the value allowed, but to the syntax allowed for the option. I noticed that there is another test class [`JLinkTest`](https://github.com/openjdk/jdk/blob/master/test/jdk/tools/jlink/JLinkTest.java) that tests for actual values. When I tested locally my build of this modified `jlink`, for invalid values I did get that `IllegalArgumentException`. 
> 
> However, I am very new to the testing framework and am welcoming more thoughts/ideas ? .

Hello Ana, I had a look at the `JLinkTest` and like you note it already has some testing for the `--compress` option there (the testCompress method). I think we should move the `testCompressInvalidValue()` that we introduced in this PR to that `JLinkTest` and test those invalid usages there, in a similar manner to what's already being tested there (for example the section below "// invalid compress level" in that test)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2560210261

From alanb at openjdk.org  Tue Nov 25 14:59:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Nov 2025 14:59:52 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty [v2]
In-Reply-To: <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
Message-ID: <FTlturJWPug-rqryfzC0pfwRufhTcE4LIOOL7wHS85w=.9a47df15-e4d7-4e82-a30e-860a398a56da@github.com>

On Tue, 25 Nov 2025 12:51:07 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Adds the patch by @DougLea
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes after code review

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28479#pullrequestreview-3505481298

From rgiulietti at openjdk.org  Tue Nov 25 15:12:45 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 25 Nov 2025 15:12:45 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
In-Reply-To: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
Message-ID: <GG1mzvk8CUYVwODmk2NnOpkkwowYRjD4jlO1Kb9QDUE=.568dbe52-7006-493e-ac63-8a88dfd584fe@github.com>

On Tue, 25 Nov 2025 00:13:03 GMT, James Yuzawa <duke at openjdk.org> wrote:

> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
> 
> Here is a very simple reproducer:
> 
> ThreadLocalRandom r = ThreadLocalRandom.current();
> // step into this call using a debugger
> r.nextGaussian();
> 
> 
> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
> 
> Sketch:
> 
> public interface RandomGenerator {
> 	default double nextGaussian() {
> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> public class Random implements RandomGenerator {
> 	@Override
> 	public synchronized double nextGaussian() {
> 		// synchronized version ...
> 	}
> }
> 
> public class ThreadLocalRandom extends Random {
> 
> 	// ADD THIS
> 	@Override
> 	public double nextGaussian() {
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> 
> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
> 
> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
> 
> 
> Set<String> tlrMethods = new HashSet<>();
> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		tlrMethods.add(desc);
> 	}
> }
> for (Method method : java.util.Random.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		if (!tlrMethods.contains(desc)) {
> 			System.out.println(desc);
> 		}
> 	}
> }
> 
> 
> That prints
> 
> void nextBytes [byte[] arg0]
> double nextGaussian []
> 
> 
> The former safely calls `Thread...

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 503:

> 501: 
> 502:     /**
> 503:      * {@inheritDoc}

Inheriting the doc from `Random` doesn't seem correct in this case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2560363811

From asemenyuk at openjdk.org  Tue Nov 25 16:27:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Nov 2025 16:27:55 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <L2KH4f8TTac_lPfvTom_TrcmJwNKF-72cpgSunYxhQQ=.1a43017b-d0d3-41c6-9977-6c85d6eecce6@github.com>

On Tue, 25 Nov 2025 03:58:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 815:

> 813:             final boolean withServices = !cmd.isRuntime()
> 814:                     && !LauncherAsServiceVerifier.getLaunchersAsServices(cmd).isEmpty()
> 815:                     && !cmd.hasArgument("--mac-app-store");

I suggest updating `LauncherAsServiceVerifier.getLaunchersAsServices()` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2560643219

From asemenyuk at openjdk.org  Tue Nov 25 16:40:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Nov 2025 16:40:57 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <ireUKOdlFR6i_dkrHROvDksSBGAB-upStqwns_znWG4=.85ab3f7d-786c-4022-a80c-fb2f74e67b42@github.com>

On Tue, 25 Nov 2025 03:58:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 73:

> 71:             },
> 72:             { new PkgInstallScript[]{
> 73:                     PkgInstallScript.POSTINSTALL }, true,

Can we avoid the copy/paste? Something like:

    public static Collection<Object[]> input() {
        List<Object[]> data = new ArrayList<>();
        for (var appStore : List.of(true, false)) {
            for (var scriptRoles : List.of(
                    List.of(PkgInstallScript.PREINSTALL, PkgInstallScript.POSTINSTALL),
                    List.of(PkgInstallScript.PREINSTALL),
                    List.of(PkgInstallScript.POSTINSTALL)
            )) {
                data.add(new Object[] {scriptRoles.toArray(PkgInstallScript[]::new), appStore});
            }
        }
        return data;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2560682990

From duke at openjdk.org  Tue Nov 25 16:47:14 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 25 Nov 2025 16:47:14 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty [v2]
In-Reply-To: <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
Message-ID: <paLm8m_abtsVv-unddgyHflu3W1E8uxm9xUuyL4lMKs=.84dd4a2a-8b2b-415d-b43b-7c98be798de1@github.com>

On Tue, 25 Nov 2025 12:51:07 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Adds the patch by @DougLea
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes after code review

Seeing that the original test was written by me, could we perhaps add me as contributor as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28479#issuecomment-3576573135

From asemenyuk at openjdk.org  Tue Nov 25 16:53:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Nov 2025 16:53:55 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <0ehgyD4RVgykR5WZRobRaSqvoRrZIUpEDvX4rCpL9QM=.889d3106-661f-435c-b1ea-d59492dc1649@github.com>

On Tue, 25 Nov 2025 03:58:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 171:

> 169:         }
> 170: 
> 171:         void verify(JPackageCommand cmd, boolean exists) {

What is the semantics of the "exists" parameter? Does it apply to the script or to the response file? It is confusing. I suggest moving it inside of the function:

        void verify(JPackageCommand cmd) {
            var scriptsEnabled = !cmd.hasArgument("--mac-app-store");
            if (cmd.isPackageUnpacked()) {
                role.verifyExists(cmd, scriptsEnabled);
            } else if (scriptsEnabled) {
                TKit.assertFileExists(responseFilePath(cmd));
            } else {
                TKit.assertPathExists(responseFilePath(cmd), false);
            }
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2560728515

From alanb at openjdk.org  Tue Nov 25 16:55:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Nov 2025 16:55:27 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
In-Reply-To: <GG1mzvk8CUYVwODmk2NnOpkkwowYRjD4jlO1Kb9QDUE=.568dbe52-7006-493e-ac63-8a88dfd584fe@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <GG1mzvk8CUYVwODmk2NnOpkkwowYRjD4jlO1Kb9QDUE=.568dbe52-7006-493e-ac63-8a88dfd584fe@github.com>
Message-ID: <ckqSJC-GaF34C9PAVRwye1ocxqwW58W92-kU_G52iFs=.8daf6357-1223-4eb0-b819-0ca301bc3ffa@github.com>

On Tue, 25 Nov 2025 15:08:47 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 503:
> 
>> 501: 
>> 502:     /**
>> 503:      * {@inheritDoc}
> 
> Inheriting the doc from `Random` doesn't seem correct in this case.

Right, this will require attention. You kinda want `{@inheritDoc java.util.random.RandomGenerator}` but without overriding the method description then it won't appear in the Method Summary. The nextGaussian method defined by j.u.Random and j.u.random.RandomGenrator will be listed in the "Method declared by ..." section of course. 

In addition, Random's implSpec has the polar method whereas RandomGenrator's implSpec is ziggurat algorithm. So I think TLR.nextGaussian will need to copy from text RandomSupport.computeNextGaussian to get the right comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2560732582

From asemenyuk at openjdk.org  Tue Nov 25 16:59:06 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Nov 2025 16:59:06 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <Eq625FcokWAPUHEmyEY3xHrvoiwlxTPH9wlhuK4s0NI=.124f368b-102e-4c54-ae16-778fdc98aac2@github.com>

On Tue, 25 Nov 2025 03:58:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java line 1:

> 1: /*

I think the only required change to this source should be:

--- a/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java
+++ b/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java
@@ -239,7 +239,9 @@ private static Map<Boolean, List<String>> partitionLaunchers(JPackageCommand cmd
     }

     static boolean launcherAsService(JPackageCommand cmd, String launcherName) {
-        if (cmd.isMainLauncher(launcherName)) {
+        if (cmd.hasArgument("--mac-app-store")) {
+            return false;
+        } else if (cmd.isMainLauncher(launcherName)) {
             return PropertyFinder.findLauncherProperty(cmd, null,
                     PropertyFinder.cmdlineBooleanOption("--launcher-as-service"),
                     PropertyFinder.nop(),


It will also make the change in PackageTest.java redundant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2560749800

From alanb at openjdk.org  Tue Nov 25 17:04:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Nov 2025 17:04:49 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
In-Reply-To: <ckqSJC-GaF34C9PAVRwye1ocxqwW58W92-kU_G52iFs=.8daf6357-1223-4eb0-b819-0ca301bc3ffa@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <GG1mzvk8CUYVwODmk2NnOpkkwowYRjD4jlO1Kb9QDUE=.568dbe52-7006-493e-ac63-8a88dfd584fe@github.com>
 <ckqSJC-GaF34C9PAVRwye1ocxqwW58W92-kU_G52iFs=.8daf6357-1223-4eb0-b819-0ca301bc3ffa@github.com>
Message-ID: <7qeMdRtL1TbOw4mIaHlKHTmgiBawvRkGR7AgGqYFLKM=.77205c85-7643-4b13-a591-a1623be24274@github.com>

On Tue, 25 Nov 2025 16:51:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 503:
>> 
>>> 501: 
>>> 502:     /**
>>> 503:      * {@inheritDoc}
>> 
>> Inheriting the doc from `Random` doesn't seem correct in this case.
>
> Right, this will require attention. You kinda want `{@inheritDoc java.util.random.RandomGenerator}` but without overriding the method description then it won't appear in the Method Summary. The nextGaussian method defined by j.u.Random and j.u.random.RandomGenrator will be listed in the "Method declared by ..." section of course. 
> 
> In addition, Random's implSpec has the polar method whereas RandomGenrator's implSpec is ziggurat algorithm. So I think TLR.nextGaussian will need to copy from text RandomSupport.computeNextGaussian to get the right comment.

In passing, I see there are several empty "Implementation Note:" in the TLR docs. It seems to be `@implNote {@inheritDoc}` when there isn't anything to inherit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2560764537

From vklang at openjdk.org  Tue Nov 25 17:34:32 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Nov 2025 17:34:32 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty [v2]
In-Reply-To: <paLm8m_abtsVv-unddgyHflu3W1E8uxm9xUuyL4lMKs=.84dd4a2a-8b2b-415d-b43b-7c98be798de1@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
 <paLm8m_abtsVv-unddgyHflu3W1E8uxm9xUuyL4lMKs=.84dd4a2a-8b2b-415d-b43b-7c98be798de1@github.com>
Message-ID: <m519igUjxyjngOQQxWT43EDm5nW9Bv85bfZM1SVLaCs=.5f0b48b8-bff1-47a0-bafa-88eabdbd479d@github.com>

On Tue, 25 Nov 2025 16:43:45 GMT, kabutz <duke at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes after code review
>
> Seeing that the original test was written by me, could we perhaps add me as contributor as well?

@kabutz Of course, I missed that when I added Doug. Thanks for the reminder, Heinz. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28479#issuecomment-3576691035

From asemenyuk at openjdk.org  Tue Nov 25 17:34:40 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Nov 2025 17:34:40 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <XW3HjRSo4dS756ymqki--xcO5_J3-3L2HS2jPNsxDg0=.09dd692f-f2c9-4e8a-8141-d4c2e65ce8af@github.com>

On Tue, 25 Nov 2025 03:58:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java line 313:

> 311: 
> 312:     public void verifyLauncherExecuted(JPackageCommand cmd) {
> 313:         if (canVerifyInstall(cmd) && !cmd.hasArgument("--mac-app-store")) {

This is a public function intended for explicit calls from tests.
If a test calls it, it assumes a launcher will be executed unless an uncontrolled condition prevents it. The most common such condition is when the test unpacks a package instead of installing it.
The set of options on the jpackage command line is fully controlled by the test. So if it adds the "--mac-app-store" option, it should not call this function. That said, the change to this function is redundant

test/jdk/tools/jpackage/share/ServiceTest.java line 229:

> 227:             appImageCmd.cmd().orElseThrow().addArgument("--mac-app-store");
> 228:         }
> 229: 

Why do we need this option for an app image?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2560829902
PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2560835901

From liach at openjdk.org  Tue Nov 25 17:34:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 17:34:46 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v26]
In-Reply-To: <_3xcrMGOjqrYJZEGYKxk6whoWbKXC9eYo_VA5DcTir8=.1f5c30dc-ba19-46c1-a510-bb16ddcee79a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <_3xcrMGOjqrYJZEGYKxk6whoWbKXC9eYo_VA5DcTir8=.1f5c30dc-ba19-46c1-a510-bb16ddcee79a@github.com>
Message-ID: <SAny4nhzYWx5EWKueJb4Us5JkG35ieSDTLL1TivSGrk=.b240b604-b622-4449-a058-c3cfcf5d72f9@github.com>

On Thu, 20 Nov 2025 23:46:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>   
>   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

Looks good. Tier 1-3 looks good too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26911#pullrequestreview-3506092775

From duke at openjdk.org  Tue Nov 25 17:39:39 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 25 Nov 2025 17:39:39 GMT
Subject: RFR: 8366478: BigDecimal roots [v26]
In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
Message-ID: <eBGQDr0giM7PCeCDv6EqStK4oAA1lf-JxejKvSjN-eU=.1b721d23-94e5-4881-84bf-6087716cbabe@github.com>

> An implementation of `BigDecimal.nthRoot(int, MathContext)`.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added tests for special cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27148/files
  - new: https://git.openjdk.org/jdk/pull/27148/files/cd576fe3..55ba5578

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=24-25

  Stats: 49 lines in 1 file changed: 37 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148

PR: https://git.openjdk.org/jdk/pull/27148

From asemenyuk at openjdk.org  Tue Nov 25 17:41:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Nov 2025 17:41:15 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <mFwGoXPTB8Zm-zwbYORoEsVBCE5KdUBdry7cYltMZvY=.808c75a6-252f-4fca-beab-bef0b4cc4e8b@github.com>

On Tue, 25 Nov 2025 03:58:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

Looks good, suggested some updates

-------------

Changes requested by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28487#pullrequestreview-3506172297

From duke at openjdk.org  Tue Nov 25 17:41:27 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Tue, 25 Nov 2025 17:41:27 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v7]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Move test for invalid values from TaskHelperTest to JLinkTest.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/d0684384..0b957114

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=05-06

  Stats: 55 lines in 2 files changed: 33 ins; 22 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Tue Nov 25 17:41:29 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Tue, 25 Nov 2025 17:41:29 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v4]
In-Reply-To: <iSdWIucP-ZCsjXO2lVLRy8rOCG8nv73IQRUqX_eTfjU=.14159fea-3234-4002-8ed8-bf9dea628122@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <a4h9SOwYJSSeMg8bgdPHlFUZNzMI2OgJeuGSS2y-C6M=.b6287fcf-ed4a-4fe1-8731-cb9f8fc08fa1@github.com>
 <qmt-s-ZxvxacHTzWpZvMQY9-8TGJMUIQFRcsipRnzek=.1348a9ba-66d4-4edd-ae0a-a9600382b455@github.com>
 <e59d6l5z44yP7YxiXJv2fosB9eiLC198lGWKlv-Z9BI=.31d211c2-0f7f-476e-93a5-419b04dcf892@github.com>
 <iSdWIucP-ZCsjXO2lVLRy8rOCG8nv73IQRUqX_eTfjU=.14159fea-3234-4002-8ed8-bf9dea628122@github.com>
Message-ID: <YvjqViSbusLSYqZonlqlqmv5vIDiQmx0qQ43VOSeMgY=.1b5faf6a-e199-4781-8fca-be8ac6149f1c@github.com>

On Tue, 25 Nov 2025 14:31:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> To my understanding, for compression plugin the validation of the actual value is performed in `DefaultCompressPlugin` (https://github.com/openjdk/jdk/blob/d57fc1b6dc313eb004892b180960ebcee1cb04c7/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java#L118 and https://github.com/openjdk/jdk/blob/d57fc1b6dc313eb004892b180960ebcee1cb04c7/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java#L115). 
>> 
>> At the moment, [`optionsHelper.handleOptions`](https://github.com/openjdk/jdk/blob/3a45e615973727446c9081b5affbbe7ffe7c3bea/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java#L527) seems to set up `TaskHelper`'s internal state and it shouldn't throw exceptions for syntactically correct options. In my opinion, this fix is not that much related to the value allowed, but to the syntax allowed for the option. I noticed that there is another test class [`JLinkTest`](https://github.com/openjdk/jdk/blob/master/test/jdk/tools/jlink/JLinkTest.java) that tests for actual values. When I tested locally my build of this modified `jlink`, for invalid values I did get that `IllegalArgumentException`. 
>> 
>> However, I am very new to the testing framework and am welcoming more thoughts/ideas ? .
>
> Hello Ana, I had a look at the `JLinkTest` and like you note it already has some testing for the `--compress` option there (the testCompress method). I think we should move the `testCompressInvalidValue()` that we introduced in this PR to that `JLinkTest` and test those invalid usages there, in a similar manner to what's already being tested there (for example the section below "// invalid compress level" in that test)

Hi Jaikiran,

I followed your advice and moved the tests for invalid values to `JLinkTest`. Please let me know if you notice anything else that I missed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2560867281

From duke at openjdk.org  Tue Nov 25 17:43:15 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 25 Nov 2025 17:43:15 GMT
Subject: RFR: 8366478: BigDecimal roots [v27]
In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
Message-ID: <WrT1nqw8DJdi3BgJvN6X0nX2G3MSOSYkPdHMT4rwGsk=.85dc379e-ef47-4c77-bc95-9cba6a394523@github.com>

> An implementation of `BigDecimal.nthRoot(int, MathContext)`.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct error output message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27148/files
  - new: https://git.openjdk.org/jdk/pull/27148/files/55ba5578..81b3b775

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=25-26

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148

PR: https://git.openjdk.org/jdk/pull/27148

From duke at openjdk.org  Tue Nov 25 17:58:36 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 25 Nov 2025 17:58:36 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty [v2]
In-Reply-To: <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
Message-ID: <y2rs-E2nke7uQXeRUJedqb8K9hgWfCIPH4tcyT6-wKE=.73f1160a-57b7-481d-9efa-f05ca2ffd870@github.com>

On Tue, 25 Nov 2025 12:51:07 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Adds the patch by @DougLea
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes after code review

Maybe /contributor Dr Heinz M. Kabutz <heinz at javaspecialists.eu> ? I'm surprised that @kabutz did not work, since I have contributed before.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28479#issuecomment-3576842296

From duke at openjdk.org  Tue Nov 25 18:23:39 2025
From: duke at openjdk.org (James Yuzawa)
Date: Tue, 25 Nov 2025 18:23:39 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v2]
In-Reply-To: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
Message-ID: <7bqpLaU9FCBPSG77Fkd31oSnj_vI2eubh-PW1c4rXRU=.60b0cb3e-8d01-4781-bebb-96df89906da2@github.com>

> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
> 
> Here is a very simple reproducer:
> 
> ThreadLocalRandom r = ThreadLocalRandom.current();
> // step into this call using a debugger
> r.nextGaussian();
> 
> 
> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
> 
> Sketch:
> 
> public interface RandomGenerator {
> 	default double nextGaussian() {
> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> public class Random implements RandomGenerator {
> 	@Override
> 	public synchronized double nextGaussian() {
> 		// synchronized version ...
> 	}
> }
> 
> public class ThreadLocalRandom extends Random {
> 
> 	// ADD THIS
> 	@Override
> 	public double nextGaussian() {
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> 
> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
> 
> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
> 
> 
> Set<String> tlrMethods = new HashSet<>();
> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		tlrMethods.add(desc);
> 	}
> }
> for (Method method : java.util.Random.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		if (!tlrMethods.contains(desc)) {
> 			System.out.println(desc);
> 		}
> 	}
> }
> 
> 
> That prints
> 
> void nextBytes [byte[] arg0]
> double nextGaussian []
> 
> 
> The former safely calls `Thread...

James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:

  8372134: ThreadLocalRandom no longer overrides nextGaussian
  
  Fix javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28483/files
  - new: https://git.openjdk.org/jdk/pull/28483/files/d9350595..245dfb4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28483&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28483&range=00-01

  Stats: 19 lines in 1 file changed: 9 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28483/head:pull/28483

PR: https://git.openjdk.org/jdk/pull/28483

From duke at openjdk.org  Tue Nov 25 18:42:20 2025
From: duke at openjdk.org (James Yuzawa)
Date: Tue, 25 Nov 2025 18:42:20 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v2]
In-Reply-To: <7qeMdRtL1TbOw4mIaHlKHTmgiBawvRkGR7AgGqYFLKM=.77205c85-7643-4b13-a591-a1623be24274@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <GG1mzvk8CUYVwODmk2NnOpkkwowYRjD4jlO1Kb9QDUE=.568dbe52-7006-493e-ac63-8a88dfd584fe@github.com>
 <ckqSJC-GaF34C9PAVRwye1ocxqwW58W92-kU_G52iFs=.8daf6357-1223-4eb0-b819-0ca301bc3ffa@github.com>
 <7qeMdRtL1TbOw4mIaHlKHTmgiBawvRkGR7AgGqYFLKM=.77205c85-7643-4b13-a591-a1623be24274@github.com>
Message-ID: <iQZ262iop1ZGh8liy8JZtBOCvqmdxcwxRfAeUMP3icg=.9d911e71-ee81-467a-9afb-a57a4294b618@github.com>

On Tue, 25 Nov 2025 17:00:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Right, this will require attention. You kinda want `{@inheritDoc java.util.random.RandomGenerator}` but without overriding the method description then it won't appear in the Method Summary. The nextGaussian method defined by j.u.Random and j.u.random.RandomGenrator will be listed in the "Method declared by ..." section of course. 
>> 
>> In addition, Random's implSpec has the polar method whereas RandomGenrator's implSpec is ziggurat algorithm. So I think TLR.nextGaussian will need to copy from text RandomSupport.computeNextGaussian to get the right comment.
>
> In passing, I see there are several empty "Implementation Note:" in the TLR docs. It seems to be `@implNote {@inheritDoc}` when there isn't anything to inherit.

I have updated the javadoc here to copy over the basic parts of RandomGenerator.nextGaussian(). I ported over the comment from the top of TLR into an implementation note. Additionally, I removed the 4 spurious `@implNote {@inheritDoc}` usages, which I found to be empty in https://docs.oracle.com/en/java/javase/25/docs/api//java.base/java/util/concurrent/ThreadLocalRandom.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2561035881

From almatvee at openjdk.org  Tue Nov 25 19:03:09 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 25 Nov 2025 19:03:09 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
In-Reply-To: <XW3HjRSo4dS756ymqki--xcO5_J3-3L2HS2jPNsxDg0=.09dd692f-f2c9-4e8a-8141-d4c2e65ce8af@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <XW3HjRSo4dS756ymqki--xcO5_J3-3L2HS2jPNsxDg0=.09dd692f-f2c9-4e8a-8141-d4c2e65ce8af@github.com>
Message-ID: <3FNt5FzXTT3t-DGW3vklwSxQ8RyfN7A-NJNEQk3hRUk=.ff882dd7-3d30-46ca-aa33-e21bcade2e37@github.com>

On Tue, 25 Nov 2025 17:24:26 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Added following tests:
>> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
>> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
>> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).
>
> test/jdk/tools/jpackage/share/ServiceTest.java line 229:
> 
>> 227:             appImageCmd.cmd().orElseThrow().addArgument("--mac-app-store");
>> 228:         }
>> 229: 
> 
> Why do we need this option for an app image?

Without it jpackage will add launchers as a service even if `--mac-app-store` is specified for PKG. I do not think it is a bug. jpackage takes `--mac-app-store` value from predefined app image. Specifying it when generating PKG at line 265 is not needed and was added to make `cmd.hasArgument("--mac-app-store")` work. Maybe we need another approach and add isMacAppStore() function somewhere which will check predefined app image or `cmd.hasArgument("--mac-app-store")` to figure out if we generating for Mac App Store.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2561089855

From cushon at openjdk.org  Tue Nov 25 19:10:25 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 25 Nov 2025 19:10:25 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v14]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/396f9426..6065acd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=12-13

  Stats: 9 lines in 3 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From cushon at openjdk.org  Tue Nov 25 19:10:28 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 25 Nov 2025 19:10:28 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v13]
In-Reply-To: <mbV7Lytks5H07JmtFG5bas_kZNwP41FlTq_CZSipvBQ=.bb8d6f96-fed5-4bd3-87e0-256d20397ffe@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <OxFkXFJpY0zj0jVvcx99tWlV06eG-4GVDvrfRrVdUFQ=.eeea6b4a-3cc9-439d-b6ba-22ae87b2f7fd@github.com>
 <mbV7Lytks5H07JmtFG5bas_kZNwP41FlTq_CZSipvBQ=.bb8d6f96-fed5-4bd3-87e0-256d20397ffe@github.com>
Message-ID: <faodE9rf3GdjMC_YqDsccZdDl_41qSOWRjjQpfwGlaU=.d82e557d-9da2-46ed-8fa8-379584d6b7db@github.com>

On Tue, 25 Nov 2025 14:00:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update discussion of truncated reads of strings containing \0
>>  - Return the number of copied bytes
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2669:
> 
>> 2667:      * @throws IllegalArgumentException if {@code dst} is {@linkplain #isReadOnly() read-only}
>> 2668:      * @throws IndexOutOfBoundsException if {@code dstOffset > dstSegment.byteSize() - B} where {@code B} is the size,
>> 2669:      *         in bytes, of the string encoded using the given charset.
> 
> Nit pick: this says "the size... of the string... encoded..."... which string? It might suggest we're talking about `src`, but in reality we're talking about a *substring* of `src`

Thanks, rephrased as "substring of {@code src}"

> test/micro/org/openjdk/bench/java/lang/foreign/FromJavaStringTest.java line 71:
> 
>> 69: 
>> 70:     @Benchmark
>> 71:     public void panama_setString() {
> 
> I'd suggest to maybe avoid "panama" here and in the other benchmark. Maybe:
> * segment_setString
> * segment_copyStringRaw
> * segment_copyStringBytes

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2561037226
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2561086681

From cushon at openjdk.org  Tue Nov 25 19:10:29 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 25 Nov 2025 19:10:29 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v8]
In-Reply-To: <Q7iO-aoqoQnFFCCmwqLdG7Em2T26esJFkynPIaX4LHQ=.c174d1fe-2b93-4490-8d45-69e66f0e9064@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <5ryxpJnBSIC6XsoEuhl-D7Tc12voCRB_XKAI0Ierqc8=.56414b2e-0be2-4a22-af0c-707e71746389@github.com>
 <CAFR_ui-U4Bdq4HBvfQuWWcjSZwMRzC7wNbK9zzjwsE=.24cc696b-8131-426e-b6f7-639247b86803@github.com>
 <Q8JPn8XfKrQW61v0SOk8lv13gkDPkpeJ2hgy5aZZUQ0=.b0d7fcfa-ef44-4b06-87e5-c98198a7b2db@github.com>
 <G1K8qYx7YJ0UPUAMFnLt9_IAjcctuAbMMDBcroPXWqg=.af828881-bb49-421a-b60f-90df648a2fc4@github.com>
 <Q7iO-aoqoQnFFCCmwqLdG7Em2T26esJFkynPIaX4LHQ=.c174d1fe-2b93-4490-8d45-69e66f0e9064@github.com>
Message-ID: <UPrtRHPvchdWY_4zl0y0DN1DRsU7-9mvyzHQK2d4nRA=.d856a754-8f86-4639-9de4-25d65cfa4e67@github.com>

On Tue, 25 Nov 2025 14:13:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Done, and I added a test to cover the IAE
>
> I think I'm confused here.
> 
> This method is called by `MemorySegment::getString` with an explicit length.
> 
> The question is -- what does the length represent? There's two options:
> 
> 1. the length, in bytes, of the region of memory that needs to be _decoded_ into the final string bytes
> 2. the length of the final string bytes
> 
> IMHO, only (1) really makes sense -- as (2) involves some charset-specific guesswork.
> 
> But if (1) is (as I hope) what we mean, I think we should probably make that clearer in the javadoc. Then, the exception we throw here is related to the fact that we don't have a way to construct a string from something bigger than a byte[] -- which is, in a way, an impl specific issue (one can imagine manually decoding the segment bytes into a new char[], which is then used to create the string -- in which case it might be possible e.g. to read 4 * N UTF32 string bytes into a LATIN1 string backed by a byte array with size N).

Thanks, I agree seems like the interpretation we want, and that it is worth clarifying that in the javadoc. I have updated it to "length, in bytes, of the region of memory to read and decode into a string", suggestions for improvements to that are welcome.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2561080479

From jvernee at openjdk.org  Tue Nov 25 19:24:59 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Nov 2025 19:24:59 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v8]
In-Reply-To: <YpmmQyTak50BdUkBPoZGKyRchAzGfZRhlZqxnNsoLlE=.203a8643-0d2b-44ba-8ac6-8ee567f235d2@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <YpmmQyTak50BdUkBPoZGKyRchAzGfZRhlZqxnNsoLlE=.203a8643-0d2b-44ba-8ac6-8ee567f235d2@github.com>
Message-ID: <u2Rkcx4U5-KHtD95-OYF79Gwz-lm3F65GJwRLtsQjIg=.26817060-f2a3-4f5e-8790-2d0a4b8c5bea@github.com>

On Fri, 21 Nov 2025 12:08:40 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace error
>   
>   This work was sponsored by: The FreeBSD Foundation

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28235#pullrequestreview-3506498719

From jvernee at openjdk.org  Tue Nov 25 19:26:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Nov 2025 19:26:01 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v14]
In-Reply-To: <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>
Message-ID: <h0C40DaG6V5HWWqOoealndPYjXjh_iqOxi1TEjEq_p8=.3c4f7585-496f-444f-b962-a067654806be@github.com>

On Tue, 25 Nov 2025 19:10:25 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3506503166

From jvernee at openjdk.org  Tue Nov 25 19:27:02 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Nov 2025 19:27:02 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v5]
In-Reply-To: <A0J-7O3cuq27oWY3tv2SIYkb3jF1DiA3B43x6xeBu7M=.a20582a5-5d23-478b-9bb6-5345712b5ef0@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <A0J-7O3cuq27oWY3tv2SIYkb3jF1DiA3B43x6xeBu7M=.a20582a5-5d23-478b-9bb6-5345712b5ef0@github.com>
Message-ID: <7P_iPS__jL7jKoqpXaf3DGRAtJSrCoGczR7H2NRw10o=.9b39c61c-f2d5-4813-8470-cdb338a24567@github.com>

On Tue, 25 Nov 2025 12:22:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> Per Minborg 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 nine additional commits since the last revision:
> 
>  - Update after comments
>  - Merge branch 'master' into improved-bulk-benchmarks
>  - Add loop variant for mismatch
>  - Use other allocateFrom overload
>  - Remove lingering comment
>  - Refactor and use long arrays
>  - Remove BulkOps
>  - Fix copyright years
>  - Improve BulkOp benchmarks

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28260#pullrequestreview-3506505972

From asemenyuk at openjdk.org  Tue Nov 25 19:45:30 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Nov 2025 19:45:30 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
In-Reply-To: <3FNt5FzXTT3t-DGW3vklwSxQ8RyfN7A-NJNEQk3hRUk=.ff882dd7-3d30-46ca-aa33-e21bcade2e37@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <XW3HjRSo4dS756ymqki--xcO5_J3-3L2HS2jPNsxDg0=.09dd692f-f2c9-4e8a-8141-d4c2e65ce8af@github.com>
 <3FNt5FzXTT3t-DGW3vklwSxQ8RyfN7A-NJNEQk3hRUk=.ff882dd7-3d30-46ca-aa33-e21bcade2e37@github.com>
Message-ID: <auij4-e4hbwCdHlLrmPlrFokZlQLgKv-0ZcaN7Odn7Q=.6cab2159-6ddf-4e73-971c-217662e75961@github.com>

On Tue, 25 Nov 2025 19:00:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> test/jdk/tools/jpackage/share/ServiceTest.java line 229:
>> 
>>> 227:             appImageCmd.cmd().orElseThrow().addArgument("--mac-app-store");
>>> 228:         }
>>> 229: 
>> 
>> Why do we need this option for an app image?
>
> Without it jpackage will add launchers as a service even if `--mac-app-store` is specified for PKG. I do not think it is a bug. jpackage takes `--mac-app-store` value from predefined app image. Specifying it when generating PKG at line 265 is not needed and was added to make `cmd.hasArgument("--mac-app-store")` work. Maybe we need another approach and add isMacAppStore() function somewhere which will check predefined app image or `cmd.hasArgument("--mac-app-store")` to figure out if we generating for Mac App Store.

Ah, right. We store the value of the `--mac-app-store` option in the app image file. Then `LauncherAsServiceVerifier.launcherAsService()` should be as follows:


diff --git a/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java b/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java
index 0be6cf685f6..a0c7164f5a4 100644
--- a/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java
+++ b/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java
@@ -239,7 +239,9 @@ private static Map<Boolean, List<String>> partitionLaunchers(JPackageCommand cmd
     }

     static boolean launcherAsService(JPackageCommand cmd, String launcherName) {
-        if (cmd.isMainLauncher(launcherName)) {
+        if (MacHelper.isForAppStore(cmd)) {
+            return false;
+        } else if (cmd.isMainLauncher(launcherName)) {
             return PropertyFinder.findLauncherProperty(cmd, null,
                     PropertyFinder.cmdlineBooleanOption("--launcher-as-service"),
                     PropertyFinder.nop(),


This will eliminate the need for cmd.hasArgument("--mac-app-store") in the PKG bundling command line.

> Maybe we need another approach and add isMacAppStore() function somewhere which will check predefined app image or cmd.hasArgument("--mac-app-store") to figure out if we generating for Mac App Store.


diff --git a/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java b/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java
index a6d24af2b25..f7b124db1db 100644
--- a/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java
+++ b/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java
@@ -797,6 +797,15 @@ private static String getPackageId(JPackageCommand cmd) {
         ).orElseGet(cmd::name);
     }

+    static boolean isForAppStore(JPackageCommand cmd) {
+        return PropertyFinder.findAppProperty(cmd,
+                PropertyFinder.cmdlineBooleanOption("--mac-app-image"),
+                PropertyFinder.appImageFile(appImageFile -> {
+                    return Boolean.toString(appImageFile.macAppStore());
+                })
+        ).map(Boolean::parseBoolean).orElse(false);
+    }
+
     public static boolean isXcodeDevToolsInstalled() {
         return Inner.XCODE_DEV_TOOLS_INSTALLED;
     }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2561194108

From rriggs at openjdk.org  Tue Nov 25 20:14:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Nov 2025 20:14:00 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID
In-Reply-To: <zfVpWlGX55KfEgCt_lRTYxrNPPK2-ai-gHkQqDa9K5k=.c18dad75-cef8-4e6b-8ca9-ff271b561d31@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
 <zfVpWlGX55KfEgCt_lRTYxrNPPK2-ai-gHkQqDa9K5k=.c18dad75-cef8-4e6b-8ca9-ff271b561d31@github.com>
Message-ID: <bXApinI6yqWqhipgLvORZK3QF-A_ttV_XRQSL8I4qgI=.5ba1a3af-acfb-46b3-9c66-f16de99cd964@github.com>

On Thu, 20 Nov 2025 17:02:14 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015.
>
> PR description edited to include correct Bug ID

@kieran-farrell Nudge, see the suggestion above.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28435#issuecomment-3577406666

From sherman at openjdk.org  Tue Nov 25 20:21:26 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 25 Nov 2025 20:21:26 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@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 doc formatting update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/0aafb674..e5da752f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 rriggs at openjdk.org  Tue Nov 25 21:09:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Nov 2025 21:09:30 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v26]
In-Reply-To: <_3xcrMGOjqrYJZEGYKxk6whoWbKXC9eYo_VA5DcTir8=.1f5c30dc-ba19-46c1-a510-bb16ddcee79a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
 <_3xcrMGOjqrYJZEGYKxk6whoWbKXC9eYo_VA5DcTir8=.1f5c30dc-ba19-46c1-a510-bb16ddcee79a@github.com>
Message-ID: <AOv65HjP54haZtg-mXoYI1trbr6TpVQjySqZYXKD-NM=.1d100524-a1bf-4772-ac36-4f6adeffcf6d@github.com>

On Thu, 20 Nov 2025 23:46:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
>> 
>> Changes include:
>> 
>> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>>    - Enhanced Javadoc documentation for all new methods
>> 
>> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>>    - Replaced manual formatting logic with the new efficient two-digit appending
>>    - Improved code clarity and consistency in date/time formatting
>> 
>> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>   
>   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26911#pullrequestreview-3506808353

From rriggs at openjdk.org  Tue Nov 25 21:13:15 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Nov 2025 21:13:15 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11]
In-Reply-To: <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
Message-ID: <-caDaiJwJQ_T1kM5_TjsEe8HsNj40wfIparhZaLfZa4=.8c0248ea-04e7-42d3-bb7f-0f811d8d2813@github.com>

On Tue, 25 Nov 2025 20:21:26 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 doc formatting update

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3506820703

From rriggs at openjdk.org  Tue Nov 25 21:31:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Nov 2025 21:31:38 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11]
In-Reply-To: <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
Message-ID: <B7oORRAksuLACBOe3sVia8TmH79H9eesHet49qq2GX0=.b67d0059-a97c-4d05-8d53-320fa934e161@github.com>

On Tue, 25 Nov 2025 20:21:26 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 doc formatting update

Try again for information on the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3577662129

From dl at openjdk.org  Tue Nov 25 21:49:17 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Nov 2025 21:49:17 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v21]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <SP2ZoFNyBAFAFvfHvj1Y4lkJZSGoKsM4mWgRWaFDEu0=.8fe5d971-b9e2-4d89-8ec3-ce964bbae0c6@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea 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 32 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8360046
 - restore positioning of threadlocal clears
 - Add comment
 - Merge branch 'openjdk:master' into JDK-8360046
 - Signal on setParallelism
 - Drop added Contended region; simplify accordingly
 - Tweaks
 - Merge branch 'openjdk:master' into JDK-8360046
 - Seperate repolling policies
 - Faster quiescent termination
 - ... and 22 more: https://git.openjdk.org/jdk/compare/875ef400...1de99906

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/9f130030..1de99906

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=19-20

  Stats: 5674 lines in 149 files changed: 3285 ins; 1418 del; 971 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From dhanalla at openjdk.org  Tue Nov 25 22:23:36 2025
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Tue, 25 Nov 2025 22:23:36 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64 [v2]
In-Reply-To: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
Message-ID: <Mc0Z5i4FeYfrF_F_OxZ0Jpq3M4bRq3ELK7MVYMvElZI=.b0f15c04-7cca-4d6f-a06d-4031681cb574@github.com>

> This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial.
> Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN).
> 
> 
> 
> The micro-benchmark results from MathBench and StrictMathBench below show the performance improvement of Math.log:
> 
> 
> **Before change**
> <html xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=OneNote.File>
> <meta name=Generator content="Microsoft OneNote 15">
> </head>
> 
> <body lang=en-US style='font-family:Calibri;font-size:11.0pt'>
> 
> 
> <div style='direction:ltr;border-width:100%'>
> 
> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
> 
> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
> 
> <div style='direction:ltr'>
> 
> Benchmark | Mode | Cnt | Score | Error | Units
> -- | -- | -- | -- | -- | --
> MathBench.logDouble | thrpt | 10 | **15549.705** | ?357.439 | ops/ms
> StrictMathBench.logDouble | thrpt | 10 | 219408.158 | ?16484.680 | ops/ms
> 
> </div>
> 
> </div>
> 
> </div>
> 
> </div>
> 
> 
> </body>
> 
> </html>
> 
> 
> 
> **After adding Math.log intrinsic**
> 
> <html xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=OneNote.File>
> <meta name=Generator content="Microsoft OneNote 15">
> </head>
> 
> <body lang=en-US style='font-family:Calibri;font-size:11.0pt'>
> 
> 
> <div style='direction:ltr;border-width:100%'>
> 
> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
> 
> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
> 
> <div style='direction:ltr'>
> 
> Benchmark | Mode | Cnt | Score | Error | Units
> -- | -- | -- | -- | -- | --
> MathBench.logDouble | thrpt | 10 | **300086.773** | ?6675.936 | ops/ms
> StrictMathBench.logDouble | thrpt | 10 | 226521.817 | ?4038.975 | ops/ms
> 
> 
> </div>
> 
> </div>
> 
> </div>
> 
> </div>
> 
> 
> </body>
> 
> </html>

Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:

  [AArch64] Math.log is 10% slower than StrictMath.log on aarch64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28306/files
  - new: https://git.openjdk.org/jdk/pull/28306/files/e8fac776..06b3dd4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28306&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28306&range=00-01

  Stats: 184 lines in 4 files changed: 66 ins; 114 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28306/head:pull/28306

PR: https://git.openjdk.org/jdk/pull/28306

From duke at openjdk.org  Tue Nov 25 23:03:11 2025
From: duke at openjdk.org (Trevor Bond)
Date: Tue, 25 Nov 2025 23:03:11 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries [v2]
In-Reply-To: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
Message-ID: <gHRCmRTkG336B8Ao4tEvHN-O5bbzjUrS0s8C3jmBZFM=.a43b9abe-9921-4b67-9daa-7cbfade720ea@github.com>

> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
> 
> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
> 
> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
> 
> | Version | Avg Time (ns/op) | ? vs Before |
> |--------|------------------:|-------------|
> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |

Trevor Bond has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28458/files
  - new: https://git.openjdk.org/jdk/pull/28458/files/c906c061..a990cd30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28458&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28458&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28458/head:pull/28458

PR: https://git.openjdk.org/jdk/pull/28458

From duke at openjdk.org  Tue Nov 25 23:08:49 2025
From: duke at openjdk.org (Trevor Bond)
Date: Tue, 25 Nov 2025 23:08:49 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries [v2]
In-Reply-To: <bFM8lu1TL_EVBacOz2in-Z2x1Ln1egd7YdA91Ka9a3M=.d5d4df5b-8457-47be-bb5a-f9f7eae137c2@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
 <bFM8lu1TL_EVBacOz2in-Z2x1Ln1egd7YdA91Ka9a3M=.d5d4df5b-8457-47be-bb5a-f9f7eae137c2@github.com>
Message-ID: <Bm36HjpZ8qtgoQDLgZIAbzMSESMd7Qje1FSDfCE5zgc=.0caf1798-c7a3-4ade-8beb-e368190a560f@github.com>

On Tue, 25 Nov 2025 04:25:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Trevor Bond has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary imports
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 171:
> 
>> 169:             if (ci == null) return null;
>> 170:             try (ci) {
>> 171:                 ClassReader reader = new ClassReaderImpl(ci.readAllBytes(), (ClassFileImpl) ClassFile.of());
> 
> Suggestion:
> 
>                 var reader = new ClassReaderImpl(ci.readAllBytes(), ClassFileImpl.DEFAULT_CONTEXT);
> 
> And you can remove the 3 imports you have added.

Thank you for this. I adjusted that line and the imports accordingly. I still found a need to import `java.lang.classfile.constantpool.ClassEntry` for the line further down converting the ClassEntry to a ClassDesc. If that can also be avoided I'm happy to fix. I also removed a few imports previously needed but that can be removed with these changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28458#discussion_r2561849713

From dhanalla at openjdk.org  Wed Nov 26 00:54:53 2025
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Wed, 26 Nov 2025 00:54:53 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64 [v2]
In-Reply-To: <9s7p49-bYB_amcD0q2XuEpeNPy4Ud1p38pE-UHEyB7c=.b9ef99f0-2381-4a83-856a-bc0dd273f4f1@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
 <9s7p49-bYB_amcD0q2XuEpeNPy4Ud1p38pE-UHEyB7c=.b9ef99f0-2381-4a83-856a-bc0dd273f4f1@github.com>
Message-ID: <vswXRpv2bbPoAfwwKvnF7vPTJYUwGEglcl5gW7cSmLU=.771f7e2e-6a7d-4c0f-9f99-bfd507a924d9@github.com>

On Tue, 18 Nov 2025 20:55:12 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Drive-by, cannot promise a full review. But I'm interested ;)
> 
> Mostly, I have questions about testing. Are there already tests for accuracy somewhere?
> 
> Do you have any benchmark results to support this PR? It would be good if we had a way to prove that performance is good for all sorts of inputs. I suppose we don't have any loops here, so we should just make sure to benchmark cases so that all possible paths of the intrinsic are covered, right?

Thanks @eme64, Updated the PR description with MathBench.logDouble results.

> test/jdk/java/lang/Math/TestLogMonotonicity.java line 61:
> 
>> 59:         // Powers of two 2^1 .. 2^16
>> 60:         for (int i = 1; i <= 16; i++) {
>> 61:             list.add(Math.pow(2.0, i));
> 
> It seems you now only cover powers of 2, right? Is this sufficient? I don't know what other tests already exist, so maybe this is already covered elsewhere?

Updated the existing LogTests.java with similar monotonicity test in Log1pTests.java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28306#issuecomment-3578261545
PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2562201697

From dhanalla at openjdk.org  Wed Nov 26 00:54:55 2025
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Wed, 26 Nov 2025 00:54:55 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64 [v2]
In-Reply-To: <Lsot8T8Xe2hd1kalJeF2GMILFvR0ZZ6nItr91NNaES8=.254ecb21-c6e5-4f45-82f1-7be43112c3d0@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
 <9s7p49-bYB_amcD0q2XuEpeNPy4Ud1p38pE-UHEyB7c=.b9ef99f0-2381-4a83-856a-bc0dd273f4f1@github.com>
 <Lsot8T8Xe2hd1kalJeF2GMILFvR0ZZ6nItr91NNaES8=.254ecb21-c6e5-4f45-82f1-7be43112c3d0@github.com>
Message-ID: <Y6w2GJyxgHOymtPuO5LG3ed6ArFuSqNBKY1QZWFWB4Q=.e3a6d64e-f93d-4622-9196-81e3f62898a2@github.com>

On Tue, 18 Nov 2025 20:51:57 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/jdk/java/lang/Math/TestLogMinValue.java line 28:
>> 
>>> 26:  * @bug 8308776
>>> 27:  * @build Tests
>>> 28:  * @summary Compare Math.log and StrictMath.log for Double.MIN_VALUE (denormal smallest positive) to ensure consistency.
>> 
>> Are there tests that check for consistency of the other values?
>
> Do we have tests that already check for sufficient accuracy?

Updated the existing LogTests with these new test scenarios.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2562194013

From dhanalla at openjdk.org  Wed Nov 26 00:54:57 2025
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Wed, 26 Nov 2025 00:54:57 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64 [v2]
In-Reply-To: <qW2UPFPlrIUuOTcOiU3_uqy687wnT54s9Mu8YOtI8V4=.ef8d809e-2d50-4f9c-b56f-8bc3043791a3@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
 <qW2UPFPlrIUuOTcOiU3_uqy687wnT54s9Mu8YOtI8V4=.ef8d809e-2d50-4f9c-b56f-8bc3043791a3@github.com>
Message-ID: <qxAr3msyIYJ9i6B57XDF5crYwta0hVw1cVpPTB40cwg=.a4ed4a13-1df0-4833-bce0-353a8e73a2c7@github.com>

On Tue, 18 Nov 2025 21:18:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   [AArch64] Math.log is 10% slower than StrictMath.log on aarch64
>
> test/jdk/java/lang/Math/TestLogMonotonicity.java line 29:
> 
>> 27:  * @run main TestLogMonotonicity
>> 28:  */
>> 29: public class TestLogMonotonicity {
> 
> So the test is checking for monotonicity over value that are 2X the previous value?
> 
> That is a very weak test.
> 
> In other math library regression tests we test for monotonicity on successive values.

Thanks @jddarcy, Updated the existing LogTests.java with similar monotonicity test in Log1pTests.java.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2562205428

From liach at openjdk.org  Wed Nov 26 01:06:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Nov 2025 01:06:48 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries [v2]
In-Reply-To: <gHRCmRTkG336B8Ao4tEvHN-O5bbzjUrS0s8C3jmBZFM=.a43b9abe-9921-4b67-9daa-7cbfade720ea@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
 <gHRCmRTkG336B8Ao4tEvHN-O5bbzjUrS0s8C3jmBZFM=.a43b9abe-9921-4b67-9daa-7cbfade720ea@github.com>
Message-ID: <qwuYBVBEoS2ErGg7tjPXpZ1NydX31aHZMccA_QrZgMY=.71a654bc-185c-4bd2-9451-ba0a9180ac34@github.com>

On Tue, 25 Nov 2025 23:03:11 GMT, Trevor Bond <duke at openjdk.org> wrote:

>> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
>> 
>> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
>> 
>> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
>> 
>> | Version | Avg Time (ns/op) | ? vs Before |
>> |--------|------------------:|-------------|
>> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
>> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |
>
> Trevor Bond has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary imports

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28458#pullrequestreview-3507718128

From duke at openjdk.org  Wed Nov 26 01:26:49 2025
From: duke at openjdk.org (duke)
Date: Wed, 26 Nov 2025 01:26:49 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries [v2]
In-Reply-To: <gHRCmRTkG336B8Ao4tEvHN-O5bbzjUrS0s8C3jmBZFM=.a43b9abe-9921-4b67-9daa-7cbfade720ea@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
 <gHRCmRTkG336B8Ao4tEvHN-O5bbzjUrS0s8C3jmBZFM=.a43b9abe-9921-4b67-9daa-7cbfade720ea@github.com>
Message-ID: <u6YEPYWHPYJjWhDGP_2DzZaROUFemSEewTwSO3Lx3CU=.64f3f8e3-3776-440a-ad4b-0d958b1afec5@github.com>

On Tue, 25 Nov 2025 23:03:11 GMT, Trevor Bond <duke at openjdk.org> wrote:

>> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
>> 
>> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
>> 
>> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
>> 
>> | Version | Avg Time (ns/op) | ? vs Before |
>> |--------|------------------:|-------------|
>> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
>> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |
>
> Trevor Bond has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary imports

@trevorkbond 
Your change (at version a990cd30b4d076d41210b3872b8abf29cc3eca9f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28458#issuecomment-3578349393

From almatvee at openjdk.org  Wed Nov 26 01:49:47 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Nov 2025 01:49:47 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v2]
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <u2wvqVApgJZ59rvu_RL0Ga0pmuT8HY67Q4c3a2E3mdM=.92dc0b40-963d-4470-9018-495768dab99e@github.com>

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

Alexander Matveev 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 three additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8351095
 - 8351095: [macos] Add more jpackage tests for --mac-app-store option [v2]
 - 8351095: [macos] Add more jpackage tests for --mac-app-store option

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28487/files
  - new: https://git.openjdk.org/jdk/pull/28487/files/bf186c2b..0de1ca31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28487&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28487&range=00-01

  Stats: 45114 lines in 624 files changed: 31613 ins; 9151 del; 4350 mod
  Patch: https://git.openjdk.org/jdk/pull/28487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28487/head:pull/28487

PR: https://git.openjdk.org/jdk/pull/28487

From almatvee at openjdk.org  Wed Nov 26 01:49:48 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Nov 2025 01:49:48 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <nSkgaviwK7qvA1S9WN-PydYQAHPL14Qf4zLavtgwxtw=.e3d504c9-3494-4615-93a1-06512402ede5@github.com>

On Tue, 25 Nov 2025 03:58:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

8351095: [macos] Add more jpackage tests for --mac-app-store option [v2]
- Fixed latest comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28487#issuecomment-3578407788

From asemenyuk at openjdk.org  Wed Nov 26 02:19:51 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 26 Nov 2025 02:19:51 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v2]
In-Reply-To: <u2wvqVApgJZ59rvu_RL0Ga0pmuT8HY67Q4c3a2E3mdM=.92dc0b40-963d-4470-9018-495768dab99e@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <u2wvqVApgJZ59rvu_RL0Ga0pmuT8HY67Q4c3a2E3mdM=.92dc0b40-963d-4470-9018-495768dab99e@github.com>
Message-ID: <HC_0Q6jEs1lmwHG0myuPMy0xzZoj73ivbUnsxIE1XOk=.cc1a8e24-744a-4ed6-b2ed-dc80cc5220f7@github.com>

On Wed, 26 Nov 2025 01:49:47 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Added following tests:
>> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
>> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
>> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).
>
> Alexander Matveev 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8351095
>  - 8351095: [macos] Add more jpackage tests for --mac-app-store option [v2]
>  - 8351095: [macos] Add more jpackage tests for --mac-app-store option

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java line 171:

> 169:                 // Launcher should not be a service with "--launcher-as-service"
> 170:                 // and "--mac-app-store" specified.
> 171:                 verify(cmd, launcherName, launcherAsService && !cmd.hasArgument("--mac-app-store"));

This change looks redundant. In case of "--mac-app-store" the list of launcher names that should be installed as services will (should) be empty after the tweak to the `boolean launcherAsService(JPackageCommand cmd, String launcherName)` function.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java line 202:

> 200:         }
> 201: 
> 202:         if (launcherAsServiceNames.isEmpty() || cmd.isRuntime() || cmd.hasArgument("--mac-app-store")) {

Same as above, this is a redundant change. `launcherAsServiceNames` should be empty if "--mac-app-store" is present.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java line 238:

> 236:         } else {
> 237:             return Objects.requireNonNull(partitionLaunchers(cmd).get(true));
> 238:         }

Same as above, this is a redundant change: `partitionLaunchers()` function will return empty partition with the names of launchers installed as services after the tweak to the `boolean launcherAsService(JPackageCommand cmd, String launcherName)` function.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28487#pullrequestreview-3508026204
PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2562528333
PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2562533081
PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2562541016

From almatvee at openjdk.org  Wed Nov 26 03:24:30 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Nov 2025 03:24:30 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v3]
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <r9qSnSv8BsJ8hpTHYKzxBX6qO1kqr_WpnGOQ8hqyKsQ=.9ef49375-f04e-42b5-979a-9daa6e7ce6bb@github.com>

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8351095: [macos] Add more jpackage tests for --mac-app-store option [v3]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28487/files
  - new: https://git.openjdk.org/jdk/pull/28487/files/0de1ca31..f9b89647

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28487&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28487&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28487/head:pull/28487

PR: https://git.openjdk.org/jdk/pull/28487

From almatvee at openjdk.org  Wed Nov 26 03:24:34 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Nov 2025 03:24:34 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v2]
In-Reply-To: <u2wvqVApgJZ59rvu_RL0Ga0pmuT8HY67Q4c3a2E3mdM=.92dc0b40-963d-4470-9018-495768dab99e@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <u2wvqVApgJZ59rvu_RL0Ga0pmuT8HY67Q4c3a2E3mdM=.92dc0b40-963d-4470-9018-495768dab99e@github.com>
Message-ID: <WfvV4sNq5oYfy-DZXRatxOAuoDFYHi3QL_yD7Z1J1M0=.b8a77dce-328b-47ea-8b84-df575b4de03b@github.com>

On Wed, 26 Nov 2025 01:49:47 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Added following tests:
>> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
>> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
>> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).
>
> Alexander Matveev 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8351095
>  - 8351095: [macos] Add more jpackage tests for --mac-app-store option [v2]
>  - 8351095: [macos] Add more jpackage tests for --mac-app-store option

8351095: [macos] Add more jpackage tests for --mac-app-store option [v3]
- Removed redundant changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28487#issuecomment-3578806695

From asemenyuk at openjdk.org  Wed Nov 26 03:55:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 26 Nov 2025 03:55:48 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v3]
In-Reply-To: <r9qSnSv8BsJ8hpTHYKzxBX6qO1kqr_WpnGOQ8hqyKsQ=.9ef49375-f04e-42b5-979a-9daa6e7ce6bb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <r9qSnSv8BsJ8hpTHYKzxBX6qO1kqr_WpnGOQ8hqyKsQ=.9ef49375-f04e-42b5-979a-9daa6e7ce6bb@github.com>
Message-ID: <aB5nyD3Qy3d5vuc7YxLkRPNtgXm9ACM-2gkyXNn82GA=.7be5e28d-9615-4b30-9016-172feb5a96e4@github.com>

On Wed, 26 Nov 2025 03:24:30 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Added following tests:
>> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
>> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
>> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351095: [macos] Add more jpackage tests for --mac-app-store option [v3]

test/jdk/tools/jpackage/share/ServiceTest.java line 267:

> 265:                     if (isMacAppStore) {
> 266:                         cmd.addArgument("--mac-app-store");
> 267:                     }

Do we still need this change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2562898582

From almatvee at openjdk.org  Wed Nov 26 04:14:48 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Nov 2025 04:14:48 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v3]
In-Reply-To: <aB5nyD3Qy3d5vuc7YxLkRPNtgXm9ACM-2gkyXNn82GA=.7be5e28d-9615-4b30-9016-172feb5a96e4@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <r9qSnSv8BsJ8hpTHYKzxBX6qO1kqr_WpnGOQ8hqyKsQ=.9ef49375-f04e-42b5-979a-9daa6e7ce6bb@github.com>
 <aB5nyD3Qy3d5vuc7YxLkRPNtgXm9ACM-2gkyXNn82GA=.7be5e28d-9615-4b30-9016-172feb5a96e4@github.com>
Message-ID: <88pEB1vkN1ZCbam177TMAkK-hlM-DKGb29Yc8yWpPks=.7713d1c7-9c30-4661-94c8-7d4d743ee97c@github.com>

On Wed, 26 Nov 2025 03:52:38 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8351095: [macos] Add more jpackage tests for --mac-app-store option [v3]
>
> test/jdk/tools/jpackage/share/ServiceTest.java line 267:
> 
>> 265:                     if (isMacAppStore) {
>> 266:                         cmd.addArgument("--mac-app-store");
>> 267:                     }
> 
> Do we still need this change?

Maybe. I am getting following error without it:

java.lang.AssertionError: Expected [2]. Actual [1]: Check the package has 2 top installation directories
	at jdk.jpackage.test.TKit.error(TKit.java:369)
	at jdk.jpackage.test.TKit.assertEquals(TKit.java:720)
	at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:858)

I need to investigate it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2562960147

From asemenyuk at openjdk.org  Wed Nov 26 05:04:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 26 Nov 2025 05:04:55 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v3]
In-Reply-To: <88pEB1vkN1ZCbam177TMAkK-hlM-DKGb29Yc8yWpPks=.7713d1c7-9c30-4661-94c8-7d4d743ee97c@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <r9qSnSv8BsJ8hpTHYKzxBX6qO1kqr_WpnGOQ8hqyKsQ=.9ef49375-f04e-42b5-979a-9daa6e7ce6bb@github.com>
 <aB5nyD3Qy3d5vuc7YxLkRPNtgXm9ACM-2gkyXNn82GA=.7be5e28d-9615-4b30-9016-172feb5a96e4@github.com>
 <88pEB1vkN1ZCbam177TMAkK-hlM-DKGb29Yc8yWpPks=.7713d1c7-9c30-4661-94c8-7d4d743ee97c@github.com>
Message-ID: <0sPVMA3Yh0t5KpeHV3wHPs11DEoHEQI-W5yGIDuVa_A=.975e91f7-3280-4840-98ac-97fa8c008f01@github.com>

On Wed, 26 Nov 2025 04:12:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> test/jdk/tools/jpackage/share/ServiceTest.java line 267:
>> 
>>> 265:                     if (isMacAppStore) {
>>> 266:                         cmd.addArgument("--mac-app-store");
>>> 267:                     }
>> 
>> Do we still need this change?
>
> Maybe. I am getting following error without it:
> 
> java.lang.AssertionError: Expected [2]. Actual [1]: Check the package has 2 top installation directories
> 	at jdk.jpackage.test.TKit.error(TKit.java:369)
> 	at jdk.jpackage.test.TKit.assertEquals(TKit.java:720)
> 	at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:858)
> 
> I need to investigate it.

Looks like in the case of predefined app image packaging, when "--mac-app-store" is used with the predefined app image but not used in the terminal packaging command, jpackage still adds service files to the package. Looks like a bug.

We added "mac-app-store" property to the app image file in [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850). Do we still need it? Why do we want to know that the predefined app image was created with "--mac-app-store" option? In app image bundling, this option affects signing identities only, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2563127128

From jpai at openjdk.org  Wed Nov 26 05:23:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 05:23:50 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v7]
In-Reply-To: <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>
Message-ID: <uWmMx004rGxp7AADfveOT2AI0PsGG0XR_CDqF5RA26I=.619f81c6-ac99-4843-954f-9eb7cc4c6e63@github.com>

On Tue, 25 Nov 2025 17:41:27 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test for invalid values from TaskHelperTest to JLinkTest.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 69:

> 67: main.opt.bind-services=\
> 68: \      --bind-services                   Link in service provider modules and\n\
> 69: \                                        their dependencies

I think we should leave this change (here and in one other place) out of this PR. There's https://bugs.openjdk.org/browse/JDK-8337422 which is tracking this and there's some discussion in that issue, which indicates that it's OK to do this change. But I think we should do it as part of JDK-8337422.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2563195225

From jpai at openjdk.org  Wed Nov 26 05:30:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 05:30:54 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v7]
In-Reply-To: <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>
Message-ID: <-xgHQnApWk_Wx2Gj6H8D99SpH9PdMA0lX0gh0-qOrFQ=.5b633e04-45c2-47d1-afba-fc9d7b583864@github.com>

On Tue, 25 Nov 2025 17:41:27 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test for invalid values from TaskHelperTest to JLinkTest.

test/jdk/tools/jlink/JLinkTest.java line 361:

> 359:         }
> 360: 
> 361:         // short command  without argument- JDK-8321139

We don't usually include JBS bug ids in code comments. For tests which are related to a bug fix, like this one, we include the bug id in the `@bug` tag of the test definition https://openjdk.org/jtreg/tag-spec.html.

This `JLinkTest`, unfortunately has a pre-existing problem that it uses `@bug` more than once (which as per the `@bug` tag specification, isn't correct). So you will have to do some extra work with this one and address that part too. Ultimately, for this test, the `@bug` should now be:


@bug 8189777 8194922 8206962 8240349 8321139

While at it, please also update the `@bug` line in `TaskHelperTest` to include 8321139.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2563227397

From jpai at openjdk.org  Wed Nov 26 05:35:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 05:35:47 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v7]
In-Reply-To: <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>
Message-ID: <uMAFrMeJF31YBnSk1MuXxTcaNYxQhS8CfofX7F0aDaw=.e6caff8d-2f53-47c4-be61-c3578b073580@github.com>

On Tue, 25 Nov 2025 17:41:27 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test for invalid values from TaskHelperTest to JLinkTest.

jlink related tests run in tier2, so they aren't covered in the GitHub actions test jobs which run only tier1. Please run tier2 tests, either locally or in our CI, to verify that these changes work fine and the tests continue to pass with these updates. I too will run these changes in our CI once.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28359#issuecomment-3579261374

From jpai at openjdk.org  Wed Nov 26 05:44:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 05:44:51 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries [v2]
In-Reply-To: <gHRCmRTkG336B8Ao4tEvHN-O5bbzjUrS0s8C3jmBZFM=.a43b9abe-9921-4b67-9daa-7cbfade720ea@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
 <gHRCmRTkG336B8Ao4tEvHN-O5bbzjUrS0s8C3jmBZFM=.a43b9abe-9921-4b67-9daa-7cbfade720ea@github.com>
Message-ID: <YOwwaBsPUlb4f3el6PhC7-lL3IAg6EolF8RxHnpexU4=.82847130-629c-40e2-9b54-c8e4a0d4f98e@github.com>

On Tue, 25 Nov 2025 23:03:11 GMT, Trevor Bond <duke at openjdk.org> wrote:

>> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
>> 
>> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
>> 
>> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
>> 
>> | Version | Avg Time (ns/op) | ? vs Before |
>> |--------|------------------:|-------------|
>> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
>> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |
>
> Trevor Bond has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary imports

Hello Trevor, please update the copyright year on `ClassHierarchyImpl.java` from `2022, 2024,` to `2022, 2025,`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28458#issuecomment-3579296618

From swen at openjdk.org  Wed Nov 26 05:49:03 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 26 Nov 2025 05:49:03 GMT
Subject: Integrated: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <5cUU4WXW2UeOBJoK3QRKXudsEsnEqQ-NCWaYMWM5fDo=.203b1e9d-5639-4be2-9e41-6cd598db42ff@github.com>

On Sat, 23 Aug 2025 04:06:13 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

This pull request has now been integrated.

Changeset: 4ffdf7af
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ffdf7af88f6c0a69663eb249957dbceea3cb697
Stats:     111 lines in 6 files changed: 75 ins; 7 del; 29 mod

8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper

Reviewed-by: liach, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/26911

From ssarathi at openjdk.org  Wed Nov 26 05:50:58 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Wed, 26 Nov 2025 05:50:58 GMT
Subject: Integrated: 8372399: Add missing CPE statements
In-Reply-To: <lv0BZ7RURfvASy1O-YjegG6_dbjRUmeNvzh2w56qQhU=.b24de879-ade7-4439-951c-625e07d7e0c8@github.com>
References: <lv0BZ7RURfvASy1O-YjegG6_dbjRUmeNvzh2w56qQhU=.b24de879-ade7-4439-951c-625e07d7e0c8@github.com>
Message-ID: <3VTLtfz4Cp3QvPVBwlADFwkJuB599m0gpIo7uQ-0eHI=.0ea33bbc-e90e-4be5-bada-f5bee6ceca71@github.com>

On Mon, 24 Nov 2025 12:00:24 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> Adds missing Classpath Exception statements
> JDK Issue: [JDK-8372399](https://bugs.openjdk.org/browse/JDK-8372399)

This pull request has now been integrated.

Changeset: 7cc584fb
Author:    Sorna Sarathi N <ssarathi at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7cc584fbe6ce3d2f14d96ffb7e9650fd3498aa7a
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8372399: Add missing CPE statements

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/28474

From jpai at openjdk.org  Wed Nov 26 06:09:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 06:09:48 GMT
Subject: RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS
In-Reply-To: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>
References: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>
Message-ID: <-22T7W3Qs_jvwLe6g9-A7vBpy87mAddv3zvuyMfZ9SI=.f80667aa-cdbe-4216-a2f9-c518c687de41@github.com>

On Tue, 18 Nov 2025 08:24:13 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test tools/jar/ReproducibleJar.java fails when running on a file system that only supports to 2038(e.g. XFS).
> 
> Before this PR, test check if the input test time after "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to "2038-01-19T03:14:07Z", then test will skip that check.
> 
> But the extraced time created by jar equal to "1970-01-01T00:00:00Z" actually. I think the extracted time set to unix epoch time is acceptable, so this PR fix the test make test check skip when the extracted time is unix epoch time.
> 
> Change has been verified locally on XFS file system and ext4 file system.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28367#pullrequestreview-3509029840

From jpai at openjdk.org  Wed Nov 26 06:09:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 06:09:50 GMT
Subject: RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS
In-Reply-To: <xeN8f3Bbu5iqQCLSKNuoz7iX2SeFrXhx2pZfgJQqArY=.12ec2ed6-8295-4d55-bee3-3ebd871860fe@github.com>
References: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>
 <xeN8f3Bbu5iqQCLSKNuoz7iX2SeFrXhx2pZfgJQqArY=.12ec2ed6-8295-4d55-bee3-3ebd871860fe@github.com>
Message-ID: <6MBy-lrlxqx2CClf8qgc2TMsuc3SSOlvo9dEBNkwvIo=.274e1d00-71cd-44dc-b289-898d3ac857c2@github.com>

On Sat, 22 Nov 2025 13:25:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test tools/jar/ReproducibleJar.java fails when running on a file system that only supports to 2038(e.g. XFS).
>> 
>> Before this PR, test check if the input test time after "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to "2038-01-19T03:14:07Z", then test will skip that check.
>> 
>> But the extraced time created by jar equal to "1970-01-01T00:00:00Z" actually. I think the extracted time set to unix epoch time is acceptable, so this PR fix the test make test check skip when the extracted time is unix epoch time.
>> 
>> Change has been verified locally on XFS file system and ext4 file system.
>
> I create a demo to explain what utimes linux system call works on XFS file system.
> 
> When the time value bigger or equals the maximum of signed integer, then the time will set to UNIX epoch time.
> 
> 
> #include <stdio.h>
> #include <sys/time.h>
> #include <time.h>
> #include <stdlib.h>
> 
> int main(int argc, char** argv) {
>     if (argc != 3) {
>         printf("usage: ./a.out file seconds\n");
>         return 1;
>     }
>     const char *filename = argv[1];
>     struct timeval times[2];
>     long time = atol(argv[2]);
> 
>     times[0].tv_sec = time;  // atime
>     times[0].tv_usec = 0;
>     
>     times[1].tv_sec = time;  // mtime
>     times[1].tv_usec = 0;
>     
>     int ret = utimes(filename, times);
>     printf("utimes to file %s as %ld return code is %d\n", filename, time, ret);
>     
>     return 0;
> }
> 
> 
> Test command and result:
> 
> 
>> gcc -Wall -Wextra ~/compiler-test/zzkk/utimes-test.c ; ./a.out a.out 2147483646 ; stat --format %y a.out
> utimes to file a.out as 2147483646 return code is 0
> 2038-01-19 11:14:06.000000000 +0800
>> gcc -Wall -Wextra ~/compiler-test/zzkk/utimes-test.c ; ./a.out a.out 2147483647 ; stat --format %y a.out
> utimes to file a.out as 2147483647 return code is 0
> 1970-01-01 08:00:00.000000000 +0800

Thank you @sendaoYan for running this experiment and checking the code. 

>  So the system call utimes set the directory to the Unix epoch time.

That answers one part of my question - so it's not the JDK code which is (re)setting the timestamp to Unix Epoch. That's a good thing. The other part to the question was whether the underlying filesystem always sets it to exact Unix epoch and from what I understand of your experiments, it always sets it to this value.

Given this, the change in this PR looks good to me. I'll run this change in our CI just to be sure that it doesn't cause any unexpected issues there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3579380186

From epeter at openjdk.org  Wed Nov 26 06:13:51 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 26 Nov 2025 06:13:51 GMT
Subject: RFR: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks [v5]
In-Reply-To: <A0J-7O3cuq27oWY3tv2SIYkb3jF1DiA3B43x6xeBu7M=.a20582a5-5d23-478b-9bb6-5345712b5ef0@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
 <A0J-7O3cuq27oWY3tv2SIYkb3jF1DiA3B43x6xeBu7M=.a20582a5-5d23-478b-9bb6-5345712b5ef0@github.com>
Message-ID: <N3B0lUZayIgQxTygSp2DFNPC4-a_HpsCXAT2V4lQ4p0=.772d6783-fffb-43a9-89af-c16141210880@github.com>

On Tue, 25 Nov 2025 12:22:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
>> 
>> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
>> 
>> It should be noted that with this change, the running time for the benchmarks would increase significantly.
>
> Per Minborg 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 nine additional commits since the last revision:
> 
>  - Update after comments
>  - Merge branch 'master' into improved-bulk-benchmarks
>  - Add loop variant for mismatch
>  - Use other allocateFrom overload
>  - Remove lingering comment
>  - Refactor and use long arrays
>  - Remove BulkOps
>  - Fix copyright years
>  - Improve BulkOp benchmarks

FYI: I'm working on a related benchmark with https://github.com/openjdk/jdk/pull/27315. But I take a different approach to alignment: I "randomize" the alignment by starting at various different offsets for loads and stores. I have lots of plots in case you are graphically inclined ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28260#issuecomment-3579400320

From jpai at openjdk.org  Wed Nov 26 06:28:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 06:28:47 GMT
Subject: RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS
In-Reply-To: <6MBy-lrlxqx2CClf8qgc2TMsuc3SSOlvo9dEBNkwvIo=.274e1d00-71cd-44dc-b289-898d3ac857c2@github.com>
References: <ANfWW1Wb_p6OwP6LNKDsyNnFIfCBhxL0shAezcW2gis=.ab9ffa26-8f38-4f88-8678-dab13badb4c1@github.com>
 <xeN8f3Bbu5iqQCLSKNuoz7iX2SeFrXhx2pZfgJQqArY=.12ec2ed6-8295-4d55-bee3-3ebd871860fe@github.com>
 <6MBy-lrlxqx2CClf8qgc2TMsuc3SSOlvo9dEBNkwvIo=.274e1d00-71cd-44dc-b289-898d3ac857c2@github.com>
Message-ID: <JFqIKeqJrqEbFYRvH3NJhgFARW_OIJdTEFOyuK6wk0g=.9687fa93-4209-4cac-a82f-78a89408ddb9@github.com>

On Wed, 26 Nov 2025 06:06:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I'll run this change in our CI just to be sure that it doesn't cause any unexpected issues there.

The test continues to pass in our CI with this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3579460584

From martin at openjdk.org  Wed Nov 26 07:17:48 2025
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 26 Nov 2025 07:17:48 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v4]
In-Reply-To: <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
Message-ID: <gAst0RpLzd69k2zy1NxTnHehbP6VSgBQAYYLEe8rNdo=.c71aba8c-80cc-469a-bebf-394b26184d3d@github.com>

On Tue, 25 Nov 2025 04:26:08 GMT, Steve Armstrong <duke at openjdk.org> wrote:

>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
>> 
>> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
>> 
>> Changes:
>> - Added new FieldUpdaterUtil class with static utility methods:
>>   * validateField() - validates field type, volatile, and static checks
>>   * computeAccessClass() - determines correct class for access checks
>>   * isSamePackage() - checks if two classes are in same package
>>   * isAncestor() - checks classloader delegation chain
>> 
>> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.
>
> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix try-catch block to not wrap IllegalArgumentException
>   
>   The validation exceptions should be thrown directly to the caller,
>   not wrapped in RuntimeException. Only the field lookup and access
>   checking code should be in the try-catch block.

Java Historian recalls many years ago suffering from duplicate maintenance of "atomic mechanics" in these core classes, but never trying to "fix" it because the risk and effort were too high.  At the very least the code duplication makes optimization very easy for the JVM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3579752573

From duke at openjdk.org  Wed Nov 26 07:54:27 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 07:54:27 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v8]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <RUoSgr8VWf8eBVVlkqG491zf3C8igB4uw1aa5j0lckA=.f42c873e-4432-438e-837a-0b66b55938f2@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Revert change addressed in another bug and move bug IDs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/0b957114..d3931c40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=06-07

  Stats: 10 lines in 3 files changed: 0 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Wed Nov 26 07:54:29 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 07:54:29 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v7]
In-Reply-To: <-xgHQnApWk_Wx2Gj6H8D99SpH9PdMA0lX0gh0-qOrFQ=.5b633e04-45c2-47d1-afba-fc9d7b583864@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>
 <-xgHQnApWk_Wx2Gj6H8D99SpH9PdMA0lX0gh0-qOrFQ=.5b633e04-45c2-47d1-afba-fc9d7b583864@github.com>
Message-ID: <DWAe_mSujZI4zWZWM7KPxnFONnpxkSXLxpIZ85QomW0=.b89c1ef8-cc36-49e1-b86b-c91b24c8ea98@github.com>

On Wed, 26 Nov 2025 05:28:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move test for invalid values from TaskHelperTest to JLinkTest.
>
> test/jdk/tools/jlink/JLinkTest.java line 361:
> 
>> 359:         }
>> 360: 
>> 361:         // short command  without argument- JDK-8321139
> 
> We don't usually include JBS bug ids in code comments. For tests which are related to a bug fix, like this one, we include the bug id in the `@bug` tag of the test definition https://openjdk.org/jtreg/tag-spec.html.
> 
> This `JLinkTest`, unfortunately has a pre-existing problem that it uses `@bug` more than once (which as per the `@bug` tag specification, isn't correct). So you will have to do some extra work with this one and address that part too. Ultimately, for this test, the `@bug` should now be:
> 
> 
> @bug 8189777 8194922 8206962 8240349 8321139
> 
> While at it, please also update the `@bug` line in `TaskHelperTest` to include 8321139.

Good Morning,

For `JLinkTest `, I noticed more bug IDs among other comments so I added those to `@bug`. I added the new bug ID to `TaskHelperTest `. Please let me know if there is some other comment that I should modify/remove.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2563786452

From duke at openjdk.org  Wed Nov 26 07:59:01 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 07:59:01 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v7]
In-Reply-To: <uWmMx004rGxp7AADfveOT2AI0PsGG0XR_CDqF5RA26I=.619f81c6-ac99-4843-954f-9eb7cc4c6e63@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>
 <uWmMx004rGxp7AADfveOT2AI0PsGG0XR_CDqF5RA26I=.619f81c6-ac99-4843-954f-9eb7cc4c6e63@github.com>
Message-ID: <ZaXHG-1S8AzpcvEAcCZyxS9zL4QjcJ6hlP7eknsE7Hk=.65a80979-fbcf-42bc-af9d-17451e6bc2e4@github.com>

On Wed, 26 Nov 2025 05:20:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move test for invalid values from TaskHelperTest to JLinkTest.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 69:
> 
>> 67: main.opt.bind-services=\
>> 68: \      --bind-services                   Link in service provider modules and\n\
>> 69: \                                        their dependencies
> 
> I think we should leave this change (here and in one other place) out of this PR. There's https://bugs.openjdk.org/browse/JDK-8337422 which is tracking this and there's some discussion in that issue, which indicates that it's OK to do this change. But I think we should do it as part of JDK-8337422.

Thank you for spotting this. I reverted this change as it will be addressed by [JDK-8337422](https://bugs.openjdk.org/browse/JDK-8337422).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2563806332

From jpai at openjdk.org  Wed Nov 26 08:29:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 08:29:51 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v7]
In-Reply-To: <DWAe_mSujZI4zWZWM7KPxnFONnpxkSXLxpIZ85QomW0=.b89c1ef8-cc36-49e1-b86b-c91b24c8ea98@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <JrZfRD9BjqPtwHQ6wj0FEUk_BJ4Ow5YSZgXuKxEgp8I=.b46518f2-d5ec-4f40-bb0d-5ed2442564c5@github.com>
 <-xgHQnApWk_Wx2Gj6H8D99SpH9PdMA0lX0gh0-qOrFQ=.5b633e04-45c2-47d1-afba-fc9d7b583864@github.com>
 <DWAe_mSujZI4zWZWM7KPxnFONnpxkSXLxpIZ85QomW0=.b89c1ef8-cc36-49e1-b86b-c91b24c8ea98@github.com>
Message-ID: <GZeonASVM_GRilta85cWKuH5jePUcMQ5Xll344tJXtA=.33a42642-f3d3-4502-90d5-4c78259c5ad1@github.com>

On Wed, 26 Nov 2025 07:51:21 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> test/jdk/tools/jlink/JLinkTest.java line 361:
>> 
>>> 359:         }
>>> 360: 
>>> 361:         // short command  without argument- JDK-8321139
>> 
>> We don't usually include JBS bug ids in code comments. For tests which are related to a bug fix, like this one, we include the bug id in the `@bug` tag of the test definition https://openjdk.org/jtreg/tag-spec.html.
>> 
>> This `JLinkTest`, unfortunately has a pre-existing problem that it uses `@bug` more than once (which as per the `@bug` tag specification, isn't correct). So you will have to do some extra work with this one and address that part too. Ultimately, for this test, the `@bug` should now be:
>> 
>> 
>> @bug 8189777 8194922 8206962 8240349 8321139
>> 
>> While at it, please also update the `@bug` line in `TaskHelperTest` to include 8321139.
>
> Good Morning,
> 
> For `JLinkTest `, I noticed more bug IDs among other comments so I added those to `@bug`. I added the new bug ID to `TaskHelperTest `. Please let me know if there is some other comment that I should modify/remove.

Hello Ana, thank you for spotting that and addressing it. I verified those bug ids and the update you have here looks good to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2563930682

From jpai at openjdk.org  Wed Nov 26 08:38:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 08:38:05 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v8]
In-Reply-To: <RUoSgr8VWf8eBVVlkqG491zf3C8igB4uw1aa5j0lckA=.f42c873e-4432-438e-837a-0b66b55938f2@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <RUoSgr8VWf8eBVVlkqG491zf3C8igB4uw1aa5j0lckA=.f42c873e-4432-438e-837a-0b66b55938f2@github.com>
Message-ID: <PX5PBmlu3nGsUtzq6wsaVYhe0xFeJIDq-MWh3SGW1vE=.452bce4e-eb5a-489a-bd40-3c326212b39d@github.com>

On Wed, 26 Nov 2025 07:54:27 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change addressed in another bug and move bug IDs.

Overall this looks good to me. Just a few final things -  I spoke with Alan and we agreed that the JBS issue title would need an update. I updated that a few minutes back. Please also update this PR title to match that one.

Then the plugin.properties in this PR will need a copyright year update (2023 needs to be changed to 2025). I missed it in the previous rounds of review. 

Finally, given the change we have done in this PR, we will need a CSR for this. I've marked this PR as requiring one. If you have created a CSR previously, here are the instructions to do so https://wiki.openjdk.org/display/csr/Main. If you need help with the CSR, let us know and one of us can help.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28359#issuecomment-3580127023

From duke at openjdk.org  Wed Nov 26 08:45:43 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 08:45:43 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v9]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <VpNS5eHf9WClHUE1JLJWc7Oz2JXclbx9lSww3WyHZaQ=.c9bb8452-480f-4d2e-b160-f5feba941257@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year in plugin properties.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/d3931c40..c3db3c8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Wed Nov 26 08:54:04 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 08:54:04 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v10]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <L9tCBqzFJn2O0WVfLQ2wIuuGYI1_2FrGkzX-uMzAcQU=.1ecc5031-5b02-4350-b448-d8c5656acf80@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Revert wording in description as it would be covered by another issue.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/c3db3c8c..88177adc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From jpai at openjdk.org  Wed Nov 26 08:54:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 08:54:06 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v9]
In-Reply-To: <VpNS5eHf9WClHUE1JLJWc7Oz2JXclbx9lSww3WyHZaQ=.c9bb8452-480f-4d2e-b160-f5feba941257@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <VpNS5eHf9WClHUE1JLJWc7Oz2JXclbx9lSww3WyHZaQ=.c9bb8452-480f-4d2e-b160-f5feba941257@github.com>
Message-ID: <vXjyrKk0TF36wnM_e7cnlKUoj5YZ-ZvmbzANdkYhS84=.c7e9265e-5c69-4680-810b-599542a0a988@github.com>

On Wed, 26 Nov 2025 08:45:43 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year in plugin properties.

Marked as reviewed by jpai (Reviewer).

test/jdk/tools/jlink/TaskHelperTest.java line 258:

> 256:         } catch (IOException ex) {
> 257:             fail("Unexpected IOException");
> 258:         }

Nit - it might be better to just remove this try/catch block and let any unexpected exception propagate (you can add a throws clause to the test method signature). That way if any unexpected exception is raised, the failure report will contain the relevant stacktrace which should help debugging the failure.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28359#pullrequestreview-3509747261
PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2564023517

From duke at openjdk.org  Wed Nov 26 08:57:08 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 08:57:08 GMT
Subject: RFR: 8321139: jlink's man page does not document the --compress
 option correctly [v11]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <8bSWGKKf5b2Zdm_q9uDozCXUPZf5bi-NsWczqxQOkiU=.c504bf8e-28ea-4531-ae62-9c7b66154fca@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with three additional commits since the last revision:

 - Update to correct copyright year.
 - Revert wording in description and man as it would be covered by another issue.
 - Revert "Update copyright year in plugin properties."
   
   This reverts commit c3db3c8c370ee9ce31ef57722dfa47d7d179b80c.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/88177adc..fa86705e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=09-10

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Wed Nov 26 09:10:57 2025
From: duke at openjdk.org (duke)
Date: Wed, 26 Nov 2025 09:10:57 GMT
Subject: RFR: 8371637: allocateNativeInternal sometimes return incorrectly
 aligned memory [v8]
In-Reply-To: <YpmmQyTak50BdUkBPoZGKyRchAzGfZRhlZqxnNsoLlE=.203a8643-0d2b-44ba-8ac6-8ee567f235d2@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
 <YpmmQyTak50BdUkBPoZGKyRchAzGfZRhlZqxnNsoLlE=.203a8643-0d2b-44ba-8ac6-8ee567f235d2@github.com>
Message-ID: <cYClOdxkPKsIbkuQCQ7QZikFnc2drAVF8MCQ1DSobiY=.060f1efc-2bf5-4d0b-bbc8-fca009b40f82@github.com>

On Fri, 21 Nov 2025 12:08:40 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace error
>   
>   This work was sponsored by: The FreeBSD Foundation

@snake66 
Your change (at version bcdbbec00e8dbaf1dde4afffaa69e9d90381230a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3580302283

From adinn at openjdk.org  Wed Nov 26 09:13:50 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 26 Nov 2025 09:13:50 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64 [v2]
In-Reply-To: <Mc0Z5i4FeYfrF_F_OxZ0Jpq3M4bRq3ELK7MVYMvElZI=.b0f15c04-7cca-4d6f-a06d-4031681cb574@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
 <Mc0Z5i4FeYfrF_F_OxZ0Jpq3M4bRq3ELK7MVYMvElZI=.b0f15c04-7cca-4d6f-a06d-4031681cb574@github.com>
Message-ID: <gCDoKcNPA_JKhg168aTfUzmegz6PWH0bU08hiT1qEg8=.7ac4ee97-edd8-48ae-b76a-75f70d91c2bc@github.com>

On Tue, 25 Nov 2025 22:23:36 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

>> This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial.
>> Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN).
>> 
>> 
>> 
>> The micro-benchmark results from MathBench and StrictMathBench below show the performance improvement of Math.log:
>> 
>> 
>> **Before change**
>> <html xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=OneNote.File>
>> <meta name=Generator content="Microsoft OneNote 15">
>> </head>
>> 
>> <body lang=en-US style='font-family:Calibri;font-size:11.0pt'>
>> 
>> 
>> <div style='direction:ltr;border-width:100%'>
>> 
>> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
>> 
>> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
>> 
>> <div style='direction:ltr'>
>> 
>> Benchmark | Mode | Cnt | Score | Error | Units
>> -- | -- | -- | -- | -- | --
>> MathBench.logDouble | thrpt | 10 | **15549.705** | ?357.439 | ops/ms
>> StrictMathBench.logDouble | thrpt | 10 | 219408.158 | ?16484.680 | ops/ms
>> 
>> </div>
>> 
>> </div>
>> 
>> </div>
>> 
>> </div>
>> 
>> 
>> </body>
>> 
>> </html>
>> 
>> 
>> 
>> **After adding Math.log intrinsic**
>> 
>> <html xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=OneNote.File>
>> <meta name=Generator content="Microsoft OneNote 15">
>> </head>
>> 
>> <body lang=en-US style='font-family:Calibri;font-size:11.0pt'>
>> 
>> 
>> <div style='direction:ltr;border-width:100%'>
>> 
>> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
>> 
>> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
>> 
>> <div style='direction:ltr'>
>> 
>> Benchmark | Mode | Cnt | Score | Error | Units
>> -- | -- | -- | -- | -- | --
>> MathBench.logDouble | thrpt | 10 | **300086.773** | ?6675.936 | ops/ms
>> StrictMathBench.logDouble | thrpt | 10 | 226521.817 | ?4038.975 | ops/ms
>> 
>> 
>> </div>
>> 
>> </div>
>> 
>> </div>
>> 
>> </div>
>> 
>> 
>> </body>
>> 
>> </html>
>
> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [AArch64] Math.log is 10% slower than StrictMath.log on aarch64

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 8812:

> 8810:   address generate_dlog() {
> 8811:     __ align(CodeEntryAlignment);
> 8812:     StubCodeMark mark(this, "StubRoutines", "dlog");

This StubCodeMark needs to be declared with a StubId as argument. See other stub generators in this file or the equivalent code in `cpu/x86/stubGenerator_x86_64_log.cpp` for an example of what it should look like.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28306#discussion_r2564133696

From duke at openjdk.org  Wed Nov 26 09:39:36 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 09:39:36 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v12]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <dpbvrXEWGOzMlfpUVb1D06oAG66l9TarIc9eny_wzps=.62d4fd29-86ca-4b14-bbda-72537bc09a34@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Move exception to @Throws signature.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/fa86705e..9ef857b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=10-11

  Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Wed Nov 26 09:39:38 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 09:39:38 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v9]
In-Reply-To: <vXjyrKk0TF36wnM_e7cnlKUoj5YZ-ZvmbzANdkYhS84=.c7e9265e-5c69-4680-810b-599542a0a988@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <VpNS5eHf9WClHUE1JLJWc7Oz2JXclbx9lSww3WyHZaQ=.c9bb8452-480f-4d2e-b160-f5feba941257@github.com>
 <vXjyrKk0TF36wnM_e7cnlKUoj5YZ-ZvmbzANdkYhS84=.c7e9265e-5c69-4680-810b-599542a0a988@github.com>
Message-ID: <oa2DlCP1XoU4CbbMpqpmQTmS0EIPNAHsucykKhxQ_X4=.1abf4306-34c5-4bad-b176-0359ccf93fec@github.com>

On Wed, 26 Nov 2025 08:48:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year in plugin properties.
>
> test/jdk/tools/jlink/TaskHelperTest.java line 258:
> 
>> 256:         } catch (IOException ex) {
>> 257:             fail("Unexpected IOException");
>> 258:         }
> 
> Nit - it might be better to just remove this try/catch block and let any unexpected exception propagate (you can add a throws clause to the test method signature). That way if any unexpected exception is raised, the failure report will contain the relevant stacktrace which should help debugging the failure.

I followed your advice and moved the exception in the `@throws` clause.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2564239787

From vklang at openjdk.org  Wed Nov 26 09:57:50 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 26 Nov 2025 09:57:50 GMT
Subject: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though
 queue is not empty [v2]
In-Reply-To: <y2rs-E2nke7uQXeRUJedqb8K9hgWfCIPH4tcyT6-wKE=.73f1160a-57b7-481d-9efa-f05ca2ffd870@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
 <XZ9xKGD5lyfMivOP6r-bAsDdNMk7SWLFyZ1hbgHgWcA=.fe874dfa-730e-463f-927a-95476da94476@github.com>
 <y2rs-E2nke7uQXeRUJedqb8K9hgWfCIPH4tcyT6-wKE=.73f1160a-57b7-481d-9efa-f05ca2ffd870@github.com>
Message-ID: <sSIeWAFZyjZ3ux2XdaUc1Nzu4Ugzk-NnrYvIws45y1Q=.36c530ce-6bb3-4ca6-a146-28b9a77327c6@github.com>

On Tue, 25 Nov 2025 17:55:41 GMT, kabutz <duke at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes after code review
>
> Maybe /contributor Dr Heinz M. Kabutz <heinz at javaspecialists.eu> ? I'm surprised that @kabutz did not work, since I have contributed before.

@kabutz Adding that worked.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28479#issuecomment-3580521422

From duke at openjdk.org  Wed Nov 26 10:20:25 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 10:20:25 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v13]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <PkwHWkNOtjGGi1eiL3RJ5MB5sHHSOmNlGwpPu8ydWX8=.93f2b02a-dd6c-4b16-9fb3-744990a9bcab@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Put back plugin configuration.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/9ef857b8..7fc0ffe0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=11-12

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Wed Nov 26 10:27:17 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 10:27:17 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v14]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <w5aBsR1c4KWAc5dvp_HX9kLHg0yMg9ZNidEJ8QulkuA=.992b2dd8-8be8-48ea-b16a-6d1ced558322@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespaces issue.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/7fc0ffe0..05b2d79e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From jbhateja at openjdk.org  Wed Nov 26 11:34:11 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 26 Nov 2025 11:34:11 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Cleanups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/aca6cc5d..756a0d0c

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=03-04

  Stats: 26 lines in 9 files changed: 5 ins; 7 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From pminborg at openjdk.org  Wed Nov 26 15:14:40 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Nov 2025 15:14:40 GMT
Subject: Integrated: 8371571: Consolidate and enhance bulk memory segment ops
 benchmarks
In-Reply-To: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
References: <2huQasTCb8RzCkBANMYsUm9Sy_CfSJElfUEajUGzgUU=.8eb916f6-d91c-463e-96f0-be74862b2059@github.com>
Message-ID: <LNUyd10oy369Wa3LbkETv-aXGS4vTplQvR-ZXuMwPCA=.1456b39a-ead1-4247-9b0b-3a0ecf31635f@github.com>

On Wed, 12 Nov 2025 09:08:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to consolidate and standardize the benchmarks related to the bulk operations for memory segments. 
> 
> All the benchmarks will now run with (heap|native)x(aligned|unaligned)x(intint|intlong|longlong) combinations.
> 
> It should be noted that with this change, the running time for the benchmarks would increase significantly.

This pull request has now been integrated.

Changeset: 1ce2a44e
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ce2a44e9f4fa9d558602dbd0489fefb0c9563ef
Stats:     701 lines in 5 files changed: 281 ins; 306 del; 114 mod

8371571: Consolidate and enhance bulk memory segment ops benchmarks

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/28260

From alanb at openjdk.org  Wed Nov 26 15:22:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Nov 2025 15:22:14 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v3]
In-Reply-To: <wXVhp99QB7kchpzHfphICqaOBiUFXHgnv1cCWBgfORA=.072b0edb-0e56-4d6f-a097-ab1396ba4c3f@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
 <jJad_byg_l20nlbAZjHDUCadnTNL6FdNmGCTESHyRE0=.d1e86a93-6478-466c-83bf-595d304d7bb8@github.com>
 <WH3ecv0QGys2-QpqltzMyz2jQGi2ZBXOo23JX9PG3GU=.77c2d810-e693-4ec2-888f-41c82094120f@github.com>
 <JSWnv-432jILEA8x1UmCkDXbS40hgNj0MggIBH_Hr6I=.ba870ff9-a6f7-41c4-ba70-615bc7421943@github.com>
 <qX7HHo1DwZMr_k6WQGzHwH-ARtJPDR5Ag08fuhPsmjE=.3003bbd1-f5af-423d-b089-0311a3e7f21e@github.com>
 <D3aZt0yz_FYuIygHxf6-HbiomMHwvGn-nd-xW64_aNk=.b82f2796-bfa3-4b3c-b750-e257770dec04@github.com>
 <wXVhp99QB7kchpzHfphICqaOBiUFXHgnv1cCWBgfORA=.072b0edb-0e56-4d6f-a097-ab1396ba4c3f@github.com>
Message-ID: <dsoKsP2DX_0JkirezlVwJ1vk-U1rVx3AkIYv-6kLv9Q=.cc34d9f4-2bf2-4eff-961b-8b7728cadf25@github.com>

On Fri, 21 Nov 2025 18:57:01 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> `{  }` is use in some man pages pick one from the items from inside the braces.  Maybe `zip-{0..9}` would work here as the `jlink` man page already uses `[ ]` for optional items.
>
> The message showed when running `jlink --help` option mentions `zip-[0-9]`. In my current approach, I kept that implementation aligned with what help would show when running the `jlink --help` command (same approach regarding `jlink --list-plugins` output). 
> 
> 
> jlink --help
> 
> Possible options include:
>       --add-modules <mod>[,<mod>...]    Root modules to resolve in addition to the
>                                         initial modules. <mod> can also be ALL-MODULE-PATH.
>       --bind-services                   Link in service provider modules and
>                                         their dependencies
>       --compress <compress>             Compression to use in compressing resources:
>                                         Accepted values are:
>                                         zip-[0-9], where zip-0 provides no compression,
>                                         and zip-9 provides the best compression.
>                                         Default is zip-6.
>                                         Deprecated values to be removed in a future release:
>                                         0:  No compression. Use zip-0 instead.
>                                         1:  Constant String Sharing
>                                         2:  ZIP. Use zip-6 instead.
> 
> 
> I did not intervene over the output of `jlink -- list-plugins`.
> 
> 
> jlink --list-plugins
> 
> List of available plugins:
>   --add-options <options>   Prepend the specified <options> string, which may
>                             include whitespace before any other options when
>                             invoking the virtual machine in the resulting image.
>   --compress <compress>     Compression to use in compressing resources:
>                             Accepted values are:
>                             zip-[0-9], where zip-0 provides no compression,
>                             and zip-9 provides the best compression.
>                             Default is zip-6.
> 
> Given the situations mentioned above, what do you believe to be the best way forward? ?

`[ ]` usually means optional so I think it would be better to just change it from `{0|1|2}` to `zip-{0-9}`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2565415295

From duke at openjdk.org  Wed Nov 26 15:23:44 2025
From: duke at openjdk.org (Trevor Bond)
Date: Wed, 26 Nov 2025 15:23:44 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries [v3]
In-Reply-To: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
Message-ID: <zYHob5oko2DmRqgwy269f2GfIupsBI0LmKF-yQADnCw=.ed8bc799-5353-4f4a-a7f5-ab22cedcc073@github.com>

> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
> 
> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
> 
> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
> 
> | Version | Avg Time (ns/op) | ? vs Before |
> |--------|------------------:|-------------|
> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |

Trevor Bond has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28458/files
  - new: https://git.openjdk.org/jdk/pull/28458/files/a990cd30..bbdf8bd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28458&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28458&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28458/head:pull/28458

PR: https://git.openjdk.org/jdk/pull/28458

From duke at openjdk.org  Wed Nov 26 15:23:46 2025
From: duke at openjdk.org (Trevor Bond)
Date: Wed, 26 Nov 2025 15:23:46 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries [v2]
In-Reply-To: <gHRCmRTkG336B8Ao4tEvHN-O5bbzjUrS0s8C3jmBZFM=.a43b9abe-9921-4b67-9daa-7cbfade720ea@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
 <gHRCmRTkG336B8Ao4tEvHN-O5bbzjUrS0s8C3jmBZFM=.a43b9abe-9921-4b67-9daa-7cbfade720ea@github.com>
Message-ID: <v3l49JsqYBjvYL3EGy4sr3zwxQvbVxdLweD9X8CZaGA=.28b116ed-a92f-44d8-be6b-320627c7236f@github.com>

On Tue, 25 Nov 2025 23:03:11 GMT, Trevor Bond <duke at openjdk.org> wrote:

>> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
>> 
>> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
>> 
>> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
>> 
>> | Version | Avg Time (ns/op) | ? vs Before |
>> |--------|------------------:|-------------|
>> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
>> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |
>
> Trevor Bond has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary imports

Thanks Jaikiran, that has been updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28458#issuecomment-3581810708

From dl at openjdk.org  Wed Nov 26 15:35:13 2025
From: dl at openjdk.org (Doug Lea)
Date: Wed, 26 Nov 2025 15:35:13 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v22]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <-kNPwoBvq5APFT98rnravszAH2whbEnsxzLLgQWhMd8=.751f5a71-b68a-45ae-9535-ebade756b685@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  For testing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/1de99906..0db798b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=20-21

  Stats: 74 lines in 1 file changed: 11 ins; 28 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From jpai at openjdk.org  Wed Nov 26 15:35:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Nov 2025 15:35:50 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries [v3]
In-Reply-To: <zYHob5oko2DmRqgwy269f2GfIupsBI0LmKF-yQADnCw=.ed8bc799-5353-4f4a-a7f5-ab22cedcc073@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
 <zYHob5oko2DmRqgwy269f2GfIupsBI0LmKF-yQADnCw=.ed8bc799-5353-4f4a-a7f5-ab22cedcc073@github.com>
Message-ID: <T5xXD_YopWuFJn793zUcF_uEgUKeFe7JGymUneGHJoU=.10793b61-13a4-4288-9dff-69e2ce329f8b@github.com>

On Wed, 26 Nov 2025 15:23:44 GMT, Trevor Bond <duke at openjdk.org> wrote:

>> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
>> 
>> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
>> 
>> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
>> 
>> | Version | Avg Time (ns/op) | ? vs Before |
>> |--------|------------------:|-------------|
>> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
>> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |
>
> Trevor Bond has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

Thank you for the update, looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28458#pullrequestreview-3511541277

From haraldei at openjdk.org  Wed Nov 26 15:37:08 2025
From: haraldei at openjdk.org (Harald Eilertsen)
Date: Wed, 26 Nov 2025 15:37:08 GMT
Subject: Integrated: 8371637: allocateNativeInternal sometimes return
 incorrectly aligned memory
In-Reply-To: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
References: <Trs5ukUMJvVb6ikJulsCS6unPy9QzRIB_6R1Nz9bQA8=.00519c4e-4b25-4e06-9b20-7e188cd359dd@github.com>
Message-ID: <63_Ou89hr5XpbbKBj5PnOLIj3raXSfRq2910UPhEpPE=.203b0b7e-2172-422b-af9f-7008f05d1c1d@github.com>

On Tue, 11 Nov 2025 14:11:28 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
> 
> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
> 
> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
> 
> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
> 
> This work was sponsored by: The FreeBSD Foundation

This pull request has now been integrated.

Changeset: 10ba0ab3
Author:    Harald Eilertsen <haraldei at openjdk.org>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10ba0ab3c0017858bafb65b49a4cadd9a0351fb4
Stats:     10 lines in 2 files changed: 8 ins; 0 del; 2 mod

8371637: allocateNativeInternal sometimes return incorrectly aligned memory

Co-authored-by: Kurt Miller <kurt at openjdk.org>
Reviewed-by: mcimadamore, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/28235

From liach at openjdk.org  Wed Nov 26 15:46:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Nov 2025 15:46:45 GMT
Subject: RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all
 Utf8 CP entries [v3]
In-Reply-To: <zYHob5oko2DmRqgwy269f2GfIupsBI0LmKF-yQADnCw=.ed8bc799-5353-4f4a-a7f5-ab22cedcc073@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
 <zYHob5oko2DmRqgwy269f2GfIupsBI0LmKF-yQADnCw=.ed8bc799-5353-4f4a-a7f5-ab22cedcc073@github.com>
Message-ID: <zZOvnHC9AxTNUy1yCqeHKIOO7sNCsvtItTTCBPA1KXM=.4dd9a86c-3105-4ac4-b401-9ff6874874d4@github.com>

On Wed, 26 Nov 2025 15:23:44 GMT, Trevor Bond <duke at openjdk.org> wrote:

>> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
>> 
>> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
>> 
>> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
>> 
>> | Version | Avg Time (ns/op) | ? vs Before |
>> |--------|------------------:|-------------|
>> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
>> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |
>
> Trevor Bond has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28458#pullrequestreview-3511581066

From duke at openjdk.org  Wed Nov 26 15:46:46 2025
From: duke at openjdk.org (Trevor Bond)
Date: Wed, 26 Nov 2025 15:46:46 GMT
Subject: Integrated: 8350938: ResourceParsingClassHierarchyResolver inflates
 all Utf8 CP entries
In-Reply-To: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
References: <KTbNy7vkRToKzPAh6id0MoZWI3yRdzR58nSl9kmadXU=.18880bb0-a666-41b3-a194-31fd46e29def@github.com>
Message-ID: <kG3l0q4Qoda2zJ0_rYJa89wBc7yI7-lX6mVBGObPHLU=.9071e5a7-7b98-475a-b4db-887ed55bc9af@github.com>

On Fri, 21 Nov 2025 16:54:48 GMT, Trevor Bond <duke at openjdk.org> wrote:

> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
> 
> I?ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
> 
> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
> 
> | Version | Avg Time (ns/op) | ? vs Before |
> |--------|------------------:|-------------|
> | **Before** | 1,483,671.539 ? 3,477.744 | ? |
> | **After** | 1,380,064.517 ? 3,482.434 | ? 7.0% faster |

This pull request has now been integrated.

Changeset: c028369d
Author:    Trevor Bond <trevorkbond at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c028369dcb0a677541b89117b0800125bc7c6c33
Stats:     30 lines in 1 file changed: 1 ins; 22 del; 7 mod

8350938: ResourceParsingClassHierarchyResolver inflates all Utf8 CP entries

Reviewed-by: liach, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/28458

From alanb at openjdk.org  Wed Nov 26 16:20:26 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Nov 2025 16:20:26 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v4]
In-Reply-To: <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
Message-ID: <p4hfrQ2yfCQdQeXUg8RfixyXaaUicUfl_p9DSbwkb64=.3eb97cda-6c7f-47d8-af4b-c5dd2fdf2d78@github.com>

On Tue, 25 Nov 2025 04:26:08 GMT, Steve Armstrong <duke at openjdk.org> wrote:

>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
>> 
>> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
>> 
>> Changes:
>> - Added new FieldUpdaterUtil class with static utility methods:
>>   * validateField() - validates field type, volatile, and static checks
>>   * computeAccessClass() - determines correct class for access checks
>>   * isSamePackage() - checks if two classes are in same package
>>   * isAncestor() - checks classloader delegation chain
>> 
>> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.
>
> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix try-catch block to not wrap IllegalArgumentException
>   
>   The validation exceptions should be thrown directly to the caller,
>   not wrapped in RuntimeException. Only the field lookup and access
>   checking code should be in the try-catch block.

I wouldn't expect to see usages of AtomicXxxFieldUpdater in new code. Maybe we should include some examples in the class descriptions to create awareness of VarHandles. It may indeed be time to look at deprecating them too.

As regards this PR then it should be very rare to need to touch these classes. Looking at the history, they have rarely need to be touched since they were introduced in JDK 5.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3582102370

From forax at openjdk.org  Wed Nov 26 16:31:56 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 26 Nov 2025 16:31:56 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v4]
In-Reply-To: <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
Message-ID: <uDfNaDCAo06pbIjnCyGYM5aQuqzOwQS2SpqThcDkB6w=.84a018b8-3fbe-4a82-99c9-c3a74220ab43@github.com>

On Tue, 25 Nov 2025 04:26:08 GMT, Steve Armstrong <duke at openjdk.org> wrote:

>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
>> 
>> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
>> 
>> Changes:
>> - Added new FieldUpdaterUtil class with static utility methods:
>>   * validateField() - validates field type, volatile, and static checks
>>   * computeAccessClass() - determines correct class for access checks
>>   * isSamePackage() - checks if two classes are in same package
>>   * isAncestor() - checks classloader delegation chain
>> 
>> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.
>
> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix try-catch block to not wrap IllegalArgumentException
>   
>   The validation exceptions should be thrown directly to the caller,
>   not wrapped in RuntimeException. Only the field lookup and access
>   checking code should be in the try-catch block.

+1 for deprecating all AtomicXxxFieldUpdater

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3582145278

From alanb at openjdk.org  Wed Nov 26 16:38:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Nov 2025 16:38:16 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v2]
In-Reply-To: <7bqpLaU9FCBPSG77Fkd31oSnj_vI2eubh-PW1c4rXRU=.60b0cb3e-8d01-4781-bebb-96df89906da2@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <7bqpLaU9FCBPSG77Fkd31oSnj_vI2eubh-PW1c4rXRU=.60b0cb3e-8d01-4781-bebb-96df89906da2@github.com>
Message-ID: <lsKlnnhSftoDOh51Xz-nJZl5kgDgb01yx-zzQd8wyzI=.f6f0de78-15ea-4692-97b8-ec9ec8094c40@github.com>

On Tue, 25 Nov 2025 18:23:39 GMT, James Yuzawa <duke at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>   
>   Fix javadoc

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 507:

> 505:      *           {@link java.util.Random#nextGaussian()} and instead uses the
> 506:      *           ziggurat-based algorithm from the default implementation of
> 507:      *           {@link java.util.random.RandomGenerator#nextGaussian()}.

The implNotes in this class start with "This method is implemented ...".  How about: "This implementation invokes the default implementation of RandomGenerator.nextGaussian and so uses McFarland's fast modified ziggurat algorithm rather than the polar method described in the super class."

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 513:

> 511:      * {@inheritDoc}
> 512:      * @throws IllegalArgumentException {@inheritDoc}
> 513:      * @implNote {@inheritDoc}

Good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2565688699
PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2565689572

From almatvee at openjdk.org  Wed Nov 26 16:38:09 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Nov 2025 16:38:09 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v3]
In-Reply-To: <7NA5vswoBH0kf2wZhu-BFGQwEOWIJ95oxO2aGgbRKPI=.64a64ed9-b76a-4f33-bb30-84ed53e2babf@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <r9qSnSv8BsJ8hpTHYKzxBX6qO1kqr_WpnGOQ8hqyKsQ=.9ef49375-f04e-42b5-979a-9daa6e7ce6bb@github.com>
 <aB5nyD3Qy3d5vuc7YxLkRPNtgXm9ACM-2gkyXNn82GA=.7be5e28d-9615-4b30-9016-172feb5a96e4@github.com>
 <88pEB1vkN1ZCbam177TMAkK-hlM-DKGb29Yc8yWpPks=.7713d1c7-9c30-4661-94c8-7d4d743ee97c@github.com>
 <0sPVMA3Yh0t5KpeHV3wHPs11DEoHEQI-W5yGIDuVa_A=.975e91f7-3280-4840-98ac-97fa8c008f01@github.com>
 <7NA5vswoBH0kf2wZhu-BFGQwEOWIJ95oxO2aGgbRKPI=.64a64ed9-b76a-4f33-bb30-84ed53e2babf@github.com>
Message-ID: <HJuK7pkCycYiEvGLsJC6gfq11lCJ54gxrjpI7BDbwJM=.c90d7d79-13cc-40c7-b875-bb6f92db07e4@github.com>

On Wed, 26 Nov 2025 16:32:46 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Looks like in the case of predefined app image packaging, when "--mac-app-store" is used with the predefined app image but not used in the terminal packaging command, jpackage still adds service files to the package. Looks like a bug.
>> 
>> We added "mac-app-store" property to the app image file in [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850). Do we still need it? Why do we want to know that the predefined app image was created with "--mac-app-store" option? In app image bundling, this option affects signing identities only, right?
>
> It is a bug in verification code. Test thinks that we should have 2 top installation directory, but we got 1. This is expected since predefined app image was generated with "--mac-app-store".

Yes, we still need it. Yes it affects signing. It is used so we can sign predefined app image correctly for Mac App Store if it was generated with "--mac-app-store".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2565689848

From almatvee at openjdk.org  Wed Nov 26 16:38:08 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Nov 2025 16:38:08 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v3]
In-Reply-To: <0sPVMA3Yh0t5KpeHV3wHPs11DEoHEQI-W5yGIDuVa_A=.975e91f7-3280-4840-98ac-97fa8c008f01@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <r9qSnSv8BsJ8hpTHYKzxBX6qO1kqr_WpnGOQ8hqyKsQ=.9ef49375-f04e-42b5-979a-9daa6e7ce6bb@github.com>
 <aB5nyD3Qy3d5vuc7YxLkRPNtgXm9ACM-2gkyXNn82GA=.7be5e28d-9615-4b30-9016-172feb5a96e4@github.com>
 <88pEB1vkN1ZCbam177TMAkK-hlM-DKGb29Yc8yWpPks=.7713d1c7-9c30-4661-94c8-7d4d743ee97c@github.com>
 <0sPVMA3Yh0t5KpeHV3wHPs11DEoHEQI-W5yGIDuVa_A=.975e91f7-3280-4840-98ac-97fa8c008f01@github.com>
Message-ID: <7NA5vswoBH0kf2wZhu-BFGQwEOWIJ95oxO2aGgbRKPI=.64a64ed9-b76a-4f33-bb30-84ed53e2babf@github.com>

On Wed, 26 Nov 2025 05:02:05 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Maybe. I am getting following error without it:
>> 
>> java.lang.AssertionError: Expected [2]. Actual [1]: Check the package has 2 top installation directories
>> 	at jdk.jpackage.test.TKit.error(TKit.java:369)
>> 	at jdk.jpackage.test.TKit.assertEquals(TKit.java:720)
>> 	at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:858)
>> 
>> I need to investigate it.
>
> Looks like in the case of predefined app image packaging, when "--mac-app-store" is used with the predefined app image but not used in the terminal packaging command, jpackage still adds service files to the package. Looks like a bug.
> 
> We added "mac-app-store" property to the app image file in [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850). Do we still need it? Why do we want to know that the predefined app image was created with "--mac-app-store" option? In app image bundling, this option affects signing identities only, right?

It is a bug in verification code. Test thinks that we should have 2 top installation directory, but we got 1. This is expected since predefined app image was generated with "--mac-app-store".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28487#discussion_r2565681263

From duke at openjdk.org  Wed Nov 26 16:42:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 26 Nov 2025 16:42:56 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v2]
In-Reply-To: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
Message-ID: <a_d2b1m39PpvKb1YbzuBSpaRvkkYpTRRDdCk3v4YWc0=.dc276a60-4f27-4d8f-b585-44a9d769a2a7@github.com>

> Adds a semantic reason for failure which can be optionally interrogated by calling code.
> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask.
> 
> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers.
> 
> We can use this approach to provide translated messages for all the distinct failure reasons if needed.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Reset to not use I18N error message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28456/files
  - new: https://git.openjdk.org/jdk/pull/28456/files/aa40f0c7..e1d411f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28456&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28456&range=00-01

  Stats: 54 lines in 3 files changed: 2 ins; 38 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/28456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28456/head:pull/28456

PR: https://git.openjdk.org/jdk/pull/28456

From duke at openjdk.org  Wed Nov 26 16:46:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 26 Nov 2025 16:46:41 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v3]
In-Reply-To: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
Message-ID: <fYuU0TjlSBvGnNpEerb_eXsowS5JBJIP6N6y4tMdjgM=.0bda4edd-f619-4ecb-a69d-7732249954de@github.com>

> Adds a semantic reason for failure which can be optionally interrogated by calling code.
> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask.
> 
> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers.
> 
> We can use this approach to provide translated messages for all the distinct failure reasons if needed.

David Beaumont has updated the pull request incrementally with two additional commits since the last revision:

 - Redo bad indentation
 - undo blank line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28456/files
  - new: https://git.openjdk.org/jdk/pull/28456/files/e1d411f9..32db09a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28456&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28456&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28456/head:pull/28456

PR: https://git.openjdk.org/jdk/pull/28456

From duke at openjdk.org  Wed Nov 26 16:53:58 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 26 Nov 2025 16:53:58 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v3]
In-Reply-To: <fYuU0TjlSBvGnNpEerb_eXsowS5JBJIP6N6y4tMdjgM=.0bda4edd-f619-4ecb-a69d-7732249954de@github.com>
References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
 <fYuU0TjlSBvGnNpEerb_eXsowS5JBJIP6N6y4tMdjgM=.0bda4edd-f619-4ecb-a69d-7732249954de@github.com>
Message-ID: <Cm5oP-9z5VB5ug5KQh-1OhM3fHU2lMxYeWfyDaBItu4=.280111f4-7a99-459e-a866-1b6a5445b361@github.com>

On Wed, 26 Nov 2025 16:46:41 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds a semantic reason for failure which can be optionally interrogated by calling code.
>> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask.
>> 
>> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers.
>> 
>> We can use this approach to provide translated messages for all the distinct failure reasons if needed.
>
> David Beaumont has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Redo bad indentation
>  - undo blank line

As discussed, the error message is now not internationalized.


Error: Unable to open ../../../valhalla/thor/build/linux-x64-debug/images/jdk/lib/modules: The image file "../../../valhalla/thor/build/linux-x64-debug/images/jdk/lib/modules" is not the correct version.
Use '<JAVA_HOME>/bin/jimage' for the JDK associated with this jimage file.


The first line is as-it-was, but the duplication of the jimage path feels unnecessary, and is likely to make that line longer than any reasonable terminal window.
But of course other places where the IOException occurs don't have the first copy of it, so it's not 100% clear if it's worth thinking about changing it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3582228438

From alanb at openjdk.org  Wed Nov 26 17:03:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Nov 2025 17:03:02 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID
In-Reply-To: <zfVpWlGX55KfEgCt_lRTYxrNPPK2-ai-gHkQqDa9K5k=.c18dad75-cef8-4e6b-8ca9-ff271b561d31@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
 <zfVpWlGX55KfEgCt_lRTYxrNPPK2-ai-gHkQqDa9K5k=.c18dad75-cef8-4e6b-8ca9-ff271b561d31@github.com>
Message-ID: <Xbsw00zHIU91P9-19v8_-wbL8gg8LrGOormSZ1fNyWc=.13c1cf02-c17e-4f42-b1ae-9a7bbbc84ae3@github.com>

On Thu, 20 Nov 2025 17:02:14 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015.
>
> PR description edited to include correct Bug ID

> @kieran-farrell Nudge, see the suggestion above.

Yes, let's try to get this done before the fork so it goes with the  main update to the UUID class description.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28435#issuecomment-3582290721

From duke at openjdk.org  Wed Nov 26 18:40:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 26 Nov 2025 18:40:53 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v4]
In-Reply-To: <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
Message-ID: <4naQvrD3HNTeM-ErtASW8vm-qdIDlBo4VN5NHWy5A-c=.17f779b0-44a8-4413-a184-158112c65360@github.com>

On Tue, 25 Nov 2025 04:26:08 GMT, Steve Armstrong <duke at openjdk.org> wrote:

>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
>> 
>> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
>> 
>> Changes:
>> - Added new FieldUpdaterUtil class with static utility methods:
>>   * validateField() - validates field type, volatile, and static checks
>>   * computeAccessClass() - determines correct class for access checks
>>   * isSamePackage() - checks if two classes are in same package
>>   * isAncestor() - checks classloader delegation chain
>> 
>> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.
>
> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix try-catch block to not wrap IllegalArgumentException
>   
>   The validation exceptions should be thrown directly to the caller,
>   not wrapped in RuntimeException. Only the field lookup and access
>   checking code should be in the try-catch block.

After?this, `sun.reflect.misc.ReflectUtil` can?be?removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3582729877

From jlu at openjdk.org  Wed Nov 26 18:40:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Nov 2025 18:40:58 GMT
Subject: RFR: 8372609: Bug4944439 does not enforce locale correctly
Message-ID: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>

This PR fixes a test bug where a `DecimalFormat` is instantiated in a static field (with the current default locale) before the test updates the system default to `Locale.US`. As a result, it may fail under various other locales, since a `Locale.US` configured `DecimalFormat` is not actually retrieved and the test expects one.

In general, the preservation and restoring of the system locale is an obsolete process. The test is instead updated to just retrieve a `DecimalFormat` using a locale accepting factory method.

I have manually confirmed that the tests passes with `-Duser.language=en -Duser.country=NL` on my machine, (which is the locale used in the reproducer).

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/28514/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28514&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372609
  Stats: 21 lines in 1 file changed: 0 ins; 17 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28514/head:pull/28514

PR: https://git.openjdk.org/jdk/pull/28514

From liach at openjdk.org  Wed Nov 26 18:44:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Nov 2025 18:44:53 GMT
Subject: RFR: 8372609: Bug4944439 does not enforce locale correctly
In-Reply-To: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>
References: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>
Message-ID: <-s62C3uRO9LEkSPJAuFU6TFWjS1QPET7MYOajC2sVvs=.23b92f93-7012-4f76-ae06-5e6d8373ba23@github.com>

On Wed, 26 Nov 2025 18:35:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes a test bug where a `DecimalFormat` is instantiated in a static field (with the current default locale) before the test updates the system default to `Locale.US`. As a result, it may fail under various other locales, since a `Locale.US` configured `DecimalFormat` is not actually retrieved and the test expects one.
> 
> In general, the preservation and restoring of the system locale is an obsolete process. The test is instead updated to just retrieve a `DecimalFormat` using a locale accepting factory method.
> 
> I have manually confirmed that the tests passes with `-Duser.language=en -Duser.country=NL` on my machine, (which is the locale used in the reproducer).

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28514#pullrequestreview-3512304444

From duke at openjdk.org  Wed Nov 26 18:58:29 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 18:58:29 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v15]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <N4DFKRsTO1nzyzpgKS-TCe8uHpHeKuaNe3UYdjZOeB8=.d77f24dc-468d-4d10-bf9a-8b5d38a6cacd@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Refactor the regular expression in documentation, help and plugin details.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/05b2d79e..1cf38582

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=13-14

  Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Wed Nov 26 19:50:09 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 19:50:09 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v16]
In-Reply-To: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
Message-ID: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com>

> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
> 
> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
> 
> Some implementation details and choices:
> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Escape regex in properties.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28359/files
  - new: https://git.openjdk.org/jdk/pull/28359/files/1cf38582..41c291b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=14-15

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359

PR: https://git.openjdk.org/jdk/pull/28359

From duke at openjdk.org  Wed Nov 26 19:53:57 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 26 Nov 2025 19:53:57 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v3]
In-Reply-To: <dsoKsP2DX_0JkirezlVwJ1vk-U1rVx3AkIYv-6kLv9Q=.cc34d9f4-2bf2-4eff-961b-8b7728cadf25@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <V1qUpYjvz9vqI8iST2cgP2t1ni8KPh-ip3SEiSIHIGw=.a3c76a36-bc85-4ade-9e13-601bc3a79e53@github.com>
 <jJad_byg_l20nlbAZjHDUCadnTNL6FdNmGCTESHyRE0=.d1e86a93-6478-466c-83bf-595d304d7bb8@github.com>
 <WH3ecv0QGys2-QpqltzMyz2jQGi2ZBXOo23JX9PG3GU=.77c2d810-e693-4ec2-888f-41c82094120f@github.com>
 <JSWnv-432jILEA8x1UmCkDXbS40hgNj0MggIBH_Hr6I=.ba870ff9-a6f7-41c4-ba70-615bc7421943@github.com>
 <qX7HHo1DwZMr_k6WQGzHwH-ARtJPDR5Ag08fuhPsmjE=.3003bbd1-f5af-423d-b089-0311a3e7f21e@github.com>
 <D3aZt0yz_FYuIygHxf6-HbiomMHwvGn-nd-xW64_aNk=.b82f2796-bfa3-4b3c-b750-e257770dec04@github.com>
 <wXVhp99QB7kchpzHfphICqaOBiUFXHgnv1cCWBgfORA=.072b0edb-0e56-4d6f-a097-ab1396ba4c3f@github.com>
 <dsoKsP2DX_0JkirezlVwJ1vk-U1rVx3AkIYv-6kLv9Q=.cc34d9f4-2bf2-4eff-961b-8b7728cadf25@github.com>
Message-ID: <HYSss9YAFSDV0lH2hUEjgVsxdzlEStqJjsTCzPrn5Cc=.14db4e49-54b1-4a92-b3c5-8f8194162d9d@github.com>

On Wed, 26 Nov 2025 15:19:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The message showed when running `jlink --help` option mentions `zip-[0-9]`. In my current approach, I kept that implementation aligned with what help would show when running the `jlink --help` command (same approach regarding `jlink --list-plugins` output). 
>> 
>> 
>> jlink --help
>> 
>> Possible options include:
>>       --add-modules <mod>[,<mod>...]    Root modules to resolve in addition to the
>>                                         initial modules. <mod> can also be ALL-MODULE-PATH.
>>       --bind-services                   Link in service provider modules and
>>                                         their dependencies
>>       --compress <compress>             Compression to use in compressing resources:
>>                                         Accepted values are:
>>                                         zip-[0-9], where zip-0 provides no compression,
>>                                         and zip-9 provides the best compression.
>>                                         Default is zip-6.
>>                                         Deprecated values to be removed in a future release:
>>                                         0:  No compression. Use zip-0 instead.
>>                                         1:  Constant String Sharing
>>                                         2:  ZIP. Use zip-6 instead.
>> 
>> 
>> I did not intervene over the output of `jlink --list-plugins`.
>> 
>> 
>> jlink --list-plugins
>> 
>> List of available plugins:
>>   --add-options <options>   Prepend the specified <options> string, which may
>>                             include whitespace before any other options when
>>                             invoking the virtual machine in the resulting image.
>>   --compress <compress>     Compression to use in compressing resources:
>>                             Accepted values are:
>>                             zip-[0-9], where zip-0 provides no compression,
>>                             and zip-9 provides the best compression.
>>                             Default is zip-6.
>> 
>> Given the situations mentioned above, what do you believe to be the best way forward? ?
>
> `[ ]` usually means optional so I think it would be better to just change it from `{0|1|2}` to `zip-{0-9}`.

Thank you, Alan. I updated the PR and CSR according to your latest feedback.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2566324169

From duke at openjdk.org  Wed Nov 26 20:14:07 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 26 Nov 2025 20:14:07 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
Message-ID: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>

This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526.

It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation.

-------------

Commit messages:
 - Reduce the amount of conditions
 - Reuse StringLatin1::equals in regionMatches

Changes: https://git.openjdk.org/jdk/pull/16933/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16933&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321283
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16933.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16933/head:pull/16933

PR: https://git.openjdk.org/jdk/pull/16933

From duke at openjdk.org  Wed Nov 26 20:14:08 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 26 Nov 2025 20:14:08 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
Message-ID: <q_q6gfPW1c9663D4GQKm4zKntVd6oLB-L9bbKsNnp60=.148de24b-8bf9-4324-81df-5525d1bb0f81@github.com>

On Sat, 2 Dec 2023 16:56:22 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526.
> 
> It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation.

@schlosna 

Running `TEST="micro:java.lang.StringComparisons.regionMatches"` on AMD 7950x at 4.5 GHz with tuned network-latency profile on and turbo-boost disabled using `numactl --localalloc -N 0` to avoid weird NUMA-like effects on heap objects.

baseline at 25f9af99be1c906fc85b8192df8fa50cced3474f:

Benchmark                             (size)  (utf16)  Mode  Cnt    Score   Error  Units
StringComparisons.regionMatches            6     true  avgt    5    4.380 ? 0.030  ns/op
StringComparisons.regionMatches            6    false  avgt    5    5.772 ? 0.056  ns/op
StringComparisons.regionMatches           15     true  avgt    5    4.005 ? 0.104  ns/op
StringComparisons.regionMatches           15    false  avgt    5    4.030 ? 0.055  ns/op
StringComparisons.regionMatches         1024     true  avgt    5   30.037 ? 0.089  ns/op
StringComparisons.regionMatches         1024    false  avgt    5   17.734 ? 0.092  ns/op
StringComparisons.regionMatchesRange       6     true  avgt    5    4.825 ? 0.067  ns/op
StringComparisons.regionMatchesRange       6    false  avgt    5    5.878 ? 0.056  ns/op
StringComparisons.regionMatchesRange      15     true  avgt    5    5.736 ? 0.069  ns/op
StringComparisons.regionMatchesRange      15    false  avgt    5    5.447 ? 0.028  ns/op
StringComparisons.regionMatchesRange    1024     true  avgt    5   31.169 ? 0.009  ns/op
StringComparisons.regionMatchesRange    1024    false  avgt    5   16.614 ? 0.168  ns/op

With 1bd619a5bd2faa8057cb85105b2c9b4997fbf2ac :

Benchmark                             (size)  (utf16)  Mode  Cnt    Score   Error  Units
StringComparisons.regionMatches            6     true  avgt    5    3.535 ? 0.022  ns/op
StringComparisons.regionMatches            6    false  avgt    5    3.134 ? 0.022  ns/op
StringComparisons.regionMatches           15     true  avgt    5    2.568 ? 0.022  ns/op
StringComparisons.regionMatches           15    false  avgt    5    3.415 ? 0.017  ns/op
StringComparisons.regionMatches         1024     true  avgt    5   30.052 ? 0.070  ns/op
StringComparisons.regionMatches         1024    false  avgt    5   17.024 ? 0.111  ns/op
StringComparisons.regionMatchesRange       6     true  avgt    5    4.819 ? 0.010  ns/op
StringComparisons.regionMatchesRange       6    false  avgt    5    5.888 ? 0.083  ns/op
StringComparisons.regionMatchesRange      15     true  avgt    5    5.849 ? 0.106  ns/op
StringComparisons.regionMatchesRange      15    false  avgt    5    5.466 ? 0.069  ns/op
StringComparisons.regionMatchesRange    1024     true  avgt    5   31.177 ? 0.015  ns/op
StringComparisons.regionMatchesRange    1024    false  avgt    5   16.872 ? 0.387  ns/op

Which translate in a ~1.8 speedup for small sized ones (which is still a fairly common use case), while bigger ones seems unchanged. 
I'm adding some better benchmark to show the positive test case improvement as well.

The new commit, introducing the full positive use case (maybe relevant for the case with few characters) adds
an additional comparison vs the `String::equals` case (which will likely perform a bare minimum amount of checks, if compared to region matches).

baseline at 25f9af99be1c906fc85b8192df8fa50cced3474f:

Benchmark                            (size)  (utf16)  Mode  Cnt   Score   Error  Units
StringComparisons.same                    6     true  avgt    5   2.402 ? 0.028  ns/op
StringComparisons.same                    6    false  avgt    5   2.056 ? 0.056  ns/op
StringComparisons.same                   15     true  avgt    5   3.733 ? 0.161  ns/op
StringComparisons.same                   15    false  avgt    5   2.807 ? 0.214  ns/op
StringComparisons.same                 1024     true  avgt    5  23.485 ? 0.150  ns/op
StringComparisons.same                 1024    false  avgt    5  15.302 ? 0.232  ns/op

StringComparisons.sameRegionMatches       6     true  avgt    5   4.410 ? 0.078  ns/op
StringComparisons.sameRegionMatches       6    false  avgt    5   5.414 ? 0.028  ns/op
StringComparisons.sameRegionMatches      15     true  avgt    5   5.770 ? 0.021  ns/op
StringComparisons.sameRegionMatches      15    false  avgt    5   5.771 ? 0.035  ns/op
StringComparisons.sameRegionMatches    1024     true  avgt    5  30.964 ? 0.023  ns/op
StringComparisons.sameRegionMatches    1024    false  avgt    5  16.807 ? 0.181  ns/op

with 1bd619a5bd2faa8057cb85105b2c9b4997fbf2ac:

Benchmark                            (size)  (utf16)  Mode  Cnt   Score   Error  Units
StringComparisons.sameRegionMatches       6     true  avgt    5   3.442 ? 0.016  ns/op
StringComparisons.sameRegionMatches       6    false  avgt    5   3.117 ? 0.002  ns/op
StringComparisons.sameRegionMatches      15     true  avgt    5   4.759 ? 0.075  ns/op
StringComparisons.sameRegionMatches      15    false  avgt    5   3.813 ? 0.026  ns/op
StringComparisons.sameRegionMatches    1024     true  avgt    5  28.308 ? 0.058  ns/op
StringComparisons.sameRegionMatches    1024    false  avgt    5  16.774 ? 0.220  ns/op

As confirmed by the previous results, the better value of this PR is with small-sized strings, but it is yet to be verified if:
- due to a better tail-handing of the `equals` intrinsics
- larger strings are limited by the amount of cache activity

Running `perfnorm` against 25f9af99be1c906fc85b8192df8fa50cced3474f with `same` vs `sameRegionMatches` reveal that 
both have high IPC with an high number of branchs and L1 cache-loads (with nearly no misses), which means that both dominate the cost of computation despite the number of instructions on `sameRegionMatches` is higher.
In short, with bigger sized-strings, the difference between the 2 intrinsic just fade away, making who perform less instructions, to perform better.

@cl4es I can undraft this, but I have no powers to create a JDK issue myself :"/

Keep it alive!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-1838571952
PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-1838744137
PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-1838950133
PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-2048905394

From redestad at openjdk.org  Wed Nov 26 20:14:08 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Nov 2025 20:14:08 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
Message-ID: <qwLEY42ZaxQSxKOhNtW1rcmO6unHz_tc5actOa5dPhg=.cf1632a5-0838-4c64-afcd-e1373ee3a56f@github.com>

On Sat, 2 Dec 2023 16:56:22 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526.
> 
> It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation.

General comments:
- Does this suggest an optimization opportunity to `ArraysSupport::mismatch`, or is the relative overhead due the inherent costs of finding the exact index in the mismatch? 
- This only optimize the case where we're comparing the entirety of both `String`s. How common is this in practice? It would be good to check a mixed benchmark where some inputs will use this fast path and others won't to assert that this doesn't have an unexpected negative impact from adding a few tests. 

The tests in `StringComparisons`, e.g. `regionMatchesRange` might be a bit naive in the sense that the offsets are constant, which perhaps unrealistically remove any overhead from the added tests in your patch here.

Filed: https://bugs.openjdk.org/browse/JDK-8321283

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-1838984100
PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-1839029351

From duke at openjdk.org  Wed Nov 26 20:14:09 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 26 Nov 2025 20:14:09 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <qwLEY42ZaxQSxKOhNtW1rcmO6unHz_tc5actOa5dPhg=.cf1632a5-0838-4c64-afcd-e1373ee3a56f@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <qwLEY42ZaxQSxKOhNtW1rcmO6unHz_tc5actOa5dPhg=.cf1632a5-0838-4c64-afcd-e1373ee3a56f@github.com>
Message-ID: <at1P4Quhcukuyw69ZfS96wU-rVbk58bncOI3ZRSgETk=.b2d17bb0-7657-4b47-b161-6fd39b220c80@github.com>

On Mon, 4 Dec 2023 16:17:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Does this suggest an optimization opportunity to ArraysSupport::mismatch, or is the relative overhead due the inherent costs of finding the exact index in the mismatch?

I suppose that's the latter; but I need to study the produced ASM for both, in case of small sized strings.
As said in https://github.com/openjdk/jdk/pull/16933#issuecomment-1838744137, the cost just fade away when cache accesses become the dominant cost

> This only optimize the case where we're comparing the entirety of both Strings. How common is this in practice?

I have the sole data point of HTTP endpoint routing which *can* have, in the hot path and common cases, exact matching too, see https://github.com/franz1981/vertx-web/blob/c6740a5991a15567521c26ac3a08091e8603f2f2/vertx-web/src/main/java/io/vertx/ext/web/impl/RouteState.java#L1251-L1262

> It would be good to check a mixed benchmark where some inputs will use this fast path and others won't to assert that this doesn't have an unexpected negative impact from adding a few tests.

You mean by having the different uses cases stressed in sequence with some probability (in order to induce some cache misses)? To be fair we should change the length too, and let the "batching" factor (ie the stride) of each different vectorized version to induce other branch-misses, instead of a "all or nothing" one, but sadly it means no longer having steady-state which will make more difficult to evaluate improvements. 
I'm +1 to this micro use case, but I would like to better understand how to write it right

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-1839084606

From liach at openjdk.org  Wed Nov 26 20:14:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Nov 2025 20:14:10 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
Message-ID: <XUE8OrTKqBiEwyLXYK7lAeCmEmvtNo60HSWIQYKptKQ=.22efaa35-ff41-4659-9502-62b8bccd4e1c@github.com>

On Sat, 2 Dec 2023 16:56:22 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526.
> 
> It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation.

With a JBS issue, you need to change the PR title to `8321283: Reuse StringLatin1::equals in regionMatches` so that the JDK bot will recognize and link the issue.

src/java.base/share/classes/java/lang/String.java line 2185:

> 2183:         byte[] ov = other.value;
> 2184:         if (coder == otherCoder) {
> 2185:             if ((ooffset | toffset) == 0 && len == (tv.length >> coder) && ov.length == tv.length) {

Just curious, is `(ooffset | toffset) == 0` more efficient than `ooffset == 0 && toffset== 0`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-1873586642
PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1414224254

From liach at openjdk.org  Wed Nov 26 20:14:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Nov 2025 20:14:11 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <q_q6gfPW1c9663D4GQKm4zKntVd6oLB-L9bbKsNnp60=.148de24b-8bf9-4324-81df-5525d1bb0f81@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <q_q6gfPW1c9663D4GQKm4zKntVd6oLB-L9bbKsNnp60=.148de24b-8bf9-4324-81df-5525d1bb0f81@github.com>
Message-ID: <0nw2D5WEsHrGC3rHk-Sh0zzM5aZLgZ5UY32EB8ijAQM=.42e02526-006b-4c8c-821a-116499355408@github.com>

On Thu, 11 Apr 2024 04:26:26 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526.
>> 
>> It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation.
>
> Keep it alive!

@franz1981 Can you update the PR title to start with `8321283: ` so the jdk bot will recognize the JBS issue, mark this ready for review, and forward this PR to the OpenJDK mailing lists?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-2050138176

From duke at openjdk.org  Wed Nov 26 20:14:13 2025
From: duke at openjdk.org (David Schlosnagle)
Date: Wed, 26 Nov 2025 20:14:13 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
Message-ID: <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>

On Sat, 2 Dec 2023 16:56:22 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526.
> 
> It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation.

src/java.base/share/classes/java/lang/String.java line 2184:

> 2182:         byte[] tv = value;
> 2183:         byte[] ov = other.value;
> 2184:         if (coder == otherCoder) {

Is this change needed as `otherCoder` is not reused?

Suggestion:

        byte[] tv = value;
        byte[] ov = other.value;
        byte coder = coder();
        if (coder == other.coder()) {

src/java.base/share/classes/java/lang/String.java line 2186:

> 2184:         if (coder == otherCoder) {
> 2185:             if (ooffset == 0 && toffset == 0 && len == (tv.length >> coder) && ov.length == tv.length) {
> 2186:                 return StringLatin1.equals(tv, ov);

A few questions on this:

- Should this also handle `UTF-16`?
- Could we save a comparison by `OR`ing offsets?
- The `equals` method will do the `tv` and `ov` length comparisons themselves, could we remove that check here or is the method call overhead too large?
- Do you happen to have results for `make test TEST="micro:java.lang.StringComparisons"`?

Suggestion:

            if ((ooffset | toffset) == 0 && len == (tv.length >> coder)) {
                return coder == LATIN1
                  ? StringLatin1.equals(tv, ov)
                  : StringUTF16.equals(tv, ov);
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1412902721
PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1412887365

From duke at openjdk.org  Wed Nov 26 20:14:13 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 26 Nov 2025 20:14:13 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>
Message-ID: <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>

On Sun, 3 Dec 2023 01:01:49 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526.
>> 
>> It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation.
>
> src/java.base/share/classes/java/lang/String.java line 2184:
> 
>> 2182:         byte[] tv = value;
>> 2183:         byte[] ov = other.value;
>> 2184:         if (coder == otherCoder) {
> 
> Is this change needed as `otherCoder` is not reused?
> 
> Suggestion:
> 
>         byte[] tv = value;
>         byte[] ov = other.value;
>         byte coder = coder();
>         if (coder == other.coder()) {

Not necessary, but given that later, in the path I have introduced, I am using directly the coder byte to both compute the actual length of `tv` (inlining String::length) and verify the coder to be the same for both `tv` and `ov`, I have avoided fetching it twice.
I see that "could" increase the register pressure, but I haven't verified it yet; there is any performance concern or is a readability/style-only concern?

> Could we save a comparison by ORing offsets?

I'm ok to use the or to save an additional offset comparison, good idea!

> Should this also handle UTF-16?

Currently String::equals doesn't use the UTF16 variant of the intrinsic, see https://github.com/openjdk/jdk/blob/949846986f572dfb82912e7d71e7bfd37a90871e/src/java.base/share/classes/java/lang/String.java#L1879-L1880; I think it's because checking byte per byte equality (from a semantic perspective), still hold. I didn't checked what are the other usage for the UTF16 version, but @cl4es could clarify it .

> The equals method will do the tv and ov length comparisons themselves, could we remove that check here or is the method call overhead too large?

I didn't remove it because region equality won't return (always) false, as equals would do, in such case, but will compare the (If existing) minimal common available length (till the specified len) between the two.

> Do you happen to have results for make test TEST="micro:java.lang.StringComparisons"?

Not yet, I have performed a microbenchmark myself to verify that with small strings (below 16 bytes), equals was much better (both by enabling and disabling the mismatch intrinsics), but I will do it, thanks!

I'm missing as well to verify the bytecode size of the method after my changes, to make sure I didn't make it non-inlineable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1413009110
PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1413008371

From duke at openjdk.org  Wed Nov 26 20:14:13 2025
From: duke at openjdk.org (David Schlosnagle)
Date: Wed, 26 Nov 2025 20:14:13 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>
 <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>
Message-ID: <piR5Av0vB3621lGw3m8mkp0diKvacCuya0MjJwR7jqM=.f2b9ab53-3cbd-40a6-952d-ad8a5790aede@github.com>

On Sun, 3 Dec 2023 06:05:45 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 2184:
>> 
>>> 2182:         byte[] tv = value;
>>> 2183:         byte[] ov = other.value;
>>> 2184:         if (coder == otherCoder) {
>> 
>> Is this change needed as `otherCoder` is not reused?
>> 
>> Suggestion:
>> 
>>         byte[] tv = value;
>>         byte[] ov = other.value;
>>         byte coder = coder();
>>         if (coder == other.coder()) {
>
> Not necessary, but given that later, in the path I have introduced, I am using directly the coder byte to both compute the actual length of `tv` (inlining String::length) and verify the coder to be the same for both `tv` and `ov`, I have avoided fetching it twice.
> I see that "could" increase the register pressure, but I haven't verified it yet; there is any performance concern or is a readability/style-only concern?

Defer to the maintainers on preference, I just noticed `otherCoder` was unused outside of single comparison and other similar patterns in this file seem to inline.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1413875411

From duke at openjdk.org  Wed Nov 26 20:14:15 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 26 Nov 2025 20:14:15 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <XUE8OrTKqBiEwyLXYK7lAeCmEmvtNo60HSWIQYKptKQ=.22efaa35-ff41-4659-9502-62b8bccd4e1c@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <XUE8OrTKqBiEwyLXYK7lAeCmEmvtNo60HSWIQYKptKQ=.22efaa35-ff41-4659-9502-62b8bccd4e1c@github.com>
Message-ID: <WS9DlV7rjdJ8W-ramJuF6bceDRc60az9FqAn5X-utwc=.66cf3ebc-0898-4092-be44-56c34bb4d178@github.com>

On Mon, 4 Dec 2023 17:11:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526.
>> 
>> It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation.
>
> src/java.base/share/classes/java/lang/String.java line 2185:
> 
>> 2183:         byte[] ov = other.value;
>> 2184:         if (coder == otherCoder) {
>> 2185:             if ((ooffset | toffset) == 0 && len == (tv.length >> coder) && ov.length == tv.length) {
> 
> Just curious, is `(ooffset | toffset) == 0` more efficient than `ooffset == 0 && toffset== 0`?

It can be, depending the probability of happening for both and if/where their caller is inlined (presenting itself into different addresses, basically): conditions easy to predict are very cheap, but if not, can have some performance penalties. 
An `|` between register is super cheap, instead: the same tecnique has been used at https://github.com/openjdk/jdk/blob/a26f7c03c72e4efe6d3219d294294c554aebc631/src/hotspot/share/utilities/copy.cpp#L215 which is supposed to be another hot-path, probably for similar reasons.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1414227453

From redestad at openjdk.org  Wed Nov 26 20:14:16 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Nov 2025 20:14:16 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>
 <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>
Message-ID: <ZwTFYEBVG-YginZm07Om3mWpnDFZRoUEFEXxTYcocZc=.9cf973d8-2cb0-4ace-ba16-c8274b70ec44@github.com>

On Sun, 3 Dec 2023 05:58:27 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 2186:
>> 
>>> 2184:         if (coder == otherCoder) {
>>> 2185:             if (ooffset == 0 && toffset == 0 && len == (tv.length >> coder) && ov.length == tv.length) {
>>> 2186:                 return StringLatin1.equals(tv, ov);
>> 
>> A few questions on this:
>> 
>> - Should this also handle `UTF-16`?
>> - Could we save a comparison by `OR`ing offsets?
>> - The `equals` method will do the `tv` and `ov` length comparisons themselves, could we remove that check here or is the method call overhead too large?
>> - Do you happen to have results for `make test TEST="micro:java.lang.StringComparisons"`?
>> 
>> Suggestion:
>> 
>>             if ((ooffset | toffset) == 0 && len == (tv.length >> coder)) {
>>                 return coder == LATIN1
>>                   ? StringLatin1.equals(tv, ov)
>>                   : StringUTF16.equals(tv, ov);
>>             }
>
>> Could we save a comparison by ORing offsets?
> 
> I'm ok to use the or to save an additional offset comparison, good idea!
> 
>> Should this also handle UTF-16?
> 
> Currently String::equals doesn't use the UTF16 variant of the intrinsic, see https://github.com/openjdk/jdk/blob/949846986f572dfb82912e7d71e7bfd37a90871e/src/java.base/share/classes/java/lang/String.java#L1879-L1880; I think it's because checking byte per byte equality (from a semantic perspective), still hold. I didn't checked what are the other usage for the UTF16 version, but @cl4es could clarify it .
> 
>> The equals method will do the tv and ov length comparisons themselves, could we remove that check here or is the method call overhead too large?
> 
> I didn't remove it because region equality won't return (always) false, as equals would do, in such case, but will compare the (If existing) minimal common available length (till the specified len) between the two.
> 
>> Do you happen to have results for make test TEST="micro:java.lang.StringComparisons"?
> 
> Not yet, I have performed a microbenchmark myself to verify that with small strings (below 16 bytes), equals was much better (both by enabling and disabling the mismatch intrinsics), but I will do it, thanks!
> 
> I'm missing as well to verify the bytecode size of the method after my changes, to make sure I didn't make it non-inlineable.

Yes, since the `coder` is checked first we know the bytes compared are either both latin1 or both UTF16 so there's no need for a UTF-16-aware char-by-char comparison here. In fact the `StringUTF16.equals` method looks completely unused.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1413697276

From duke at openjdk.org  Wed Nov 26 20:14:17 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 26 Nov 2025 20:14:17 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <ZwTFYEBVG-YginZm07Om3mWpnDFZRoUEFEXxTYcocZc=.9cf973d8-2cb0-4ace-ba16-c8274b70ec44@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>
 <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>
 <ZwTFYEBVG-YginZm07Om3mWpnDFZRoUEFEXxTYcocZc=.9cf973d8-2cb0-4ace-ba16-c8274b70ec44@github.com>
Message-ID: <cWtRy4c6UK1SPJsraI1sY1OLl9WlMclgDw90pzd8Wpg=.c5960c70-b861-4440-843b-dc1452cd3935@github.com>

On Mon, 4 Dec 2023 10:51:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> Could we save a comparison by ORing offsets?
>> 
>> I'm ok to use the or to save an additional offset comparison, good idea!
>> 
>>> Should this also handle UTF-16?
>> 
>> Currently String::equals doesn't use the UTF16 variant of the intrinsic, see https://github.com/openjdk/jdk/blob/949846986f572dfb82912e7d71e7bfd37a90871e/src/java.base/share/classes/java/lang/String.java#L1879-L1880; I think it's because checking byte per byte equality (from a semantic perspective), still hold. I didn't checked what are the other usage for the UTF16 version, but @cl4es could clarify it .
>> 
>>> The equals method will do the tv and ov length comparisons themselves, could we remove that check here or is the method call overhead too large?
>> 
>> I didn't remove it because region equality won't return (always) false, as equals would do, in such case, but will compare the (If existing) minimal common available length (till the specified len) between the two.
>> 
>>> Do you happen to have results for make test TEST="micro:java.lang.StringComparisons"?
>> 
>> Not yet, I have performed a microbenchmark myself to verify that with small strings (below 16 bytes), equals was much better (both by enabling and disabling the mismatch intrinsics), but I will do it, thanks!
>> 
>> I'm missing as well to verify the bytecode size of the method after my changes, to make sure I didn't make it non-inlineable.
>
> Yes, since the `coder` is checked first we know the bytes compared are either both latin1 or both UTF16 so there's no need for a UTF-16-aware char-by-char comparison here. In fact the `StringUTF16.equals` method looks completely unused.

I can send a separate PR to remove it in case, unless we have any plans to use it elsewhere

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1413765820

From redestad at openjdk.org  Wed Nov 26 20:14:17 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Nov 2025 20:14:17 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <cWtRy4c6UK1SPJsraI1sY1OLl9WlMclgDw90pzd8Wpg=.c5960c70-b861-4440-843b-dc1452cd3935@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>
 <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>
 <ZwTFYEBVG-YginZm07Om3mWpnDFZRoUEFEXxTYcocZc=.9cf973d8-2cb0-4ace-ba16-c8274b70ec44@github.com>
 <cWtRy4c6UK1SPJsraI1sY1OLl9WlMclgDw90pzd8Wpg=.c5960c70-b861-4440-843b-dc1452cd3935@github.com>
Message-ID: <qn4s6ia2axdNDksvuXI7akaCSKiW6WtPVgI4sWbKF5o=.4d17cec3-c745-4e6c-bf00-c47e309ec746@github.com>

On Mon, 4 Dec 2023 11:52:29 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Yes, since the `coder` is checked first we know the bytes compared are either both latin1 or both UTF16 so there's no need for a UTF-16-aware char-by-char comparison here. In fact the `StringUTF16.equals` method looks completely unused.
>
> I can send a separate PR to remove it in case, unless we have any plans to use it elsewhere

`StringUTF16::equals` was used before https://bugs.openjdk.org/browse/JDK-8215017 - I don't remember exactly what performance verification I did back then. x86 intrinsics seem to emit the exact same asm, aarch64 does a little bit of extra optimization for the UTF16 case (avoids code and a branch for checking tailing byte, but only if the UTF16 string is 1-3 elements long). Perhaps we should double-check that JDK-8215017 didn't significantly regress some UTF16 equality checks before we rip out code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1413872054

From redestad at openjdk.org  Wed Nov 26 20:14:18 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Nov 2025 20:14:18 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <qn4s6ia2axdNDksvuXI7akaCSKiW6WtPVgI4sWbKF5o=.4d17cec3-c745-4e6c-bf00-c47e309ec746@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>
 <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>
 <ZwTFYEBVG-YginZm07Om3mWpnDFZRoUEFEXxTYcocZc=.9cf973d8-2cb0-4ace-ba16-c8274b70ec44@github.com>
 <cWtRy4c6UK1SPJsraI1sY1OLl9WlMclgDw90pzd8Wpg=.c5960c70-b861-4440-843b-dc1452cd3935@github.com>
 <qn4s6ia2axdNDksvuXI7akaCSKiW6WtPVgI4sWbKF5o=.4d17cec3-c745-4e6c-bf00-c47e309ec746@github.com>
Message-ID: <TlqJgxTXpCEKozR4arraq2ME5LSLsffgf9EYGV7Q9Uw=.8d9ebead-ac0d-4aa7-b2d8-2b4eb55e026b@github.com>

On Mon, 4 Dec 2023 13:27:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I can send a separate PR to remove it in case, unless we have any plans to use it elsewhere
>
> `StringUTF16::equals` was used before https://bugs.openjdk.org/browse/JDK-8215017 - I don't remember exactly what performance verification I did back then. x86 intrinsics seem to emit the exact same asm, aarch64 does a little bit of extra optimization for the UTF16 case (avoids code and a branch for checking tailing byte, but only if the UTF16 string is 1-3 elements long). Perhaps we should double-check that JDK-8215017 didn't significantly regress some UTF16 equality checks before we rip out code.

Going out on this tangent... I've compared the mainline (Base) with a build where `String::equals` is restored to pre-JDK-8215017 using a modified version of the StringEquals microbenchmark that tests UTF16 Strings of size 3. One test (EQ) where the strings are equals, another (NE) where they are not. The EQ one is the main contender for a case that would benefit from avoiding the trailing byte check on aarch64:

On my M1 (aarch64):


Name                          Cnt  Base   Error   Test   Error  Unit  Change
StringEquals.equalsUTF16_3_EQ   5 1,750 ? 0,009  1,864 ? 0,401 ns/op   0,94x (p = 0,070 )
StringEquals.equalsUTF16_3_NE   5 1,674 ? 0,026  1,839 ? 0,179 ns/op   0,91x (p = 0,001*)
  * = significant
 ```

Similarly restoring the pre-JDK-8215017 version seem to be a net loss on x86:

Name                          Cnt  Base   Error   Test   Error  Unit  Change
StringEquals.equalsUTF16_3_EQ   5 2.885 ? 0.054  2.886 ? 0.036 ns/op   1.00x (p = 0.837 )
StringEquals.equalsUTF16_3_NE   5 2.581 ? 0.002  2.756 ? 0.003 ns/op   0.94x (p = 0.000*)
  * = significant


So it seems JDK-8215017 was either neutral or a small performance win (phew!). The avoided branch and overall reduction in code complexity outweighs the win (if any) from not having the redundant `COMPARE_BYTE` chunk of code emitted in the StringUTF16 case. There are other platforms I can't currently check, but I think it's likely that we'd see similar numbers there. So it seems to be the case that `StringUTF16::equals` can be safely removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1414118658

From duke at openjdk.org  Wed Nov 26 20:14:18 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 26 Nov 2025 20:14:18 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <TlqJgxTXpCEKozR4arraq2ME5LSLsffgf9EYGV7Q9Uw=.8d9ebead-ac0d-4aa7-b2d8-2b4eb55e026b@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>
 <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>
 <ZwTFYEBVG-YginZm07Om3mWpnDFZRoUEFEXxTYcocZc=.9cf973d8-2cb0-4ace-ba16-c8274b70ec44@github.com>
 <cWtRy4c6UK1SPJsraI1sY1OLl9WlMclgDw90pzd8Wpg=.c5960c70-b861-4440-843b-dc1452cd3935@github.com>
 <qn4s6ia2axdNDksvuXI7akaCSKiW6WtPVgI4sWbKF5o=.4d17cec3-c745-4e6c-bf00-c47e309ec746@github.com>
 <TlqJgxTXpCEKozR4arraq2ME5LSLsffgf9EYGV7Q9Uw=.8d9ebead-ac0d-4aa7-b2d8-2b4eb55e026b@github.com>
Message-ID: <ujbCnzvQstYlGPeI2OPzWWKfGdzNgDZarcFAyV7JX2I=.4ea16267-9a85-4927-8ce0-4e52573ca1e6@github.com>

On Mon, 4 Dec 2023 15:57:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `StringUTF16::equals` was used before https://bugs.openjdk.org/browse/JDK-8215017 - I don't remember exactly what performance verification I did back then. x86 intrinsics seem to emit the exact same asm, aarch64 does a little bit of extra optimization for the UTF16 case (avoids code and a branch for checking tailing byte, but only if the UTF16 string is 1-3 elements long). Perhaps we should double-check that JDK-8215017 didn't significantly regress some UTF16 equality checks before we rip out code.
>
> Going out on this tangent... I've compared the mainline (Base) with a build where `String::equals` is restored to pre-JDK-8215017 using a modified version of the StringEquals microbenchmark that tests UTF16 Strings of size 3. One test (EQ) where the strings are equals, another (NE) where they are not. The EQ one is the main contender for a case that would benefit from avoiding the trailing byte check on aarch64:
> 
> On my M1 (aarch64):
> 
> 
> Name                          Cnt  Base   Error   Test   Error  Unit  Change
> StringEquals.equalsUTF16_3_EQ   5 1,750 ? 0,009  1,864 ? 0,401 ns/op   0,94x (p = 0,070 )
> StringEquals.equalsUTF16_3_NE   5 1,674 ? 0,026  1,839 ? 0,179 ns/op   0,91x (p = 0,001*)
>   * = significant
>  ```
> 
> Similarly restoring the pre-JDK-8215017 version seem to be a net loss on x86:
> 
> Name                          Cnt  Base   Error   Test   Error  Unit  Change
> StringEquals.equalsUTF16_3_EQ   5 2.885 ? 0.054  2.886 ? 0.036 ns/op   1.00x (p = 0.837 )
> StringEquals.equalsUTF16_3_NE   5 2.581 ? 0.002  2.756 ? 0.003 ns/op   0.94x (p = 0.000*)
>   * = significant
> 
> 
> So it seems JDK-8215017 was either neutral or a small performance win (phew!). The avoided branch and overall reduction in code complexity outweighs the win (if any) from not having the redundant `COMPARE_BYTE` chunk of code emitted in the StringUTF16 case. There are other platforms I can't currently check, but I think it's likely that we'd see similar numbers there. So it seems to be the case that `StringUTF16::equals` can be safely removed.

Nice one, I can happily send a PR for it, but I feel bad about it; you have performed the check yourself (and were aware of what dropping it would mean...)

separated question @cl4es, how do you obtained the 'Change` column with the `p` value? is in some jdk script I've missed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1414125814
PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1414129103

From duke at openjdk.org  Wed Nov 26 20:14:18 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 26 Nov 2025 20:14:18 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <ujbCnzvQstYlGPeI2OPzWWKfGdzNgDZarcFAyV7JX2I=.4ea16267-9a85-4927-8ce0-4e52573ca1e6@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <UKIHWBxjJZ8F8UnVfxx0RHtUyxpt_XOEhUHhWKLxH2E=.158d272f-fa64-4cae-8dd8-48512d32b233@github.com>
 <j49xrAebg0PQDgrCBhXAj7GYqzp_uuIT9vlMyC0X4dI=.7f997d9b-28ac-4e11-91a3-fec6c0f99b72@github.com>
 <ZwTFYEBVG-YginZm07Om3mWpnDFZRoUEFEXxTYcocZc=.9cf973d8-2cb0-4ace-ba16-c8274b70ec44@github.com>
 <cWtRy4c6UK1SPJsraI1sY1OLl9WlMclgDw90pzd8Wpg=.c5960c70-b861-4440-843b-dc1452cd3935@github.com>
 <qn4s6ia2axdNDksvuXI7akaCSKiW6WtPVgI4sWbKF5o=.4d17cec3-c745-4e6c-bf00-c47e309ec746@github.com>
 <TlqJgxTXpCEKozR4arraq2ME5LSLsffgf9EYGV7Q9Uw=.8d9ebead-ac0d-4aa7-b2d8-2b4eb55e026b@github.com>
 <ujbCnzvQstYlGPeI2OPzWWKfGdzNgDZarcFAyV7JX2I=.4ea16267-9a85-4927-8ce0-4e52573ca1e6@github.com>
Message-ID: <bfqsuhx1II7wtJJxFAh3k0ZsGZhOWSRpDl_z2JV1_2Y=.de92b952-f682-465a-9499-3b3d3592f123@github.com>

On Mon, 4 Dec 2023 16:04:35 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Going out on this tangent... I've compared the mainline (Base) with a build where `String::equals` is restored to pre-JDK-8215017 using a modified version of the StringEquals microbenchmark that tests UTF16 Strings of size 3. One test (EQ) where the strings are equals, another (NE) where they are not. The EQ one is the main contender for a case that would benefit from avoiding the trailing byte check on aarch64:
>> 
>> On my M1 (aarch64):
>> 
>> 
>> Name                          Cnt  Base   Error   Test   Error  Unit  Change
>> StringEquals.equalsUTF16_3_EQ   5 1,750 ? 0,009  1,864 ? 0,401 ns/op   0,94x (p = 0,070 )
>> StringEquals.equalsUTF16_3_NE   5 1,674 ? 0,026  1,839 ? 0,179 ns/op   0,91x (p = 0,001*)
>>   * = significant
>>  ```
>> 
>> Similarly restoring the pre-JDK-8215017 version seem to be a net loss on x86:
>> 
>> Name                          Cnt  Base   Error   Test   Error  Unit  Change
>> StringEquals.equalsUTF16_3_EQ   5 2.885 ? 0.054  2.886 ? 0.036 ns/op   1.00x (p = 0.837 )
>> StringEquals.equalsUTF16_3_NE   5 2.581 ? 0.002  2.756 ? 0.003 ns/op   0.94x (p = 0.000*)
>>   * = significant
>> 
>> 
>> So it seems JDK-8215017 was either neutral or a small performance win (phew!). The avoided branch and overall reduction in code complexity outweighs the win (if any) from not having the redundant `COMPARE_BYTE` chunk of code emitted in the StringUTF16 case. There are other platforms I can't currently check, but I think it's likely that we'd see similar numbers there. So it seems to be the case that `StringUTF16::equals` can be safely removed.
>
> separated question @cl4es, how do you obtained the 'Change` column with the `p` value? is in some jdk script I've missed?

Gentle ping on the previous (although OT) question; did you have a OSS comparison tools which work on JMH results? If yes, is very nice!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1491970410

From dhanalla at openjdk.org  Wed Nov 26 21:06:26 2025
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Wed, 26 Nov 2025 21:06:26 GMT
Subject: RFR: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log
 on aarch64 [v3]
In-Reply-To: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
References: <MSo-nt9a7XFm7QaFGYAftChTUCajmScF9DuvE2CsgeY=.ce1d690d-7f40-45e8-84c6-56d843c525c3@github.com>
Message-ID: <6lET0hX7bDMhtRlvnIw2R4Df_pcIrihcHNjYrqKvTMI=.72367a3f-a937-45ff-9f96-f7a2cb6f2ad4@github.com>

> This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial.
> Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN).
> 
> 
> 
> The micro-benchmark results from MathBench and StrictMathBench below show the performance improvement of Math.log:
> 
> 
> **Before change**
> <html xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=OneNote.File>
> <meta name=Generator content="Microsoft OneNote 15">
> </head>
> 
> <body lang=en-US style='font-family:Calibri;font-size:11.0pt'>
> 
> 
> <div style='direction:ltr;border-width:100%'>
> 
> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
> 
> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
> 
> <div style='direction:ltr'>
> 
> Benchmark | Mode | Cnt | Score | Error | Units
> -- | -- | -- | -- | -- | --
> MathBench.logDouble | thrpt | 10 | **15549.705** | ?357.439 | ops/ms
> StrictMathBench.logDouble | thrpt | 10 | 219408.158 | ?16484.680 | ops/ms
> 
> </div>
> 
> </div>
> 
> </div>
> 
> </div>
> 
> 
> </body>
> 
> </html>
> 
> 
> 
> **After adding Math.log intrinsic**
> 
> <html xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=OneNote.File>
> <meta name=Generator content="Microsoft OneNote 15">
> </head>
> 
> <body lang=en-US style='font-family:Calibri;font-size:11.0pt'>
> 
> 
> <div style='direction:ltr;border-width:100%'>
> 
> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
> 
> <div style='direction:ltr;margin-top:0in;margin-left:0in;width:12.9277in'>
> 
> <div style='direction:ltr'>
> 
> Benchmark | Mode | Cnt | Score | Error | Units
> -- | -- | -- | -- | -- | --
> MathBench.logDouble | thrpt | 10 | **300086.773** | ?6675.936 | ops/ms
> StrictMathBench.logDouble | thrpt | 10 | 226521.817 | ?4038.975 | ops/ms
> 
> 
> </div>
> 
> </div>
> 
> </div>
> 
> </div>
> 
> 
> </body>
> 
> </html>

Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:

  [AArch64] Math.log is 10% slower than StrictMath.log on aarch64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28306/files
  - new: https://git.openjdk.org/jdk/pull/28306/files/06b3dd4d..60a0b8e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28306&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28306&range=01-02

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28306/head:pull/28306

PR: https://git.openjdk.org/jdk/pull/28306

From rriggs at openjdk.org  Wed Nov 26 21:41:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 26 Nov 2025 21:41:52 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
Message-ID: <UofYm5TPDXjsmRaFIlcyZeGVWRfzFfrflpYqnECl_Y8=.0117ab2d-aaf8-4f66-9139-20ffcda50d17@github.com>

On Sat, 2 Dec 2023 16:56:22 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526.
> 
> It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation.

This PR has aged quite a bit. Please merge with master to get an up-to-date PR.
It might be cleaner to close this PR and start fresh.
Also, please reconfirm the performance numbers.
Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-3583290268

From duke at openjdk.org  Wed Nov 26 22:08:14 2025
From: duke at openjdk.org (James Yuzawa)
Date: Wed, 26 Nov 2025 22:08:14 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v3]
In-Reply-To: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
Message-ID: <gorB3SZQego7xgJXT1UDtvP6pUtOQjbEIe7xVxTQW3E=.c7a90086-e5d8-473e-8e74-dbe515d3e08f@github.com>

> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
> 
> Here is a very simple reproducer:
> 
> ThreadLocalRandom r = ThreadLocalRandom.current();
> // step into this call using a debugger
> r.nextGaussian();
> 
> 
> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
> 
> Sketch:
> 
> public interface RandomGenerator {
> 	default double nextGaussian() {
> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> public class Random implements RandomGenerator {
> 	@Override
> 	public synchronized double nextGaussian() {
> 		// synchronized version ...
> 	}
> }
> 
> public class ThreadLocalRandom extends Random {
> 
> 	// ADD THIS
> 	@Override
> 	public double nextGaussian() {
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> 
> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
> 
> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
> 
> 
> Set<String> tlrMethods = new HashSet<>();
> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		tlrMethods.add(desc);
> 	}
> }
> for (Method method : java.util.Random.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		if (!tlrMethods.contains(desc)) {
> 			System.out.println(desc);
> 		}
> 	}
> }
> 
> 
> That prints
> 
> void nextBytes [byte[] arg0]
> double nextGaussian []
> 
> 
> The former safely calls `Thread...

James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:

  8372134: ThreadLocalRandom no longer overrides nextGaussian
  
  Fix Javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28483/files
  - new: https://git.openjdk.org/jdk/pull/28483/files/245dfb4d..54228b28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28483&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28483&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28483/head:pull/28483

PR: https://git.openjdk.org/jdk/pull/28483

From duke at openjdk.org  Wed Nov 26 22:08:15 2025
From: duke at openjdk.org (James Yuzawa)
Date: Wed, 26 Nov 2025 22:08:15 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v2]
In-Reply-To: <lsKlnnhSftoDOh51Xz-nJZl5kgDgb01yx-zzQd8wyzI=.f6f0de78-15ea-4692-97b8-ec9ec8094c40@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <7bqpLaU9FCBPSG77Fkd31oSnj_vI2eubh-PW1c4rXRU=.60b0cb3e-8d01-4781-bebb-96df89906da2@github.com>
 <lsKlnnhSftoDOh51Xz-nJZl5kgDgb01yx-zzQd8wyzI=.f6f0de78-15ea-4692-97b8-ec9ec8094c40@github.com>
Message-ID: <sW0Xl9_htEWsirVo9TK-gur3eIMMl7kpjKq8pL2RRb0=.8193edcc-06e6-493b-9fe7-a1688bc0d7bc@github.com>

On Wed, 26 Nov 2025 16:35:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>>   
>>   Fix javadoc
>
> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 507:
> 
>> 505:      *           {@link java.util.Random#nextGaussian()} and instead uses the
>> 506:      *           ziggurat-based algorithm from the default implementation of
>> 507:      *           {@link java.util.random.RandomGenerator#nextGaussian()}.
> 
> The implNotes in this class start with "This method is implemented ...".  How about: "This implementation invokes the default implementation of RandomGenerator.nextGaussian and so uses McFarland's fast modified ziggurat algorithm rather than the polar method described in the super class."

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2566596488

From nbenalla at openjdk.org  Thu Nov 27 00:08:17 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Nov 2025 00:08:17 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>

> Get JDK 27 underway.

Nizar Benalla 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:

 - Update --release 26 symbol information for JDK 26 build 25
   The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
 - revert MAX_COLUMNS to 80
 - Update LATEST_MAJOR_VERSION in Versions.java
 - Merge branch 'master' into start-of-release-27
 - Merge branch 'master' into start-of-release-27
 - Merge branch 'master' into start-of-release-27
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Merge branch 'master' into start-of-release-27
 - update links to JVMS 26 and 27
 - ... and 2 more: https://git.openjdk.org/jdk/compare/53a97205...78895b2b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/3d9eb308..78895b2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=04-05

  Stats: 69573 lines in 1019 files changed: 46890 ins; 15885 del; 6798 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

PR: https://git.openjdk.org/jdk/pull/28130

From nbenalla at openjdk.org  Thu Nov 27 00:27:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Nov 2025 00:27:50 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
Message-ID: <tA5MCownWk5rOgrTIV535ZBZOsTHJU5YeZN6CR41FT4=.332bc50e-a918-4e64-95be-88a141c9593a@github.com>

On Thu, 27 Nov 2025 00:08:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla 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:
> 
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Merge branch 'master' into start-of-release-27
>  - update links to JVMS 26 and 27
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4bfba094...78895b2b

I had to make some changes to respect the 80 character limit we used to have.
Instead of showing a long list for the --release values in the javac help output we show the following:

  --target <release>, -target <release>
        Generate class files suitable for the specified Java SE release.
        Supported releases: 
            8, 9, 10, ..., 25, 26, 27

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28130#issuecomment-3583630744

From iris at openjdk.org  Thu Nov 27 00:37:53 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 27 Nov 2025 00:37:53 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
Message-ID: <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>

On Thu, 27 Nov 2025 00:08:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla 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:
> 
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Merge branch 'master' into start-of-release-27
>  - update links to JVMS 26 and 27
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/a52f9076...78895b2b

The changes in com.sun.tools.javac.main.Option don't appear strictly necessary for the start of release updates...

test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:

> 48: public class HelpOutputColumnWidthTest extends TestRunner {
> 49: 
> 50:     public static final int MAX_COLUMNS = 80;

I though that the default terminal width was 24x80 in most systems, so 84 seems an odd choice.  I agree that 80 seems more appropriate.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3513096801
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2566785560

From iris at openjdk.org  Thu Nov 27 00:37:54 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 27 Nov 2025 00:37:54 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
 <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>
Message-ID: <EZ6E_tH3VAGcKj7bcwIV08SJFx82vCibl-HDKki_sRY=.1ee06657-2d3e-441e-b991-96e5ce3b1b3b@github.com>

On Thu, 27 Nov 2025 00:31:23 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Nizar Benalla 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:
>> 
>>  - Update --release 26 symbol information for JDK 26 build 25
>>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>>  - revert MAX_COLUMNS to 80
>>  - Update LATEST_MAJOR_VERSION in Versions.java
>>  - Merge branch 'master' into start-of-release-27
>>  - Merge branch 'master' into start-of-release-27
>>  - Merge branch 'master' into start-of-release-27
>>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>>  - Merge branch 'master' into start-of-release-27
>>  - update links to JVMS 26 and 27
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/a52f9076...78895b2b
>
> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
> 
>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>> 49: 
>> 50:     public static final int MAX_COLUMNS = 80;
> 
> I though that the default terminal width was 24x80 in most systems, so 84 seems an odd choice.  I agree that 80 seems more appropriate.

oops.. that should have been `80x24`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2566789434

From duke at openjdk.org  Thu Nov 27 00:46:11 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Nov 2025 00:46:11 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID [v2]
In-Reply-To: <Cp7CYDu_RqOwsT680z2DrIp9CP02Rw7oWyAhKrD2PmI=.73bbb410-f076-4055-91be-c07d5051bfca@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
 <Cp7CYDu_RqOwsT680z2DrIp9CP02Rw7oWyAhKrD2PmI=.73bbb410-f076-4055-91be-c07d5051bfca@github.com>
Message-ID: <e9Pyhfln68L-BYQGnvVIwpjOkRwyfuGim2r3rCflGro=.078178d2-ab6d-47ab-95ac-0a6fd4af16a2@github.com>

On Fri, 21 Nov 2025 11:03:43 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spec update

src/java.base/share/classes/java/util/UUID.java line 40:

> 38:  * <p> There exist different variants of these UUIDs.  The methods
> 39:  * of this class are for manipulating the Leach-Salz variant, although the
> 40:  * constructors allow the creation of any variant of UUID (described below).

Something like?this?
Suggestion:

 * <p>This class is primarily designed for manipulating Leach-Salz variant UUIDs,
 * but it also supports the creation of UUIDs of other variants.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28435#discussion_r2566797285

From almatvee at openjdk.org  Thu Nov 27 01:11:26 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 27 Nov 2025 01:11:26 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v4]
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <ydsC7bF6SX7QMTNm0RPBnZbQRep4U9gtII0kKnDtJjw=.8defa925-b9a4-41e5-96fc-860140c5e7f2@github.com>

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8351095: [macos] Add more jpackage tests for --mac-app-store option [v4]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28487/files
  - new: https://git.openjdk.org/jdk/pull/28487/files/f9b89647..777beb55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28487&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28487&range=02-03

  Stats: 8 lines in 2 files changed: 4 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28487/head:pull/28487

PR: https://git.openjdk.org/jdk/pull/28487

From almatvee at openjdk.org  Thu Nov 27 01:11:27 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 27 Nov 2025 01:11:27 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v3]
In-Reply-To: <r9qSnSv8BsJ8hpTHYKzxBX6qO1kqr_WpnGOQ8hqyKsQ=.9ef49375-f04e-42b5-979a-9daa6e7ce6bb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <r9qSnSv8BsJ8hpTHYKzxBX6qO1kqr_WpnGOQ8hqyKsQ=.9ef49375-f04e-42b5-979a-9daa6e7ce6bb@github.com>
Message-ID: <T73nt70B2binHJgJ_VTiLQcvYNsfDDdbIHJTPNMHNUo=.e8fc0c98-d52c-489e-b2fe-f533451fa5c2@github.com>

On Wed, 26 Nov 2025 03:24:30 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Added following tests:
>> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
>> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
>> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351095: [macos] Add more jpackage tests for --mac-app-store option [v3]

8351095: [macos] Add more jpackage tests for --mac-app-store option [v4]
- Removed unnecessary "--mac-app-store" when creating PKG from predefined app image.
- Fixed `cmdlineBooleanOption()` to return `Optional.empty()` is boolean option is not found, so `findAppProperty()` falls back to app image to find option value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28487#issuecomment-3583769864

From asemenyuk at openjdk.org  Thu Nov 27 01:46:27 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 27 Nov 2025 01:46:27 GMT
Subject: RFR: 8372385:
 tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java
 fails
Message-ID: <-9d_tlYTefxcpfDVaCdt-pDtPtGzR4HpcuL7GcyhAEI=.4c9a1426-8188-4396-b49f-9f906a44dcf9@github.com>

Fix MainTest.java to ignore optional environment-specific errors in jpackage's output

-------------

Commit messages:
 - 8372385: tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java fails

Changes: https://git.openjdk.org/jdk/pull/28519/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28519&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372385
  Stats: 59 lines in 1 file changed: 53 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28519.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28519/head:pull/28519

PR: https://git.openjdk.org/jdk/pull/28519

From asemenyuk at openjdk.org  Thu Nov 27 01:47:49 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 27 Nov 2025 01:47:49 GMT
Subject: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store
 option [v4]
In-Reply-To: <ydsC7bF6SX7QMTNm0RPBnZbQRep4U9gtII0kKnDtJjw=.8defa925-b9a4-41e5-96fc-860140c5e7f2@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
 <ydsC7bF6SX7QMTNm0RPBnZbQRep4U9gtII0kKnDtJjw=.8defa925-b9a4-41e5-96fc-860140c5e7f2@github.com>
Message-ID: <bQptH3fHTp_uUph2pCqF7MSqziB2c3wJ9BAbKKDh7Kg=.1b5a9ab9-e9a0-4340-bc1f-7fe28ad8f2f9@github.com>

On Thu, 27 Nov 2025 01:11:26 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Added following tests:
>> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
>> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
>> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351095: [macos] Add more jpackage tests for --mac-app-store option [v4]

Marked as reviewed by asemenyuk (Reviewer).

Looks good. Thank you!

-------------

PR Review: https://git.openjdk.org/jdk/pull/28487#pullrequestreview-3513284422
PR Comment: https://git.openjdk.org/jdk/pull/28487#issuecomment-3583898332

From xgong at openjdk.org  Thu Nov 27 01:50:33 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 27 Nov 2025 01:50:33 GMT
Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java
 implementation
Message-ID: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>

The current subword (`byte`/`short`) gather load API implementation is not well-suited for platforms that provide native vector instructions for these operations. As **discussed in PR [1]**, we'd like to re-implement these APIs with a **unified cross-platform** solution.

The main idea is to re-implement the API at Java-level, by performing multiple sub-gather operations. Each sub-gather operation loads a portion of elements using a specific index vector by calling the HotSpot intrinsic API. The partial results are then merged using vector `slice` and `or` operations. This design simplifies the VM compiler intrinsic implementation and better aligns with the Vector API design principles.

Key changes:
1. Re-implement the subword gather load API at the Java level. The HotSpot intrinsic `VectorSupport.loadWithMap` is simplified by reducing the vector index parameters from four (vix1-vix4) to a single parameter.
2. Adjust the compiler intrinsic implementation to support the new Java API, including updates to the x86 backend implementation.

The performance impact varies across different scenarios on X86. I tested the performance with different AVX levels on an X86 machine that supports AVX512. To achieve optimal performance, I also **applied PR [2]**, which improves the performance of the **`slice()`** API on X86. Following is the summarized performance gains, where:

- "non masked" means the gather operation is not the masked gather API.
- "masked" means the gather operation is the masked gather API.
- "1 gather cases" means the gather API is implemented with a single gather operation. E.g. Load `Short128Vector` with `MaxVectorSize=256`.
- "2 gather cases" means the gather API is implemented with 2 parts of gather operations. E.g. Load `Short256Vector` with `MaxVectorSize=256`.
- "4 gather cases" means the gather API is implemented with 4 parts of gather operations. E.g. Load `Byte256Vector` with `MaxVectorSize=256`.
- "Un-intrinsified" means the gather operation is not supported to be intrinsified by hotspot. E.g. Load `Byte512Vector` with `MaxVectorSize=256`. The singificant performance uplifts comes from the Java-level changes which removes the vector index generation and range checks for such cases.


----------------------------------------------------------------------------
               |          UseAVX=3           |          UseAVX=2           |
               |-----------------------------|-----------------------------|
               |  non masked  |  masked      | non masked   |    masked    |
               |--------------|--------------|--------------|--------------|
1 gather cases | 0.99 ~ 1.06x | 0.94 ~ 1.11x | 0.94 ~ 1.00x | 0.99 ~ 1.11x |
---------------|--------------|--------------|--------------|--------------|
2 gather cases | 0.94 ~ 1.01x | 0.88 ~ 0.97x |  0.8 ~ 1.13x | 0.82 ~ 0.93x |
---------------|--------------|--------------|--------------|--------------|
4 gather cases | 0.92 ~ 0.95x | 0.84 ~ 0.88x | 0.98 ~ 1.06x | 0.81 ~ 0.92x |
---------------|--------------|--------------|--------------|--------------|
Un-intrinsified|     N/A      |     N/A      | 1.48 ~ 1.65x |  1.1 ~ 1.53x |
---------------|--------------|--------------|--------------|--------------|


There are performance regressions especially for APIs that need splitting and merging operations. And the regressions are more significant for the masked cases. This is caused by the additional vector/mask slice and merging operations in Java code, which I think is un-avoidable.

Note-1: Compared with before, this patch **disables** the gather API intrinsification for **64-bit species** when **`MaxVectorSize=8`**, because it would generate a 16-bit vector, which is smaller than the supported minimum vector size of 32-bit. This limitation can be addressed by adjusting the IR pattern in the future. However, this requires significant refactoring of the X86 backend implementation, which is challenging for me. I'd like to leave this as a separate work. And it would be much more helpful if I can get any help from the X86 experts.

Note-2: This patch only includes the refactoring of the Java API code and the HotSpot x86 backend implementation. A follow-up patch will add the support for the AArch64 SVE backend.

[1] https://github.com/openjdk/jdk/pull/26236
[2] https://github.com/openjdk/jdk/pull/24104

-------------

Commit messages:
 - 8372136: VectorAPI: Refactor subword gather load API java implementation

Changes: https://git.openjdk.org/jdk/pull/28520/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28520&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372136
  Stats: 558 lines in 13 files changed: 383 ins; 78 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/28520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28520/head:pull/28520

PR: https://git.openjdk.org/jdk/pull/28520

From xgong at openjdk.org  Thu Nov 27 01:50:33 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 27 Nov 2025 01:50:33 GMT
Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java
 implementation
In-Reply-To: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
References: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
Message-ID: <4dKiP3u-Kcutl_lVtumJdVmeC1r2ZAJR_YQwuE7sxV8=.bd847945-5ce3-4cff-973e-7d4421f837c1@github.com>

On Thu, 27 Nov 2025 01:42:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The current subword (`byte`/`short`) gather load API implementation is not well-suited for platforms that provide native vector instructions for these operations. As **discussed in PR [1]**, we'd like to re-implement these APIs with a **unified cross-platform** solution.
> 
> The main idea is to re-implement the API at Java-level, by performing multiple sub-gather operations. Each sub-gather operation loads a portion of elements using a specific index vector by calling the HotSpot intrinsic API. The partial results are then merged using vector `slice` and `or` operations. This design simplifies the VM compiler intrinsic implementation and better aligns with the Vector API design principles.
> 
> Key changes:
> 1. Re-implement the subword gather load API at the Java level. The HotSpot intrinsic `VectorSupport.loadWithMap` is simplified by reducing the vector index parameters from four (vix1-vix4) to a single parameter.
> 2. Adjust the compiler intrinsic implementation to support the new Java API, including updates to the x86 backend implementation.
> 
> The performance impact varies across different scenarios on X86. I tested the performance with different AVX levels on an X86 machine that supports AVX512. To achieve optimal performance, I also **applied PR [2]**, which improves the performance of the **`slice()`** API on X86. Following is the summarized performance gains, where:
> 
> - "non masked" means the gather operation is not the masked gather API.
> - "masked" means the gather operation is the masked gather API.
> - "1 gather cases" means the gather API is implemented with a single gather operation. E.g. Load `Short128Vector` with `MaxVectorSize=256`.
> - "2 gather cases" means the gather API is implemented with 2 parts of gather operations. E.g. Load `Short256Vector` with `MaxVectorSize=256`.
> - "4 gather cases" means the gather API is implemented with 4 parts of gather operations. E.g. Load `Byte256Vector` with `MaxVectorSize=256`.
> - "Un-intrinsified" means the gather operation is not supported to be intrinsified by hotspot. E.g. Load `Byte512Vector` with `MaxVectorSize=256`. The singificant performance uplifts comes from the Java-level changes which removes the vector index generation and range checks for such cases.
> 
> 
> ----------------------------------------------------------------------------
>                |          UseAVX=3           |          UseAVX=2           |
>                |-----------------------------|-----------------------------|
>                |  non maske...

Following is the performance changes of JMH `org.openjdk.bench.jdk.incubator.vector.GatherOperationsBenchmark` with **-XX:UseAVX=2|3** relatively.

<img width="1768" height="370" alt="image" src="https://github.com/user-attachments/assets/35222e36-ff51-47b3-8012-9bd0aa53770e" />



<img width="1770" height="347" alt="image" src="https://github.com/user-attachments/assets/ac7d4e90-a52c-45a4-9dda-76bc0305f688" />


<img width="1540" height="312" alt="image" src="https://github.com/user-attachments/assets/33c57e08-320d-41ae-9c62-599dca9d8d34" />



<img width="1546" height="354" alt="image" src="https://github.com/user-attachments/assets/4365a079-f49d-4812-9fef-ad65f6aa7872" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28520#issuecomment-3583900604

From asemenyuk at openjdk.org  Thu Nov 27 01:52:47 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 27 Nov 2025 01:52:47 GMT
Subject: RFR: 8372385:
 tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java
 fails
In-Reply-To: <-9d_tlYTefxcpfDVaCdt-pDtPtGzR4HpcuL7GcyhAEI=.4c9a1426-8188-4396-b49f-9f906a44dcf9@github.com>
References: <-9d_tlYTefxcpfDVaCdt-pDtPtGzR4HpcuL7GcyhAEI=.4c9a1426-8188-4396-b49f-9f906a44dcf9@github.com>
Message-ID: <ITrTZ_jRHdhw_WgMkP88zK4LGR5zckLDlifFQ1cm4HI=.8e188e14-74de-4851-bf13-53fc2642777d@github.com>

On Thu, 27 Nov 2025 01:39:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix MainTest.java to ignore optional environment-specific errors in jpackage's output.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28519#issuecomment-3583904689

From almatvee at openjdk.org  Thu Nov 27 01:58:48 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 27 Nov 2025 01:58:48 GMT
Subject: RFR: 8372385:
 tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java
 fails
In-Reply-To: <-9d_tlYTefxcpfDVaCdt-pDtPtGzR4HpcuL7GcyhAEI=.4c9a1426-8188-4396-b49f-9f906a44dcf9@github.com>
References: <-9d_tlYTefxcpfDVaCdt-pDtPtGzR4HpcuL7GcyhAEI=.4c9a1426-8188-4396-b49f-9f906a44dcf9@github.com>
Message-ID: <9WdZ5RaEpWvf6buygwTZobbEJpAnRr5S-5XPr6FsOqs=.b4e94f41-ff7d-4086-aa5f-f0089ef60642@github.com>

On Thu, 27 Nov 2025 01:39:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix MainTest.java to ignore optional environment-specific errors in jpackage's output.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28519#pullrequestreview-3513299674

From xgong at openjdk.org  Thu Nov 27 02:00:48 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 27 Nov 2025 02:00:48 GMT
Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java
 implementation
In-Reply-To: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
References: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
Message-ID: <ihTxWMBxPbgJEy-5BmQOPB-i4L9vv9fIp7KkSnluoZw=.0e6cf73a-e35c-4096-b20e-1c64296126de@github.com>

On Thu, 27 Nov 2025 01:42:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The current subword (`byte`/`short`) gather load API implementation is not well-suited for platforms that provide native vector instructions for these operations. As **discussed in PR [1]**, we'd like to re-implement these APIs with a **unified cross-platform** solution.
> 
> The main idea is to re-implement the API at Java-level, by performing multiple sub-gather operations. Each sub-gather operation loads a portion of elements using a specific index vector by calling the HotSpot intrinsic API. The partial results are then merged using vector `slice` and `or` operations. This design simplifies the VM compiler intrinsic implementation and better aligns with the Vector API design principles.
> 
> Key changes:
> 1. Re-implement the subword gather load API at the Java level. The HotSpot intrinsic `VectorSupport.loadWithMap` is simplified by reducing the vector index parameters from four (vix1-vix4) to a single parameter.
> 2. Adjust the compiler intrinsic implementation to support the new Java API, including updates to the x86 backend implementation.
> 
> The performance impact varies across different scenarios on X86. I tested the performance with different AVX levels on an X86 machine that supports AVX512. To achieve optimal performance, I also **applied PR [2]**, which improves the performance of the **`slice()`** API on X86. Following is the summarized performance gains, where:
> 
> - "non masked" means the gather operation is not the masked gather API.
> - "masked" means the gather operation is the masked gather API.
> - "1 gather cases" means the gather API is implemented with a single gather operation. E.g. Load `Short128Vector` with `MaxVectorSize=256`.
> - "2 gather cases" means the gather API is implemented with 2 parts of gather operations. E.g. Load `Short256Vector` with `MaxVectorSize=256`.
> - "4 gather cases" means the gather API is implemented with 4 parts of gather operations. E.g. Load `Byte256Vector` with `MaxVectorSize=256`.
> - "Un-intrinsified" means the gather operation is not supported to be intrinsified by hotspot. E.g. Load `Byte512Vector` with `MaxVectorSize=256`. The singificant performance uplifts comes from the Java-level changes which removes the vector index generation and range checks for such cases.
> 
> 
> ----------------------------------------------------------------------------
>                |          UseAVX=3           |          UseAVX=2           |
>                |-----------------------------|-----------------------------|
>                |  non maske...

Hi @iwanowww , @PaulSandoz , @sviswa7, @jatin-bhateja, this is a refactoring patch for subword gather-load APIs together with the X86 changes as we discussed in https://github.com/openjdk/jdk/pull/26236.  Could you please help take a look?

Since I'm not quite familiar with X86 instructions, any feedback or help from @sviswa7 or @jatin-bhateja would be much helpful.  There are performance regressions with current version, but I think it still has improvement opportunities for the X86 codegen. Hence, I'd appreciate for any help on that!

Thanks a lot in advance!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28520#issuecomment-3583917222

From jpai at openjdk.org  Thu Nov 27 02:06:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 02:06:46 GMT
Subject: RFR: 8372609: Bug4944439 does not enforce locale correctly
In-Reply-To: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>
References: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>
Message-ID: <yyONkLjis2_LeLcXF7OgwPjhJV4gdo46lWsySE76qGQ=.cbf5aff4-1a6c-440a-9584-6f0b44c1c67d@github.com>

On Wed, 26 Nov 2025 18:35:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes a test bug where a `DecimalFormat` is instantiated in a static field (with the current default locale) before the test updates the system default to `Locale.US`. As a result, it may fail under various other locales, since a `Locale.US` configured `DecimalFormat` is not actually retrieved and the test expects one.
> 
> In general, the preservation and restoring of the system locale is an obsolete process. The test is instead updated to just retrieve a `DecimalFormat` using a locale accepting factory method.
> 
> I have manually confirmed that the tests passes with `-Duser.language=en -Duser.country=NL` on my machine, (which is the locale used in the reproducer).

Hello Justin, the change looks reasonable to me. I'm guessing the call to `NumberFormat.getInstance(...)` would still return and exercise a `DecimalFormat` instance, and thus the original intent of the test for JDK-4944439 would be preserved?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28514#pullrequestreview-3513312964

From nbenalla at openjdk.org  Thu Nov 27 02:25:47 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Nov 2025 02:25:47 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <EZ6E_tH3VAGcKj7bcwIV08SJFx82vCibl-HDKki_sRY=.1ee06657-2d3e-441e-b991-96e5ce3b1b3b@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
 <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>
 <EZ6E_tH3VAGcKj7bcwIV08SJFx82vCibl-HDKki_sRY=.1ee06657-2d3e-441e-b991-96e5ce3b1b3b@github.com>
Message-ID: <UpXYpfEPhm4i1vBqS1gz9G8gDd3YOXnh_5vCaBknMpA=.41bb620e-3db9-43a1-8c58-2e8711003476@github.com>

On Thu, 27 Nov 2025 00:35:11 GMT, Iris Clark <iris at openjdk.org> wrote:

>> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
>> 
>>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>>> 49: 
>>> 50:     public static final int MAX_COLUMNS = 80;
>> 
>> I though that the default terminal width was 24x80 in most systems, so 84 seems an odd choice.  I agree that 80 seems more appropriate.
>
> oops.. that should have been `80x24`.

I should have included more [context](https://github.com/openjdk/jdk/pull/25008#discussion_r2071880549).
The default width was increased to 84 in the last start of release update, I reverted it back to the original value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2566979887

From almatvee at openjdk.org  Thu Nov 27 03:08:56 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 27 Nov 2025 03:08:56 GMT
Subject: Integrated: 8351095: [macos] Add more jpackage tests for
 --mac-app-store option
In-Reply-To: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
References: <EfDxo7H2e5DSCJ23Ke_38cf79WQPXRAvVPDk5MMHxPc=.fd8d8572-d25e-4598-acdb-c8cb491d4dcb@github.com>
Message-ID: <UhhMqdMzahxba7sok6zNZqKqa6cIPvxl101qMiDrS0Y=.ef550105-0293-4b24-be48-cfd50f668d5d@github.com>

On Tue, 25 Nov 2025 03:58:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Added following tests:
> - Verify mac app store PKG doesn't have scripts (added to `PkgScriptsTest.java`).
> - `--launcher-as-service` ignored for mac app store PKG  (added to `ServiceTest.java`).
> - `--launcher-as-service` for additional launcher ignored for mac app store PKG (added to `ServiceTest.java`).

This pull request has now been integrated.

Changeset: b054a565
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b054a5657105ace7e66f6044692e14bb075dfb6c
Stats:     66 lines in 5 files changed: 41 ins; 1 del; 24 mod

8351095: [macos] Add more jpackage tests for --mac-app-store option

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/28487

From asemenyuk at openjdk.org  Thu Nov 27 04:20:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 27 Nov 2025 04:20:54 GMT
Subject: Integrated: 8372385:
 tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java
 fails
In-Reply-To: <-9d_tlYTefxcpfDVaCdt-pDtPtGzR4HpcuL7GcyhAEI=.4c9a1426-8188-4396-b49f-9f906a44dcf9@github.com>
References: <-9d_tlYTefxcpfDVaCdt-pDtPtGzR4HpcuL7GcyhAEI=.4c9a1426-8188-4396-b49f-9f906a44dcf9@github.com>
Message-ID: <DBDJmHCpqp3v9Gjxples3GvpqbYyche-2t0VidenBQ4=.80709d76-bcc9-4e24-b96f-fa2eb791361f@github.com>

On Thu, 27 Nov 2025 01:39:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix MainTest.java to ignore optional environment-specific errors in jpackage's output.

This pull request has now been integrated.

Changeset: 55362e19
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55362e191d447c2116f111cef438700eca24aab1
Stats:     59 lines in 1 file changed: 53 ins; 0 del; 6 mod

8372385: tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java fails

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28519

From duke at openjdk.org  Thu Nov 27 04:54:56 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Thu, 27 Nov 2025 04:54:56 GMT
Subject: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place [v4]
In-Reply-To: <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
 <8nUBgMWXuesE-iMD1wy7hwWiI2_ekA-KZFWRZoEfFJo=.4eb83f36-f6c8-4ea7-8a73-3d3ae88ba951@github.com>
Message-ID: <0d-nB72go_67k_f2Hk3owDj18Yw92zJrOkcPGB14Thw=.a5c2da63-c272-4904-90a4-2ea6b545927b@github.com>

On Tue, 25 Nov 2025 04:26:08 GMT, Steve Armstrong <duke at openjdk.org> wrote:

>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
>> 
>> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
>> 
>> Changes:
>> - Added new FieldUpdaterUtil class with static utility methods:
>>   * validateField() - validates field type, volatile, and static checks
>>   * computeAccessClass() - determines correct class for access checks
>>   * isSamePackage() - checks if two classes are in same package
>>   * isAncestor() - checks classloader delegation chain
>> 
>> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>>   * Simplified constructor to use validateField() and computeAccessClass()
>>   * Removed duplicate isAncestor() and isSamePackage() methods
>> 
>> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.
>
> Steve Armstrong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix try-catch block to not wrap IllegalArgumentException
>   
>   The validation exceptions should be thrown directly to the caller,
>   not wrapped in RuntimeException. Only the field lookup and access
>   checking code should be in the try-catch block.

Thank you everyone for sharing your inputs and for this detailed discussion. It was very informative. I will close this PR in that case even if the deprecation is not imminent. And I think deprecating such stable APIs is more of a team effort beyond my scope as a new contributor with lots of signoffs from different stakeholders. Thank you once again for taking the time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3584197028

From duke at openjdk.org  Thu Nov 27 04:54:58 2025
From: duke at openjdk.org (Steve Armstrong)
Date: Thu, 27 Nov 2025 04:54:58 GMT
Subject: Withdrawn: 8364544: Extract the checks of AtomicXxxFieldUpdater into a
 common place
In-Reply-To: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
References: <xpm6WKmMtIttUdWCiuKpP54ZGHnYN8Ma7dJAbg5A3F0=.b2727796-603a-42a0-a81e-16d087515ab0@github.com>
Message-ID: <FlbnN1yqaL8fTmraj83QwUuf_2lzCkXpiZUS1NYgrJM=.4addaf06-bca8-422b-ac64-025fab71e68f@github.com>

On Sat, 22 Nov 2025 07:37:01 GMT, Steve Armstrong <duke at openjdk.org> wrote:

> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate field validation and access checking logic in their constructors and helper methods.
> 
> This change extracts the common validation and utility methods into a new package-private class FieldUpdaterUtil to eliminate code duplication and improve maintainability.
> 
> Changes:
> - Added new FieldUpdaterUtil class with static utility methods:
>   * validateField() - validates field type, volatile, and static checks
>   * computeAccessClass() - determines correct class for access checks
>   * isSamePackage() - checks if two classes are in same package
>   * isAncestor() - checks classloader delegation chain
> 
> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil
>   * Simplified constructor to use validateField() and computeAccessClass()
>   * Removed duplicate isAncestor() and isSamePackage() methods
> 
> Existing tests in test/jdk/java/util/concurrent/tck and test/jdk/java/util/concurrent/atomic verify that the refactoring preserves the original behavior.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/28464

From alanb at openjdk.org  Thu Nov 27 07:55:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Nov 2025 07:55:50 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v3]
In-Reply-To: <gorB3SZQego7xgJXT1UDtvP6pUtOQjbEIe7xVxTQW3E=.c7a90086-e5d8-473e-8e74-dbe515d3e08f@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <gorB3SZQego7xgJXT1UDtvP6pUtOQjbEIe7xVxTQW3E=.c7a90086-e5d8-473e-8e74-dbe515d3e08f@github.com>
Message-ID: <Kr11Qe1wtlgoJWKTzMWPAf1hO28TU--V3L5zTcE8ypU=.2687e33d-dade-4529-8b19-42c6c0692805@github.com>

On Wed, 26 Nov 2025 22:08:14 GMT, James Yuzawa <duke at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>   
>   Fix Javadoc

Thanks for the updates, I think this looks okay now.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 920:

> 918:      */
> 919:     default double nextGaussian() {
> 920:         // See Knuth, TAOCP, Vol. 2, 3rd edition, Section 3.4.1 Algorithm C.

Can you update the copyright header on this file to 2025.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28483#pullrequestreview-3513891235
PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2567479065

From alanb at openjdk.org  Thu Nov 27 08:00:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Nov 2025 08:00:53 GMT
Subject: RFR: 8321283: Reuse StringLatin1::equals in regionMatches
In-Reply-To: <UofYm5TPDXjsmRaFIlcyZeGVWRfzFfrflpYqnECl_Y8=.0117ab2d-aaf8-4f66-9139-20ffcda50d17@github.com>
References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com>
 <UofYm5TPDXjsmRaFIlcyZeGVWRfzFfrflpYqnECl_Y8=.0117ab2d-aaf8-4f66-9139-20ffcda50d17@github.com>
Message-ID: <VySsVSm3hLh-UC7-YPfL1iWwBehkZLMpwTVuk5SVSFE=.4e6fac6e-4588-4bd9-9cec-389e455dde4c@github.com>

On Wed, 26 Nov 2025 21:38:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>  Please merge with master to get an up-to-date PR. It might be cleaner to close this PR and start fresh. Also, please reconfirm the performance numbers. Thanks

Yes, it looks this branch is nearly 2 years behind mainline so very important to sync up and refresh performance results.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-3584587964

From alanb at openjdk.org  Thu Nov 27 08:44:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Nov 2025 08:44:51 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v16]
In-Reply-To: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com>
Message-ID: <Qp19PLUPK6znOZ5pHd57SiyddYiPHdJ7cq9Cs6_7Q3Y=.3d429ac5-55c7-4903-b52c-f08f0cdc4a54@github.com>

On Wed, 26 Nov 2025 19:50:09 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Escape regex in properties.

good work

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28359#pullrequestreview-3514071881

From cushon at openjdk.org  Thu Nov 27 09:41:35 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 27 Nov 2025 09:41:35 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v14]
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <ZtWwCAIUAkk6SyaDSriObADWnnwkw3RnxUsE2va8t1s=.5bd15610-285e-4748-8f4e-d7b96745c3aa@github.com>

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge commit 'f94644999766e752f7d60ce52c14a7db79005035^' into JDK-8328821-make-clear-consistent
 - Add an implementation comment to AbstractImmutableMap
 - Update for Stable Values
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Update test/jdk/java/util/Collection/MOAT.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Update copyright year
   
   and add the bug number to the modified test
 - Update unmodifiable map javadoc
 - ... and 8 more: https://git.openjdk.org/jdk/compare/df5b105b...ab5dab9a

-------------

Changes: https://git.openjdk.org/jdk/pull/18522/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=13
  Stats: 120 lines in 3 files changed: 114 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522

PR: https://git.openjdk.org/jdk/pull/18522

From vklang at openjdk.org  Thu Nov 27 09:46:10 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 27 Nov 2025 09:46:10 GMT
Subject: Integrated: 8371740 : LinkedTransferQueue.poll() returns null even
 though queue is not empty
In-Reply-To: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
References: <reWhCb1lJ44X_VscPtOQ9_RzjFD0xf-edomhfMixR9s=.d7de3ef4-72cf-45c4-876f-7e134b659306@github.com>
Message-ID: <B4vAkkcrqR1CnRN2ClBPENO6ibUwxwQsUQS8OfYft2Y=.61e06a57-9b90-454e-a68f-04e010794055@github.com>

On Mon, 24 Nov 2025 17:31:20 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adds the patch by @DougLea

This pull request has now been integrated.

Changeset: d350158e
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d350158e060c01acf49759dcbdd1f4d72530111b
Stats:     87 lines in 2 files changed: 80 ins; 0 del; 7 mod

8371740: LinkedTransferQueue.poll() returns null even though queue is not empty

Co-authored-by: Doug Lea <dl at openjdk.org>
Co-authored-by: Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/28479

From jpai at openjdk.org  Thu Nov 27 09:59:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 09:59:52 GMT
Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option
 correctly [v16]
In-Reply-To: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com>
References: <NmDgz-9xiElunuEo7kCfQPYC5T8R2OmkIRoOWRdKG8w=.7119e56a-5b70-4ed8-8bff-b8cda78cb09e@github.com>
 <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com>
Message-ID: <3ChoMkdCWTMqPPpKsqq6hyYYlNLKJx_5npa4_eJCdMw=.1dced7c7-28af-4c10-a233-c1e1b46b6412@github.com>

On Wed, 26 Nov 2025 19:50:09 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Escape regex in properties.

The latest changes in `41c291b4` look good to me. Thank you for addressing this issue and the patience during the reviews.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28359#pullrequestreview-3514370302

From rgiulietti at openjdk.org  Thu Nov 27 11:03:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 27 Nov 2025 11:03:51 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v3]
In-Reply-To: <gorB3SZQego7xgJXT1UDtvP6pUtOQjbEIe7xVxTQW3E=.c7a90086-e5d8-473e-8e74-dbe515d3e08f@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <gorB3SZQego7xgJXT1UDtvP6pUtOQjbEIe7xVxTQW3E=.c7a90086-e5d8-473e-8e74-dbe515d3e08f@github.com>
Message-ID: <Vxg60nWdGL9-ulD5CvyVGe2-8YKv56C8hXQxqBNbEnM=.04c7004a-32b5-4eca-a7d4-01ebbe30b738@github.com>

On Wed, 26 Nov 2025 22:08:14 GMT, James Yuzawa <duke at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>   
>   Fix Javadoc

Thanks @yuzawa-san, looks good.

@yuzawa-san As suggested by @AlanBateman, please update the 2nd copyright year on L.2 of `RandomGenerator`

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28483#pullrequestreview-3514625894
PR Comment: https://git.openjdk.org/jdk/pull/28483#issuecomment-3585254300

From galder at openjdk.org  Thu Nov 27 11:04:59 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 27 Nov 2025 11:04:59 GMT
Subject: RFR: 8372119: Missing copyright header in MinMaxVector
In-Reply-To: <T3rigtgg__HkUqLPXpvfSr8-OCwSXbuPl8b05hxXRIc=.0f54d739-6412-43a6-b7d5-c03ac3b4dbd2@github.com>
References: <QgQzaCpP8hWV8jnYHb-asJJFASYygMjGdiZdwEJ-0pg=.8671d8ed-82ae-4fc8-ba3f-02966666fc28@github.com>
 <T3rigtgg__HkUqLPXpvfSr8-OCwSXbuPl8b05hxXRIc=.0f54d739-6412-43a6-b7d5-c03ac3b4dbd2@github.com>
Message-ID: <DpNdn6vPolDWEcMV2LHaO17Vk43xXf289Ybx2KfzZ8s=.9f0c5e54-cbce-4e06-ae48-9feb16dc12cc@github.com>

On Wed, 19 Nov 2025 14:30:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Trivial PR to add missing copyright header in JMH benchmark.
>
> Looks good to me too.

Thanks @TobiHartmann @chhagedorn @jerboaa

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28387#issuecomment-3585257112

From alanb at openjdk.org  Thu Nov 27 11:14:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Nov 2025 11:14:19 GMT
Subject: RFR: 8371815: API docs for 2-arg StructuredTaskScope.open should say
 timeout may expire before or while waiting in join
Message-ID: <2pc-IGQH8AXXacp_cA-5jpU4gugEZUet_qFBoZ7WHTY=.85b2b795-0f46-4736-a4df-ccdb3950d5a1@github.com>

The 2-arg STS.open method currently has "If the timeout expires before the scope has joined", it should say "If the timeout expires before or while waiting in join". The update brings this sentence into line with the same phrase used in other places in the API docs that speak of timeouts.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/28526/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28526&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371815
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28526/head:pull/28526

PR: https://git.openjdk.org/jdk/pull/28526

From vklang at openjdk.org  Thu Nov 27 12:19:47 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 27 Nov 2025 12:19:47 GMT
Subject: RFR: 8371815: API docs for 2-arg StructuredTaskScope.open should
 say timeout may expire before or while waiting in join
In-Reply-To: <2pc-IGQH8AXXacp_cA-5jpU4gugEZUet_qFBoZ7WHTY=.85b2b795-0f46-4736-a4df-ccdb3950d5a1@github.com>
References: <2pc-IGQH8AXXacp_cA-5jpU4gugEZUet_qFBoZ7WHTY=.85b2b795-0f46-4736-a4df-ccdb3950d5a1@github.com>
Message-ID: <hl4C-eLRSAYIXXIhwiv7PJB82Q0pkxBzzVJUDTXtEhg=.3abb934b-3818-445a-86a4-561bb4627b14@github.com>

On Thu, 27 Nov 2025 08:34:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The 2-arg STS.open method currently has "If the timeout expires before the scope has joined", it should say "If the timeout expires before or while waiting in join". The update brings this sentence into line with the same phrase used in other places in the API docs that speak of timeouts.

Much clearer, thanks Alan

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28526#pullrequestreview-3514991419

From duke at openjdk.org  Thu Nov 27 13:30:06 2025
From: duke at openjdk.org (James Yuzawa)
Date: Thu, 27 Nov 2025 13:30:06 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v4]
In-Reply-To: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
Message-ID: <TY6R7UuoLXLsAV-pteUWx238zfz8adDYJQnGl3gLohM=.35f2c6cd-9da8-450d-bf22-13e0b404ebea@github.com>

> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
> 
> Here is a very simple reproducer:
> 
> ThreadLocalRandom r = ThreadLocalRandom.current();
> // step into this call using a debugger
> r.nextGaussian();
> 
> 
> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
> 
> Sketch:
> 
> public interface RandomGenerator {
> 	default double nextGaussian() {
> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> public class Random implements RandomGenerator {
> 	@Override
> 	public synchronized double nextGaussian() {
> 		// synchronized version ...
> 	}
> }
> 
> public class ThreadLocalRandom extends Random {
> 
> 	// ADD THIS
> 	@Override
> 	public double nextGaussian() {
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> 
> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
> 
> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
> 
> 
> Set<String> tlrMethods = new HashSet<>();
> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		tlrMethods.add(desc);
> 	}
> }
> for (Method method : java.util.Random.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		if (!tlrMethods.contains(desc)) {
> 			System.out.println(desc);
> 		}
> 	}
> }
> 
> 
> That prints
> 
> void nextBytes [byte[] arg0]
> double nextGaussian []
> 
> 
> The former safely calls `Thread...

James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:

  8372134: ThreadLocalRandom no longer overrides nextGaussian
  
  Update copyright header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28483/files
  - new: https://git.openjdk.org/jdk/pull/28483/files/54228b28..57d0d4f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28483&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28483&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28483/head:pull/28483

PR: https://git.openjdk.org/jdk/pull/28483

From duke at openjdk.org  Thu Nov 27 13:30:08 2025
From: duke at openjdk.org (James Yuzawa)
Date: Thu, 27 Nov 2025 13:30:08 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v4]
In-Reply-To: <Kr11Qe1wtlgoJWKTzMWPAf1hO28TU--V3L5zTcE8ypU=.2687e33d-dade-4529-8b19-42c6c0692805@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <gorB3SZQego7xgJXT1UDtvP6pUtOQjbEIe7xVxTQW3E=.c7a90086-e5d8-473e-8e74-dbe515d3e08f@github.com>
 <Kr11Qe1wtlgoJWKTzMWPAf1hO28TU--V3L5zTcE8ypU=.2687e33d-dade-4529-8b19-42c6c0692805@github.com>
Message-ID: <CFhlx7kIBDieiR965m1b9vuqyVVHSzCs-3_NmBgWpnc=.ba7bd246-96fd-446a-af16-8599db0d5917@github.com>

On Thu, 27 Nov 2025 07:47:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>>   
>>   Update copyright header
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 920:
> 
>> 918:      */
>> 919:     default double nextGaussian() {
>> 920:         // See Knuth, TAOCP, Vol. 2, 3rd edition, Section 3.4.1 Algorithm C.
> 
> Can you update the copyright header on this file to 2025.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2568679860

From vklang at openjdk.org  Thu Nov 27 13:32:18 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 27 Nov 2025 13:32:18 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v4]
In-Reply-To: <TY6R7UuoLXLsAV-pteUWx238zfz8adDYJQnGl3gLohM=.35f2c6cd-9da8-450d-bf22-13e0b404ebea@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <TY6R7UuoLXLsAV-pteUWx238zfz8adDYJQnGl3gLohM=.35f2c6cd-9da8-450d-bf22-13e0b404ebea@github.com>
Message-ID: <NI9j1mkSkV4qP70tHHtDLxvZasA_nezcrZCaBFmo89c=.0e659177-1bf2-4ad7-8717-a4e1b6951364@github.com>

On Thu, 27 Nov 2025 13:30:06 GMT, James Yuzawa <duke at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>   
>   Update copyright header

src/java.base/share/classes/java/util/random/RandomGenerator.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2024, 2025 Oracle and/or its affiliates. All rights reserved.

Format looks like this:

Suggestion:

 * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2568690365

From mcimadamore at openjdk.org  Thu Nov 27 13:37:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 27 Nov 2025 13:37:53 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v14]
In-Reply-To: <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>
Message-ID: <jli3PLAA8xuZDQWLfy-bazPPJlKmJQimN5tJ04XMOQg=.281c4f3d-1f81-46b7-a6ca-1e1017ced054@github.com>

On Tue, 25 Nov 2025 19:10:25 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Looks good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3515409304

From duke at openjdk.org  Thu Nov 27 13:46:19 2025
From: duke at openjdk.org (James Yuzawa)
Date: Thu, 27 Nov 2025 13:46:19 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v5]
In-Reply-To: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
Message-ID: <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>

> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
> 
> Here is a very simple reproducer:
> 
> ThreadLocalRandom r = ThreadLocalRandom.current();
> // step into this call using a debugger
> r.nextGaussian();
> 
> 
> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
> 
> Sketch:
> 
> public interface RandomGenerator {
> 	default double nextGaussian() {
> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> public class Random implements RandomGenerator {
> 	@Override
> 	public synchronized double nextGaussian() {
> 		// synchronized version ...
> 	}
> }
> 
> public class ThreadLocalRandom extends Random {
> 
> 	// ADD THIS
> 	@Override
> 	public double nextGaussian() {
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> 
> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
> 
> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
> 
> 
> Set<String> tlrMethods = new HashSet<>();
> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		tlrMethods.add(desc);
> 	}
> }
> for (Method method : java.util.Random.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		if (!tlrMethods.contains(desc)) {
> 			System.out.println(desc);
> 		}
> 	}
> }
> 
> 
> That prints
> 
> void nextBytes [byte[] arg0]
> double nextGaussian []
> 
> 
> The former safely calls `Thread...

James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:

  8372134: ThreadLocalRandom no longer overrides nextGaussian
  
  Update copyright header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28483/files
  - new: https://git.openjdk.org/jdk/pull/28483/files/57d0d4f7..502bbe9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28483&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28483&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28483/head:pull/28483

PR: https://git.openjdk.org/jdk/pull/28483

From rgiulietti at openjdk.org  Thu Nov 27 13:46:20 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 27 Nov 2025 13:46:20 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v5]
In-Reply-To: <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
Message-ID: <Ib6Sr3Q8qHJMowdgicSbilrMN25Sci9PZtG-VMZqdvA=.f47cdff5-08f5-41e0-bc5f-478d8f2d110d@github.com>

On Thu, 27 Nov 2025 13:43:12 GMT, James Yuzawa <duke at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>   
>   Update copyright header

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28483#pullrequestreview-3515438843

From duke at openjdk.org  Thu Nov 27 13:46:23 2025
From: duke at openjdk.org (James Yuzawa)
Date: Thu, 27 Nov 2025 13:46:23 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v4]
In-Reply-To: <NI9j1mkSkV4qP70tHHtDLxvZasA_nezcrZCaBFmo89c=.0e659177-1bf2-4ad7-8717-a4e1b6951364@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <TY6R7UuoLXLsAV-pteUWx238zfz8adDYJQnGl3gLohM=.35f2c6cd-9da8-450d-bf22-13e0b404ebea@github.com>
 <NI9j1mkSkV4qP70tHHtDLxvZasA_nezcrZCaBFmo89c=.0e659177-1bf2-4ad7-8717-a4e1b6951364@github.com>
Message-ID: <wjHI-L2uf2MhSp8RK6pKx9WVYVeJ_efjSVMXCLzrJ4o=.64185ac4-938c-4de8-8ef0-5efe88cf5c35@github.com>

On Thu, 27 Nov 2025 13:28:48 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>>   
>>   Update copyright header
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2024, 2025 Oracle and/or its affiliates. All rights reserved.
> 
> Format looks like this:
> 
> Suggestion:
> 
>  * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2568736744

From alanb at openjdk.org  Thu Nov 27 13:51:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Nov 2025 13:51:56 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v5]
In-Reply-To: <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
Message-ID: <R6hMgVehjAO-0IjXu4HjcLZTY6Hc6CYu2W8ad6bwI9k=.3d7c1ac9-b101-4ed2-a91a-2d0a2373b56b@github.com>

On Thu, 27 Nov 2025 13:46:19 GMT, James Yuzawa <duke at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>   
>   Update copyright header

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28483#pullrequestreview-3515483203

From cushon at openjdk.org  Thu Nov 27 14:14:10 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 27 Nov 2025 14:14:10 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v15]
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <GGb9gfpRGdnyxJ2eMQ3RoEQBdB89rmML6STmocdtWT4=.33561c50-4b8a-463b-8657-6e8872c9a7c1@github.com>

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into JDK-8328821-make-clear-consistent
 - Merge commit 'f94644999766e752f7d60ce52c14a7db79005035' into JDK-8328821-make-clear-consistent
 - Merge commit 'f94644999766e752f7d60ce52c14a7db79005035^' into JDK-8328821-make-clear-consistent
 - Add an implementation comment to AbstractImmutableMap
 - Update for Stable Values
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Update test/jdk/java/util/Collection/MOAT.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - ... and 10 more: https://git.openjdk.org/jdk/compare/86aae125...f113d6ab

-------------

Changes: https://git.openjdk.org/jdk/pull/18522/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=14
  Stats: 91 lines in 3 files changed: 85 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522

PR: https://git.openjdk.org/jdk/pull/18522

From cushon at openjdk.org  Thu Nov 27 14:14:13 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 27 Nov 2025 14:14:13 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v14]
In-Reply-To: <ZtWwCAIUAkk6SyaDSriObADWnnwkw3RnxUsE2va8t1s=.5bd15610-285e-4748-8f4e-d7b96745c3aa@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <ZtWwCAIUAkk6SyaDSriObADWnnwkw3RnxUsE2va8t1s=.5bd15610-285e-4748-8f4e-d7b96745c3aa@github.com>
Message-ID: <e1-QRqttct_ttXtNAgQpMPUtXq4eJRC0fDyE5-toBps=.d0673956-6479-4f98-986f-bd4ee8d19164@github.com>

On Thu, 27 Nov 2025 09:41:35 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge commit 'f94644999766e752f7d60ce52c14a7db79005035^' into JDK-8328821-make-clear-consistent
>  - Add an implementation comment to AbstractImmutableMap
>  - Update for Stable Values
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Update test/jdk/java/util/Collection/MOAT.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Update copyright year
>    
>    and add the bug number to the modified test
>  - Update unmodifiable map javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/df5b105b...ab5dab9a

I resolve some merge conflicts with JEP 526. The previous JEP 502 implementation needed some changes here to ensure the derived view collections throw UOE, for JEP 526 it looks like that was fixed and no changes are necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-3586075463

From alanb at openjdk.org  Thu Nov 27 14:19:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Nov 2025 14:19:59 GMT
Subject: Integrated: 8371815: API docs for 2-arg StructuredTaskScope.open
 should say timeout may expire before or while waiting in join
In-Reply-To: <2pc-IGQH8AXXacp_cA-5jpU4gugEZUet_qFBoZ7WHTY=.85b2b795-0f46-4736-a4df-ccdb3950d5a1@github.com>
References: <2pc-IGQH8AXXacp_cA-5jpU4gugEZUet_qFBoZ7WHTY=.85b2b795-0f46-4736-a4df-ccdb3950d5a1@github.com>
Message-ID: <vgNsbp2l3zcilKdOOLkYMiyoEuCDatkQMAtHY5RgENk=.f1fcfa83-4c4f-43e1-93a8-43cd0cacc9ed@github.com>

On Thu, 27 Nov 2025 08:34:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The 2-arg STS.open method currently has "If the timeout expires before the scope has joined", it should say "If the timeout expires before or while waiting in join". The update brings this sentence into line with the same phrase used in other places in the API docs that speak of timeouts.

This pull request has now been integrated.

Changeset: 6901c05c
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6901c05c9d23cde41e2af510e7d610af66e40770
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8371815: API docs for 2-arg StructuredTaskScope.open should say timeout may expire before or while waiting in join

Reviewed-by: vklang

-------------

PR: https://git.openjdk.org/jdk/pull/28526

From vklang at openjdk.org  Thu Nov 27 14:27:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 27 Nov 2025 14:27:55 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v5]
In-Reply-To: <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
Message-ID: <qjevQbrz6NkV9wqptJ0ySexG8GkT0fN0o9Jt94-En6s=.31f85239-34e1-4f42-89da-753c9b214f57@github.com>

On Thu, 27 Nov 2025 13:46:19 GMT, James Yuzawa <duke at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>   
>   Update copyright header

Thanks for doing this, @yuzawa-san!

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28483#pullrequestreview-3515702055

From vklang at openjdk.org  Thu Nov 27 15:53:02 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 27 Nov 2025 15:53:02 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v22]
In-Reply-To: <-kNPwoBvq5APFT98rnravszAH2whbEnsxzLLgQWhMd8=.751f5a71-b68a-45ae-9535-ebade756b685@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <-kNPwoBvq5APFT98rnravszAH2whbEnsxzLLgQWhMd8=.751f5a71-b68a-45ae-9535-ebade756b685@github.com>
Message-ID: <o7lQ_UAp-iYLBTfKLeA5g3zyM6_0DOoGOMLXx2597hU=.d2ef3aa1-e094-480d-8e97-2324cd43af07@github.com>

On Wed, 26 Nov 2025 15:35:13 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   For testing

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1435:

> 1433:          */
> 1434:         final void topLevelExec(ForkJoinTask<?> task, int cfg) {
> 1435:             int fifo = cfg & FIFO, clr = cfg & CLEAR_TLS;

@DougLea `clr` isn't used (so there's no clearing of TLs)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2569349951

From liach at openjdk.org  Thu Nov 27 16:23:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Nov 2025 16:23:21 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field
 trusting
Message-ID: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>

Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.

They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.

We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.

Paging @minborg who requested Optional folding for review.

I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

-------------

Commit messages:
 - Spurious change
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
 - Issue number and test update
 - Fixed optional and unit test
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
 - Stage

Changes: https://git.openjdk.org/jdk/pull/28540/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372696
  Stats: 183 lines in 13 files changed: 169 ins; 13 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540

PR: https://git.openjdk.org/jdk/pull/28540

From liach at openjdk.org  Thu Nov 27 16:27:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Nov 2025 16:27:52 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <uuPHSGfRVckl3j5nRrikwU5eTwVjMhRrgiqB2RxKZBk=.91ecc1c8-cbed-45fb-be56-7900f23fc1ac@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

This uses another one of the 16-bit instanceKlassFlags, which requires runtime engineers to agree. Need compiler review to check if such IR tests are the best way to ensure constant folding for core library classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3586679853

From duke at openjdk.org  Thu Nov 27 16:35:57 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Nov 2025 16:35:57 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v5]
In-Reply-To: <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
Message-ID: <OkAg78z6PegvhxzNyCPjQeL4KxXacVl6IVGsWHs2Ffw=.3eb90c20-56c1-448d-ba44-d9dc235ece31@github.com>

On Thu, 27 Nov 2025 13:46:19 GMT, James Yuzawa <duke at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>   
>   Update copyright header

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 2:

> 1: /*
> 2:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

This?file should?probably also?have the?year?line before?this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2569483682

From jvernee at openjdk.org  Thu Nov 27 16:50:48 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Nov 2025 16:50:48 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <0f6w-e-F6PVzyBNmFsu37oNVKgKSxNwQMfA1Y2GC46c=.d196d665-deeb-432c-b089-a4f5494b44ec@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3516377492

From alanb at openjdk.org  Thu Nov 27 16:58:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Nov 2025 16:58:50 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v5]
In-Reply-To: <OkAg78z6PegvhxzNyCPjQeL4KxXacVl6IVGsWHs2Ffw=.3eb90c20-56c1-448d-ba44-d9dc235ece31@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
 <OkAg78z6PegvhxzNyCPjQeL4KxXacVl6IVGsWHs2Ffw=.3eb90c20-56c1-448d-ba44-d9dc235ece31@github.com>
Message-ID: <loQYHODmgFlmHFO1UdYG0l0PMS3mwqErB23x9BeeTqo=.c804a662-b6c2-4436-8c78-9c901784fcfc@github.com>

On Thu, 27 Nov 2025 16:31:50 GMT, ExE Boss <duke at openjdk.org> wrote:

>> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>>   
>>   Update copyright header
>
> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 2:
> 
>> 1: /*
>> 2:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> This?file should?probably also?have the?year?line before?this.

The sources contributed by Doug Lea have this header and shouldn't be changed here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28483#discussion_r2569540054

From alanb at openjdk.org  Thu Nov 27 18:50:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Nov 2025 18:50:47 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

src/hotspot/share/ci/ciField.cpp line 220:

> 218:     return false;
> 219:   // Explicit opt-in from system classes
> 220:   if (holder->trust_final_fields())

This is definitely nicer than listing specific classes. It would be nicer again once we can make this exceptions go away.

src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 61:

> 59: /// fields in classes specified by this annotation.
> 60: ///
> 61: /// This annotation is only recognized on privileged code and is ignored elsewhere.

"privileged code" hints of protection domains, permissions or security manager. Some of the annotations are limited to classes defined by the boot loader, is it the case here too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2569767299
PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2569764340

From liach at openjdk.org  Thu Nov 27 19:01:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Nov 2025 19:01:52 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
Message-ID: <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>

On Thu, 27 Nov 2025 18:45:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
>> 
>> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
>> 
>> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
>> 
>> Paging @minborg who requested Optional folding for review.
>> 
>> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.
>
> src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 61:
> 
>> 59: /// fields in classes specified by this annotation.
>> 60: ///
>> 61: /// This annotation is only recognized on privileged code and is ignored elsewhere.
> 
> "privileged code" hints of protection domains, permissions or security manager. Some of the annotations are limited to classes defined by the boot loader, is it the case here too?

I took this sentence from `@AOTSafeClassInitializer`.  The term "privileged" comes from this variable in `classFileParser.cpp`:
https://github.com/openjdk/jdk/blob/d94c52ccf2fed3fc66d25a34254c9b581c175fa1/src/hotspot/share/classfile/classFileParser.cpp#L1818-L1820

The other annotations have this note, which seems incorrect from the hotspot excerpt:

@implNote
This annotation only takes effect for fields of classes loaded by the boot
loader.  Annotations on fields of classes loaded outside of the boot loader
are ignored.


This behavior seems to be originally changed by 6964a690ed9a23d4c0692da2dfbced46e1436355, referring to an inaccessible issue.

What should I do with this? Should I leave this as-is and create a separate patch to update this comment for vm.annotation annotations, or fix this first and have the separate patch fix other annotations later?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2569787223

From liach at openjdk.org  Thu Nov 27 19:11:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Nov 2025 19:11:47 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
Message-ID: <JWIrmuux-_o4Pl4YXYfPWqxceoGdi_8s8ynrp3aXgJw=.ccbf84bf-242f-4bc8-a06b-55e3fac41b7a@github.com>

On Thu, 27 Nov 2025 18:47:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
>> 
>> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
>> 
>> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
>> 
>> Paging @minborg who requested Optional folding for review.
>> 
>> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.
>
> src/hotspot/share/ci/ciField.cpp line 220:
> 
>> 218:     return false;
>> 219:   // Explicit opt-in from system classes
>> 220:   if (holder->trust_final_fields())
> 
> This is definitely nicer than listing specific classes. It would be nicer again once we can make this exceptions go away.

True, this occupies one of the 16 precious instance klass bits in runtime. I wish we can derive this from our final means final restrictions, but their setup is to permit use-sites to migrate more easily, and is harder for declaration sites to deduce if a declaration is easier to be permitted. We can consider blanket-trust when the JVM uses `--illegal-final-field-mutation=deny` without additional `--enable-final-field-mutation`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2569800720

From duke at openjdk.org  Thu Nov 27 19:18:51 2025
From: duke at openjdk.org (duke)
Date: Thu, 27 Nov 2025 19:18:51 GMT
Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian
 [v5]
In-Reply-To: <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
 <RDEmmKBEH-r_XoF-9_HGa5neappOwfBf_Xpj-rKeoRw=.df527bb0-c898-4f89-ac4d-fa149092c0c7@github.com>
Message-ID: <oYHbR8KxXcv_48SFh-6EazRpBd60SAUyfeO42Y9MfSQ=.51cb8bfb-3660-4cf9-866d-fdc86d40ff67@github.com>

On Thu, 27 Nov 2025 13:46:19 GMT, James Yuzawa <duke at openjdk.org> wrote:

>> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
>> 
>> Here is a very simple reproducer:
>> 
>> ThreadLocalRandom r = ThreadLocalRandom.current();
>> // step into this call using a debugger
>> r.nextGaussian();
>> 
>> 
>> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
>> 
>> Sketch:
>> 
>> public interface RandomGenerator {
>> 	default double nextGaussian() {
>> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> public class Random implements RandomGenerator {
>> 	@Override
>> 	public synchronized double nextGaussian() {
>> 		// synchronized version ...
>> 	}
>> }
>> 
>> public class ThreadLocalRandom extends Random {
>> 
>> 	// ADD THIS
>> 	@Override
>> 	public double nextGaussian() {
>> 		return RandomSupport.computeNextGaussian(this);
>> 	}
>> }
>> 
>> 
>> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
>> 
>> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
>> 
>> 
>> Set<String> tlrMethods = new HashSet<>();
>> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		tlrMethods.add(desc);
>> 	}
>> }
>> for (Method method : java.util.Random.class.getDeclaredMethods()) {
>> 	int mod = method.getModifiers();
>> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
>> 		String desc =
>> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
>> 		if (!tlrMethods.contains(desc)) {
>> 			System.out.println(...
>
> James Yuzawa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8372134: ThreadLocalRandom no longer overrides nextGaussian
>   
>   Update copyright header

@yuzawa-san 
Your change (at version 502bbe9c371983a8e19d26ee387505e454c3769c) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28483#issuecomment-3587075654

From liach at openjdk.org  Thu Nov 27 19:21:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Nov 2025 19:21:53 GMT
Subject: RFR: 8346657: Improve out of bounds exception messages for
 MemorySegments [v10]
In-Reply-To: <ZEVS93Aiipf_5N4nh9o0xMejv9yZmnkrBM5C9wjqxtg=.880c1d7a-2e51-4f5f-99b3-5aa90ac353ab@github.com>
References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com>
 <ZEVS93Aiipf_5N4nh9o0xMejv9yZmnkrBM5C9wjqxtg=.880c1d7a-2e51-4f5f-99b3-5aa90ac353ab@github.com>
Message-ID: <qsaALkTs_Tb5fmgWQ_03Flrq86hS4KDiAfA_4Uauv9c=.5306f32c-7d71-4d17-8b2f-083b54c331f4@github.com>

On Fri, 21 Nov 2025 17:26:59 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
>> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
>> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach
>
> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implement re-throwing approach according to reviewer recomandation

This should be fine, though compilers might prefer separate not-inlined methods for throwing exceptions, so the `catch` block may do  something like:

    @ForceInline
    void checkSliceBounds(long offset, long length) {
        try {
            checkBounds(offset, length);
        } catch (IndexOutOfBoundsException e) {
            throwOutOfBounds(offset, length, true);
        }
    }

    @DontInline
    void throwOutOfBounds(long offset, long length, boolean slice) {
            String msg = String.format("Out of bound access on segment %s; attempting to %s of length %d at offset %d " +
                    "which is outside the valid range 0 <= offset+length < byteSize (=%d)", this, slice ? "get slice" : "access an element", length, offset, this.length);
            throw new IndexOutOfBoundsException(msg);
        }
    }


So the inlined `checkSliceBounds`/`checkAccessBounds` is smaller.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28124#pullrequestreview-3516725181

From duke at openjdk.org  Thu Nov 27 20:28:58 2025
From: duke at openjdk.org (James Yuzawa)
Date: Thu, 27 Nov 2025 20:28:58 GMT
Subject: Integrated: 8372134: ThreadLocalRandom no longer overrides
 nextGaussian
In-Reply-To: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com>
Message-ID: <qgbxwkP8XzfTOVkEqSykk3P8Ean8ca4TXuiuG4hsTX0=.705e4c34-023f-43ca-80e9-5fbafe91b957@github.com>

On Tue, 25 Nov 2025 00:13:03 GMT, James Yuzawa <duke at openjdk.org> wrote:

> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention.
> 
> Here is a very simple reproducer:
> 
> ThreadLocalRandom r = ThreadLocalRandom.current();
> // step into this call using a debugger
> r.nextGaussian();
> 
> 
> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used.
> 
> Sketch:
> 
> public interface RandomGenerator {
> 	default double nextGaussian() {
> 		// remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> public class Random implements RandomGenerator {
> 	@Override
> 	public synchronized double nextGaussian() {
> 		// synchronized version ...
> 	}
> }
> 
> public class ThreadLocalRandom extends Random {
> 
> 	// ADD THIS
> 	@Override
> 	public double nextGaussian() {
> 		return RandomSupport.computeNextGaussian(this);
> 	}
> }
> 
> 
> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals.
> 
> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others:
> 
> 
> Set<String> tlrMethods = new HashSet<>();
> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		tlrMethods.add(desc);
> 	}
> }
> for (Method method : java.util.Random.class.getDeclaredMethods()) {
> 	int mod = method.getModifiers();
> 	if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) {
> 		String desc =
> 				method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters());
> 		if (!tlrMethods.contains(desc)) {
> 			System.out.println(desc);
> 		}
> 	}
> }
> 
> 
> That prints
> 
> void nextBytes [byte[] arg0]
> double nextGaussian []
> 
> 
> The former safely calls `Thread...

This pull request has now been integrated.

Changeset: f1d90b8b
Author:    James Yuzawa <jtyuzawa at gmail.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1d90b8b25b78b15dc6529a5a6e45633eb250286
Stats:     28 lines in 2 files changed: 17 ins; 10 del; 1 mod

8372134: ThreadLocalRandom no longer overrides nextGaussian

Reviewed-by: alanb, rgiulietti, vklang

-------------

PR: https://git.openjdk.org/jdk/pull/28483

From duke at openjdk.org  Fri Nov 28 05:50:00 2025
From: duke at openjdk.org (Harshit470250)
Date: Fri, 28 Nov 2025 05:50:00 GMT
Subject: RFR: 8372710: Update ProcessBuilder/Basic regex
Message-ID: <rFM7flNsMEh5ZPxN3kSXu7BqjKTlSq4FsX1tgrdbxJE=.edb42bd0-b16e-42f4-8af7-58680507fc2f@github.com>

The exception format was changed by [JDK-8352533](https://github.com/openjdk/jdk/pull/24149). This pr implement those changes for the PERMISSION_DENIED_ERROR_MSG and NO_SUCH_FILE_ERROR_MSG.
Similar changes was also done here [ibmruntimes/openj9-openjdk-jdk25/commit/51102b1](https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/40) done by @theresa-m

-------------

Commit messages:
 - Update ProcessBuilder/Basic regex

Changes: https://git.openjdk.org/jdk/pull/27244/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27244&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372710
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27244/head:pull/27244

PR: https://git.openjdk.org/jdk/pull/27244

From duke at openjdk.org  Fri Nov 28 05:54:50 2025
From: duke at openjdk.org (Harshit470250)
Date: Fri, 28 Nov 2025 05:54:50 GMT
Subject: RFR: 8372710: Update ProcessBuilder/Basic regex
In-Reply-To: <rFM7flNsMEh5ZPxN3kSXu7BqjKTlSq4FsX1tgrdbxJE=.edb42bd0-b16e-42f4-8af7-58680507fc2f@github.com>
References: <rFM7flNsMEh5ZPxN3kSXu7BqjKTlSq4FsX1tgrdbxJE=.edb42bd0-b16e-42f4-8af7-58680507fc2f@github.com>
Message-ID: <fKz2vu_2QeX6Y8j2Iq3e62gypbhjAhf13ZTfuXG_Jgk=.457d8ce7-f318-4100-956e-fecdabe418c4@github.com>

On Fri, 12 Sep 2025 06:27:56 GMT, Harshit470250 <duke at openjdk.org> wrote:

> The exception format was changed by [JDK-8352533](https://github.com/openjdk/jdk/pull/24149). This pr implement those changes for the PERMISSION_DENIED_ERROR_MSG and NO_SUCH_FILE_ERROR_MSG.
> Similar changes was also done here [ibmruntimes/openj9-openjdk-jdk25/commit/51102b1](https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/40) done by @theresa-m

@shipilev Can you take a look at this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27244#issuecomment-3588003688

From shade at openjdk.org  Fri Nov 28 08:27:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Nov 2025 08:27:48 GMT
Subject: RFR: 8372710: Update ProcessBuilder/Basic regex
In-Reply-To: <rFM7flNsMEh5ZPxN3kSXu7BqjKTlSq4FsX1tgrdbxJE=.edb42bd0-b16e-42f4-8af7-58680507fc2f@github.com>
References: <rFM7flNsMEh5ZPxN3kSXu7BqjKTlSq4FsX1tgrdbxJE=.edb42bd0-b16e-42f4-8af7-58680507fc2f@github.com>
Message-ID: <_enfpum6MMySHVoaw8p29lgsw3i3BaQc7xMvMThwp-Q=.f288d7ff-7210-4a1f-9c8e-4edb90b33ac7@github.com>

On Fri, 12 Sep 2025 06:27:56 GMT, Harshit470250 <duke at openjdk.org> wrote:

> The exception format was changed by [JDK-8352533](https://github.com/openjdk/jdk/pull/24149). This pr implement those changes for the PERMISSION_DENIED_ERROR_MSG and NO_SUCH_FILE_ERROR_MSG.
> Similar changes was also done here [ibmruntimes/openj9-openjdk-jdk25/commit/51102b1](https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/40) done by @theresa-m

Ah yes, OK, the change you mentioned did this:


-#define IOE_FORMAT "error=%d, %s"
+#define IOE_FORMAT "%s, error: %d (%s) %s"


...so we now need the `:` instead of `=`. I am somewhat surprised it never failed in our testing before.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27244#pullrequestreview-3517910183

From pminborg at openjdk.org  Fri Nov 28 09:03:49 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 28 Nov 2025 09:03:49 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <H19jbssyUOV56d0xYR4EHV6a4ZCYIA95yz_w5gZX--M=.afd0782d-56dd-4eca-b607-1b7f4813b440@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

I really like this one!

I wonder if we could enable the new annotation `@TrustFinalFields` on package level as well so we could get rid of _all_ the special handing in `ciField.spp`. I am not sure this is the best way to do it but it would perhaps be possible to annotate the `package-info.java` file. For example in `java.lang.invoke.package-info.java`:


@TrustFinalFields
package java.lang.invoke;


Is there a better way to do it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3588443540

From galder at openjdk.org  Fri Nov 28 09:23:58 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 28 Nov 2025 09:23:58 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v2]
In-Reply-To: <4vSKAtr0tUG0V193gIvnEFdHm18ZhqflVAwk-09IVQ0=.081806f5-6303-4b4f-975d-7c85427ccae5@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <4vSKAtr0tUG0V193gIvnEFdHm18ZhqflVAwk-09IVQ0=.081806f5-6303-4b4f-975d-7c85427ccae5@github.com>
Message-ID: <QlXOb1QkCXxut0UIA7W-Y-m2nZI60tE7_AxeBUfvYkE=.edbb4495-43dc-49d0-b96e-6cff4e9b13c0@github.com>

On Thu, 20 Nov 2025 04:01:09 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
>> 
>> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
>> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
>> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
>> 
>> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
>> 
>> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
>> 
>> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
>> 
>> Current optimizations related to `VectorMaskCastNode` include:
>> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
>> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
>> 
>> This PR does the following optimizations:
>> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
>> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect...
>
> Eric Fang 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 three additional commits since the last revision:
> 
>  - Don't read and write the same memory in the JMH benchmarks
>  - Merge branch 'master' into JDK-8370863-mask-cast-opt
>  - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns
>    
>    `VectorMaskCastNode` is used to cast a vector mask from one type to
>    another type. The cast may be generated by calling the vector API `cast`
>    or generated by the compiler. For example, some vector mask operations
>    like `trueCount` require the input mask to be integer types, so for
>    floating point type masks, the compiler will cast the mask to the
>    corresponding integer type mask automatically before doing the mask
>    operation. This kind of cast is very common.
>    
>    If the vector element size is not changed, the `VectorMaskCastNode`
>    don't generate code, otherwise code will be generated to extend or narrow
>    the mask. This IR node is not free no matter it generates code or not
>    because it may block some optimizations. For example:
>    1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))`
>    The middle `VectorMaskCast` prevented the following optimization:
>    `(VectorStoremask (VectorLoadMask x)) => (x)`
>    2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which
>    blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
>    
>    In these IR patterns, the value of the input `x` is not changed, so we
>    can safely do the optimization. But if the input value is changed, we
>    can't eliminate the cast.
>    
>    The general idea of this PR is introducing an `uncast_mask` helper
>    function, which can be used to uncast a chain of `VectorMaskCastNode`,
>    like the existing `Node::uncast(bool)` function. The funtion returns
>    the first non `VectorMaskCastNode`.
>    
>    The intended use case is when the IR pattern to be optimized may
>    contain one or more consecutive `VectorMaskCastNode` and this does not
>    affect the correctness of the optimization. Then this function can be
>    called to eliminate the `VectorMaskCastNode` chain.
>    
>    Current optimizations related to `VectorMaskCastNode` include:
>    1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
>    2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>        => (VectorMaskCast (...

Nice improvement @erifan, just some small comments from me

src/hotspot/share/opto/vectornode.cpp line 1056:

> 1054: //   x remains to be a bool vector with no changes.
> 1055: // This function can be used to eliminate the VectorMaskCast in such patterns.
> 1056: Node* VectorNode::uncast_mask(Node* n) {

Could this be a static method instead?

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastIdentityTest.java line 57:

> 55:         applyIfCPUFeatureAnd = {"asimd", "true", "sve", "false"})
> 56:     public static int testTwoCastToDifferentType() {
> 57:         // The types before and after the two casts are not the same, so the cast cannot be eliminated.

Outdated comment. Also please expand assertion comments

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastIdentityTest.java line 79:

> 77:         applyIfCPUFeatureAnd = {"avx2", "true", "avx512", "false"})
> 78:     public static int testTwoCastToDifferentType2() {
> 79:         // The types before and after the two casts are not the same, so the cast cannot be eliminated.

Could you expand the documentation on the IR assertions? It's not immediately clear why with AVX-512 the cast remains but with AVX-2 it's removed. Also, this comment is outdated.

test/hotspot/jtreg/compiler/vectorapi/VectorMaskToLongTest.java line 240:

> 238: 
> 239:     @Test
> 240:     @IR(counts = { IRNode.VECTOR_LONG_TO_MASK, "= 0",

Could you add some assertion comments here as well to understand what causes the differences with different architectures?

test/hotspot/jtreg/compiler/vectorapi/VectorMaskToLongTest.java line 260:

> 258: 
> 259:     @Test
> 260:     @IR(counts = { IRNode.VECTOR_LONG_TO_MASK, "= 0",

Same here

-------------

Changes requested by galder (Author).

PR Review: https://git.openjdk.org/jdk/pull/28313#pullrequestreview-3518051437
PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2570915091
PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2570925650
PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2570924373
PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2570932229
PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2570932750

From cushon at openjdk.org  Fri Nov 28 09:30:58 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 28 Nov 2025 09:30:58 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v14]
In-Reply-To: <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>
Message-ID: <eX-w4zKuYbtPpCgw_a7sObcw7QMu-IkDVpu3yb4_Cek=.58d561fc-24fc-4185-9836-f2e8e5723b08@github.com>

On Tue, 25 Nov 2025 19:10:25 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Thanks again for the reviews!

I think the next step is to got through the CSR process (and wait for the JDK 27 branch to open). I made some updates to the draft CSR, let me know if you have any feedback or would be willing to review the CSR: https://bugs.openjdk.org/browse/JDK-8372338

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3588536242

From mcimadamore at openjdk.org  Fri Nov 28 10:21:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Nov 2025 10:21:49 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v14]
In-Reply-To: <eX-w4zKuYbtPpCgw_a7sObcw7QMu-IkDVpu3yb4_Cek=.58d561fc-24fc-4185-9836-f2e8e5723b08@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>
 <eX-w4zKuYbtPpCgw_a7sObcw7QMu-IkDVpu3yb4_Cek=.58d561fc-24fc-4185-9836-f2e8e5723b08@github.com>
Message-ID: <-MO9i3zeJzbP6NV0dIgj-q-LoHusFRxuinzY9vpcczU=.3541ae56-774f-4b23-bc71-2b08e8095332@github.com>

On Fri, 28 Nov 2025 09:27:55 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Thanks again for the reviews!
> 
> I think the next step is to got through the CSR process (and wait for the JDK 27 branch to open). I made some updates to the draft CSR, let me know if you have any feedback or would be willing to review the CSR: https://bugs.openjdk.org/browse/JDK-8372338

I've streamlined the text a bit, and added myself as a reviewer. That should be enough to move it through the pipeline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3588707606

From alanb at openjdk.org  Fri Nov 28 10:55:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Nov 2025 10:55:54 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
Message-ID: <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>

On Thu, 27 Nov 2025 18:58:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 61:
>> 
>>> 59: /// fields in classes specified by this annotation.
>>> 60: ///
>>> 61: /// This annotation is only recognized on privileged code and is ignored elsewhere.
>> 
>> "privileged code" hints of protection domains, permissions or security manager. Some of the annotations are limited to classes defined by the boot loader, is it the case here too?
>
> I took this sentence from `@AOTSafeClassInitializer`.  The term "privileged" comes from this variable in `classFileParser.cpp`:
> https://github.com/openjdk/jdk/blob/d94c52ccf2fed3fc66d25a34254c9b581c175fa1/src/hotspot/share/classfile/classFileParser.cpp#L1818-L1820
> 
> The other annotations have this note, which seems incorrect from the hotspot excerpt:
> 
> @implNote
> This annotation only takes effect for fields of classes loaded by the boot
> loader.  Annotations on fields of classes loaded outside of the boot loader
> are ignored.
> 
> 
> This behavior seems to be originally changed by 6964a690ed9a23d4c0692da2dfbced46e1436355, referring to an inaccessible issue.
> 
> What should I do with this? Should I leave this as-is and create a separate patch to update this comment for vm.annotation annotations, or fix this first and have the separate patch fix other annotations later?

For this PR then you could just change the last sentence to say that the annotation is only effective for classes defined by the boot class loader or platform class loader. A follow-up PR could propose changes to the other annotation descriptions.

As regards background then one of the significant changes in JDK 9 was that java.* modules could be mapped to the platform class loader without give them "all permission" in the security manager execution mode. If you see JBS issues or comments speaking of "de-privileging" then it's likely related to changes that "moved" modules that were originally mapped to the boot class loader to the platform class loader. Now that the security manager execution mode is gone then we don't have to deal with all these issues now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571257172

From alanb at openjdk.org  Fri Nov 28 10:59:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Nov 2025 10:59:48 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <JWIrmuux-_o4Pl4YXYfPWqxceoGdi_8s8ynrp3aXgJw=.ccbf84bf-242f-4bc8-a06b-55e3fac41b7a@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <JWIrmuux-_o4Pl4YXYfPWqxceoGdi_8s8ynrp3aXgJw=.ccbf84bf-242f-4bc8-a06b-55e3fac41b7a@github.com>
Message-ID: <Y3ZawicQrH0Cj6bG2XGSAUez9GTmkAIRiJWr3t9jPLU=.fbabc76f-3cf6-4d1a-9c48-68b2cbbeeee2@github.com>

On Thu, 27 Nov 2025 19:08:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/hotspot/share/ci/ciField.cpp line 220:
>> 
>>> 218:     return false;
>>> 219:   // Explicit opt-in from system classes
>>> 220:   if (holder->trust_final_fields())
>> 
>> This is definitely nicer than listing specific classes. It would be nicer again once we can make this exceptions go away.
>
> True, this occupies one of the 16 precious instance klass bits in runtime. I wish we can derive this from our final means final restrictions, but their setup is to permit use-sites to migrate more easily, and is harder for declaration sites to deduce if a declaration is easier to be permitted. We can consider blanket-trust when the JVM uses `--illegal-final-field-mutation=deny` without additional `--enable-final-field-mutation`.

This would be the equivalent of running with -XX:+TrustFinalNonStaticFields, which would be nice, but there would be performance surprises as soon as you enable final field mutation for any module (and likely ALL-UNNAMED).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571272623

From alanb at openjdk.org  Fri Nov 28 11:08:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Nov 2025 11:08:56 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <H19jbssyUOV56d0xYR4EHV6a4ZCYIA95yz_w5gZX--M=.afd0782d-56dd-4eca-b607-1b7f4813b440@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <H19jbssyUOV56d0xYR4EHV6a4ZCYIA95yz_w5gZX--M=.afd0782d-56dd-4eca-b607-1b7f4813b440@github.com>
Message-ID: <27R9PsHG0Jn3Ov39a-G9IXvKoEG01P0mOKMfVVrF4S4=.82593db1-0844-428f-9eff-af1529ff9663@github.com>

On Fri, 28 Nov 2025 09:00:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> I wonder if we could enable the new annotation `@TrustFinalFields` on package level as well so we could get rid of _all_ the special handing in `ciField.spp`. I am not sure this is the best way to do it but it would perhaps be possible to annotate the `package-info.java` file. For example in `java.lang.invoke.package-info.java`:

The VM don't read/parse the package-info class. It's really only used from APIs to read the annotations. In any case, teh long term goal needs to be to remove all special handling.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3588887344

From jpai at openjdk.org  Fri Nov 28 13:32:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 13:32:52 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
 <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>
Message-ID: <iRETQJf1F3YXVglgIPRKaJLtlaKO25gFz_bnvFrE2jY=.9ac10abf-9f44-4bf2-978c-b7ac45d4edc6@github.com>

On Fri, 28 Nov 2025 10:52:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I took this sentence from `@AOTSafeClassInitializer`.  The term "privileged" comes from this variable in `classFileParser.cpp`:
>> https://github.com/openjdk/jdk/blob/d94c52ccf2fed3fc66d25a34254c9b581c175fa1/src/hotspot/share/classfile/classFileParser.cpp#L1818-L1820
>> 
>> The other annotations have this note, which seems incorrect from the hotspot excerpt:
>> 
>> @implNote
>> This annotation only takes effect for fields of classes loaded by the boot
>> loader.  Annotations on fields of classes loaded outside of the boot loader
>> are ignored.
>> 
>> 
>> This behavior seems to be originally changed by 6964a690ed9a23d4c0692da2dfbced46e1436355, referring to an inaccessible issue.
>> 
>> What should I do with this? Should I leave this as-is and create a separate patch to update this comment for vm.annotation annotations, or fix this first and have the separate patch fix other annotations later?
>
> For this PR then you could just change the last sentence to say that the annotation is only effective for classes defined by the boot class loader or platform class loader. A follow-up PR could propose changes to the other annotation descriptions.
> 
> As regards background then one of the significant changes in JDK 9 was that java.* modules could be mapped to the platform class loader without give them "all permission" in the security manager execution mode. If you see JBS issues or comments speaking of "de-privileging" then it's likely related to changes that "moved" modules that were originally mapped to the boot class loader to the platform class loader. Now that the security manager execution mode is gone then we don't have to deal with all these issues now.

Hello Chen, should this annotation also mention what happens if a class annotated with `@TrustFinalFields` has any of its `final` fields updated? For example, `@Stable` has this to say about such unexpected updates:


...It is in general a bad idea to reset such
* variables to any other value, since compiled code might have folded
* an earlier stored value, and will never detect the reset value.


Are there any unexpected consequences of marking a class as `@TrustFinalFields` and having a `@Stable` on any of the final fields (for example an array):


@TrustedFinalFields
class JDKFooBar {
    private final String reallyFinal;

    @Stable
    private final int reallyFinalButAlsoStable;

    @Stable
    private final long[] finalAndStableArray;

}

Finally, would it still be recommended that a class annotated with `@TrustFinalFields` also have a final array field annoted with `@Stable` if that array field elements are initialized to a non-default value only once?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571701254

From jpai at openjdk.org  Fri Nov 28 13:38:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 13:38:47 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <iRETQJf1F3YXVglgIPRKaJLtlaKO25gFz_bnvFrE2jY=.9ac10abf-9f44-4bf2-978c-b7ac45d4edc6@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
 <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>
 <iRETQJf1F3YXVglgIPRKaJLtlaKO25gFz_bnvFrE2jY=.9ac10abf-9f44-4bf2-978c-b7ac45d4edc6@github.com>
Message-ID: <VQLfnM7dV7vMvn4VLD-WKQ3gHsFEVsdxQz98iebILUc=.1ed7e9cc-2f03-4109-8fa5-be69f7e7482f@github.com>

On Fri, 28 Nov 2025 13:30:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> For this PR then you could just change the last sentence to say that the annotation is only effective for classes defined by the boot class loader or platform class loader. A follow-up PR could propose changes to the other annotation descriptions.
>> 
>> As regards background then one of the significant changes in JDK 9 was that java.* modules could be mapped to the platform class loader without give them "all permission" in the security manager execution mode. If you see JBS issues or comments speaking of "de-privileging" then it's likely related to changes that "moved" modules that were originally mapped to the boot class loader to the platform class loader. Now that the security manager execution mode is gone then we don't have to deal with all these issues now.
>
> Hello Chen, should this annotation also mention what happens if a class annotated with `@TrustFinalFields` has any of its `final` fields updated? For example, `@Stable` has this to say about such unexpected updates:
> 
> 
> ...It is in general a bad idea to reset such
> * variables to any other value, since compiled code might have folded
> * an earlier stored value, and will never detect the reset value.
> 
> 
> Are there any unexpected consequences of marking a class as `@TrustFinalFields` and having a `@Stable` on any of the final fields (for example an array):
> 
> 
> @TrustedFinalFields
> class JDKFooBar {
>     private final String reallyFinal;
> 
>     @Stable
>     private final int reallyFinalButAlsoStable;
> 
>     @Stable
>     private final long[] finalAndStableArray;
> 
> }
> 
> Finally, would it still be recommended that a class annotated with `@TrustFinalFields` also have a final array field annoted with `@Stable` if that array field elements are initialized to a non-default value only once?

One another question - if a class/interface is annotated with `@TargetFinalFields`, is that annotation only applicable to that specific class or would it also be applicable for any (final fields in) subclasses of that class or implementations of that interface (does the VM ignore this annotation on an interface, should it)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571717831

From jpai at openjdk.org  Fri Nov 28 13:47:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 13:47:48 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 49:

> 47: /// As a result, this should be used on classes where package-wide trusting is
> 48: /// not possible due to backward compatibility concerns, such as for `java.util`
> 49: /// classes.

Should this sentence be reworded? It's not clear what the backward compatible concerns (for `java.util` package) are. I think it might be better to leave out any backward compatibility part when explaining which classes to use this annotation on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571741641

From rgiulietti at openjdk.org  Fri Nov 28 14:39:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 28 Nov 2025 14:39:54 GMT
Subject: RFR: 8366478: BigDecimal roots [v25]
In-Reply-To: <Pi4r0rEMuFSNNwloGc-IOzaPJHj4ivdH1N8vPfTnk5w=.2cbf1638-ddfc-4b8a-a379-5ab66495675b@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 <46-VBAJRLDdG66FU6IxuHzbl8XD_V7L_YIzA9FAYOnE=.46304352-888c-4dd9-8157-cb27a5e3248b@github.com>
 <1n-hiqgl4Yu8rZMb7FkxFVstU5mJWzSf5mtl2ydNKmc=.17e94958-ef31-4f96-9014-33aa0f269890@github.com>
 <Pi4r0rEMuFSNNwloGc-IOzaPJHj4ivdH1N8vPfTnk5w=.2cbf1638-ddfc-4b8a-a379-5ab66495675b@github.com>
Message-ID: <SLspymXoZX-HvptIR1CXaw16LlUsKtbc3WqyJ9Oeaqk=.2f5b51b4-ab92-4acc-a77a-60406bd0ed57@github.com>

On Mon, 27 Oct 2025 17:28:02 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> At some point we also need good whitebox tests, possibly covering all the code paths.
>> Further, an update of the CSR with the new name is needed as well.
>
> @rgiulietti I will add tests after the CSR approval.

@fabioromano1 There are currently no tests for `rootn()` other than the special cases for `sqrt()` and/or on zeros.

Since this PR will probably _not_ make it for the JDK 26 Rampdown planned on 2025-12-04, there's now less pressure to rush them into the PR. However, at some point they will be needed to complete your work on it.

Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3589564512

From duke at openjdk.org  Fri Nov 28 15:08:06 2025
From: duke at openjdk.org (Chayan)
Date: Fri, 28 Nov 2025 15:08:06 GMT
Subject: RFR: 8361207: Build native Windows ARM64 MSI packages
In-Reply-To: <Qz3Gw9ozNSsFOR-g-VN6I5t3qDt8JAS55v_fwYM4H0I=.0795cfdb-c39f-4140-ad5a-824eedfa3f0a@github.com>
References: <s623zbmBUFlxmuTp28Vsn91sAr3iOsWgvd_lgzgNKbY=.af803cce-376d-450d-a6f2-e93074c2680e@github.com>
 <YIFOvlCTRcfH3hr4p2WNijyT-DNL1DEAN2vHi5Z44RU=.de217840-9d77-4a79-815b-0e4612085e98@github.com>
 <Qz3Gw9ozNSsFOR-g-VN6I5t3qDt8JAS55v_fwYM4H0I=.0795cfdb-c39f-4140-ad5a-824eedfa3f0a@github.com>
Message-ID: <eh4awt47hY-zz2xbTg7DGWwOOjFnswUmi_qmqCNgRWU=.5f2d3408-43a3-4288-b022-0a6438920c42@github.com>

On Wed, 27 Aug 2025 22:36:08 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> @alexeysemenyukoracle can i speed up the OCA verification?
>
> @infeo have you received an OCA verification request? They sent it to you about three weeks ago.

@alexeysemenyukoracle Is the fix acceptable ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26093#issuecomment-3536177963

From liach at openjdk.org  Fri Nov 28 15:08:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Nov 2025 15:08:56 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
Message-ID: <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>

On Fri, 28 Nov 2025 13:45:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
>> 
>> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
>> 
>> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
>> 
>> Paging @minborg who requested Optional folding for review.
>> 
>> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.
>
> src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 49:
> 
>> 47: /// As a result, this should be used on classes where package-wide trusting is
>> 48: /// not possible due to backward compatibility concerns, such as for `java.util`
>> 49: /// classes.
> 
> Should this sentence be reworded? It's not clear what the backward compatible concerns (for `java.util` package) are. I think it might be better to leave out any backward compatibility part when explaining which classes to use this annotation on.

Existing users have been hacking java.util final fields. I think leaving out the backward compatibility part causes more trouble, because otherwise people can just blanket-approve java.util classes for trusting and break those applications.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571941033

From liach at openjdk.org  Fri Nov 28 15:08:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Nov 2025 15:08:57 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <VQLfnM7dV7vMvn4VLD-WKQ3gHsFEVsdxQz98iebILUc=.1ed7e9cc-2f03-4109-8fa5-be69f7e7482f@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
 <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>
 <iRETQJf1F3YXVglgIPRKaJLtlaKO25gFz_bnvFrE2jY=.9ac10abf-9f44-4bf2-978c-b7ac45d4edc6@github.com>
 <VQLfnM7dV7vMvn4VLD-WKQ3gHsFEVsdxQz98iebILUc=.1ed7e9cc-2f03-4109-8fa5-be69f7e7482f@github.com>
Message-ID: <khq0N0_Qo2ziTunmpLWt7pAP58w75SD6lpbh5nSziio=.d79e7764-a24c-47f2-aa97-0b2fd4bb3b50@github.com>

On Fri, 28 Nov 2025 13:35:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Chen, should this annotation also mention what happens if a class annotated with `@TrustFinalFields` has any of its `final` fields updated? For example, `@Stable` has this to say about such unexpected updates:
>> 
>> 
>> ...It is in general a bad idea to reset such
>> * variables to any other value, since compiled code might have folded
>> * an earlier stored value, and will never detect the reset value.
>> 
>> 
>> Are there any unexpected consequences of marking a class as `@TrustFinalFields` and having a `@Stable` on any of the final fields (for example an array):
>> 
>> 
>> @TrustedFinalFields
>> class JDKFooBar {
>>     private final String reallyFinal;
>> 
>>     @Stable
>>     private final int reallyFinalButAlsoStable;
>> 
>>     @Stable
>>     private final long[] finalAndStableArray;
>> 
>> }
>> 
>> Finally, would it still be recommended that a class annotated with `@TrustFinalFields` also have a final array field annoted with `@Stable` if that array field elements are initialized to a non-default value only once?
>
> One another question - if a class/interface is annotated with `@TargetFinalFields`, is that annotation only applicable to that specific class or would it also be applicable for any (final fields in) subclasses of that class or implementations of that interface (does the VM ignore this annotation on an interface, should it)?

I don't think we should mention anything about updating final fields. If you use this field, you intend the fields not to get subsequently updated. Promising the behavior in this case only introduces more trouble and is meaningless for this annotation's readers. For inheritance, we can add a word or two.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571939030

From cnorrbin at openjdk.org  Fri Nov 28 15:11:00 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 28 Nov 2025 15:11:00 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1
Message-ID: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>

Hi everyone,

Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.

To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).

To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.

Testing:
* Oracle tiers 1-5
* Local testing:
  - `hotspot/jtreg/containers/` 
  - `jdk/jdk/internal/platform/docker/`
on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations

-------------

Commit messages:
 - resource limit availability checks on container tests

Changes: https://git.openjdk.org/jdk/pull/28557/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28557&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372615
  Stats: 63 lines in 21 files changed: 32 ins; 5 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/28557.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28557/head:pull/28557

PR: https://git.openjdk.org/jdk/pull/28557

From duke at openjdk.org  Fri Nov 28 16:09:56 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 28 Nov 2025 16:09:56 GMT
Subject: RFR: 8366478: BigDecimal roots [v25]
In-Reply-To: <SLspymXoZX-HvptIR1CXaw16LlUsKtbc3WqyJ9Oeaqk=.2f5b51b4-ab92-4acc-a77a-60406bd0ed57@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 <46-VBAJRLDdG66FU6IxuHzbl8XD_V7L_YIzA9FAYOnE=.46304352-888c-4dd9-8157-cb27a5e3248b@github.com>
 <1n-hiqgl4Yu8rZMb7FkxFVstU5mJWzSf5mtl2ydNKmc=.17e94958-ef31-4f96-9014-33aa0f269890@github.com>
 <Pi4r0rEMuFSNNwloGc-IOzaPJHj4ivdH1N8vPfTnk5w=.2cbf1638-ddfc-4b8a-a379-5ab66495675b@github.com>
 <SLspymXoZX-HvptIR1CXaw16LlUsKtbc3WqyJ9Oeaqk=.2f5b51b4-ab92-4acc-a77a-60406bd0ed57@github.com>
Message-ID: <qsu0fvhTSdnap5dIqlb8kF7M53fRLNI9YoG8JgqXM8g=.fa6d6b44-93f1-4cd3-8c61-e4d64b733e91@github.com>

On Fri, 28 Nov 2025 14:36:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti I will add tests after the CSR approval.
>
> @fabioromano1 There are currently no tests for `rootn()` other than the special cases for `sqrt()` and/or on zeros.
> 
> Since this PR will probably _not_ make it for the JDK 26 Rampdown planned on 2025-12-04, there's now less pressure to rush them into the PR. However, at some point they will be needed to complete your work on it.
> 
> Thanks

@rgiulietti Soon I will add the tests for the paths that are not covered yet by the current ones.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3589809608

From rgiulietti at openjdk.org  Fri Nov 28 16:09:59 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 28 Nov 2025 16:09:59 GMT
Subject: RFR: 8366478: BigDecimal roots [v27]
In-Reply-To: <WrT1nqw8DJdi3BgJvN6X0nX2G3MSOSYkPdHMT4rwGsk=.85dc379e-ef47-4c77-bc95-9cba6a394523@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 <WrT1nqw8DJdi3BgJvN6X0nX2G3MSOSYkPdHMT4rwGsk=.85dc379e-ef47-4c77-bc95-9cba6a394523@github.com>
Message-ID: <l4zBteY8j_DHt_ufr83tX4BulfovRfD9PNU94l624Jo=.f7ae95c7-d493-4f93-ab6e-39c122bfd61d@github.com>

On Tue, 25 Nov 2025 17:43:15 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An implementation of `BigDecimal.nthRoot(int, MathContext)`.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct error output message

Keep in mind that we will busy with the Rampdown, so we might not have much time to review and approve until after 2025-12-04. So take your time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3589819219

From duke at openjdk.org  Fri Nov 28 22:00:51 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 28 Nov 2025 22:00:51 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v14]
In-Reply-To: <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <CjZsoVKyZJpyc-mVNohZp0yjDk5ssTfrogL7tMr58Sk=.9331226f-cd73-4591-8e51-f01454718f5f@github.com>
Message-ID: <K_EDbmBq0GT1ANsTfVNRY19BvtLkKKFrjxOFYJ9sFrs=.f2e63497-b824-4582-873c-f45a14adedd0@github.com>

On Tue, 25 Nov 2025 19:10:25 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

## Re?**CSR**:

diff -U 3 a/JDK?8372338.md b/JDK?8372338.md
--- a/JDK?8372338.md
+++ b/JDK?8372338.md
@@ -15,7 +15,7 @@
 Solution
 --------

-This change adds threw new methods to support efficient handling of non-null terminated strings:
+This change adds three new methods to support efficient handling of non-null terminated strings:

 * `MemorySegment#getString(long offset, Charset charset, long length)`
 * `MemorySegment#copy(String src, Charset dstEncoding, int srcIndex, MemorySegment dst, long dstOffset, int numChars)`
@@ -28,11 +28,11 @@
 2. number of code units
 3. the number of characters in the resulting string

-(3) was was rejected because for variable length encodings it requires a decoding step to convert to bytes for a bulk copy operation. This leaves (1) and (2) as candidates -- since the conversion between the two is a trivial scaling factor, either would have been a viable choice. Code units might be more natural for native strings encoded as an array of code units. Using a byte length was [decided on](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021215.html) to allow supporting arbitrary charsets, since not all charsets may have a concept of a code unit.
+(3) was rejected because for variable length encodings it requires a decoding step to convert to bytes for a bulk copy operation. This leaves (1) and (2) as candidates -- since the conversion between the two is a trivial scaling factor, either would have been a viable choice. Code units might be more natural for native strings encoded as an array of code units. Using a byte length was [decided on](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021215.html) to allow supporting arbitrary charsets, since not all charsets may have a concept of a code unit.

 For `copy` and `allocateFrom`, the `srcIndex` and `numChars` are expressed in terms of character offsets into the string. This is the only practical choice here, since the client already has a Java string, and computing an offset in bytes or code units would require additional computation.

-The new `copy` method is the dual of the new `getString`, and allows writing strings to a target memory segment without a terminator. There was a potential analogy to the existing `MemorySegment#setString` methods here, but they write strings with null terminators. This operation is more in common with the other `copy` overloads, where here a String is the source of data Strings (as opposed to e.g. an array).
+The new `copy` method is the dual of the new `getString`, and allows writing strings to a target memory segment without a terminator. There was a potential analogy to the existing `MemorySegment#setString` methods here, but they write strings with null terminators. This operation is more in common with the other `copy` overloads, where here a String is the source of data (as opposed to e.g. an array).

 Specification
 -------------

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3590599626

From rriggs at openjdk.org  Sat Nov 29 01:52:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 29 Nov 2025 01:52:56 GMT
Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in
 UUID [v2]
In-Reply-To: <Cp7CYDu_RqOwsT680z2DrIp9CP02Rw7oWyAhKrD2PmI=.73bbb410-f076-4055-91be-c07d5051bfca@github.com>
References: <poWuyZcEP_5xejyNLpYLYh37fjuXlBlLiuQ99qKCkLc=.28aeb10f-eac1-4149-993c-b5e461f7d84f@github.com>
 <Cp7CYDu_RqOwsT680z2DrIp9CP02Rw7oWyAhKrD2PmI=.73bbb410-f076-4055-91be-c07d5051bfca@github.com>
Message-ID: <oQcXp2Jy902GA93bMLRZ05uo07-Yi50-a4j_mIqFWxI=.d60b1d53-93ba-4816-9c39-c32716fdcdf7@github.com>

On Fri, 21 Nov 2025 11:03:43 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spec update

Don't wait but for doc-only changes there is a bit more time until RPD2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28435#issuecomment-3590828775

From jpai at openjdk.org  Sat Nov 29 07:12:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Nov 2025 07:12:53 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
 <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
Message-ID: <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>

On Fri, 28 Nov 2025 15:06:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 49:
>> 
>>> 47: /// As a result, this should be used on classes where package-wide trusting is
>>> 48: /// not possible due to backward compatibility concerns, such as for `java.util`
>>> 49: /// classes.
>> 
>> Should this sentence be reworded? It's not clear what the backward compatible concerns (for `java.util` package) are. I think it might be better to leave out any backward compatibility part when explaining which classes to use this annotation on.
>
> Existing users have been hacking java.util final fields. I think leaving out the backward compatibility part causes more trouble, because otherwise people can just blanket-approve java.util classes for trusting and break those applications.

Hello Chen,

> because otherwise people can just blanket-approve java.util classes for trusting and break those applications.

This is one of the reasons why I asked some of the questions that I did. We have seen several PRs in the recent past where `@Stable` annotation has been introduced in the core classes of Java SE because it aids constant folding optimizations. Most of those changes have been backed merely by JMH benchmarks. It won't be a surprise if we start seeing another round of PRs where the usage of this new `@TrustFinalFields` gets proposed to some of these classes in the JDK because it shows an improvement in some micro benchmark. It also won't be a surprise if those PRs too won't have associated regression tests. Furthermore, unlike `@Stable` which gets applied directly on the field(s) of interest, this new annotation will be applied a bit "far away" from such fields. So it will need additional review cycles to understand if this usage can impact the code functionally in any manner. Specifying the semantics of this annotation in various usage scenarios, in its javadoc, will aid in reviewing su
 ch changes in future, instead of having to regularly look into the JVM code to understand how this annotation behaves.

Classes in `java.util` aren't special in any way. So if applications are changing the values of final fields of some of those classes, then the same would be done for other packages of Java SE APIs too. If, like you note, applying `@TrustFinalFields` on such classes is going to break applications, then it will be useful to specify what kind of breakages those will be (in a similar manner to what the `@Stable` annotation's javadoc does).

Very specifically, I think adding a few sentences clarifying the following scenarios in this annotation's javadoc will be useful:

- Will this annotation be honoured only on the specific class that it is applied to? Or will it be taken into consideration for final fields in subclasses too? 
- If this annotation gets applied on a class and if that class has some final fields which are already marked `@Stable`, what kind of implications will that have, if any?
- If this annotation is marked on a class which has a `final` array field (for example `final long[] ids`), is it useful to continue placing a `@Stable` annotation on such array fields if the elements of those arrays are going to be initialized to a non-default value just once?
- If after all the precautions are taken, if the final field of a class annotated with `@TrustFinalFields` does get updated to a new value, what kind of impact would it have (stating that such behaviour is unspecified and in general is a bad idea would be enough, if that's all there is to it)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2572850670

From duke at openjdk.org  Sat Nov 29 18:39:39 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 29 Nov 2025 18:39:39 GMT
Subject: RFR: 8366478: BigDecimal roots [v28]
In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
Message-ID: <mi8tD8yXGg8h9SJB5xMxZqt-ZxmhvkXD94EqzAuY0Bk=.6bb1eb73-eea0-407f-b636-1e0a99660c00@github.com>

> An implementation of `BigDecimal.nthRoot(int, MathContext)`.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added tests for exact result cases and handle result assertions for n < 0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27148/files
  - new: https://git.openjdk.org/jdk/pull/27148/files/81b3b775..1f773b38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=26-27

  Stats: 51 lines in 2 files changed: 16 ins; 4 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/27148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148

PR: https://git.openjdk.org/jdk/pull/27148

From davidalayachew at gmail.com  Sat Nov 29 19:29:33 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 29 Nov 2025 14:29:33 -0500
Subject: Question about method references
Message-ID: <CAA9v-_OVkmeAKN+Lug=AOpiPCoSDdNMAV9YsVCdoz4juds=35g@mail.gmail.com>

Hello @core-libs-dev <core-libs-dev at openjdk.org>,

Let's say I have a record User(String first, String last) {}. That code
grants me User::first and User::last as accessor methods. Very cool.

I can access those accessor methods if I am given the class. It is a
trivial call from User.class ---> Class.getRecordComponents() --->
RecordComponent.getAccessor() ---> Method.invoke() ---> User::first/last.
It is very powerful.

But this only lets me go top-down. If I want to take a record accessor like
User::first and turn that into a record component, then that is not
something I can see how to do.

Is it impossible? There is a lot of value in being able to look at a method
reference and be able to see that class that that method being referenced
is contained within. For example, I would like to be able to look at
User::first, and be able to get the accompanying RecordComponent. And if
not that, then at least the accompanying java.lang.reflect.Method. Is that
possible?

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251129/ecf4c328/attachment-0001.htm>

From davidalayachew at gmail.com  Sat Nov 29 19:42:26 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 29 Nov 2025 14:42:26 -0500
Subject: Question about method references
In-Reply-To: <CAA9v-_OVkmeAKN+Lug=AOpiPCoSDdNMAV9YsVCdoz4juds=35g@mail.gmail.com>
References: <CAA9v-_OVkmeAKN+Lug=AOpiPCoSDdNMAV9YsVCdoz4juds=35g@mail.gmail.com>
Message-ID: <CAA9v-_P-puB4aHW2EVsa5Z7KU-7P-AsxyBDCn8ohHtuR22TRLw@mail.gmail.com>

And to simplify the question, is it possible for me to create some function
foo that can do this?

record User(String firstName, String lastName) {}
java.lang.reflect.Method getFirstName = foo(User::firstName);

Or better yet, like this?

java.lang.reflect.RecordComponent getLastName = foo(User::lastName);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251129/8e13bbe3/attachment.htm>

From duke at openjdk.org  Sat Nov 29 21:55:18 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Sat, 29 Nov 2025 21:55:18 GMT
Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED,
 NONNULL
Message-ID: <jGwX3Mh8Y24iS-jsNYZAt6_xoUTMwzwUe5GLjN7ypdI=.04f7738e-74e0-4e83-888b-46c14b379d22@github.com>

I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well.

The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile.

-------------

Commit messages:
 - 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL

Changes: https://git.openjdk.org/jdk/pull/28568/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8179918
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28568/head:pull/28568

PR: https://git.openjdk.org/jdk/pull/28568

From duke at openjdk.org  Sun Nov 30 00:30:05 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Sun, 30 Nov 2025 00:30:05 GMT
Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, 
 NONNULL [v2]
In-Reply-To: <jGwX3Mh8Y24iS-jsNYZAt6_xoUTMwzwUe5GLjN7ypdI=.04f7738e-74e0-4e83-888b-46c14b379d22@github.com>
References: <jGwX3Mh8Y24iS-jsNYZAt6_xoUTMwzwUe5GLjN7ypdI=.04f7738e-74e0-4e83-888b-46c14b379d22@github.com>
Message-ID: <f3envVNccPWJUdvBn5jpxXlUSx-QJ7FGKZT1MqBMpAw=.77301076-7c2e-41ed-a300-892bd5b0de65@github.com>

> I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well.
> 
> The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile.

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28568/files
  - new: https://git.openjdk.org/jdk/pull/28568/files/1d4eba6b..bbce28c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28568/head:pull/28568

PR: https://git.openjdk.org/jdk/pull/28568

From liach at openjdk.org  Sun Nov 30 05:24:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 05:24:43 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Essay

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28540/files
  - new: https://git.openjdk.org/jdk/pull/28540/files/f02b9da2..712dbf1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=00-01

  Stats: 150 lines in 2 files changed: 130 ins; 8 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540

PR: https://git.openjdk.org/jdk/pull/28540

From liach at openjdk.org  Sun Nov 30 05:24:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 05:24:44 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
 <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
 <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>
Message-ID: <TvUzakskfYFBfgX8a2mLmeLUrPnxauvl2Uf7GD5Klns=.ec0fdd74-3b7d-446a-a22a-53cb885358b3@github.com>

On Sat, 29 Nov 2025 07:10:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Existing users have been hacking java.util final fields. I think leaving out the backward compatibility part causes more trouble, because otherwise people can just blanket-approve java.util classes for trusting and break those applications.
>
> Hello Chen,
> 
>> because otherwise people can just blanket-approve java.util classes for trusting and break those applications.
> 
> This is one of the reasons why I asked some of the questions that I did. We have seen several PRs in the recent past where `@Stable` annotation has been introduced in the core classes of Java SE because it aids constant folding optimizations. Most of those changes have been backed merely by JMH benchmarks. It won't be a surprise if we start seeing another round of PRs where the usage of this new `@TrustFinalFields` gets proposed to some of these classes in the JDK because it shows an improvement in some micro benchmark. It also won't be a surprise if those PRs too won't have associated regression tests. Furthermore, unlike `@Stable` which gets applied directly on the field(s) of interest, this new annotation will be applied a bit "far away" from such fields. So it will need additional review cycles to understand if this usage can impact the code functionally in any manner. Specifying the semantics of this annotation in various usage scenarios, in its javadoc, will aid in reviewing 
 such changes in future, instead of having to regularly look into the JVM code to understand how this annotation behaves.
> 
> Classes in `java.util` aren't special in any way. So if applications are changing the values of final fields of some of those classes, then the same would be done for other packages of Java SE APIs too. If, like you note, applying `@TrustFinalFields` on such classes is going to break applications, then it will be useful to specify what kind of breakages those will be (in a similar manner to what the `@Stable` annotation's javadoc does).
> 
> Very specifically, I think adding a few sentences clarifying the following scenarios in this annotation's javadoc will be useful:
> 
> - Will this annotation be honoured only on the specific class that it is applied to? Or will it be taken into consideration for final fields in subclasses too? 
> - If this annotation gets applied on a class and if that class has some final fields which are already marked `@Stable`, what kind of implications will that have, if any?
> - If this annotation is marked on a class which has a `final` array field (for example `final long[] ids`), is it useful to continue placing a `@Stable` annotation on such array fields if the elements of those arrays are going to be initialized to a non-default value just once?
> - If after all the precautions are taken, if the final field of a class...

If you want an essay, I have written one - I just hope whatever bikeshedding for this essay does not affect the progress of Lazy Constant's performance demands.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573355600

From liach at openjdk.org  Sun Nov 30 05:36:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 05:36:47 GMT
Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter
 parsing to improve performance [v2]
In-Reply-To: <QL431F7FEFZCl3ftcvvWq5pwLgbKBfEcQ6QFSRiKcFc=.1945b2f4-508b-467b-b073-1310d5f5ef79@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <QL431F7FEFZCl3ftcvvWq5pwLgbKBfEcQ6QFSRiKcFc=.1945b2f4-508b-467b-b073-1310d5f5ef79@github.com>
Message-ID: <-M2fXk0-NVQKUcMw8Wyx0ENjNr3584l41Bwa3tv-bW8=.ad669cec-e0a1-442a-ba93-6ccf729b7ed5@github.com>

On Tue, 25 Nov 2025 06:44:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
>> 
>> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
>> 
>> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
>> 
>> Parsing scenarios show improvements from 12% to 95%
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

I think instead of checking each component printer parser, we should check the public methods on `DateTimeFormatterBuilder` that can take a `TemporalField` and track the `onlyChronoField` there.

This is better because this is where users can actaully pass in non-ChronoField. For example, I last time discovered text printer parser, and now have discovered DefaultValueParser is problematic too.

So I believe guarding where users can pass custom TemporalField and adding a boolean field on a DateTimeFormatterBuilder to keep track of this is better.

-------------

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3521038435

From alanb at openjdk.org  Sun Nov 30 07:51:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Nov 2025 07:51:51 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>
Message-ID: <RioTxs6EP8H6oW3DRnJsZm12OP1WNjKxumyERgD_MjA=.72b3557b-c85e-42a1-beb4-b2efb065c5e8@github.com>

On Sun, 30 Nov 2025 05:24:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
>> 
>> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
>> 
>> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
>> 
>> Paging @minborg who requested Optional folding for review.
>> 
>> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Essay

src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 1:

> 1: Constant Folding in the Hotspot Compiler

I assume any write-up of HotSpot constant folding should move into src/hotspot tree, maybe a block comment in one of the source files?

src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 106:

> 104: `trustedFinal` setting.
> 105: 
> 106: ### Make Final Mean Final

I think you can drop this section for now. It's okay to reference JEP 500 but it will be annoying to have to maintain this text as there are many steps to follow this one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573492977
PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573493426

From alanb at openjdk.org  Sun Nov 30 07:54:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Nov 2025 07:54:46 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <TvUzakskfYFBfgX8a2mLmeLUrPnxauvl2Uf7GD5Klns=.ec0fdd74-3b7d-446a-a22a-53cb885358b3@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
 <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
 <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>
 <TvUzakskfYFBfgX8a2mLmeLUrPnxauvl2Uf7GD5Klns=.ec0fdd74-3b7d-446a-a22a-53cb885358b3@github.com>
Message-ID: <h76V5hGnLdtKJxC8n93b0fqom8auRdttN9d8vU_UGFk=.9e67adba-ec7d-45b9-be65-cacf2c11dd32@github.com>

On Sun, 30 Nov 2025 05:19:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hello Chen,
>> 
>>> because otherwise people can just blanket-approve java.util classes for trusting and break those applications.
>> 
>> This is one of the reasons why I asked some of the questions that I did. We have seen several PRs in the recent past where `@Stable` annotation has been introduced in the core classes of Java SE because it aids constant folding optimizations. Most of those changes have been backed merely by JMH benchmarks. It won't be a surprise if we start seeing another round of PRs where the usage of this new `@TrustFinalFields` gets proposed to some of these classes in the JDK because it shows an improvement in some micro benchmark. It also won't be a surprise if those PRs too won't have associated regression tests. Furthermore, unlike `@Stable` which gets applied directly on the field(s) of interest, this new annotation will be applied a bit "far away" from such fields. So it will need additional review cycles to understand if this usage can impact the code functionally in any manner. Specifying the semantics of this annotation in various usage scenarios, in its javadoc, will aid in reviewing
  such changes in future, instead of having to regularly look into the JVM code to understand how this annotation behaves.
>> 
>> Classes in `java.util` aren't special in any way. So if applications are changing the values of final fields of some of those classes, then the same would be done for other packages of Java SE APIs too. If, like you note, applying `@TrustFinalFields` on such classes is going to break applications, then it will be useful to specify what kind of breakages those will be (in a similar manner to what the `@Stable` annotation's javadoc does).
>> 
>> Very specifically, I think adding a few sentences clarifying the following scenarios in this annotation's javadoc will be useful:
>> 
>> - Will this annotation be honoured only on the specific class that it is applied to? Or will it be taken into consideration for final fields in subclasses too? 
>> - If this annotation gets applied on a class and if that class has some final fields which are already marked `@Stable`, what kind of implications will that have, if any?
>> - If this annotation is marked on a class which has a `final` array field (for example `final long[] ids`), is it useful to continue placing a `@Stable` annotation on such array fields if the elements of those arrays are going to be initialized to a non-default value just once?
>> - If after all the precautions are taken, if...
>
> If you want an essay, I have written one - I just hope whatever bikeshedding for this essay does not affect the progress of Lazy Constant's performance demands.

> * If after all the precautions are taken, if the final field of a class annotated with `@TrustFinalFields` does get updated to a new value, what kind of impact would it have (stating that such behaviour is unspecified and in general is a bad idea would be enough, if that's all there is to it)

Field.set, which is probably the API that these libraries are using, already includes a warning about "unpredictable effects, including cases in which other parts of a program continue to use the original value of this field", so I think that is okay for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573494589

From alanb at openjdk.org  Sun Nov 30 08:07:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Nov 2025 08:07:46 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <h76V5hGnLdtKJxC8n93b0fqom8auRdttN9d8vU_UGFk=.9e67adba-ec7d-45b9-be65-cacf2c11dd32@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
 <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
 <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>
 <TvUzakskfYFBfgX8a2mLmeLUrPnxauvl2Uf7GD5Klns=.ec0fdd74-3b7d-446a-a22a-53cb885358b3@github.com>
 <h76V5hGnLdtKJxC8n93b0fqom8auRdttN9d8vU_UGFk=.9e67adba-ec7d-45b9-be65-cacf2c11dd32@github.com>
Message-ID: <wTT9gIxnm6lIjpOCpkaPVjS1BN1zWN_w0F-Xo4f-bZQ=.32e466bb-7f44-4371-876a-6cf3e11153e8@github.com>

On Sun, 30 Nov 2025 07:51:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If you want an essay, I have written one - I just hope whatever bikeshedding for this essay does not affect the progress of Lazy Constant's performance demands.
>
>> * If after all the precautions are taken, if the final field of a class annotated with `@TrustFinalFields` does get updated to a new value, what kind of impact would it have (stating that such behaviour is unspecified and in general is a bad idea would be enough, if that's all there is to it)
> 
> Field.set, which is probably the API that these libraries are using, already includes a warning about "unpredictable effects, including cases in which other parts of a program continue to use the original value of this field", so I think that is okay for now.

> Existing users have been hacking java.util final fields. I think leaving out the backward compatibility part causes more trouble, because otherwise people can just blanket-approve java.util classes for trusting and break those applications.

I don't think we have a lot of data on this as it doesn't lend itself to static analysis. Aside from serialization libraries, it's possible the hacking of finals is ad hoc and in random areas (someone pointed to something in Netty hacking a final field in a class in sun.nio.ch at one point). So I probably wouldn't call out java.util specifically but maybe you brought that up specifically as there are so many performance critical classes there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573499552

From duke at openjdk.org  Sun Nov 30 12:09:28 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 30 Nov 2025 12:09:28 GMT
Subject: RFR: 8366478: BigDecimal roots [v29]
In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
Message-ID: <YoeWZfrnXfIRC5o62wh26zXDng0Qc43sWyXKOqUBfWw=.28fab307-56d1-41d5-babf-d5e4e1ee65b4@github.com>

> An implementation of `BigDecimal.nthRoot(int, MathContext)`.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Correct for loop of precision in two digit tests
 - Added one digit tests to cover new paths

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27148/files
  - new: https://git.openjdk.org/jdk/pull/27148/files/1f773b38..97dbb083

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=27-28

  Stats: 55 lines in 2 files changed: 21 ins; 14 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148

PR: https://git.openjdk.org/jdk/pull/27148

From lancea at openjdk.org  Sun Nov 30 12:56:00 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 30 Nov 2025 12:56:00 GMT
Subject: Integrated: 8369432: Add Support for JDBC 4.5 MR
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: <v0E9oG1ZMJb6hhL-cChCuQ9qokCxIIRxhWKjFD6dUfw=.bd526a2e-1381-4185-9794-d3fc6bd67a05@github.com>

On Wed, 8 Oct 2025 14:49:07 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

This pull request has now been integrated.

Changeset: 282f3394
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/282f339406d67d189e06c0bf8c7ca8d8cf5774e0
Stats:     2693 lines in 27 files changed: 2336 ins; 233 del; 124 mod

8369432: Add Support for JDBC 4.5 MR

Reviewed-by: alanb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/27693

From liach at openjdk.org  Sun Nov 30 14:52:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 14:52:52 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <RioTxs6EP8H6oW3DRnJsZm12OP1WNjKxumyERgD_MjA=.72b3557b-c85e-42a1-beb4-b2efb065c5e8@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>
 <RioTxs6EP8H6oW3DRnJsZm12OP1WNjKxumyERgD_MjA=.72b3557b-c85e-42a1-beb4-b2efb065c5e8@github.com>
Message-ID: <w-LIyF7YVEs08VXf557Cn36LPFDkU2ma4dC1LdUOPe0=.ce2aa819-6718-48fc-90d2-39a086cb6649@github.com>

On Sun, 30 Nov 2025 07:47:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Essay
>
> src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 1:
> 
>> 1: Constant Folding in the Hotspot Compiler
> 
> I assume any write-up of HotSpot constant folding should move into src/hotspot tree, maybe a block comment in one of the source files?

I intend this to be a user-oriented guide on constant folding. I should just call it constant folding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573814710

From liach at openjdk.org  Sun Nov 30 14:52:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 14:52:53 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <w-LIyF7YVEs08VXf557Cn36LPFDkU2ma4dC1LdUOPe0=.ce2aa819-6718-48fc-90d2-39a086cb6649@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>
 <RioTxs6EP8H6oW3DRnJsZm12OP1WNjKxumyERgD_MjA=.72b3557b-c85e-42a1-beb4-b2efb065c5e8@github.com>
 <w-LIyF7YVEs08VXf557Cn36LPFDkU2ma4dC1LdUOPe0=.ce2aa819-6718-48fc-90d2-39a086cb6649@github.com>
Message-ID: <Xda9WTd21w9uuSF0q4iFLrUAuIn9Qd-oN2LJyNG1nds=.3a7a1133-83a4-4eba-a25b-3b69c219f0ca@github.com>

On Sun, 30 Nov 2025 14:50:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 1:
>> 
>>> 1: Constant Folding in the Hotspot Compiler
>> 
>> I assume any write-up of HotSpot constant folding should move into src/hotspot tree, maybe a block comment in one of the source files?
>
> I intend this to be a user-oriented guide on constant folding. I should just call it constant folding.

I intend this to be a user-oriented guide on constant folding. I should just call it constant folding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573814847

From dl at openjdk.org  Sun Nov 30 17:51:45 2025
From: dl at openjdk.org (Doug Lea)
Date: Sun, 30 Nov 2025 17:51:45 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v23]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <XkUjRPpIeO05FL5XEAhHgPcknvTHLyvGSm-fo-MLuk8=.6736cf51-2c85-4f74-a203-b21d247896df@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea 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 35 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8360046
 - Cleanup
 - For testing
 - Merge branch 'openjdk:master' into JDK-8360046
 - restore positioning of threadlocal clears
 - Add comment
 - Merge branch 'openjdk:master' into JDK-8360046
 - Signal on setParallelism
 - Drop added Contended region; simplify accordingly
 - Tweaks
 - ... and 25 more: https://git.openjdk.org/jdk/compare/64b74bd0...654c1dc6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/0db798b5..654c1dc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=21-22

  Stats: 9533 lines in 293 files changed: 6653 ins; 1426 del; 1454 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From dl at openjdk.org  Sun Nov 30 18:05:52 2025
From: dl at openjdk.org (Doug Lea)
Date: Sun, 30 Nov 2025 18:05:52 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v22]
In-Reply-To: <o7lQ_UAp-iYLBTfKLeA5g3zyM6_0DOoGOMLXx2597hU=.d2ef3aa1-e094-480d-8e97-2324cd43af07@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <-kNPwoBvq5APFT98rnravszAH2whbEnsxzLLgQWhMd8=.751f5a71-b68a-45ae-9535-ebade756b685@github.com>
 <o7lQ_UAp-iYLBTfKLeA5g3zyM6_0DOoGOMLXx2597hU=.d2ef3aa1-e094-480d-8e97-2324cd43af07@github.com>
Message-ID: <IG77hhlu49eojwFJ8v4xp4BgZLaoDB_fqlhgn8IP6L0=.437738c1-b970-43ff-afed-98591c68d40d@github.com>

On Thu, 27 Nov 2025 15:49:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   For testing
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1435:
> 
>> 1433:          */
>> 1434:         final void topLevelExec(ForkJoinTask<?> task, int cfg) {
>> 1435:             int fifo = cfg & FIFO, clr = cfg & CLEAR_TLS;
> 
> @DougLea `clr` isn't used (so there's no clearing of TLs)

This was transiently clobbered but reinstated elsewhere.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2574391655

From duke at openjdk.org  Sun Nov 30 21:55:35 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Sun, 30 Nov 2025 21:55:35 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v4]
In-Reply-To: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
Message-ID: <TtrCqYe1UEGxWwkSjT177Jkp0oXbcT-JVbbSJVC2YSg=.0fe7096c-4b86-4c07-8870-2526293a1f18@github.com>

> The goal of the PR is to improve both, sequential and parallel, sorting of primitives.
> 
> **The main achievements**
> 
> - introduced Radix in parallel sorting which shows several times boost of performance and has linear complexity instead of n*ln(n)
> - improved mixed insertion sort (makes whole sorting faster)
> - improved merging sort for almost sorted data
> - optimized parallel sorting
> - improved step for pivot candidates and pivot partitioning
> - suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError
> - minor javadoc and comment changes
> 
> - extended existing tests
> - added tests for radix sort, heap sort, insertion sort
> - added benchmarking JMH tests
> - improved test coverage
> 
> **The summary of benchmarking:**
> 
> **Sequential sorting (Arrays.sort)**
> 
> byte: up to 50% faster
> char: 4-7 times faster
> short: 2-6 times faster
> int: 1.2-5 times faster
> long: 1.2-5 times faster
> float: 1.2-5 times faster
> double: 1.2-4 times faster
> 
> **Parallel sorting (Arrays.parallelSort)**
> 
> int: 1.2-9 times faster
> long: 1.2-9 times faster
> float: 1.2-4 times faster
> double: 1.2-4 times faster
> 
> **AVX512 support**
> 
> Vamsi Parasa suggested faster sort routines by taking advantage of AVX512 instructions, see https://github.com/openjdk/jdk/pull/14227, sources of sorting were modified. Therefore, I performed benchmarking of the final version (which includes optimizations by Vamsi Parasa and optimizations from my side) on a server with CPUs supported AVX512 instructions, no regression of performance was found, see detailed benchmarking results.
> 
> **High-level chart showing how the actual sorting algorithm is selected
> based on parallel/sequential and input size**
> 
> **int/long/float/double**
> 
> if size < MAX_INSERTION_SORT_SIZE(=51) => [ mixed ] insertion sort
> if array is almost sorted and size > MIN_MERGING_SORT_SIZE(=512) => merging sort
> if recursion depth > MAX_RECURSION_DEPTH(=64) => heap sort
> if random data => two pivots quicksort, else => one pivot quicksort
> 
> **byte**
> 
> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
> else => counting sort
> 
> **char/short**
> 
> if size > MIN_COUNTING_SORT_SIZE(640) => counting sort
> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
> if recursion depth > MAX_RECURSION_DEPTH(=64) => counting sort
> if random data => two pivots quicksort, else => one pivot quicksort
> 
> **parallel sorting (int/long/float/double)**
> 
> if size < MIN_PARALLEL_SORT_SIZE(3K) => sequential sort
> invoke parallel merge sort, depth depends on paral...

Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8266431: Dual-Pivot Quicksort improvements
  
  * Improved mixed insertion sort
  * Created DualPivotQuicksort template
  * Added descitpion of sorting logic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27411/files
  - new: https://git.openjdk.org/jdk/pull/27411/files/bcd2fa3f..013394a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27411&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27411&range=02-03

  Stats: 1860 lines in 3 files changed: 1713 ins; 92 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/27411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27411/head:pull/27411

PR: https://git.openjdk.org/jdk/pull/27411

From duke at openjdk.org  Sun Nov 30 21:55:36 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Sun, 30 Nov 2025 21:55:36 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3]
In-Reply-To: <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
Message-ID: <Ywsx-uzEYWc__9QleBGwos_8AMIf-sU9R9r0hKUdevk=.dc5acfb7-b57e-4ffb-9f2a-18b32cff55ab@github.com>

On Wed, 22 Oct 2025 21:06:04 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> The goal of the PR is to improve both, sequential and parallel, sorting of primitives.
>> 
>> **The main achievements**
>> 
>> - introduced Radix in parallel sorting which shows several times boost of performance and has linear complexity instead of n*ln(n)
>> - improved mixed insertion sort (makes whole sorting faster)
>> - improved merging sort for almost sorted data
>> - optimized parallel sorting
>> - improved step for pivot candidates and pivot partitioning
>> - suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError
>> - minor javadoc and comment changes
>> 
>> - extended existing tests
>> - added tests for radix sort, heap sort, insertion sort
>> - added benchmarking JMH tests
>> - improved test coverage
>> 
>> **The summary of benchmarking:**
>> 
>> **Sequential sorting (Arrays.sort)**
>> 
>> byte: up to 50% faster
>> char: 4-7 times faster
>> short: 2-6 times faster
>> int: 1.2-5 times faster
>> long: 1.2-5 times faster
>> float: 1.2-5 times faster
>> double: 1.2-4 times faster
>> 
>> **Parallel sorting (Arrays.parallelSort)**
>> 
>> int: 1.2-9 times faster
>> long: 1.2-9 times faster
>> float: 1.2-4 times faster
>> double: 1.2-4 times faster
>> 
>> **AVX512 support**
>> 
>> Vamsi Parasa suggested faster sort routines by taking advantage of AVX512 instructions, see https://github.com/openjdk/jdk/pull/14227, sources of sorting were modified. Therefore, I performed benchmarking of the final version (which includes optimizations by Vamsi Parasa and optimizations from my side) on a server with CPUs supported AVX512 instructions, no regression of performance was found, see detailed benchmarking results.
>> 
>> **High-level chart showing how the actual sorting algorithm is selected
>> based on parallel/sequential and input size**
>> 
>> **int/long/float/double**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => [ mixed ] insertion sort
>> if array is almost sorted and size > MIN_MERGING_SORT_SIZE(=512) => merging sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => heap sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **byte**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> else => counting sort
>> 
>> **char/short**
>> 
>> if size > MIN_COUNTING_SORT_SIZE(640) => counting sort
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => counting sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **parallel sorting (int/lo...
>
> Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements
>   
>   * Added @java.io.Serial
>   * Added information about the best data types for thresholds of sorting
>   * Added comments about native implementation based on AVX512 instructions

Hi all,

Please find my latest changes: I improved mixed insertion sort
(and therefore the whole sorting), added description of sorting logic
and created code template to reduce the duplication. Also I
added a generation script.

@DougLea Doug Lea
@jatin-bhateja, @jbhateja Jatin Bhateja
@tarsa Piotr Tarsa

Please look at the latest sources.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3593562248

From duke at openjdk.org  Sun Nov 30 23:43:51 2025
From: duke at openjdk.org (Piotr Tarsa)
Date: Sun, 30 Nov 2025 23:43:51 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3]
In-Reply-To: <Ywsx-uzEYWc__9QleBGwos_8AMIf-sU9R9r0hKUdevk=.dc5acfb7-b57e-4ffb-9f2a-18b32cff55ab@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
 <Ywsx-uzEYWc__9QleBGwos_8AMIf-sU9R9r0hKUdevk=.dc5acfb7-b57e-4ffb-9f2a-18b32cff55ab@github.com>
Message-ID: <KzWK3cKC93OPARxCgknlRNH2achSNcdkqz1hm12gjbs=.9b569afa-a34c-4546-bbf3-1f22a3282681@github.com>

On Sun, 30 Nov 2025 21:51:55 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8266431: Dual-Pivot Quicksort improvements
>>   
>>   * Added @java.io.Serial
>>   * Added information about the best data types for thresholds of sorting
>>   * Added comments about native implementation based on AVX512 instructions
>
> Hi all,
> 
> Please find my latest changes: I improved mixed insertion sort
> (and therefore the whole sorting), added description of sorting logic
> and created code template to reduce the duplication. Also I
> added a generation script.
> 
> @DougLea Doug Lea
> @jatin-bhateja, @jbhateja Jatin Bhateja
> @tarsa Piotr Tarsa
> 
> Please look at the latest sources.

@VladimirIaroslavski: the organization (code partitioning) of the template looks good overall. iiuc the template + generator together are more than twice shorter than the original full java code, so the gains are definitely there. one small extra suggestion (not well thought out so you can ignore it): maybe it would be beneficial to apply such templating to test code too, if that makes sense?

i have one suggestion to test out, i.e. speeding up counting in case the store-to-load forwarding (or memory disambiguation in general) in the cpu is not good enough. the idea is described here: https://fastcompression.blogspot.com/2014/09/counting-bytes-fast-little-trick-from.html and in short it's about replacing one counter array with multiple counter arrays that are modified one after another. the problem only occurs when frequently modifying same counters (i.e. same memory locations) back-to-back, e.g. if you're making histogram of data which has runs of the same value or run of a very few different values (modern cpus perform multiple operations at once, so they can try to count multiple values in parallel). in short: it's all explained in the article. some extra theory as to what is the mechanism in the cpu that's relevant to the counting optimisation is https://en.wikipedia.org/wiki/Load-Hit-Store and https://en.wikipedia.org/wiki/Memory_disambiguation#Store_to_load_forwardin
 g but it's probably enough to just test out the idea without going too deep into theory. using multiple counter arrays of course adds some constant overhead (for allocation at the beginning and merging counters at the end of counting), so it would be beneficial for big enough arrays only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3593881394