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