From haosun at openjdk.org  Fri Aug  1 00:04:02 2025
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 1 Aug 2025 00:04:02 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>
Message-ID: <6CRZBpGwS69ZgWKLmIG7UOj9jPqVxvieJKEAT9lao-Y=.af3bdd20-0a45-4928-8c5b-197b377e8ba3@github.com>

On Wed, 30 Jul 2025 16:26:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Hao,
> 
> > Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
> > Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.
> 
> Thank you for bringing this up. I'm able to reproduce this issue with this newer version of jtreg. I'll take a look to see what's going on.

Thanks for your confirm, Jaikiran.
Forgot to mention that I tested `jdk_all, hotspot_all, langtools_all` with jtreg `8` and only found these two test failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3141675024

From jlu at openjdk.org  Fri Aug  1 00:14:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 00:14:54 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v2]
In-Reply-To: <-jShvVkEpQ1sPrcEvsMOTj-91dL1vm_ZFhw7NSUJ8jE=.7368c6c6-6126-410e-9fa7-b694122c9bc9@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <-jShvVkEpQ1sPrcEvsMOTj-91dL1vm_ZFhw7NSUJ8jE=.7368c6c6-6126-410e-9fa7-b694122c9bc9@github.com>
Message-ID: <Ni6ClTQjiga_f7aTHypy6lZwW3kXtOvuqtCubrInD_Y=.ec492568-d953-4f71-b38c-1064d7b890fb@github.com>

On Thu, 31 Jul 2025 22:04:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/text/DecimalFormat.java line 3544:

> 3542:             var t = text.substring(position, Math.min(tlen, position + alen))
> 3543:                 .replaceAll(lmsp, "-");
> 3544:             return t.regionMatches(0, a, 0, alen);

I presume the original solution was regex for all cases, and you made the single char case for the fast path. If you still have the perf benchmark handy, I wonder how a char by char approach would compare instead of regex. It would also simplify the code since it would be combining the slow and fast path. Although the perf is variable based on the affix string length vs lms length (11).


int i = 0;
for (; position + i < Math.min(tlen, position + alen); i++) {
    int tIndex = lms.indexOf(text.charAt(position + i));
    int aIndex = lms.indexOf(affix.charAt(i));
    // Non LMS. Match direct
    if (tIndex < 0 && aIndex < 0) {
        if (text.charAt(position + i) != affix.charAt(i)) {
            return false;
        }
    } else {
        // By here, at least one LMS. Ensure both LMS.
        if (tIndex < 0 || aIndex < 0) {
            return false;
        }
    }
}
// Return true if entire affix was matched
return i == alen;

test/jdk/java/text/Format/NumberFormat/LenientMinusSignTest.java line 120:

> 118:         public void testLenientPrefix(String sign) throws ParseException {
> 119:             var df = new DecimalFormat(PREFIX, DFS);
> 120:             df.setStrict(false);

No need to set strict as false since `df` is lenient by default. If it was done for clarity, I think the method name already adequately indicates it is a lenient style test. Applies to CNF test as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2246593124
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2246491998

From asemenyuk at openjdk.org  Fri Aug  1 00:30:23 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 1 Aug 2025 00:30:23 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test
Message-ID: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>

- Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
- Test shortcuts in the predefined app image.

Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.

Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.

Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.

Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.

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

Commit messages:
 - LauncherShortcut: bugfix
 - LinuxHelper: Use `gtk-launch` command to launch .desktop files
 - AddLShortcutTest: make it work on Linux
 - WinShortcutVerifier: fix bad merge
 - AddLShortcutTest: add testStartupDirectory() tests to exercise combinations of startup directory in the main launcher and in the additional launcher; add testInvokeShortcuts() to invoke launchers through shortcuts and verify work directory; cover shortcuts in the predefined app image
 - WinShortcutVerifier: add getInvokeShortcutSpecs(); streamline expectLauncherShortcuts()
 - LinuxHelper: add getInvokeShortcutSpecs(); add DesktopFile type to streamline verifyDesktopFile()
 - PrintEnv: support `--print-workdir` CLI option and `jpackage.test.appOutput` Java property to redirect output
 - Rework .desktop files verification: Always verify .desktop files are installed in the system folder on package install and uninstalled on package uninstall. Always verify contents of .desktop files.
 - LauncherAsServiceVerifier: follow-up for the changes in the AdditionalLauncher
 - ... and 12 more: https://git.openjdk.org/jdk/compare/3d74cbe0...8d8e7d8f

Changes: https://git.openjdk.org/jdk/pull/26584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334238
  Stats: 2676 lines in 21 files changed: 1976 ins; 481 del; 219 mod
  Patch: https://git.openjdk.org/jdk/pull/26584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26584/head:pull/26584

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

From missa at openjdk.org  Fri Aug  1 02:47:00 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Fri, 1 Aug 2025 02:47:00 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3]
In-Reply-To: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
Message-ID: <KbmiBeu_cedNpiQZ2ZZYTtfv4XLYLthKSwKzeVOEjXk=.17801272-3e2b-4e31-81f1-af1f70f15d57@github.com>

On Thu, 31 Jul 2025 21:32:16 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
>> 
>> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
>> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
>> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
>> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
>> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
>> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2

@eme64 Available to run the additional tests? Also, a couple of the pre-submit checks had failures unrelated to the code changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3141980741

From asemenyuk at openjdk.org  Fri Aug  1 03:13:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 1 Aug 2025 03:13:53 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test [v2]
In-Reply-To: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
Message-ID: <VXbt3pDqOni1AAbhh4i93TC7knxl2UTHfySm2UhQb8I=.842e7960-85dc-455f-ae63-7dfff43bf0e4@github.com>

> - Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
> - Test shortcuts in the predefined app image.
> 
> Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.
> 
> Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.
> 
> Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.
> 
> Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.

Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision:

 - Consistent log message format
 - AdditionalLauncher: bugfix
 - LauncherShortcut: make it work with the current variant of jpackage without JDK-8308349 mods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26584/files
  - new: https://git.openjdk.org/jdk/pull/26584/files/8d8e7d8f..2d754ee8

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

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

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

From asemenyuk at openjdk.org  Fri Aug  1 03:20:26 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 1 Aug 2025 03:20:26 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test [v3]
In-Reply-To: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
Message-ID: <Qy7s5z2sVeMLvwhTI3kMJaD6uwptzXz5JIpcPXjhiOI=.26d06be5-a047-41db-a335-ab27f59d7cfc@github.com>

> - Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
> - Test shortcuts in the predefined app image.
> 
> Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.
> 
> Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.
> 
> Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.
> 
> Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - Fix a typo
 - Bash script to clean jpackage test log files to reduce noise in diff-s

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26584/files
  - new: https://git.openjdk.org/jdk/pull/26584/files/2d754ee8..b5da8074

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

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

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

From liach at openjdk.org  Fri Aug  1 04:04:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 04:04:52 GMT
Subject: RFR: 8364370: java.text.DecimalFormat specification indentation
 correction
In-Reply-To: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
Message-ID: <RtytsHnkKk8cAYqZNrTKANOcYHj4H4Aq5oNmG6ynwlI=.5bf05824-fd37-41bb-95f1-444a9dd7af72@github.com>

On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this doc only PR.
> 
> java.text.DecimalFormat uses an implSpec tag in the middle of the class description. This location was on purpose as the contents related to the surrounding section. However, this has caused slight indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
> 
> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

I assume this will be backported to 25. This does not happen on 24 but happens on 25 ea.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26585#pullrequestreview-3077580598

From liach at openjdk.org  Fri Aug  1 04:59:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 04:59:03 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v6]
In-Reply-To: <nB8C9HdNf8Sb4QJmdB_czsVwpwC6MMWswamNeb9Fh3g=.49bf352e-5561-41d0-887a-7ab95544b62e@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <nB8C9HdNf8Sb4QJmdB_czsVwpwC6MMWswamNeb9Fh3g=.49bf352e-5561-41d0-887a-7ab95544b62e@github.com>
Message-ID: <9qbN4Of758ARTZowX1K4zEAZ27rDjHs5EjS6fFstAK0=.841e6e2b-45db-43bd-8146-2f9cb576d496@github.com>

On Thu, 31 Jul 2025 19:04:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Less specific reasons for IAE

@vy Can you help review this patch too? For context, `objectFieldOffset(Class, String)` should only find trusted fields and is a bootstrap optimization, while the Field-accepting version is the generic API.

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

PR Comment: https://git.openjdk.org/jdk/pull/25945#issuecomment-3142172712

From vyazici at openjdk.org  Fri Aug  1 09:30:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 1 Aug 2025 09:30:58 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v6]
In-Reply-To: <nB8C9HdNf8Sb4QJmdB_czsVwpwC6MMWswamNeb9Fh3g=.49bf352e-5561-41d0-887a-7ab95544b62e@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <nB8C9HdNf8Sb4QJmdB_czsVwpwC6MMWswamNeb9Fh3g=.49bf352e-5561-41d0-887a-7ab95544b62e@github.com>
Message-ID: <iaKIoL2MA75koWe-uodEQrndwYJtdX_ZuKAjMDuEdmg=.5526f684-e6cb-4247-a268-abb43d9abb4b@github.com>

On Thu, 31 Jul 2025 19:04:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Less specific reasons for IAE

I don't possess sufficient experience on `Unsafe` et al., though given there are no behavioral changes, I presume it should all be fine. I've verified the following:

* `Unsafe` doc improvements
* `U::objectFieldOffset(Class,String)` throws descriptive `IE`
* `U::objectFieldOffset1` is renamed to more descriptive `knownObjectFieldOffset0`
* `Atomic*FieldUpdater` checks and their TCK counterparts (This could have actually been a separate PR, but I see that the component owners gave consent.)
* `AddressComputationContractTest`

I guess you will have a follow-up JBS ticket (along with a PR? ?) for @minborg's [suggestion on consolidating checks in `Atomic*FieldUpdater` classes](https://github.com/openjdk/jdk/pull/25945/files#r2189548142). For instance, I see `AIFU.AIFUImpl::isAncestor` is not even used.

test/jdk/jdk/internal/misc/Unsafe/AddressComputationContractTest.java line 64:

> 62: 
> 63:     @Test
> 64:     void fastObjectFieldOffset() {

Nit: You may want to match the corresponding impl. method name, as you did in other test methods:

Suggestion:

    void knownObjectFieldOffset() {

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25945#pullrequestreview-3078367564
PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2247407686

From bkilambi at openjdk.org  Fri Aug  1 10:41:54 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 1 Aug 2025 10:41:54 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
Message-ID: <ND0_VL3jJpKfqZ7qajzzncDN7uJB6IAq-atF1hM0CvE=.5251d21f-7465-4b1c-808f-a7eee9b1bae8@github.com>

On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

test/micro/org/openjdk/bench/java/lang/VectorBitConversion.java line 3:

> 1: package org.openjdk.bench.java.lang;
> 2: 
> 3: import org.openjdk.jmh.annotations.Benchmark;

This file might also need a Copyright?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2247638120

From duke at openjdk.org  Fri Aug  1 10:51:54 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 1 Aug 2025 10:51:54 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v4]
In-Reply-To: <m6z0vmAes7aQk4QpJsPqS18dcLczUkQ-_52aCm7vIvg=.dd097645-37a0-4398-b725-9230efbe9c1b@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <kkvOk-QQEqJ7Wk5E610EIQtemolyXErsu1y-ku1kRmw=.b7a066ef-9856-472f-9dda-0d31495eff9d@github.com>
 <m6z0vmAes7aQk4QpJsPqS18dcLczUkQ-_52aCm7vIvg=.dd097645-37a0-4398-b725-9230efbe9c1b@github.com>
Message-ID: <X_N_11FX5aBJWon5tOFe_knoDl-GeMkLKuD1xz1oRt0=.e97c9c51-98fa-4867-a970-d18f8b95d38d@github.com>

On Thu, 31 Jul 2025 22:08:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 1002:
>> 
>>> 1000: 
>>> 1001:         if (loadNumberData(locale) instanceof Object[] d &&
>>> 1002:             d[0] instanceof String[] numberElements) {
>> 
>> Should the size be validated here, before accessing `d[0]`?
>
> This should be fine, as there would be no situation where empty array would be returned: https://github.com/openjdk/jdk/blob/724e8c076e1aed05de893ef9366af0e62cc2ac2b/src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java#L223
> I modified the `else` case, where the field was not initialized, btw.

Thanks for checking

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2247668339

From qamai at openjdk.org  Fri Aug  1 12:00:53 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 1 Aug 2025 12:00:53 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
Message-ID: <7UqSdBPWH0SbdkhAUvF_qM10rK0oFsJXhUKWA3VlL14=.0c35e297-7276-468b-98c6-046e84897625@github.com>

On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

`VectorNode::is_reinterpret_opcode` returns `true` for `Op_ReinterpretHF2S` and `Op_ReinterpretS2HF`, which are very similar to the nodes in this PR, can you add these nodes to that method instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3144328104

From duke at openjdk.org  Fri Aug  1 12:06:31 2025
From: duke at openjdk.org (Ayush Rigal)
Date: Fri, 1 Aug 2025 12:06:31 GMT
Subject: RFR: 8364315: Remove unused xml files from
 test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/xmlfiles
Message-ID: <FYHMZIOXmUBPoCikESitbrwWeJ7V_sceOQxIK7_FJyc=.390777f0-d637-4f73-be1b-c7e551b9edb6@github.com>

There are number of unused files in the XML test code base. These are not used in any tests and are not referenced within the code base. They appear to be legacy files. These can be removed.

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

Commit messages:
 - 8364315: Remove unused xml files from test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/xmlfiles

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

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

From alanb at openjdk.org  Fri Aug  1 12:12:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Aug 2025 12:12:01 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
Message-ID: <tTMKUB3oIbOLjBpVzRS-g7IxMEIya9h3JKTJC0UM9xA=.0741de49-4a75-4173-af6f-c90f415c2c42@github.com>

On Wed, 30 Jul 2025 10:39:22 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert non-visible markdown comments to JavaDoc for consistency.

I've done a number of passes over this and overall I think it looks quite good, and gives us a better encapsulated jimage API for jrtfs, the system module finder, and the jrt protocol handler to use. Thanks for taking all the feedback during all the iterations of this.

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

PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3140576069

From jpai at openjdk.org  Fri Aug  1 12:12:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Aug 2025 12:12:02 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
Message-ID: <KiMPEr27K2FCzVhyE_ZbyqrbhpqsJlGhWUmPaw_uDuQ=.752ce1b2-362d-46f7-8ffb-4fb8a377cd59@github.com>

On Wed, 30 Jul 2025 10:39:22 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert non-visible markdown comments to JavaDoc for consistency.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 318:

> 316:         Node buildModulesNode(String name) {
> 317:             assert name.startsWith(MODULES_ROOT + "/") : "Invalid module node name: " + name;
> 318:             // Will fail for non-directory resources since the jimage name does not

Instead of "will fail for ...", should we reword it to "will return null for ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2247818549

From duke at openjdk.org  Fri Aug  1 12:18:37 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 1 Aug 2025 12:18:37 GMT
Subject: RFR: 8077587: BigInteger Roots [v66]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <1pqzM9dutFROzezg0dYK2kpmutMxTXy7rM7lOIm6YT0=.153f0eb9-926a-41f7-9baf-e911bb4cbe97@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Removed dead code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/dbf7b522..8b242fe7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=65
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=64-65

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

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

From bkilambi at openjdk.org  Fri Aug  1 12:19:54 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 1 Aug 2025 12:19:54 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
Message-ID: <UoT_z_H4E_R2wNwHMvnByrhwz9J3OedyOyiSDVvIi8E=.558af8c9-47be-40df-9f11-f37931bd7977@github.com>

On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

src/hotspot/share/opto/vectornode.cpp line 1830:

> 1828: }
> 1829: 
> 1830: bool VectorReinterpretNode::implemented(int opc, uint vlen, BasicType src_type, BasicType dst_type) {

`opc` is not used in this method. Do we need this parameter here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2247834249

From duke at openjdk.org  Fri Aug  1 12:37:46 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 1 Aug 2025 12:37:46 GMT
Subject: RFR: 8077587: BigInteger Roots [v67]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <5XAmoEFyb0LXWYxRjMMn9IKn-yLWsS02Uk8tWkVHahQ=.f4ca9e00-c3d4-479e-a19c-7d841c78a501@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Code simplification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/8b242fe7..20f71485

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=66
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=65-66

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

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

From duke at openjdk.org  Fri Aug  1 12:39:40 2025
From: duke at openjdk.org (Brett Okken)
Date: Fri, 1 Aug 2025 12:39:40 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives
Message-ID: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>

As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.

https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html

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

Commit messages:
 - whitespace
 - use counted positive values when converting latin1 to utf-8

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

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

From duke at openjdk.org  Fri Aug  1 12:41:56 2025
From: duke at openjdk.org (Brett Okken)
Date: Fri, 1 Aug 2025 12:41:56 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives
In-Reply-To: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
Message-ID: <v5rMHbV1UT7DJUJYjmRDSzQAkc_C2g_vWWGT8W50DiE=.9e7e7b2f-adfb-4194-86aa-adf9716c6613@github.com>

On Fri, 1 Aug 2025 12:34:15 GMT, Brett Okken <duke at openjdk.org> wrote:

> As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html

Benchmark on win64

Baseline:


Benchmark                           (charsetName)  Mode  Cnt      Score     Error  Units
StringEncode.encodeAllMixed                 UTF-8  avgt   10  20067.519 ?? 528.152  ns/op
StringEncode.encodeAsciiLong                UTF-8  avgt   10  12115.389 ?? 307.491  ns/op
StringEncode.encodeAsciiShort               UTF-8  avgt   10     70.098 ??   1.696  ns/op
StringEncode.encodeLatin1LongEnd            UTF-8  avgt   10   1974.391 ?? 162.405  ns/op
StringEncode.encodeLatin1LongOnly           UTF-8  avgt   10    270.097 ??  13.840  ns/op
StringEncode.encodeLatin1LongStart          UTF-8  avgt   10   1876.366 ??  51.971  ns/op
StringEncode.encodeLatin1Mixed              UTF-8  avgt   10   4973.070 ?? 130.426  ns/op
StringEncode.encodeLatin1Short              UTF-8  avgt   10     96.227 ??   2.816  ns/op
StringEncode.encodeShortMixed               UTF-8  avgt   10    360.586 ??   8.691  ns/op
StringEncode.encodeUTF16LongEnd             UTF-8  avgt   10   1534.748 ??  34.584  ns/op
StringEncode.encodeUTF16LongOnly            UTF-8  avgt   10    528.919 ??  15.143  ns/op
StringEncode.encodeUTF16LongStart           UTF-8  avgt   10   2275.117 ??  50.152  ns/op
StringEncode.encodeUTF16Mixed               UTF-8  avgt   10   4398.943 ?? 116.607  ns/op
StringEncode.encodeUTF16Short               UTF-8  avgt   10    152.219 ??   8.677  ns/op



Patch:

Benchmark                           (charsetName)  Mode  Cnt      Score     Error  Units
StringEncode.encodeAllMixed                 UTF-8  avgt   10  18876.056 ?? 330.644  ns/op
StringEncode.encodeAsciiLong                UTF-8  avgt   10  12040.590 ?? 165.905  ns/op
StringEncode.encodeAsciiShort               UTF-8  avgt   10     69.895 ??   0.318  ns/op
StringEncode.encodeLatin1LongEnd            UTF-8  avgt   10    574.455 ??  14.769  ns/op
StringEncode.encodeLatin1LongOnly           UTF-8  avgt   10    284.553 ??   1.886  ns/op
StringEncode.encodeLatin1LongStart          UTF-8  avgt   10   2230.789 ??  11.043  ns/op
StringEncode.encodeLatin1Mixed              UTF-8  avgt   10   3278.998 ??  96.779  ns/op
StringEncode.encodeLatin1Short              UTF-8  avgt   10     99.332 ??   1.977  ns/op
StringEncode.encodeShortMixed               UTF-8  avgt   10    378.183 ??  17.504  ns/op
StringEncode.encodeUTF16LongEnd             UTF-8  avgt   10   1531.960 ??  19.300  ns/op
StringEncode.encodeUTF16LongOnly            UTF-8  avgt   10    563.810 ??   4.811  ns/op
StringEncode.encodeUTF16LongStart           UTF-8  avgt   10   2270.970 ??  28.495  ns/op
StringEncode.encodeUTF16Mixed               UTF-8  avgt   10   4403.824 ??  60.338  ns/op
StringEncode.encodeUTF16Short               UTF-8  avgt   10    158.600 ??   2.044  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/26597#issuecomment-3144446972

From bkilambi at openjdk.org  Fri Aug  1 12:44:56 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 1 Aug 2025 12:44:56 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
Message-ID: <Ch3xO_CDKhg91XCyE728txxvyrTaRYxYB8pPtzT-FfI=.afa42b36-ecab-4f20-b22d-678ef03cb9e7@github.com>

On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

test/micro/org/openjdk/bench/java/lang/VectorBitConversion.java line 67:

> 65: 
> 66:     @Benchmark
> 67:     public long[] doubleToLongBits() {

Would something like this be more concise (and maybe more readable as well) - 

@Benchmark
public long[] doubleToLongBits() {
    for (int i = 0; i < doubles.length; i++) {
        resultLongs[i] = Double.doubleToLongBits(doubles[i]);
    }
    return resultLongs;
}


The loop should still get vectorized (if vectorizable).

Same for other benchmarks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2247880010

From bkilambi at openjdk.org  Fri Aug  1 12:48:55 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 1 Aug 2025 12:48:55 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
Message-ID: <yIOUpfDrnLAiZmNc7ILrGSwROp1mgeChBwtXHzTJU9o=.a82140e3-af74-4ece-8850-fcece5abc6f0@github.com>

On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

Although this is not in the scope of this patch, but I wonder if we could rename `ReinterpretS2HF` and `ReinterpretHF2S` to `MoveHF2S` and `MoveS2HF` to keep naming consistent with other types? WDYT @jatin-bhateja

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

PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3144464995

From bkilambi at openjdk.org  Fri Aug  1 12:54:54 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 1 Aug 2025 12:54:54 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
Message-ID: <sbCTlmYeppEWTNLRENsPxpa_gLh0SQq3Wh8B11F_Tcg=.a48c3679-4ba1-4594-ac0c-44f9d16c114f@github.com>

On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

src/hotspot/share/opto/vectornode.cpp line 1831:

> 1829: 
> 1830: bool VectorReinterpretNode::implemented(int opc, uint vlen, BasicType src_type, BasicType dst_type) {
> 1831:   if ((src_type == T_FLOAT && dst_type == T_INT) ||

Just a suggestion, do you feel a `switch-case` could be more readable/clear in this case? Something like this -


bool VectorReinterpretNode::implemented(uint vlen, BasicType src_type, BasicType dst_type) {
  switch (src_type) {
    case T_FLOAT:
      if (dst_type != T_INT)    return false;
      break;
    case T_INT:
      if (dst_type != T_FLOAT)  return false;
      break;
    case T_DOUBLE:
      if (dst_type != T_LONG)   return false;
      break;
    case T_LONG:
      if (dst_type != T_DOUBLE) return false;
      break;
    default:
      return false;
  }
  return Matcher::match_rule_supported_auto_vectorization(Op_VectorReinterpret, vlen, dst_type);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2247906630

From liach at openjdk.org  Fri Aug  1 12:58:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 12:58:54 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives
In-Reply-To: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
Message-ID: <VRuEmh1UuGWan7UfbbxTD9H1JpcuSdZFik968HHU7zY=.217e17e8-4baa-4c4e-bb01-28d1d9007e48@github.com>

On Fri, 1 Aug 2025 12:34:15 GMT, Brett Okken <duke at openjdk.org> wrote:

> As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html

src/java.base/share/classes/java/lang/String.java line 1297:

> 1295:         }
> 1296:         int dp = positives;
> 1297:         for (int i=dp; i<val.length; ++i) {

Suggestion:

        for (int i = dp; i < val.length; ++i) {

Though we usually use `i++` more often, `++i` should be fine too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26597#discussion_r2247915445

From jpai at openjdk.org  Fri Aug  1 13:00:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Aug 2025 13:00:03 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <ogI0LDJwH7ochb54mGArTep8RqX0lnDPrffe9vFaHx4=.4c6560aa-583e-4679-9fdb-228a76198723@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
 <ogI0LDJwH7ochb54mGArTep8RqX0lnDPrffe9vFaHx4=.4c6560aa-583e-4679-9fdb-228a76198723@github.com>
Message-ID: <BgPpj2f046zCLPM-I54DXWaQFa--XK0sb5HCrDsLuIc=.f548c27d-9fd1-41a4-a204-9e56ddc3b5d3@github.com>

On Mon, 21 Jul 2025 11:41:21 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 543:
>> 
>>> 541:         // As such, non-directory nodes are always complete.
>>> 542:         boolean isCompleted() {
>>> 543:             return true;
>> 
>> Seems like a risky default to have this be a concrete method/default that is not required to be overridden.
>> A subclass (not that many here) could forget to override and have a default wrong answer. YMMV.
>
> Hmm, fair. The protected constructor only exists because of ExplodedImage (and I had hoped to be able to get rid of that completely with this work, but sadly couldn't). I added a clear warning to not create other subtypes. I could move this to an abstract method, but honestly I don't think it fixes anything since "completeness" is a concept that only makes sense internally for the implementation in this class (it's package access, so cannot be seen elsewhere). Making it abstract would mean that it needs to be more visible, which I dislike.

In addition to what Roger noted, the default implementation of this `isCompleted()` method and the default implementation of `getLocation()` method a few lines below seem to contradict each other. `isCompleted()` by default returns `true` implying a resource node type but `getLocation()` by default throws an exception, implying a non-resource node type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2247917086

From duke at openjdk.org  Fri Aug  1 13:15:29 2025
From: duke at openjdk.org (Brett Okken)
Date: Fri, 1 Aug 2025 13:15:29 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives [v2]
In-Reply-To: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
Message-ID: <RAEVEwPQn9HITx6gFkIQ-J0jRPhaju86-SmeTFuIxUA=.613dbc86-fdae-4e18-af47-658aba03b557@github.com>

> As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html

Brett Okken has updated the pull request incrementally with one additional commit since the last revision:

  coding conventions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26597/files
  - new: https://git.openjdk.org/jdk/pull/26597/files/947f9182..26bd9d94

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

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

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

From duke at openjdk.org  Fri Aug  1 13:22:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 1 Aug 2025 13:22:02 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <xX177zY5r3FDdea_NHchW29iKE_1e3kUgBS6cl7qI3E=.869de4ff-c291-483b-9db1-710965cc54b5@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
 <_xr23bKDmLusU-_TXQICLnk4Y11GBrIA5jvK-r4GL74=.97a4be69-1de6-4d18-bd2d-21ace429b985@github.com>
 <xX177zY5r3FDdea_NHchW29iKE_1e3kUgBS6cl7qI3E=.869de4ff-c291-483b-9db1-710965cc54b5@github.com>
Message-ID: <8v_wYIOk4uaLiD_YcNgJqfmehuFqJfA9tSb18wASkJU=.f2fcc70b-1799-4951-950a-7e0043664925@github.com>

On Tue, 22 Jul 2025 15:29:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Absolutely. This sort of thing is always a balance between clarity and conciseness. But here I think you're right so I pulled the `name` into a `@param`. I dislike doing it for the return types in most cases though, since that encourages duplication with the method's first sentence.
>
> The {@return 1st sentence text} can be used on the first line and javadoc will put the text in both places without needing duplication in the source.  [(javadoc  tag specification](https://docs.oracle.com/en/java/javase/22/docs/specs/javadoc/doc-comment-spec.html))

I don't think that's better because the "1st sentence text" isn't prefixed with the word "Returns", one if a verb-phase (the action of the method) and the other a noun phrase (the thing returned).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2247975975

From duke at openjdk.org  Fri Aug  1 13:31:06 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 1 Aug 2025 13:31:06 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <yQEkeD2-U6mJaKA2vmTvYxbHk0RTwVKrOwYBJK7VrsU=.41ab750e-cfe7-49dc-b1e0-a1d8dba1ee5f@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
 <yQEkeD2-U6mJaKA2vmTvYxbHk0RTwVKrOwYBJK7VrsU=.41ab750e-cfe7-49dc-b1e0-a1d8dba1ee5f@github.com>
Message-ID: <2IB0CA6O-HFS9dqbQWSy6g0PFjfpdGgGPB7qDb2yVzY=.1e257569-f3b0-42ba-bc93-4cdaee4e190a@github.com>

On Thu, 31 Jul 2025 12:40:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Convert non-visible markdown comments to JavaDoc for consistency.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 70:
> 
>> 68:  *
>> 69:  * <p>While similar to {@code BasicImageReader}, this class is not a conceptual
>> 70:  * subtype of, it and deliberately hides types such as {@code ImageLocation} to
> 
> Hello David, is the comma here after "of" intentional? It reads a bit odd in the current form.

Ta, it should be "of it,", not "of, it".

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 172:
> 
>> 170:         requireOpen();
>> 171:         if (!node.isResource()) {
>> 172:             throw new IllegalStateException("Not a resource node: " + node);
> 
> Should this "public ByteBuffer getResourceBuffer(Node node)" throw `IllegalArgumentException` instead of `IllegalStateException` if the passed `node` isn't a resource node?

Hhm, good point. Most of the other cases are ISE, so maybe I got carried away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2247994894
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2247997480

From duke at openjdk.org  Fri Aug  1 13:31:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 1 Aug 2025 13:31:07 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <58dZrvPejcKmpsrPdcmzCJWoXR_Tu_inMfk8PuB1zmE=.096138ee-f88d-4a88-8e3b-657ca77d985d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
 <58dZrvPejcKmpsrPdcmzCJWoXR_Tu_inMfk8PuB1zmE=.096138ee-f88d-4a88-8e3b-657ca77d985d@github.com>
Message-ID: <yqDmyqvYQ_hz_TyVegcMtXr2lTYftiT4V-zy0qs0VLg=.65c5808a-0a3c-4dad-90cf-9a76bf4b62de@github.com>

On Wed, 23 Jul 2025 06:50:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback changes.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 106:
> 
>> 104:      *
>> 105:      * <p>This is the expected was to open an {@code ImageReader}, and it should
>> 106:      * be rare for anything other than the native byte order to be needed.
> 
> I think the "Almost all callers" and "This is the expected was (typo)" comments are confusing. Can we remove these?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2247989719

From duke at openjdk.org  Fri Aug  1 13:31:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 1 Aug 2025 13:31:08 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <BgPpj2f046zCLPM-I54DXWaQFa--XK0sb5HCrDsLuIc=.f548c27d-9fd1-41a4-a204-9e56ddc3b5d3@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
 <ogI0LDJwH7ochb54mGArTep8RqX0lnDPrffe9vFaHx4=.4c6560aa-583e-4679-9fdb-228a76198723@github.com>
 <BgPpj2f046zCLPM-I54DXWaQFa--XK0sb5HCrDsLuIc=.f548c27d-9fd1-41a4-a204-9e56ddc3b5d3@github.com>
Message-ID: <E1vsxqCnRs23ckizuiD3OMGnjKC1BBn1HM4PzmWZbQ0=.de3a2a6a-c63c-44c6-8a2b-13d28224aa6f@github.com>

On Fri, 1 Aug 2025 12:56:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hmm, fair. The protected constructor only exists because of ExplodedImage (and I had hoped to be able to get rid of that completely with this work, but sadly couldn't). I added a clear warning to not create other subtypes. I could move this to an abstract method, but honestly I don't think it fixes anything since "completeness" is a concept that only makes sense internally for the implementation in this class (it's package access, so cannot be seen elsewhere). Making it abstract would mean that it needs to be more visible, which I dislike.
>
> In addition to what Roger noted, the default implementation of this `isCompleted()` method and the default implementation of `getLocation()` method a few lines below seem to contradict each other. `isCompleted()` by default returns `true` implying a resource node type but `getLocation()` by default throws an exception, implying a non-resource node type.

"is completed" is a non-directory type, "getLocation() failing" is a non-resource type. The abstract class is consistently saying "I'm not a thing of /that/ type" (because it isn't and these are the only answers it can give).
I don't think there's *any* risk or issue here. The abstract class is internal, clearly documented and overloaded exactly once by a trusted collaborator. Do you really think this is a "risk"? And if you do, please give your suggestion as to what would be better. Otherwise nothing is actionable here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2247987436

From duke at openjdk.org  Fri Aug  1 13:35:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 1 Aug 2025 13:35:03 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <ozQQw711FChfevZp5IRUYKc1n1yAV6CQAtymTxhfDf4=.fcf26d23-139d-43f1-b20c-c7b69760242f@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
 <ozQQw711FChfevZp5IRUYKc1n1yAV6CQAtymTxhfDf4=.fcf26d23-139d-43f1-b20c-c7b69760242f@github.com>
Message-ID: <8izHB4JDk9LtR0U6md-kqYjLJequQLe12SD4FRyXfh0=.d0eacf57-c860-4973-9046-24730078f773@github.com>

On Thu, 31 Jul 2025 13:42:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Convert non-visible markdown comments to JavaDoc for consistency.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 283:
> 
>> 281:          *
>> 282:          * <p>Note also that there is no reentrant calling back to this method from within
>> 283:          * the node handling code.
> 
> This paragraph and the previous one feels like too much detail and I'm not sure they are necessary.

As someone who struggled through understanding this code, mainly do to sparse comments, I added additional information for the next maintainer. The no-reentrant calling behaviour is actually important to avoid issues during evaluation, and I tripped over this at least once (hence a comment). Happy to reframe it as "future changes shouldn't call back reentrantly" (as an instruction, not an observation).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2248004502

From mullan at openjdk.org  Fri Aug  1 13:40:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 1 Aug 2025 13:40:06 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
Message-ID: <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>

On Thu, 31 Jul 2025 12:58:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan 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:
> 
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

Can you attach a snapshot of the output with these new settings?

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3144624195

From jpai at openjdk.org  Fri Aug  1 13:40:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Aug 2025 13:40:05 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <E1vsxqCnRs23ckizuiD3OMGnjKC1BBn1HM4PzmWZbQ0=.de3a2a6a-c63c-44c6-8a2b-13d28224aa6f@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
 <ogI0LDJwH7ochb54mGArTep8RqX0lnDPrffe9vFaHx4=.4c6560aa-583e-4679-9fdb-228a76198723@github.com>
 <BgPpj2f046zCLPM-I54DXWaQFa--XK0sb5HCrDsLuIc=.f548c27d-9fd1-41a4-a204-9e56ddc3b5d3@github.com>
 <E1vsxqCnRs23ckizuiD3OMGnjKC1BBn1HM4PzmWZbQ0=.de3a2a6a-c63c-44c6-8a2b-13d28224aa6f@github.com>
Message-ID: <U5RvuCphGAlVfxyUmcSZFtm-dm9PudIfA7--HMmSSOU=.e6eab399-8ee1-43e9-895d-ab0b9de66229@github.com>

On Fri, 1 Aug 2025 13:24:36 GMT, David Beaumont <duke at openjdk.org> wrote:

> "is completed" is a non-directory type, "getLocation() failing" is a non-resource type.

If getLocation() by default throws a `IllegalStateException` stating that the `Node` is not a resource type, then I think it would be more accurate for `isCompleted()` to by default return `false` to match the claim that the `Node` is not a resource type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2248013833

From duke at openjdk.org  Fri Aug  1 13:45:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 1 Aug 2025 13:45:02 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <xX177zY5r3FDdea_NHchW29iKE_1e3kUgBS6cl7qI3E=.869de4ff-c291-483b-9db1-710965cc54b5@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
 <_xr23bKDmLusU-_TXQICLnk4Y11GBrIA5jvK-r4GL74=.97a4be69-1de6-4d18-bd2d-21ace429b985@github.com>
 <xX177zY5r3FDdea_NHchW29iKE_1e3kUgBS6cl7qI3E=.869de4ff-c291-483b-9db1-710965cc54b5@github.com>
Message-ID: <_QykBndndTgfhZM749uD3Icw5HXm1PSZ4rMKSGxgHls=.5ba47d29-a073-4469-9184-6f3c29a18582@github.com>

On Tue, 22 Jul 2025 15:26:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> True, though would you prefer to change the comment ("by default this method throws... and is overridden by directory subclasses...") or the implementation of things like `getChildNames()` so they call `isDirectory()` ?
>> 
>> Personally I dislike this "test and call" approach and would rather have restructured the API to be more object-oriented, and have callers use a more structured dispatch mechanism (but this would incur cost of lambdas etc.), but that's a really disruptive change.
>> 
>> Alternatively a type token/enum of some sort could be used to define node type. This is all internal/trusted API though, so I'm happy with trusting that things "do what they say" (it's going to be really obvious if something claims to be a directory and then throws when asks for its child names, and that's almost exclusively why anyone calls isDirectory() to start with).
>> 
>> So in summary, apart from maybe tweaking the comment slightly, I think this is fine as is.
>
> I would change the comment.

Comment changed, though note that I can't @link to Directory because it's a non-visible type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2248026262

From duke at openjdk.org  Fri Aug  1 13:54:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 1 Aug 2025 13:54:03 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <ozQQw711FChfevZp5IRUYKc1n1yAV6CQAtymTxhfDf4=.fcf26d23-139d-43f1-b20c-c7b69760242f@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
 <ozQQw711FChfevZp5IRUYKc1n1yAV6CQAtymTxhfDf4=.fcf26d23-139d-43f1-b20c-c7b69760242f@github.com>
Message-ID: <VCLJXIRzm8QTdPZhmcKjc3dtpPeK9ogX0mJuJjZH4_U=.6c087040-26cc-43a1-a1b2-29bb9eff95e6@github.com>

On Thu, 31 Jul 2025 13:04:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Convert non-visible markdown comments to JavaDoc for consistency.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 189:
> 
>> 187:         private final Set<ImageReader> openers = new HashSet<>();
>> 188: 
>> 189:         // Attributes of the .jimage file. The jimage file does not contain
> 
> Nit - (pre-existing) calling it a `.jimage` file makes it look like `jimage` is a (well known) extension for jimage files. As far as I know, it isn't (the default jimage file that we ship in the JDK is just named `modules`). Perhaps we should change this to "Attributes of the jimage file."?

Good call. It's definitely not the file extension.

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 195:
> 
>> 193: 
>> 194:         // Cache of all user visible nodes, guarded by synchronizing 'this' instance.
>> 195:         private final HashMap<String, Node> nodes;
> 
> Pre-existing, but since we are cleaning up some of this code, perhaps we can make this declaration a `Map` instead of a `HashMap`?

Done.

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 316:
> 
>> 314:          * is not present in the cache.
>> 315:          */
>> 316:         Node buildModulesNode(String name) {
> 
> Should this be `private` method?

Done, ta.

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 318:
> 
>> 316:         Node buildModulesNode(String name) {
>> 317:             assert name.startsWith(MODULES_ROOT + "/") : "Invalid module node name: " + name;
>> 318:             // Will fail for non-directory resources since the jimage name does not
> 
> Instead of "will fail for ...", should we reword it to "will return null for ..."

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2248042724
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2248040245
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2248045113
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2248047716

From duke at openjdk.org  Fri Aug  1 13:54:04 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 1 Aug 2025 13:54:04 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <PeFJ7ADhkpVqSWbybg5K8pu-Lvv4LJNgOr1e-VzcARc=.5b836d65-b2b0-411b-b660-ab7b9f4d1f23@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
 <rnTrM1C_f2-DgXtPaInMsZkdJoQYcH9IsXQUD5twyAE=.b66d6278-c4fc-4675-860b-786c6f8003f8@github.com>
 <rKnKLZeDI3kGz7YPIfNBsZmtMKt4EgmyiuYsFcSFUWM=.8c2760c2-0785-4dad-b002-563c73d7f6cf@github.com>
 <PeFJ7ADhkpVqSWbybg5K8pu-Lvv4LJNgOr1e-VzcARc=.5b836d65-b2b0-411b-b660-ab7b9f4d1f23@github.com>
Message-ID: <ormcPnP4LCEit-fhKEBSxvxuB-S47J4OA1Z-9pvaG2o=.531dcee2-6520-4427-9e8f-28e98b6dc71e@github.com>

On Thu, 31 Jul 2025 13:58:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I don't think I can, can I? That method takes a Runnable, not some sort of Callable that throws E.
>
> The construct that Alan suggested works fine here. The fact that ImageReader.open() returns some value shouldn't matter here. I gave this a try locally and the use of `assertThrows(...)` with `ImageReader.open(...)` works as expected.

Ahh, I hadn't spotted that it's using a "ThrowingRunnable" type. I think my code completion might have picked up a different assertThrows() method when I looked at it. Ta for testing.
Sadly the failure message is lost now though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2248035536

From duke at openjdk.org  Fri Aug  1 14:02:27 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 1 Aug 2025 14:02:27 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v17]
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <OaOpZpWlp-Rmftv4mDJndJk4Ae_d9W3hrI6JXglB7lo=.3f8ca640-8d29-4a5d-acb0-50264b85d8dd@github.com>

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  More review feedback tweaks.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/5b8e8250..2e78d0db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=15-16

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

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

From mdonovan at openjdk.org  Fri Aug  1 14:10:54 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 1 Aug 2025 14:10:54 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>
Message-ID: <P4OFtEPX7OPcZFERND0ToyPzWVzz4jZUIL46qhtAMHQ=.c5cc4e86-d7ab-4826-ba07-85f5cdc88231@github.com>

On Fri, 1 Aug 2025 13:36:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Can you attach a snapshot of the output with these new settings?

<img width="1037" height="997" alt="Screenshot 2025-08-01 at 10 07 32?AM" src="https://github.com/user-attachments/assets/0d2efc34-629e-4510-8de9-3acc068a6446" />

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3144715904

From coffeys at openjdk.org  Fri Aug  1 14:24:11 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 1 Aug 2025 14:24:11 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
Message-ID: <7pqiE7w7YX6ojyK5Kw7T7LdcwJRqrt-g7EfyCLEzs_Q=.bd4d6ea1-dd60-461c-b40d-e5a6db03f2ad@github.com>

On Thu, 31 Jul 2025 12:58:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan 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:
> 
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

LGTM

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24424#pullrequestreview-3079441371

From mullan at openjdk.org  Fri Aug  1 14:30:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 1 Aug 2025 14:30:56 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <P4OFtEPX7OPcZFERND0ToyPzWVzz4jZUIL46qhtAMHQ=.c5cc4e86-d7ab-4826-ba07-85f5cdc88231@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>
 <P4OFtEPX7OPcZFERND0ToyPzWVzz4jZUIL46qhtAMHQ=.c5cc4e86-d7ab-4826-ba07-85f5cdc88231@github.com>
Message-ID: <nG5OTE_uS_t-jXoIJzhDrKi0g9dhP1I1gDGoDY7vbYI=.b414aa67-e0fa-48cf-b49d-a10ed77b5ff6@github.com>

On Fri, 1 Aug 2025 14:08:18 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> > Can you attach a snapshot of the output with these new settings?
> 

I can't see all of the groups or the signature algorithms. Is it truncated?

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3144783388

From duke at openjdk.org  Fri Aug  1 15:00:03 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 1 Aug 2025 15:00:03 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
 <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
 <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>
Message-ID: <zOTX9iQJ7lBJQBJqbjsLxpnZDGIcT7J2F2anwqQgK7k=.a3ec5a23-d70b-4345-804d-3a4e3472280c@github.com>

On Wed, 30 Jul 2025 10:57:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I?mean the?existing private?fields of?`SharedSecrets`[^1] so?that the?JIT is?able to?constant?fold calls?to?`SharedSecrets?::getJava*Access()` so?that it?becomes equally?as?performant as?using a?`Holder`?class.
>> 
>> Modifiers are?transient, as?those are?sourced?from the?`InnerClasses`?attribute, which?can?be?changed when?classes are?redefined by?a?**JVMTI**?agent, but?access?flags can?t?be?changed through?redefinition.
>> 
>> [^1]: https://github.com/openjdk/jdk/blob/330ee871315348594171c43aa75b58f6027001af/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java#L62-L92
>
> I don't think inner class attributes can be changed via JVMTI RedefineClasses either.  I'm pretty sure we check and that's considered a change of schema.  File an RFE to make SharedSecrets fields @Stable though for a different change.

I?don?t?have a?**JBS**?account, and?I?don?t?like going?through <https://bugreport.java.com>, so?could someone?else file?said?**RFE**?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248196045

From rriggs at openjdk.org  Fri Aug  1 15:12:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Aug 2025 15:12:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <zOTX9iQJ7lBJQBJqbjsLxpnZDGIcT7J2F2anwqQgK7k=.a3ec5a23-d70b-4345-804d-3a4e3472280c@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
 <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
 <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>
 <zOTX9iQJ7lBJQBJqbjsLxpnZDGIcT7J2F2anwqQgK7k=.a3ec5a23-d70b-4345-804d-3a4e3472280c@github.com>
Message-ID: <_0yq0VEEVe1apROVSN5nckimKR_PQOurkq3Rc_qxCwo=.6e7f9c28-6ab6-4561-8336-8133d14badf5@github.com>

On Fri, 1 Aug 2025 14:57:03 GMT, ExE Boss <duke at openjdk.org> wrote:

>> I don't think inner class attributes can be changed via JVMTI RedefineClasses either.  I'm pretty sure we check and that's considered a change of schema.  File an RFE to make SharedSecrets fields @Stable though for a different change.
>
> I?don?t?have a?**JBS**?account, and?I?don?t?like going?through <https://bugreport.java.com>, so?could someone?else file?said?**RFE**?

Created https://bugs.openjdk.org/browse/JDK-8364540

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248224660

From mdonovan at openjdk.org  Fri Aug  1 15:15:01 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 1 Aug 2025 15:15:01 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <nG5OTE_uS_t-jXoIJzhDrKi0g9dhP1I1gDGoDY7vbYI=.b414aa67-e0fa-48cf-b49d-a10ed77b5ff6@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>
 <P4OFtEPX7OPcZFERND0ToyPzWVzz4jZUIL46qhtAMHQ=.c5cc4e86-d7ab-4826-ba07-85f5cdc88231@github.com>
 <nG5OTE_uS_t-jXoIJzhDrKi0g9dhP1I1gDGoDY7vbYI=.b414aa67-e0fa-48cf-b49d-a10ed77b5ff6@github.com>
Message-ID: <ev0QpCdSdHP94MUhWURRRszmhIpg8G5BhKvWcJ2cB1M=.5d2aa605-97fd-4a49-b97e-622164019407@github.com>

On Fri, 1 Aug 2025 14:28:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > Can you attach a snapshot of the output with these new settings?
> 
> I can't see all of the groups or the signature algorithms. Is it truncated?

It's not truncated, I just needed to resize the terminal window for a screenshot.
<img width="463" height="909" alt="Screenshot 2025-08-01 at 11 11 11?AM" src="https://github.com/user-attachments/assets/a39b6cd2-2e94-4ba4-a872-75e2cf01b0cc" />

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3144909601

From coleenp at openjdk.org  Fri Aug  1 15:25:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 1 Aug 2025 15:25:02 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <Nr-UUunnDCGoWJoIBr77q58_1ThDFEX-6vnWFTo01yE=.8ae9dbcb-ddcc-4f84-9816-5de395e839da@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

Thank you for reviewing Tobias, Roger and Chen.

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

PR Comment: https://git.openjdk.org/jdk/pull/26517#issuecomment-3144938447

From coleenp at openjdk.org  Fri Aug  1 15:25:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 1 Aug 2025 15:25:03 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <_0yq0VEEVe1apROVSN5nckimKR_PQOurkq3Rc_qxCwo=.6e7f9c28-6ab6-4561-8336-8133d14badf5@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
 <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
 <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>
 <zOTX9iQJ7lBJQBJqbjsLxpnZDGIcT7J2F2anwqQgK7k=.a3ec5a23-d70b-4345-804d-3a4e3472280c@github.com>
 <_0yq0VEEVe1apROVSN5nckimKR_PQOurkq3Rc_qxCwo=.6e7f9c28-6ab6-4561-8336-8133d14badf5@github.com>
Message-ID: <qtwv2gD8ZM7JHaR64AvAi16QItv4CZOrT3Bc1-29A-U=.d3420e33-b31b-4b18-b9e9-d36cab0e0096@github.com>

On Fri, 1 Aug 2025 15:10:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I?don?t?have a?**JBS**?account, and?I?don?t?like going?through <https://bugreport.java.com>, so?could someone?else file?said?**RFE**?
>
> Created https://bugs.openjdk.org/browse/JDK-8364540

Thanks Roger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248246788

From coleenp at openjdk.org  Fri Aug  1 15:25:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 1 Aug 2025 15:25:04 GMT
Subject: Integrated: 8364187: Make getClassAccessFlagsRaw non-native
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <2HVJZKZ8FwStZduaGH4jA-zQsd8VDH4VF_1lnO1lDlY=.790ad8b0-d8da-43c5-81d5-97387b6ddcad@github.com>

On Mon, 28 Jul 2025 20:14:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: ee3665bc
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee3665bca026fe53409df8391d49477c64ae23a2
Stats:     128 lines in 16 files changed: 61 ins; 36 del; 31 mod

8364187: Make getClassAccessFlagsRaw non-native

Reviewed-by: thartmann, rriggs, liach

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

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

From coleenp at openjdk.org  Fri Aug  1 15:25:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 1 Aug 2025 15:25:03 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <h0k-2CPFK6Zh2eVLqfuvVDUmxXo5Drkgo-0XVM85A3s=.9b435eba-01c4-4dd3-933b-ed0cdb89187a@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>
 <WaSIOivDQRRQnonz9wGKjhjtHhtDduz6boD7uMyM86Y=.e62e0a8c-0f0c-4e23-846f-3744707527fa@github.com>
 <h0k-2CPFK6Zh2eVLqfuvVDUmxXo5Drkgo-0XVM85A3s=.9b435eba-01c4-4dd3-933b-ed0cdb89187a@github.com>
Message-ID: <jIpeMc9SvMoKF4H612gN8vP-VpMJb81CxP9gwG-W2Eg=.95089384-3d63-4e78-980f-9c84262953bd@github.com>

On Tue, 29 Jul 2025 14:35:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is a good suggestion but I made it Raw to match getRawClassAnnotations this name.
>
> Thanks for the rename. I think `raw annotations` means the uninterpreted byte data in the attribute is carried over raw; this concept is less applicable to the access_flags u2 value.

Thank you for the suggested name change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248245044

From mullan at openjdk.org  Fri Aug  1 15:31:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 1 Aug 2025 15:31:00 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
Message-ID: <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>

On Thu, 31 Jul 2025 12:58:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan 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:
> 
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

Thanks for the latest screenshot. I don't think the signature algorithms should be "none". If we can't access the provider-specific defaults, then I think we should omit this information for now. @artur-oracle or @haimaychao can you check this out and see if there is a way to get those defaults? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3144961133

From rriggs at openjdk.org  Fri Aug  1 15:31:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Aug 2025 15:31:59 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives [v2]
In-Reply-To: <RAEVEwPQn9HITx6gFkIQ-J0jRPhaju86-SmeTFuIxUA=.613dbc86-fdae-4e18-af47-658aba03b557@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
 <RAEVEwPQn9HITx6gFkIQ-J0jRPhaju86-SmeTFuIxUA=.613dbc86-fdae-4e18-af47-658aba03b557@github.com>
Message-ID: <Q3cI9cbPOXCigpTCJMU3_z1nnWN--VUxH_JH-YZwl7Q=.85a7a4c8-6896-46e5-9e9a-03b2dee2efdf@github.com>

On Fri, 1 Aug 2025 13:15:29 GMT, Brett Okken <duke at openjdk.org> wrote:

>> As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coding conventions

src/java.base/share/classes/java/lang/String.java line 1293:

> 1291: 
> 1292:         byte[] dst = StringUTF16.newBytesFor(val.length);
> 1293:         if (positives > 0) {

I wonder if for very short strings, the overhead of the setup for `arraycopy` is worth it.
It might be interesting to raise the test here to 4 or 8 for the array copy  and otherwise start the loop at 0 and see if the performance difference is detectable.

src/java.base/share/classes/java/lang/String.java line 1297:

> 1295:         }
> 1296:         int dp = positives;
> 1297:         for (int i=dp; i<val.length; ++i) {

Spaces are preferred around operators.  (Match style in the rest of the file).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26597#discussion_r2248269084
PR Review Comment: https://git.openjdk.org/jdk/pull/26597#discussion_r2248254384

From bpb at openjdk.org  Fri Aug  1 15:44:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 1 Aug 2025 15:44:55 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v5]
In-Reply-To: <kJJVhUhIjdv5bhF2UUoPNze4bBgBGula-2ps0QDR1hk=.0a3102d1-b4c3-4b96-b042-b3c16cab23bb@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <kJJVhUhIjdv5bhF2UUoPNze4bBgBGula-2ps0QDR1hk=.0a3102d1-b4c3-4b96-b042-b3c16cab23bb@github.com>
Message-ID: <nNyIZGYCU70WPexx77qasZ_0yjubEBMahR0LB9oroHE=.fb16847e-95b9-4137-8a56-14884c548f2f@github.com>

On Thu, 31 Jul 2025 22:16:55 GMT, Darragh Conway <duke at openjdk.org> wrote:

>> There were a couple of post review comments for PR: https://github.com/openjdk/jdk/pull/26193 after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.
>
> Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed blank lines at end of file

Looks all right now.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26445#pullrequestreview-3079709015

From liach at openjdk.org  Fri Aug  1 16:14:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 16:14:58 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives
In-Reply-To: <v5rMHbV1UT7DJUJYjmRDSzQAkc_C2g_vWWGT8W50DiE=.9e7e7b2f-adfb-4194-86aa-adf9716c6613@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
 <v5rMHbV1UT7DJUJYjmRDSzQAkc_C2g_vWWGT8W50DiE=.9e7e7b2f-adfb-4194-86aa-adf9716c6613@github.com>
Message-ID: <LEbHkOhn5zKsiTkx2JqQDwLnDbKa3QXYDi2154TIpPQ=.9f0e0bfa-00c1-4427-a33c-85861d6e247e@github.com>

On Fri, 1 Aug 2025 12:39:05 GMT, Brett Okken <duke at openjdk.org> wrote:

>> As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html
>
> Benchmark on win64
> 
> Baseline:
> 
> 
> Benchmark                           (charsetName)  Mode  Cnt      Score     Error  Units
> StringEncode.encodeAllMixed                 UTF-8  avgt   10  20067.519 ?? 528.152  ns/op
> StringEncode.encodeAsciiLong                UTF-8  avgt   10  12115.389 ?? 307.491  ns/op
> StringEncode.encodeAsciiShort               UTF-8  avgt   10     70.098 ??   1.696  ns/op
> StringEncode.encodeLatin1LongEnd            UTF-8  avgt   10   1974.391 ?? 162.405  ns/op
> StringEncode.encodeLatin1LongOnly           UTF-8  avgt   10    270.097 ??  13.840  ns/op
> StringEncode.encodeLatin1LongStart          UTF-8  avgt   10   1876.366 ??  51.971  ns/op
> StringEncode.encodeLatin1Mixed              UTF-8  avgt   10   4973.070 ?? 130.426  ns/op
> StringEncode.encodeLatin1Short              UTF-8  avgt   10     96.227 ??   2.816  ns/op
> StringEncode.encodeShortMixed               UTF-8  avgt   10    360.586 ??   8.691  ns/op
> StringEncode.encodeUTF16LongEnd             UTF-8  avgt   10   1534.748 ??  34.584  ns/op
> StringEncode.encodeUTF16LongOnly            UTF-8  avgt   10    528.919 ??  15.143  ns/op
> StringEncode.encodeUTF16LongStart           UTF-8  avgt   10   2275.117 ??  50.152  ns/op
> StringEncode.encodeUTF16Mixed               UTF-8  avgt   10   4398.943 ?? 116.607  ns/op
> StringEncode.encodeUTF16Short               UTF-8  avgt   10    152.219 ??   8.677  ns/op
> 
> 
> 
> Patch:
> 
> Benchmark                           (charsetName)  Mode  Cnt      Score     Error  Units
> StringEncode.encodeAllMixed                 UTF-8  avgt   10  18876.056 ?? 330.644  ns/op
> StringEncode.encodeAsciiLong                UTF-8  avgt   10  12040.590 ?? 165.905  ns/op
> StringEncode.encodeAsciiShort               UTF-8  avgt   10     69.895 ??   0.318  ns/op
> StringEncode.encodeLatin1LongEnd            UTF-8  avgt   10    574.455 ??  14.769  ns/op
> StringEncode.encodeLatin1LongOnly           UTF-8  avgt   10    284.553 ??   1.886  ns/op
> StringEncode.encodeLatin1LongStart          UTF-8  avgt   10   2230.789 ??  11.043  ns/op
> StringEncode.encodeLatin1Mixed              UTF-8  avgt   10   3278.998 ??  96.779  ns/op
> StringEncode.encodeLatin1Short              UTF-8  avgt   10     99.332 ??   1.977  ns/op
> StringEncode.encodeShortMixed               UTF-8  avgt   10    378.183 ??  17.504  ns/op
> StringEncode.encodeUTF16LongEnd             UTF-8  avgt   10   1531.960 ??  19.300  ns/op
> StringEncode.encodeUTF16LongOnly            UTF-8  avgt   10    563.810 ??   4.811  ns/op
> StringEncode.encodeUTF16LongS...

@bokken FYI to make JMH comparison easier, you can let JMH generate JSON reports, upload them to github gists, and use https://jmh.morethan.io/ to compare the two results from two gists.

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

PR Comment: https://git.openjdk.org/jdk/pull/26597#issuecomment-3145088238

From liach at openjdk.org  Fri Aug  1 16:16:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 16:16:01 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v7]
In-Reply-To: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>

> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Test update advised by volkan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25945/files
  - new: https://git.openjdk.org/jdk/pull/25945/files/d920ec13..1ce1415c

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

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

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

From liach at openjdk.org  Fri Aug  1 16:29:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 16:29:04 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v6]
In-Reply-To: <iaKIoL2MA75koWe-uodEQrndwYJtdX_ZuKAjMDuEdmg=.5526f684-e6cb-4247-a268-abb43d9abb4b@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <nB8C9HdNf8Sb4QJmdB_czsVwpwC6MMWswamNeb9Fh3g=.49bf352e-5561-41d0-887a-7ab95544b62e@github.com>
 <iaKIoL2MA75koWe-uodEQrndwYJtdX_ZuKAjMDuEdmg=.5526f684-e6cb-4247-a268-abb43d9abb4b@github.com>
Message-ID: <0JXst5iEe0Q1pZ941WaDNn_MbrhH87DtaZXXg0fYtx4=.eaaa8d5b-9f13-47bf-a772-e696b6faae26@github.com>

On Fri, 1 Aug 2025 09:11:07 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Less specific reasons for IAE
>
> test/jdk/jdk/internal/misc/Unsafe/AddressComputationContractTest.java line 64:
> 
>> 62: 
>> 63:     @Test
>> 64:     void fastObjectFieldOffset() {
> 
> Nit: You may want to match the corresponding impl. method name, as you did in other test methods:
> 
> Suggestion:
> 
>     void knownObjectFieldOffset() {

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2248387724

From liach at openjdk.org  Fri Aug  1 16:31:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 16:31:56 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4]
In-Reply-To: <KTciYdwCgUJ1otXc_7HjgGHWqLioPuVWVnhEeTFpQxw=.afc39270-80d2-443e-888d-cf98260519d5@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
 <rYXSnbM_L_gYi6HtWacqGzKVxh9FutK3xvqNKleIcIE=.7c02c7e2-3305-4c47-b80b-e1c695e507c1@github.com>
 <KTciYdwCgUJ1otXc_7HjgGHWqLioPuVWVnhEeTFpQxw=.afc39270-80d2-443e-888d-cf98260519d5@github.com>
Message-ID: <b4c0rPM82UmOqD7gnt0D6h81HLNFGNwfFLkCp2MzR-M=.2969c08f-584e-4185-aa85-773f52409fc4@github.com>

On Mon, 7 Jul 2025 12:05:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 405:
>> 
>>> 403:                 throw new IllegalArgumentException("Must be volatile type");
>>> 404: 
>>> 405:             if (Modifier.isStatic(modifiers))
>> 
>> Can we break out the Modifier tests in the three updater classes to a common method?
>
> Should we include that in this patch?

Created https://bugs.openjdk.org/browse/JDK-8364544 to track that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2248393574

From liach at openjdk.org  Fri Aug  1 16:41:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 16:41:37 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v9]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <GbdAr9fWbrVloxGW5nYqprt4WsQaXoHPYjjDVg810mY=.9752922a-3a0c-42ec-8163-a5eea78b2749@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Fixes
 - Fix sourceversion test
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java
 - Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
   
   Co-authored-by: Luca Kellermann <lukellmann at gmail.com>
 - Don't need to update latestSupported later
   
 - ... and 4 more: https://git.openjdk.org/jdk/compare/ee3665bc...ce9cf84b

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=08
  Stats: 1284 lines in 6 files changed: 1138 ins; 87 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/25017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017

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

From jlu at openjdk.org  Fri Aug  1 16:42:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 16:42:56 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v4]
In-Reply-To: <DtV-__lo4sL7akdq2buxSm7YkxFnN7jZzpFtFD7H2ug=.df4332a4-eb68-4d94-b8ab-273dc2b90c6e@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <DtV-__lo4sL7akdq2buxSm7YkxFnN7jZzpFtFD7H2ug=.df4332a4-eb68-4d94-b8ab-273dc2b90c6e@github.com>
Message-ID: <MiG-GBgAmxpwAoSrwD16zeY7QS_QJZkBp6IqLOG2xcA=.86525e07-d632-48ff-bed0-a26ce4d08ab2@github.com>

On Thu, 31 Jul 2025 22:30:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   flipped again, which was correct

src/java.base/share/classes/java/text/DecimalFormat.java line 422:

> 420:  * @implNote The default implementation follows the LDML specification for
> 421:  * {@code parseLenient} elements to interpret minus sign patterns when lenient
> 422:  * parsing is enabled.

IMO, the following is more clear.

`when lenient parsing is enabled` -> `when {@link #isStrict()} returns false`
`interpret minus sign patterns` -> `enable loose matching of minus sign patterns`

Also, I'm unsure on mentioning `{@code parseLenient} elements` because I'm not sure that users of DecimalFormat will be aware of such LMDL elements. This also seems to be the first time a direct mention of an LDML element is made. I'm not sure of a better alternative ATM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248412292

From jlu at openjdk.org  Fri Aug  1 17:18:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 17:18:53 GMT
Subject: RFR: 8364370: java.text.DecimalFormat specification indentation
 correction
In-Reply-To: <cJD3ayzO-dHf5SY1_p1oFpGc9lEwC7XRmo2W12qkO8Q=.7e13b4b7-4769-4303-81ef-7b3873ccb750@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
 <cJD3ayzO-dHf5SY1_p1oFpGc9lEwC7XRmo2W12qkO8Q=.7e13b4b7-4769-4303-81ef-7b3873ccb750@github.com>
Message-ID: <8URx40uS_iH5AxhU_RRIOw7hormoEFui1qFmhfr-_x4=.dcf65c43-5b59-4d64-8a81-78c0501dc50b@github.com>

On Thu, 31 Jul 2025 23:21:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this doc only PR.
>> 
>> java.text.DecimalFormat uses an implSpec tag in the middle of the class description. This location was on purpose as the contents related to the surrounding section. However, this has caused slight indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
>> 
>> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.
>
> In fact, per the [specs](https://docs.oracle.com/en/java/javase/24/docs/specs/javadoc/doc-comment-spec.html#block-tags):
> 
>> The content of a block tag is any text following the tag up to, but not including, either the next block tag, or the end of the documentation comment.
> 
> It may be surprising that block tags have higher precedence over HTML headers. Just a note for the future.

Thanks @liach  for taking a look. Yes, I don't believe there should be anything preventing this from getting into 25 as well. 

I plan to integrate soon, but I want to make sure @naotoj is OK with the changes as well since he spotted the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/26585#issuecomment-3145250840

From erikj at openjdk.org  Fri Aug  1 17:23:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 17:23:56 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
Message-ID: <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>

On Fri, 27 Jun 2025 16:15:57 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:
> 
>   Remove problemlisting

make/ModuleWrapper.gmk line 82:

> 80:     TARGETS += $(LAUNCHERS_LIST)
> 81:   endif
> 82: endif

I think it would be cleaner if this could be kept in LauncherCommon.gmk and avoid having ModuleWrapper.gmk involved in this. I think it can be done relatively easily. In SetupBuildLauncherBody, instead of constructing the variable `$(MODULE)_INCLUDED_LAUNCHERS`, declare dependencies for `$(LAUNCHER_LIST)`, something like this:

$(LAUNCHER_LIST): $$($1)
TARGETS += $(LAUNCHER_LIST)


Then put the the recipe for `$(LAUNCHER_LIST)` at the end of LauncherCommon.gmk. The $(LAUNCHER_LIST) value will sometimes be added to TARGETS multiple times, but that's ok I think.

make/StaticLibs.gmk line 163:

> 161: # $2: The launcher name
> 162: define SetupRelauncher
> 163:   $1_$2_LAUNCHER_ARGS_LINE :=  $$(shell cat $$(SUPPORT_OUTPUTDIR)/static-native/relaunchers/$1/$2-relauncher-arguments.txt)

`$(call ReadFile, ...)`

also, double space?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2248147264
PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2248474424

From naoto at openjdk.org  Fri Aug  1 17:28:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 17:28:57 GMT
Subject: RFR: 8364370: java.text.DecimalFormat specification indentation
 correction
In-Reply-To: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
Message-ID: <g1ENZnrZFY3uf6f_nCK0FQepMb_Tksg2jC_gbtyFkMY=.4ae1aa65-a97b-43ef-94fc-be7b2d8ce09f@github.com>

On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this doc only PR.
> 
> java.text.DecimalFormat uses an implSpec tag in the middle of the class description. This location was on purpose as the contents related to the surrounding section. However, this has caused slight indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
> 
> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

Looks fine. Thanks for the fix!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26585#pullrequestreview-3080033495

From rgiulietti at openjdk.org  Fri Aug  1 17:38:09 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 1 Aug 2025 17:38:09 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v6]
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <TVUEpvw-2J6zEVENjg44GuyLqZ04Ut6CPWnFrHLMkU0=.4ba817f3-c8e5-460f-a676-95de04d20218@github.com>

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge master.
 - Refactoring to paramaterized tests.
 - Removed temporary comment from tests.
 - Added tests.
 - Added comment to COMPAT static field.
 - Merge branch 'master' into 8362448
 - 8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
 - Remove some unused methods from FloatingDecimal.
 - Renamed compatibility config option.
 - Merge branch 'master' into dtoa
 - ... and 3 more: https://git.openjdk.org/jdk/compare/2ba8a06f...3fe001c1

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

Changes: https://git.openjdk.org/jdk/pull/26364/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26364&range=05
  Stats: 190 lines in 7 files changed: 140 ins; 7 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/26364.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26364/head:pull/26364

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

From henryjen at openjdk.org  Fri Aug  1 18:00:10 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 1 Aug 2025 18:00:10 GMT
Subject: RFR: 8359174: tools/jlink/JLink20000Packages.java timed out [v6]
In-Reply-To: <ihq0S4WzSfAYg9g_fSLb_oiyTvPeiWD02lJHcl9nHZg=.9d149209-8be2-4058-8dd8-6bed334352ba@github.com>
References: <ihq0S4WzSfAYg9g_fSLb_oiyTvPeiWD02lJHcl9nHZg=.9d149209-8be2-4058-8dd8-6bed334352ba@github.com>
Message-ID: <Mc8HmM8-SJEEuoAE6o5y-6J1oEqVlbIEni0iZpulqJU=.4499d731-3f5f-4993-80a2-7f95e9d82c24@github.com>

> Create a jar directly from the memory instead of real file, this should reduce the I/O overhead which likely the reason for the time out.
> The issue is not reproducible locally, and fails intermittently, so we simply trying to reduce time needed.
> The jar file created is verified manually running jtreg with retain=all.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Clean up module dependencies

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25981/files
  - new: https://git.openjdk.org/jdk/pull/25981/files/b631d2c5..ba135ff8

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

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

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

From henryjen at openjdk.org  Fri Aug  1 18:03:52 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 1 Aug 2025 18:03:52 GMT
Subject: RFR: 8359174: tools/jlink/JLink20000Packages.java timed out [v7]
In-Reply-To: <ihq0S4WzSfAYg9g_fSLb_oiyTvPeiWD02lJHcl9nHZg=.9d149209-8be2-4058-8dd8-6bed334352ba@github.com>
References: <ihq0S4WzSfAYg9g_fSLb_oiyTvPeiWD02lJHcl9nHZg=.9d149209-8be2-4058-8dd8-6bed334352ba@github.com>
Message-ID: <4YaqAT65lxqBB13eoVrI6hNzPogClmy5oZN_j6xv2xo=.3facf047-f6cf-4d60-b54c-804cb46a30ba@github.com>

> Create a jar directly from the memory instead of real file, this should reduce the I/O overhead which likely the reason for the time out.
> The issue is not reproducible locally, and fails intermittently, so we simply trying to reduce time needed.
> The jar file created is verified manually running jtreg with retain=all.

Henry Jen 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 eight additional commits since the last revision:

 - Merge openjdk/master' into JDK-8359174
 - Clean up module dependencies
 - Clean up jtreg directives
 - Adapt review feedbacks
 - Update copyright year
 - Update copyright year
 - cleanup
 - 8359174: tools/jlink/JLink20000Packages.java timed out

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25981/files
  - new: https://git.openjdk.org/jdk/pull/25981/files/ba135ff8..95c07cb8

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

  Stats: 68021 lines in 1872 files changed: 38641 ins; 19122 del; 10258 mod
  Patch: https://git.openjdk.org/jdk/pull/25981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25981/head:pull/25981

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

From liach at openjdk.org  Fri Aug  1 18:12:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 18:12:34 GMT
Subject: RFR: 8361730: The CodeBuilder.trying(BlockCodeBuilder,CatchBuilder)
 method generates corrupted bytecode in certain cases
Message-ID: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>

Explicitly document that BlockCodeBuilder expects control flow to continue after it merges back to the parent block, so failure to do that by the users can lead to malformed code. This is better than introducing complex and costly analysis.

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

Commit messages:
 - 8361730: The CodeBuilder.trying(BlockCodeBuilder,CatchBuilder) method generates corrupted bytecode in certain cases

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

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

From erikj at openjdk.org  Fri Aug  1 18:29:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 18:29:57 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <MYOxu1Y0X-cadUHNUOGHl-bo3zq3NFHzqr77RCG8i8g=.536325df-4118-449a-9fc1-b7a63673b25b@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3080178709

From jlu at openjdk.org  Fri Aug  1 18:46:02 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 18:46:02 GMT
Subject: RFR: 8364370: java.text.DecimalFormat specification indentation
 correction
In-Reply-To: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
Message-ID: <zcGPE3_eUPxeZ6ltxBpE2WQU2pDln6cADPMnzcn2cNY=.6936b240-af97-4086-ad99-f7c58cbfc480@github.com>

On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this doc only PR.
> 
> java.text.DecimalFormat uses an implSpec tag in the middle of the class description. This location was on purpose as the contents related to the surrounding section. However, this has caused slight indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
> 
> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

Thanks Chen and Naoto. I will open the 25 stabilization backport shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26585#issuecomment-3145444401

From jlu at openjdk.org  Fri Aug  1 18:46:03 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 18:46:03 GMT
Subject: Integrated: 8364370: java.text.DecimalFormat specification indentation
 correction
In-Reply-To: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
Message-ID: <1jqueEZsuh8RS7bw5kGxElSzR_1_zd1gPYJ7i5pWezc=.05b3a952-3d7d-4225-bda6-fe76e554f306@github.com>

On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this doc only PR.
> 
> java.text.DecimalFormat uses an implSpec tag in the middle of the class description. This location was on purpose as the contents related to the surrounding section. However, this has caused slight indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
> 
> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

This pull request has now been integrated.

Changeset: 8e921aee
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e921aee5abb20c240b45cb75b06fb1f316d8a1f
Stats:     13 lines in 1 file changed: 7 ins; 6 del; 0 mod

8364370: java.text.DecimalFormat specification indentation correction

Reviewed-by: liach, naoto

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

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

From duke at openjdk.org  Fri Aug  1 18:55:58 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 1 Aug 2025 18:55:58 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v7]
In-Reply-To: <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
Message-ID: <y6A2skrkFLNYIggVUp_WLwDJzlKEEVsBNrRc6nV1Vyk=.b072dca2-a60d-427e-a04b-9c4ff19560e1@github.com>

On Fri, 1 Aug 2025 16:16:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update advised by volkan

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1093:

> 1091:      * startup.  This should not be used to find fields in non-trusted code.
> 1092:      * Use the {@link #objectFieldOffset(Field) Field}-accepting version for
> 1093:      * arbitrary fields instead.

It?s?also?used to?obtain?offsets of?fields in?classes which?have their?fields filtered?from?reflection using?`Reflection?::registerFieldsToFilter(?)`, such?as?fields in?`java.lang.ClassLoader` or?`java.lang.Module`.

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1108:

> 1106:         if (result < 0) {
> 1107:             String type = switch ((int) result) {
> 1108:                 case -2 -> "a static field";

Suggestion:

                case -2 -> "is a static field";

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2248635899
PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2248630006

From naoto at openjdk.org  Fri Aug  1 18:57:13 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 18:57:13 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v5]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <VYntO9YT8IQ663JWKIdx6ARzLTgTIaDSHiHSCd0pRW8=.37b4cd3e-f431-415e-a7d5-025b48f27557@github.com>

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Spec update
 - Supplementary/CanonEq tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/38f3286f..d4bd416a

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

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

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

From naoto at openjdk.org  Fri Aug  1 19:05:27 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 19:05:27 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v6]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has 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 16 commits:

 - Merge branch 'master' into JDK-8363972-Loose-matching-dash
 - Spec update
 - Supplementary/CanonEq tests
 - flipped again, which was correct
 - flipped the size check
 - Address review comments
 - Merge branch 'master' into JDK-8363972-Loose-matching-dash
 - tidying up
 - test location
 - spec update
 - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d

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

Changes: https://git.openjdk.org/jdk/pull/26580/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=05
  Stats: 409 lines in 8 files changed: 373 ins; 21 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

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

From hchao at openjdk.org  Fri Aug  1 19:11:01 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 1 Aug 2025 19:11:01 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
Message-ID: <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>

On Fri, 1 Aug 2025 15:28:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Thanks for the latest screenshot. I don't think the signature algorithms should be "none". If we can't access the provider-specific defaults, then I think we should omit this information for now. @artur-oracle or @haimaychao can you check this out and see if there is a way to get those defaults? Thanks.

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/net/ssl/SSLParameters.java#L852
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/net/ssl/SSLParameters.java#L868

So if we never call `setSignatureSchemes()` on the `SSLParameters`, then `getSignatureSchemes()` will return null. But it doesn't mean no signature schemes are used, and it means underlying provider-specific default signature schemes will be used over the TLS connections. We may use `System.getProperty("jdk.tls.client.SignatureSchemes")`, but it works if the property has been set. It seems no public API we can use to query it directly.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3145519481

From naoto at openjdk.org  Fri Aug  1 19:11:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 19:11:01 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v4]
In-Reply-To: <MiG-GBgAmxpwAoSrwD16zeY7QS_QJZkBp6IqLOG2xcA=.86525e07-d632-48ff-bed0-a26ce4d08ab2@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <DtV-__lo4sL7akdq2buxSm7YkxFnN7jZzpFtFD7H2ug=.df4332a4-eb68-4d94-b8ab-273dc2b90c6e@github.com>
 <MiG-GBgAmxpwAoSrwD16zeY7QS_QJZkBp6IqLOG2xcA=.86525e07-d632-48ff-bed0-a26ce4d08ab2@github.com>
Message-ID: <I8l1yVAH-jRQXDFk9V3VtYqyd9bVpbsXD-BEclHClfE=.d4b76392-220e-4c83-b0e8-293eb086ea1e@github.com>

On Fri, 1 Aug 2025 16:40:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   flipped again, which was correct
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 422:
> 
>> 420:  * @implNote The default implementation follows the LDML specification for
>> 421:  * {@code parseLenient} elements to interpret minus sign patterns when lenient
>> 422:  * parsing is enabled.
> 
> IMO, the following is more clear.
> 
> `when lenient parsing is enabled` -> `when {@link #isStrict()} returns false`
> `interpret minus sign patterns` -> `enable loose matching of minus sign patterns`
> 
> Also, I'm unsure on mentioning `{@code parseLenient} elements` because I'm not sure that users of DecimalFormat will be aware of such LMDL elements. This also seems to be the first time a direct mention of an LDML element is made. I'm not sure of a better alternative ATM.

Thanks, modified as you suggested. For the `parseLenient`, the problem is in the LDML document side, as there is no description for it, and their loose matching description is kind of incorrect (use [:DASH:], which is not the case here. So I just dropped it in this iteration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248692643

From naoto at openjdk.org  Fri Aug  1 19:11:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 19:11:04 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v2]
In-Reply-To: <Ni6ClTQjiga_f7aTHypy6lZwW3kXtOvuqtCubrInD_Y=.ec492568-d953-4f71-b38c-1064d7b890fb@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <-jShvVkEpQ1sPrcEvsMOTj-91dL1vm_ZFhw7NSUJ8jE=.7368c6c6-6126-410e-9fa7-b694122c9bc9@github.com>
 <Ni6ClTQjiga_f7aTHypy6lZwW3kXtOvuqtCubrInD_Y=.ec492568-d953-4f71-b38c-1064d7b890fb@github.com>
Message-ID: <lgZ0vFWAH7KYZ_L_PS2ogkfKeVKPIjNPeun5eHxK2QM=.b8fce492-6ca6-4cbf-a32b-a2733b40262e@github.com>

On Thu, 31 Jul 2025 23:58:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 3544:
> 
>> 3542:             var t = text.substring(position, Math.min(tlen, position + alen))
>> 3543:                 .replaceAll(lmsp, "-");
>> 3544:             return t.regionMatches(0, a, 0, alen);
> 
> I presume the original solution was regex for all cases, and you made the single char case for the fast path. If you still have the perf benchmark handy, I wonder how a char by char approach would compare instead of regex. It would also simplify the code since it would be combining the slow and fast path.
> 
> 
> int i = 0;
> for (; position + i < Math.min(tlen, position + alen); i++) {
>     int tIndex = lms.indexOf(text.charAt(position + i));
>     int aIndex = lms.indexOf(affix.charAt(i));
>     // Non LMS. Match direct
>     if (tIndex < 0 && aIndex < 0) {
>         if (text.charAt(position + i) != affix.charAt(i)) {
>             return false;
>         }
>     } else {
>         // By here, at least one LMS. Ensure both LMS.
>         if (tIndex < 0 || aIndex < 0) {
>             return false;
>         }
>     }
> }
> // Return true if entire affix was matched
> return i == alen;

Comparing string char-by-char is problematic, as it cannot handle supplementary and/or normalization, so it is not possible to combine those paths. Yes, regex is slow, but need to rely on it for those reasons. I believe 99.9% of the use cases fall into the affix length == 1, so I think it is OK.

> test/jdk/java/text/Format/NumberFormat/LenientMinusSignTest.java line 120:
> 
>> 118:         public void testLenientPrefix(String sign) throws ParseException {
>> 119:             var df = new DecimalFormat(PREFIX, DFS);
>> 120:             df.setStrict(false);
> 
> No need to set strict as false since `df` is lenient by default. If it was done for clarity, I think the method name already adequately indicates it is a lenient style test. Applies to CNF test as well.

This was intentional. Although redundant, I wanted to make sure it is in lenient mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248692543
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248692479

From hchao at openjdk.org  Fri Aug  1 19:24:04 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 1 Aug 2025 19:24:04 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
Message-ID: <qgN4wPVujSOrsGzxtvzywgmy9HRBcyBjmR07O29YoOo=.658f7cca-8d8d-48b2-9bff-fa8599775772@github.com>

On Thu, 31 Jul 2025 12:58:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan 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:
> 
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

Links to API doc should be:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/net/ssl/SSLParameters.java#L729
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/net/ssl/SSLParameters.java#L745

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3145547735

From jrose at openjdk.org  Fri Aug  1 19:26:58 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 1 Aug 2025 19:26:58 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v7]
In-Reply-To: <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
Message-ID: <fWZNuipiXUXWGlsTRFnjcrBt48o_OVxminsq0Vn1gG0=.25c3e0cb-3001-4384-b93b-607269d16867@github.com>

On Fri, 1 Aug 2025 16:16:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update advised by volkan

Marked as reviewed by jrose (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25945#pullrequestreview-3080341936

From abarashev at openjdk.org  Fri Aug  1 19:27:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 19:27:55 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
 <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
Message-ID: <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>

On Fri, 1 Aug 2025 19:08:22 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Thanks for the latest screenshot. I don't think the signature algorithms should be "none". If we can't access the provider-specific defaults, then I think we should omit this information for now. @artur-oracle or @haimaychao can you check this out and see if there is a way to get those defaults? Thanks.

We actually have 2 lists of signature algorithms: one for the handshake and another for certificates. Both lists are being constructed only during the TLS handshake (see `SignatureScheme.updateHandshakeLocalSupportedAlgs` method).  There is no public API currently to get those lists, although it shouldn't be hard to add such API call.
The code currently being reviewed should only display signature schemes set with `jdk.tls.client.SignatureSchemes` system property.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3145557453

From liach at openjdk.org  Fri Aug  1 20:15:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 20:15:58 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v7]
In-Reply-To: <y6A2skrkFLNYIggVUp_WLwDJzlKEEVsBNrRc6nV1Vyk=.b072dca2-a60d-427e-a04b-9c4ff19560e1@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
 <y6A2skrkFLNYIggVUp_WLwDJzlKEEVsBNrRc6nV1Vyk=.b072dca2-a60d-427e-a04b-9c4ff19560e1@github.com>
Message-ID: <s2o16CP-50uIGQJHp3mWsU_AKwzHZ29zC_zuUgaESZo=.d911cb70-7fb1-4a85-8817-b14123f85ffe@github.com>

On Fri, 1 Aug 2025 18:43:04 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update advised by volkan
>
> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1108:
> 
>> 1106:         if (result < 0) {
>> 1107:             String type = switch ((int) result) {
>> 1108:                 case -2 -> "a static field";
> 
> Suggestion:
> 
>                 case -2 -> "is a static field";

To be picky, "not found" should be "is not found" too. I intentionally omitted "is" from both fragments to make it more simple.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2248796912

From jlu at openjdk.org  Fri Aug  1 20:20:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 20:20:31 GMT
Subject: [jdk25] RFR: 8364370: java.text.DecimalFormat specification
 indentation correction
Message-ID: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>

Please review this PR which is a backport of commit [8e921aee](https://github.com/openjdk/jdk/commit/8e921aee5abb20c240b45cb75b06fb1f316d8a1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

It is a trivial doc-only change to correct indentation alignment in the class specification of DecimalFormat.

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

Commit messages:
 - Backport 8e921aee5abb20c240b45cb75b06fb1f316d8a1f

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

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

From liach at openjdk.org  Fri Aug  1 20:21:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 20:21:57 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v7]
In-Reply-To: <y6A2skrkFLNYIggVUp_WLwDJzlKEEVsBNrRc6nV1Vyk=.b072dca2-a60d-427e-a04b-9c4ff19560e1@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
 <y6A2skrkFLNYIggVUp_WLwDJzlKEEVsBNrRc6nV1Vyk=.b072dca2-a60d-427e-a04b-9c4ff19560e1@github.com>
Message-ID: <_zaZ1GfvUl4STxeeE0oFk2GCofYru_btBGZhKzPZT5w=.b6135766-c36c-481f-80bb-4c5c78c489b2@github.com>

On Fri, 1 Aug 2025 18:46:53 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update advised by volkan
>
> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1093:
> 
>> 1091:      * startup.  This should not be used to find fields in non-trusted code.
>> 1092:      * Use the {@link #objectFieldOffset(Field) Field}-accepting version for
>> 1093:      * arbitrary fields instead.
> 
> It?s?also?used to?obtain?offsets of?fields in?classes which?have their?fields filtered?from?reflection using?`Reflection?::registerFieldsToFilter(?)`, such?as?fields in?`java.lang.ClassLoader` or?`java.lang.Module`.

I don't think this is ever the intention of [JDK-8182487](https://bugs.openjdk.org/browse/JDK-8182487) (928ca49c21d7e571e88dd27cf47033bf88d2dc71) - it is a side effect, and you can always query the VM for a Field object if you are determined, or java.lang.invoke.MemberName can be used to obtain an offset for filtered fields too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2248804132

From jlu at openjdk.org  Fri Aug  1 20:23:00 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 20:23:00 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v4]
In-Reply-To: <I8l1yVAH-jRQXDFk9V3VtYqyd9bVpbsXD-BEclHClfE=.d4b76392-220e-4c83-b0e8-293eb086ea1e@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <DtV-__lo4sL7akdq2buxSm7YkxFnN7jZzpFtFD7H2ug=.df4332a4-eb68-4d94-b8ab-273dc2b90c6e@github.com>
 <MiG-GBgAmxpwAoSrwD16zeY7QS_QJZkBp6IqLOG2xcA=.86525e07-d632-48ff-bed0-a26ce4d08ab2@github.com>
 <I8l1yVAH-jRQXDFk9V3VtYqyd9bVpbsXD-BEclHClfE=.d4b76392-220e-4c83-b0e8-293eb086ea1e@github.com>
Message-ID: <_16t2LaftunzLITOKdsg1nfd8eGiPjqrEzT_EZa2MVM=.68766205-163d-4969-bff8-5a0ea8a4b983@github.com>

On Fri, 1 Aug 2025 19:08:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormat.java line 422:
>> 
>>> 420:  * @implNote The default implementation follows the LDML specification for
>>> 421:  * {@code parseLenient} elements to interpret minus sign patterns when lenient
>>> 422:  * parsing is enabled.
>> 
>> IMO, the following is more clear.
>> 
>> `when lenient parsing is enabled` -> `when {@link #isStrict()} returns false`
>> `interpret minus sign patterns` -> `enable loose matching of minus sign patterns`
>> 
>> Also, I'm unsure on mentioning `{@code parseLenient} elements` because I'm not sure that users of DecimalFormat will be aware of such LMDL elements. This also seems to be the first time a direct mention of an LDML element is made. I'm not sure of a better alternative ATM.
>
> Thanks, modified as you suggested. For the `parseLenient`, the problem is in the LDML document side, as there is no description for it, and their loose matching description is kind of incorrect (use [:DASH:], which is not the case here. So I just dropped it in this iteration.

I noticed that as well, so I could not think of a better alternative. I think dropping the element name is the right choice, less is more in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248805340

From liach at openjdk.org  Fri Aug  1 20:24:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 20:24:59 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v7]
In-Reply-To: <_zaZ1GfvUl4STxeeE0oFk2GCofYru_btBGZhKzPZT5w=.b6135766-c36c-481f-80bb-4c5c78c489b2@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
 <y6A2skrkFLNYIggVUp_WLwDJzlKEEVsBNrRc6nV1Vyk=.b072dca2-a60d-427e-a04b-9c4ff19560e1@github.com>
 <_zaZ1GfvUl4STxeeE0oFk2GCofYru_btBGZhKzPZT5w=.b6135766-c36c-481f-80bb-4c5c78c489b2@github.com>
Message-ID: <PHvaeFjvRpPsL2dgd68_b18B6amnuGMHquzm4UTp4kA=.fd3f78d1-3ba8-4aee-bde2-76d994d9f703@github.com>

On Fri, 1 Aug 2025 20:19:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1093:
>> 
>>> 1091:      * startup.  This should not be used to find fields in non-trusted code.
>>> 1092:      * Use the {@link #objectFieldOffset(Field) Field}-accepting version for
>>> 1093:      * arbitrary fields instead.
>> 
>> It?s?also?used to?obtain?offsets of?fields in?classes which?have their?fields filtered?from?reflection using?`Reflection?::registerFieldsToFilter(?)`, such?as?fields in?`java.lang.ClassLoader` or?`java.lang.Module`.
>
> I don't think this is ever the intention of [JDK-8182487](https://bugs.openjdk.org/browse/JDK-8182487) (928ca49c21d7e571e88dd27cf47033bf88d2dc71) - it is a side effect, and you can always query the VM for a Field object if you are determined, or java.lang.invoke.MemberName can be used to obtain an offset for filtered fields too.

In an analogy, you could argue the existing `objectFieldOffset` can be used to obtain offsets of static fields in classes. Clearly that is a wrong way to use it; for internal APIs, we have the freedom to explicitly stop supporting some usages we deem deviating from our purpose, unlike the compatibility requirements imposed on public APIs like sun.misc.Unsafe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2248808092

From liach at openjdk.org  Fri Aug  1 20:25:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 20:25:53 GMT
Subject: [jdk25] RFR: 8364370: java.text.DecimalFormat specification
 indentation correction
In-Reply-To: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
References: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
Message-ID: <QUQ0aEqnPMHrxRE5KESlpY4i1B6wddtCDNiG2ou-OGI=.a62d6bcf-5f59-42f6-ba40-222259243cc4@github.com>

On Fri, 1 Aug 2025 20:14:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [8e921aee](https://github.com/openjdk/jdk/commit/8e921aee5abb20c240b45cb75b06fb1f316d8a1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> It is a trivial doc-only change to correct indentation alignment in the class specification of DecimalFormat.

Thanks for this doc-only fix.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26603#pullrequestreview-3080473382

From vyazici at openjdk.org  Fri Aug  1 20:36:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 1 Aug 2025 20:36:58 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v7]
In-Reply-To: <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
Message-ID: <BrtpUShVC-fkHTwhbK43_7jvE_Vu1cXpYy6nmdAcyZc=.2ebde74f-1494-45e9-ae10-7927a52c7c78@github.com>

On Fri, 1 Aug 2025 16:16:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update advised by volkan

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25945#pullrequestreview-3080495002

From naoto at openjdk.org  Fri Aug  1 21:05:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 21:05:54 GMT
Subject: [jdk25] RFR: 8364370: java.text.DecimalFormat specification
 indentation correction
In-Reply-To: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
References: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
Message-ID: <6N64dFtlTH7krbIvCeLKNGcog8pgu-fDg9dteFRM6Tk=.84418e52-61ae-4680-bbe4-ad019e553250@github.com>

On Fri, 1 Aug 2025 20:14:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [8e921aee](https://github.com/openjdk/jdk/commit/8e921aee5abb20c240b45cb75b06fb1f316d8a1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> It is a trivial doc-only change to correct indentation alignment in the class specification of DecimalFormat.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26603#pullrequestreview-3080560105

From jlu at openjdk.org  Fri Aug  1 21:29:01 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 21:29:01 GMT
Subject: [jdk25] Integrated: 8364370: java.text.DecimalFormat specification
 indentation correction
In-Reply-To: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
References: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
Message-ID: <_HdjNkbsv0E07OgyrW4gPoahGaHklLreUlXmDdrBnHg=.6ec5d378-de62-4603-be2b-60a793403056@github.com>

On Fri, 1 Aug 2025 20:14:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [8e921aee](https://github.com/openjdk/jdk/commit/8e921aee5abb20c240b45cb75b06fb1f316d8a1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> It is a trivial doc-only change to correct indentation alignment in the class specification of DecimalFormat.

This pull request has now been integrated.

Changeset: b5bec8db
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5bec8db3f11febcd3c8147571d84e9791c458d9
Stats:     13 lines in 1 file changed: 7 ins; 6 del; 0 mod

8364370: java.text.DecimalFormat specification indentation correction

Reviewed-by: liach, naoto
Backport-of: 8e921aee5abb20c240b45cb75b06fb1f316d8a1f

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

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

From jlu at openjdk.org  Fri Aug  1 22:44:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 22:44:59 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v6]
In-Reply-To: <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
Message-ID: <nhUA6ScKF0Dkig1myEl3m5P1C8dnsdioCqTxp6NXm40=.e8629345-3631-4dbf-8f84-416bd9867275@github.com>

On Fri, 1 Aug 2025 19:05:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has 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 16 commits:
> 
>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>  - Spec update
>  - Supplementary/CanonEq tests
>  - flipped again, which was correct
>  - flipped the size check
>  - Address review comments
>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>  - tidying up
>  - test location
>  - spec update
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d

src/java.base/share/classes/java/text/DecimalFormat.java line 3512:

> 3510: 
> 3511:     /**
> 3512:      * {@return if the text matches the affix} In lenient mode, lenient

It's more clear to state that lenient minus signs in the affix match to lenient minus signs in the text. (Not just match to hyphen-minus.)

src/java.base/share/classes/java/text/DecimalFormat.java line 3543:

> 3541:             var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ);
> 3542:             var a = lmsp.matcher(affix).replaceAll("-");
> 3543:             var t = lmsp.matcher(text.substring(position, Math.min(tlen, position + alen)))

I don't think this works. If you see my other comment regarding the test case and swap it such that `lenientMinusSign` is "-\u00E4" and the pattern (affix) includes "a\u0308" and we parse some text such as "\u00E41.5".

Then we have the following,


var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ); // Returns pattern [-?]
var a = lmsp.matcher(affix).replaceAll("-"); // Gets correctly normalized to "-"
// Incorrectly matches against "?1" and normalized to "-1" since the substring returned is indexed from 0 to 2.
var t = lmsp.matcher(text.substring(position, Math.min(tlen, position + alen)))


That is, I think we need to substring after we have performed the normalization. Something such as,


var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ);
var a = lmsp.matcher(affix).replaceAll("-");
var t = lmsp.matcher(text).replaceAll("-");
return t.startsWith(a, position);


However, we will still run into issues later in DecimalFormat, as the position is incremented by the original prefix length.


        } else if (gotNegative) {
            position += negativePrefix.length();


So for "?1.5" we would start parsing at position = 2, erroneously returning "0.5". So further thought may be needed.

test/jdk/java/text/Format/NumberFormat/LenientMinusSignTest.java line 128:

> 126:             .set(dfs, "-\u00E5");
> 127:         var df = new DecimalFormat("#.#;a\u0308#.#", dfs);
> 128:         assertEquals(df.parse("a\u03081.5"), -1.5);

This one confuses me, should it not be parsing "\u00E51.5" such that the test can check if canonical equivalence occurs when matching the text "\u00E5" to the affix "a\u0308"? Otherwise, we are just parsing the exact pattern we set? Also I think it should be "\u00E4", not "\u00E5".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248872126
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248949783
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248892644

From naoto at openjdk.org  Fri Aug  1 23:25:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 23:25:57 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v6]
In-Reply-To: <nhUA6ScKF0Dkig1myEl3m5P1C8dnsdioCqTxp6NXm40=.e8629345-3631-4dbf-8f84-416bd9867275@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
 <nhUA6ScKF0Dkig1myEl3m5P1C8dnsdioCqTxp6NXm40=.e8629345-3631-4dbf-8f84-416bd9867275@github.com>
Message-ID: <umxWb0-DaBBFVa87fkrxiV79LeQ8nH4yxslgOnocFrM=.5ff7950d-32a8-411b-b169-38817e97e86c@github.com>

On Fri, 1 Aug 2025 22:19:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>>  - Spec update
>>  - Supplementary/CanonEq tests
>>  - flipped again, which was correct
>>  - flipped the size check
>>  - Address review comments
>>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>>  - tidying up
>>  - test location
>>  - spec update
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 3543:
> 
>> 3541:             var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ);
>> 3542:             var a = lmsp.matcher(affix).replaceAll("-");
>> 3543:             var t = lmsp.matcher(text.substring(position, Math.min(tlen, position + alen)))
> 
> I don't think this works. If you see my other comment regarding the test case and swap it such that `lenientMinusSign` is "-\u00E4" and the pattern (affix) includes "a\u0308" and we parse some text such as "\u00E41.5".
> 
> Then we have the following,
> 
> 
> var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ); // Returns pattern [-?]
> var a = lmsp.matcher(affix).replaceAll("-"); // Gets correctly normalized to "-"
> // Incorrectly matches against "?1" and normalized to "-1" since the substring returned is indexed from 0 to 2.
> var t = lmsp.matcher(text.substring(position, Math.min(tlen, position + alen)))
> 
> 
> That is, I think we need to substring after we have performed the normalization. Something such as,
> 
> 
> var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ);
> var a = lmsp.matcher(affix).replaceAll("-");
> var t = lmsp.matcher(text).replaceAll("-");
> return t.startsWith(a, position);
> 
> 
> However, we will still run into issues later in DecimalFormat, as the position is incremented by the original prefix length.
> 
> 
>         } else if (gotNegative) {
>             position += negativePrefix.length();
> 
> 
> So for "?1.5" we would start parsing at position = 2, erroneously returning "0.5". So further thought may be needed.

The current implementations assume the prefix/suffix lengths in a lot of places (no wonder), should be re-examined.

> test/jdk/java/text/Format/NumberFormat/LenientMinusSignTest.java line 128:
> 
>> 126:             .set(dfs, "-\u00E5");
>> 127:         var df = new DecimalFormat("#.#;a\u0308#.#", dfs);
>> 128:         assertEquals(df.parse("a\u03081.5"), -1.5);
> 
> This one confuses me, should it not be parsing "\u00E51.5" such that the test can check if canonical equivalence occurs when matching the text "\u00E5" to the affix "a\u0308"? Otherwise, we are just parsing the exact pattern we set? Also I think it should be "\u00E4", not "\u00E5".

That's correct. I think the simple case is not that simple. Need to rethink.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2249005477
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2249005036

From duke at openjdk.org  Sat Aug  2 12:04:57 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 2 Aug 2025 12:04:57 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v7]
In-Reply-To: <s2o16CP-50uIGQJHp3mWsU_AKwzHZ29zC_zuUgaESZo=.d911cb70-7fb1-4a85-8817-b14123f85ffe@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
 <y6A2skrkFLNYIggVUp_WLwDJzlKEEVsBNrRc6nV1Vyk=.b072dca2-a60d-427e-a04b-9c4ff19560e1@github.com>
 <s2o16CP-50uIGQJHp3mWsU_AKwzHZ29zC_zuUgaESZo=.d911cb70-7fb1-4a85-8817-b14123f85ffe@github.com>
Message-ID: <q6eY307tY_vzy5VE1Su1Rva_0q-bN2s-XPZC8KnSubY=.3ffe632c-fd7f-4110-919b-4f83a2846609@github.com>

On Fri, 1 Aug 2025 20:13:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1108:
>> 
>>> 1106:         if (result < 0) {
>>> 1107:             String type = switch ((int) result) {
>>> 1108:                 case -2 -> "a static field";
>> 
>> Suggestion:
>> 
>>                 case -2 -> "is a static field";
>
> To be picky, "not found" should be "is not found" too. I intentionally omitted "is" from both fragments to make it more simple.

?Field Foo.bar not?found? is?a?valid?sentence, but??Field Foo.baz a?static?field? is?not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2249224597

From rriggs at openjdk.org  Sat Aug  2 14:03:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 2 Aug 2025 14:03:55 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v5]
In-Reply-To: <kJJVhUhIjdv5bhF2UUoPNze4bBgBGula-2ps0QDR1hk=.0a3102d1-b4c3-4b96-b042-b3c16cab23bb@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <kJJVhUhIjdv5bhF2UUoPNze4bBgBGula-2ps0QDR1hk=.0a3102d1-b4c3-4b96-b042-b3c16cab23bb@github.com>
Message-ID: <E2k2RxIG3qdqDsEy802Gsumf5tBskUseU95w2ed0efQ=.78c095e5-7dc5-40cf-8788-6f0fda189f95@github.com>

On Thu, 31 Jul 2025 22:16:55 GMT, Darragh Conway <duke at openjdk.org> wrote:

>> There were a couple of post review comments for PR: https://github.com/openjdk/jdk/pull/26193 after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.
>
> Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed blank lines at end of file

looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26445#pullrequestreview-3081051571

From duke at openjdk.org  Sat Aug  2 16:09:54 2025
From: duke at openjdk.org (duke)
Date: Sat, 2 Aug 2025 16:09:54 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v5]
In-Reply-To: <kJJVhUhIjdv5bhF2UUoPNze4bBgBGula-2ps0QDR1hk=.0a3102d1-b4c3-4b96-b042-b3c16cab23bb@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <kJJVhUhIjdv5bhF2UUoPNze4bBgBGula-2ps0QDR1hk=.0a3102d1-b4c3-4b96-b042-b3c16cab23bb@github.com>
Message-ID: <STsyH3eoXM6-w_ln4PaulPEQQFNigiKafNUdZo2Pnh0=.724ce261-521d-4ff1-848f-43294089d448@github.com>

On Thu, 31 Jul 2025 22:16:55 GMT, Darragh Conway <duke at openjdk.org> wrote:

>> There were a couple of post review comments for PR: https://github.com/openjdk/jdk/pull/26193 after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.
>
> Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed blank lines at end of file

@DarraghConway 
Your change (at version 67c73d1eeb35e973b27fbfcffd8b6e3582f48cd8) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26445#issuecomment-3146586133

From duke at openjdk.org  Sun Aug  3 11:05:58 2025
From: duke at openjdk.org (Darragh Conway)
Date: Sun, 3 Aug 2025 11:05:58 GMT
Subject: Integrated: 8363720: Follow up to JDK-8360411 with post review
 comments
In-Reply-To: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
Message-ID: <PzDaiF_il9EoTNu1eu8HNVAoaxZUbUACVOfmbI2ZMtU=.5ff35a04-7c85-428f-8926-1c6f643562e2@github.com>

On Wed, 23 Jul 2025 14:07:25 GMT, Darragh Conway <duke at openjdk.org> wrote:

> There were a couple of post review comments for PR: https://github.com/openjdk/jdk/pull/26193 after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.

This pull request has now been integrated.

Changeset: a5e0c9d0
Author:    DarraghConway <darragh.conway at oracle.com>
Committer: Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5e0c9d0c52e028321bb38e471ce98e389e67fe1
Stats:     28 lines in 1 file changed: 8 ins; 7 del; 13 mod

8363720: Follow up to JDK-8360411 with post review comments

Reviewed-by: bpb, rriggs

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

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

From duke at openjdk.org  Sun Aug  3 13:37:54 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 3 Aug 2025 13:37:54 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: <7_hGRPSddpEvGRJxCGREDYZjqQ68_0rIPzHVV-NOjFA=.63974cf2-8f61-451d-a509-60727d065e29@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())`

Its author may have prioritized the versatility of the APIs.

> `codePointCount(0, length())`

This workaround is only effective if the instance expression is sufficiently short or can afford to be stored to a new temporary variable once. It can be a pain in the neck that you have to write the expression even twice to get the number of code points in the entire string instance.

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

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

From tvaleev at openjdk.org  Sun Aug  3 13:42:41 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 3 Aug 2025 13:42:41 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v7]
In-Reply-To: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
Message-ID: <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>

> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
> 
> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
> 
> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Add @implSpec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25297/files
  - new: https://git.openjdk.org/jdk/pull/25297/files/a2788651..0a062f6e

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

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

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

From asemenyuk at openjdk.org  Sun Aug  3 16:52:28 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sun, 3 Aug 2025 16:52:28 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test [v4]
In-Reply-To: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
Message-ID: <OnsHIHHpdE-VYJTwlLvsuGErT_5j7sxT9Xz-rK0DUZQ=.cccdd4a2-c177-493a-aac3-5a4412e24b49@github.com>

> - Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
> - Test shortcuts in the predefined app image.
> 
> Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.
> 
> Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.
> 
> Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.
> 
> Not directly related to the subject of the PR:
>  - JPackageCommand: Added missing and removed redundant `verifyMutable()` calls. Converted "jpt-unpacked-folder" option into the member field. Added `JPackageCommand.createMutableCopy()` complementary to the existing `JPackageCommand.createImmutableCopy()`.
>  - Added `test/jdk/tools/jpackage/clean_test_output.sh` Bash script filtering test logs to minimize noise in diffs.
> 
> Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.

Alexey Semenyuk has updated the pull request incrementally with 10 additional commits since the last revision:

 - LauncherShortcut: add appImageFilePropertyName()
 - JPackageCommand: verify names of additional launcher are precisely recorded in .jpackage.xml file
 - JPackageCommand: remove path to the unpacked directory from the argument list as it interferes with extracting arguments with optional values.
 - clean_test_output.sh: better
 - AddLShortcutTest: make it a better fit for JDK-8308349
 - LinuxHelper: bugfix
 - AddLShortcutTest: modify
 - LinuxHelper: bugfix
 - WinShortcutVerifier: make it a better fit for JDK-8308349
 - LinuxHelper: allow empty lines in .desktop files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26584/files
  - new: https://git.openjdk.org/jdk/pull/26584/files/b5da8074..975a493f

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

  Stats: 56 lines in 6 files changed: 25 ins; 9 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/26584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26584/head:pull/26584

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

From duke at openjdk.org  Sun Aug  3 18:20:00 2025
From: duke at openjdk.org (ExE Boss)
Date: Sun, 3 Aug 2025 18:20:00 GMT
Subject: RFR: 8361730: The
 CodeBuilder.trying(BlockCodeBuilder,CatchBuilder) method generates corrupted
 bytecode in certain cases
In-Reply-To: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
References: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
Message-ID: <CNf7CS31N-RkoA5za1_IGP38WcXfdoHOST6wCAdPlMI=.894b7414-2d3d-487b-83c3-6da2c0e35c42@github.com>

On Fri, 1 Aug 2025 18:05:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> Explicitly document that BlockCodeBuilder expects control flow to continue after it merges back to the parent block, so failure to do that by the users can lead to malformed code. This is better than introducing complex and costly analysis.

I?think?that the?`trying`?builder could?be?improved to?only?insert the?`goto?branchLabel`?when the?last?instruction or?pseudo?instruction isn?t?a?`ReturnInstruction`, a?`ThrowInstruction`, or?a?`BranchInstruction`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26602#issuecomment-3148612587

From asemenyuk at openjdk.org  Sun Aug  3 23:14:42 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sun, 3 Aug 2025 23:14:42 GMT
Subject: RFR: 8364587: Update jpackage internal javadoc
Message-ID: <jK5OUpoMgcXi6MtSsFj0q0Q0sdFoah8QuTlWCNCQ4E0=.d0b1f753-563a-4114-92be-eab47bb12c7d@github.com>

Fix javadoc errors in DefaultLauncherIcon, Launcher, and Application classes. Additionally, add javadoc to some methods of PackagingPipeline class.

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

Commit messages:
 - DefaultLauncherIcon: minor javadoc fix
 - Add javadoc to PackagingPipeline
 - Launcher, Application: fix javadoc

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

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

From liach at openjdk.org  Sun Aug  3 23:49:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 3 Aug 2025 23:49:58 GMT
Subject: RFR: 8361730: The
 CodeBuilder.trying(BlockCodeBuilder,CatchBuilder) method generates corrupted
 bytecode in certain cases
In-Reply-To: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
References: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
Message-ID: <w8U9MLsodALaDRASYmzGzrwoQ73Du7sn3iHxpDXWTGU=.98d52f2d-59cb-4e51-aa8c-6bc7f2d8360d@github.com>

On Fri, 1 Aug 2025 18:05:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> Explicitly document that BlockCodeBuilder expects control flow to continue after it merges back to the parent block, so failure to do that by the users can lead to malformed code. This is better than introducing complex and costly analysis.

I don't think your suggestion work when one block code builder ends immediately with another block code builder. The enclosing one may require the goto if the nested one breaks to its break label.

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

PR Comment: https://git.openjdk.org/jdk/pull/26602#issuecomment-3148782928

From liach at openjdk.org  Mon Aug  4 00:24:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Aug 2025 00:24:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
Message-ID: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>

Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

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

Commit messages:
 - Years
 - Roll back Objects.rNN for now
 - Review remarks
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Bork
 - Try generify the NPE tracing API
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Perf concerns
 - Tests, MPs based prints
 - Objects rNN better message

Changes: https://git.openjdk.org/jdk/pull/26600/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364588
  Stats: 390 lines in 12 files changed: 335 ins; 13 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/26600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600

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

From liach at openjdk.org  Mon Aug  4 00:24:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Aug 2025 00:24:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <ksPqCsaVSiWksRW5oIZmkZ0TimHDV030yw31f42Vmzs=.9365ce10-9ba7-4da5-b577-e1bb4368886b@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

Thanks for the preliminary review. After some thinking, to avoid wasting review cycles, I am pulling the common infrastructure for requireNonNull and Checks::nullCheck into a JDK-internal API, and the changes here are mostly confined to runtime.

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

PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3148805289

From dholmes at openjdk.org  Mon Aug  4 00:24:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 00:24:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <FgcCs3wtRwUawkd0mM0h9E9I03F9BAB_8OhTPIEMH4U=.0516eeff-61d5-45c5-a884-312ce07bca5b@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

src/hotspot/share/classfile/javaClasses.cpp line 3060:

> 3058: }
> 3059: 
> 3060: bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool hidden_ok) {

Suggestion:

bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool allow_hidden) {

src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:

> 38:   static bool get_NPE_message_at(outputStream* ss, Method* method, int bci);
> 39:   // NPE extended message. Return true if string is printed.
> 40:   static bool get_NPE_message_at(outputStream* ss, Method* method, int bci, int slot);

Can you combine these with a default slot parameter (-1?) ? I'm suspecting not even though it might appear that once you have the slot you could call the new method, but the new method seems to expect only particular "kinds" of slot i.e. non-bytecode. But this is not documented at all. Please add comments to make it clear what the `slot` parameter is expected to be and how these two methods differ.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2248868942
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2248881502

From liach at openjdk.org  Mon Aug  4 00:24:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Aug 2025 00:24:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <FgcCs3wtRwUawkd0mM0h9E9I03F9BAB_8OhTPIEMH4U=.0516eeff-61d5-45c5-a884-312ce07bca5b@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <FgcCs3wtRwUawkd0mM0h9E9I03F9BAB_8OhTPIEMH4U=.0516eeff-61d5-45c5-a884-312ce07bca5b@github.com>
Message-ID: <sGKHMLSCvSm9UYsRFcahJf7vyYyT1Z0yfAPM4D9nKdo=.de4402e8-ce6f-4e38-94b3-6911cd5d92e0@github.com>

On Fri, 1 Aug 2025 21:05:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>
> src/hotspot/share/classfile/javaClasses.cpp line 3060:
> 
>> 3058: }
>> 3059: 
>> 3060: bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool hidden_ok) {
> 
> Suggestion:
> 
> bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool allow_hidden) {

Done.

> src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:
> 
>> 38:   static bool get_NPE_message_at(outputStream* ss, Method* method, int bci);
>> 39:   // NPE extended message. Return true if string is printed.
>> 40:   static bool get_NPE_message_at(outputStream* ss, Method* method, int bci, int slot);
> 
> Can you combine these with a default slot parameter (-1?) ? I'm suspecting not even though it might appear that once you have the slot you could call the new method, but the new method seems to expect only particular "kinds" of slot i.e. non-bytecode. But this is not documented at all. Please add comments to make it clear what the `slot` parameter is expected to be and how these two methods differ.

Done, and documented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2250200947
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2250201005

From asemenyuk at openjdk.org  Mon Aug  4 04:54:49 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 4 Aug 2025 04:54:49 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test [v5]
In-Reply-To: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
Message-ID: <VYPyMj3UEHduM_UuuhPJ4O8juiCWKs0JUWsKMYQDBbE=.a2b454a0-aff4-4251-b4ec-362ccb1f263a@github.com>

> - Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
> - Test shortcuts in the predefined app image.
> 
> Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.
> 
> Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.
> 
> Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.
> 
> Not directly related to the subject of the PR:
>  - JPackageCommand: Added missing and removed redundant `verifyMutable()` calls. Converted "jpt-unpacked-folder" option into the member field. Added `JPackageCommand.createMutableCopy()` complementary to the existing `JPackageCommand.createImmutableCopy()`.
>  - Added `test/jdk/tools/jpackage/clean_test_output.sh` Bash script filtering test logs to minimize noise in diffs.
> 
> Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - Use TKit.waitForFileCreated() to await for test output file
 - Use java.time.Duration and java.time.Instant in TKit.waitForFileCreated(). Make it public.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26584/files
  - new: https://git.openjdk.org/jdk/pull/26584/files/975a493f..a95677ff

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

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

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

From jjiang at openjdk.org  Mon Aug  4 07:43:35 2025
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 4 Aug 2025 07:43:35 GMT
Subject: RFR: 8364597: Replace THL A29 Limited with Tencent
Message-ID: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>

`THL A29 Limited` was a `Tencent` company but was dissolved.
So, the copyright notes just use `Tencent` directly.

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

Commit messages:
 - 8364597: Replace THL A29 Limited with Tencent

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

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

From mdonovan at openjdk.org  Mon Aug  4 12:59:55 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 4 Aug 2025 12:59:55 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
 <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
 <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>
Message-ID: <cnqT7g1JdcDC0IjD8h386mUWQPL9AgcQOW_Djrjz4l4=.06a5f9be-ad54-4466-936d-7a443560cd2b@github.com>

On Fri, 1 Aug 2025 19:25:43 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> The code currently being reviewed should only display signature schemes set with `jdk.tls.client.SignatureSchemes` system property.

Should that be displayed with `-XshowSettings:security:tls` or `-XshowSettings:security:properties`? On the surface, the latter makes more sense to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3150596127

From asemenyuk at openjdk.org  Mon Aug  4 13:43:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 4 Aug 2025 13:43:57 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test [v5]
In-Reply-To: <VYPyMj3UEHduM_UuuhPJ4O8juiCWKs0JUWsKMYQDBbE=.a2b454a0-aff4-4251-b4ec-362ccb1f263a@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
 <VYPyMj3UEHduM_UuuhPJ4O8juiCWKs0JUWsKMYQDBbE=.a2b454a0-aff4-4251-b4ec-362ccb1f263a@github.com>
Message-ID: <VIOANdfuy670CzhxhwLd4CFFRzvX5-e3v78NK625ws8=.f25fd77f-c63a-4554-a406-451b9220ec81@github.com>

On Mon, 4 Aug 2025 04:54:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
>> - Test shortcuts in the predefined app image.
>> 
>> Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.
>> 
>> Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.
>> 
>> Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.
>> 
>> Not directly related to the subject of the PR:
>>  - JPackageCommand: Added missing and removed redundant `verifyMutable()` calls. Converted "jpt-unpacked-folder" option into the member field. Added `JPackageCommand.createMutableCopy()` complementary to the existing `JPackageCommand.createImmutableCopy()`.
>>  - Added `test/jdk/tools/jpackage/clean_test_output.sh` Bash script filtering test logs to minimize noise in diffs.
>> 
>> Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use TKit.waitForFileCreated() to await for test output file
>  - Use java.time.Duration and java.time.Instant in TKit.waitForFileCreated(). Make it public.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/26584#issuecomment-3150773364

From abarashev at openjdk.org  Mon Aug  4 13:48:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 4 Aug 2025 13:48:55 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <cnqT7g1JdcDC0IjD8h386mUWQPL9AgcQOW_Djrjz4l4=.06a5f9be-ad54-4466-936d-7a443560cd2b@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
 <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
 <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>
 <cnqT7g1JdcDC0IjD8h386mUWQPL9AgcQOW_Djrjz4l4=.06a5f9be-ad54-4466-936d-7a443560cd2b@github.com>
Message-ID: <pI0eJIHdSw72R3vuyOWeNuDZv796bVjCvaFFDag_m94=.fd65f249-5b40-408f-92e4-c85c4948fb42@github.com>

On Mon, 4 Aug 2025 12:57:20 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> > The code currently being reviewed should only display signature schemes set with `jdk.tls.client.SignatureSchemes` system property.
> 
> Should that be displayed with `-XshowSettings:security:tls` or `-XshowSettings:security:properties`? On the surface, the latter makes more sense to me.

I think we should either implement a public API to provide those signature schemes or not display them at all to avoid any confusion. If someone sets `jdk.tls.client.SignatureSchemes` system property they would sure know about it. That property overrides all other signature schemes for both "signature_algorithms" and "signature_algorithms_cert" extensions.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3150790567

From asemenyuk at openjdk.org  Mon Aug  4 13:57:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 4 Aug 2025 13:57:09 GMT
Subject: RFR: 8359756: Bug in RuntimePackageTest.testName test
Message-ID: <88AI1ujHoRmWpdPIxeb-FZOzEokz7RHBlzEOVMUzoag=.bb55f71a-eb31-424f-b730-2c4bcb1fdca3@github.com>

- Fix `RuntimePackageTest.testName()` test case.
- Add `RuntimePackageTest.testFromBundle()` to cover the case of building a runtime package from a bundle on macOS. This test case was available in [SigningRuntimeImagePackageTest test](https://github.com/openjdk/jdk/blob/fc4755535d61c2fd4d9a2c9a673da148f742f035/test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java#L170), which is not a part of the standard test runs.

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

Commit messages:
 - Add test case to cover building of a runtime package from a runtime bundle on mac. Refactor verification code.
 - RuntimePackageTest: fix that RuntimePackageTest.testName() didn't remove `--name` option from jpackage command line when building any but a .deb package.

Changes: https://git.openjdk.org/jdk/pull/26607/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359756
  Stats: 151 lines in 2 files changed: 77 ins; 34 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/26607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26607/head:pull/26607

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

From asemenyuk at openjdk.org  Mon Aug  4 13:57:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 4 Aug 2025 13:57:09 GMT
Subject: RFR: 8359756: Bug in RuntimePackageTest.testName test
In-Reply-To: <88AI1ujHoRmWpdPIxeb-FZOzEokz7RHBlzEOVMUzoag=.bb55f71a-eb31-424f-b730-2c4bcb1fdca3@github.com>
References: <88AI1ujHoRmWpdPIxeb-FZOzEokz7RHBlzEOVMUzoag=.bb55f71a-eb31-424f-b730-2c4bcb1fdca3@github.com>
Message-ID: <-ga6uAnQ-YBgsyocJ0Fl7Y8j0INDxQ7HIx3di8VhJmA=.80fb3cff-599f-41e8-89b9-f6895e977c84@github.com>

On Sun, 3 Aug 2025 22:46:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix `RuntimePackageTest.testName()` test case.
> - Add `RuntimePackageTest.testFromBundle()` to cover the case of building a runtime package from a bundle on macOS. This test case was available in [SigningRuntimeImagePackageTest test](https://github.com/openjdk/jdk/blob/fc4755535d61c2fd4d9a2c9a673da148f742f035/test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java#L170), which is not a part of the standard test runs.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/26607#issuecomment-3150814486

From asemenyuk at openjdk.org  Mon Aug  4 13:58:00 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 4 Aug 2025 13:58:00 GMT
Subject: RFR: 8364587: Update jpackage internal javadoc
In-Reply-To: <jK5OUpoMgcXi6MtSsFj0q0Q0sdFoah8QuTlWCNCQ4E0=.d0b1f753-563a-4114-92be-eab47bb12c7d@github.com>
References: <jK5OUpoMgcXi6MtSsFj0q0Q0sdFoah8QuTlWCNCQ4E0=.d0b1f753-563a-4114-92be-eab47bb12c7d@github.com>
Message-ID: <IBUu6HPJwPHcOQYMW7NkpwKmK-8WcbJHlRt85Mj2BG8=.70b4ab06-2d0f-44d3-a29b-008297f7016c@github.com>

On Sun, 3 Aug 2025 23:08:17 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix javadoc errors in DefaultLauncherIcon, Launcher, and Application classes. Additionally, add javadoc to some methods of PackagingPipeline class.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/26609#issuecomment-3150820296

From rgiulietti at openjdk.org  Mon Aug  4 13:59:06 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 4 Aug 2025 13:59:06 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v7]
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <A_9LersslZvDYc_zh6-wNSfB42TQ4xBvCSUc9WjLFqA=.e446b82b-3f5f-40de-a8b4-facd4e25a0e6@github.com>

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into 8362448
 - Merge master.
 - Refactoring to paramaterized tests.
 - Removed temporary comment from tests.
 - Added tests.
 - Added comment to COMPAT static field.
 - Merge branch 'master' into 8362448
 - 8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
 - Remove some unused methods from FloatingDecimal.
 - Renamed compatibility config option.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/fc475553...d5cb9cf8

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

Changes: https://git.openjdk.org/jdk/pull/26364/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26364&range=06
  Stats: 190 lines in 7 files changed: 140 ins; 7 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/26364.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26364/head:pull/26364

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

From dnsimon at openjdk.org  Mon Aug  4 15:04:04 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 4 Aug 2025 15:04:04 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <bsYDcgavbXfmf2WP_iXtlEJGKPZppbq1yBGektW4cI0=.4e19234e-cd9a-40d7-add6-e6cbcf8ea01c@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

src/hotspot/share/prims/jvm.cpp line 1744:

> 1742: JVM_END
> 1743: 
> 1744: JVM_ENTRY(jint, JVM_GetClassAccessFlags(JNIEnv *env, jclass cls))

What about the declaration in `jvm.h`? https://github.com/openjdk/jdk/blob/6c52b73465b0d0daeafc54c3c6cec3062bf490c5/src/hotspot/share/include/jvm.h#L610

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2251770425

From galder at openjdk.org  Mon Aug  4 15:50:57 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 4 Aug 2025 15:50:57 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <UoT_z_H4E_R2wNwHMvnByrhwz9J3OedyOyiSDVvIi8E=.558af8c9-47be-40df-9f11-f37931bd7977@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <UoT_z_H4E_R2wNwHMvnByrhwz9J3OedyOyiSDVvIi8E=.558af8c9-47be-40df-9f11-f37931bd7977@github.com>
Message-ID: <Y9wAy2ATBnuS1rx2nfog9psWD4JKZOuyUAOma8zgyRo=.f10fbce1-afb4-4046-8d4c-92f8fc98e02b@github.com>

On Fri, 1 Aug 2025 12:17:03 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
>> 
>> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
>> 
>> 
>> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
>> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
>> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
>> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
>> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
>> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
>> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
>> 
>> 
>> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
>> 
>> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.
>
> src/hotspot/share/opto/vectornode.cpp line 1830:
> 
>> 1828: }
>> 1829: 
>> 1830: bool VectorReinterpretNode::implemented(int opc, uint vlen, BasicType src_type, BasicType dst_type) {
> 
> `opc` is not used in this method. Do we need this parameter here?

Yup not needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2251882431

From galder at openjdk.org  Mon Aug  4 15:55:56 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 4 Aug 2025 15:55:56 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <sbCTlmYeppEWTNLRENsPxpa_gLh0SQq3Wh8B11F_Tcg=.a48c3679-4ba1-4594-ac0c-44f9d16c114f@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <sbCTlmYeppEWTNLRENsPxpa_gLh0SQq3Wh8B11F_Tcg=.a48c3679-4ba1-4594-ac0c-44f9d16c114f@github.com>
Message-ID: <87722bascgvRzxbCm2Npiamp8TmwaGlqCB7rfkdNNFY=.6cb35d1f-2dec-4340-84e5-92ebd3d81921@github.com>

On Fri, 1 Aug 2025 12:52:21 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
>> 
>> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
>> 
>> 
>> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
>> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
>> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
>> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
>> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
>> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
>> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
>> 
>> 
>> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
>> 
>> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.
>
> src/hotspot/share/opto/vectornode.cpp line 1831:
> 
>> 1829: 
>> 1830: bool VectorReinterpretNode::implemented(int opc, uint vlen, BasicType src_type, BasicType dst_type) {
>> 1831:   if ((src_type == T_FLOAT && dst_type == T_INT) ||
> 
> Just a suggestion, do you feel a `switch-case` could be more readable/clear in this case? Something like this -
> 
> 
> bool VectorReinterpretNode::implemented(uint vlen, BasicType src_type, BasicType dst_type) {
>   switch (src_type) {
>     case T_FLOAT:
>       if (dst_type != T_INT)    return false;
>       break;
>     case T_INT:
>       if (dst_type != T_FLOAT)  return false;
>       break;
>     case T_DOUBLE:
>       if (dst_type != T_LONG)   return false;
>       break;
>     case T_LONG:
>       if (dst_type != T_DOUBLE) return false;
>       break;
>     default:
>       return false;
>   }
>   return Matcher::match_rule_supported_auto_vectorization(Op_VectorReinterpret, vlen, dst_type);
> }

Both options look just fine to me, but I'm happy to re-write it like that if others also feel the same way.

> test/micro/org/openjdk/bench/java/lang/VectorBitConversion.java line 67:
> 
>> 65: 
>> 66:     @Benchmark
>> 67:     public long[] doubleToLongBits() {
> 
> Would something like this be more concise (and maybe more readable as well) - 
> 
> @Benchmark
> public long[] doubleToLongBits() {
>     for (int i = 0; i < doubles.length; i++) {
>         resultLongs[i] = Double.doubleToLongBits(doubles[i]);
>     }
>     return resultLongs;
> }
> 
> 
> The loop should still get vectorized (if vectorizable).
> 
> Same for other benchmarks.

Maybe but there's a reason why I wrote these benchmark methods this way. Keeping each line doing one thing makes it easier to map each line to the assembly (e.g. `perfasm`) and related IR nodes (e.g. `PrintIdeal`). That IMO is more important than the conciseness of the benchmark. What do others think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2251893141
PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2251889884

From rriggs at openjdk.org  Mon Aug  4 16:13:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Aug 2025 16:13:57 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v6]
In-Reply-To: <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
Message-ID: <e8CHDPohPv6YlEjeHZbS0zxcg9K4vrklc7sYsOr-R7I=.69f89236-7fb7-4192-81bd-350ab4b42626@github.com>

On Fri, 1 Aug 2025 19:05:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has 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 16 commits:
> 
>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>  - Spec update
>  - Supplementary/CanonEq tests
>  - flipped again, which was correct
>  - flipped the size check
>  - Address review comments
>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>  - tidying up
>  - test location
>  - spec update
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d

The description and CSR should be clearer that lenient parsing is enabled by default.
The CSR compatibility paragraph mentions this as the default "implementation"; it might be more smoothly described as lenient parsing. Mentioning "implementation" implies there might be another/different implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/26580#issuecomment-3151397513

From pminborg at openjdk.org  Mon Aug  4 17:27:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 4 Aug 2025 17:27:05 GMT
Subject: RFR: 8364540: Apply @Stable to Shared Secrets
Message-ID: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>

This PR proposes to update the `SharedSecrets` class in `jdk.internal.access` to annotate all but one static field with the `@Stable` annotation.

The `@Stable` annotation was added to all static fields except for `javaAWTFontAccess`, which remains unannotated. This is because it can be set using several code paths.

No tests were changed or added, as this is an internal annotation adjustment with no expected behavioral impact.

This PR passes `tier1`, `tier2`, and `tier3` testing on multiple platforms.

In a future follow-up issue, we could identify fields in the implementations of the access classes that, in turn, are stable themselves. When this PR is integrated, it might be possible to remove local copies of access in classes to reduce bytecode size with little or no performance impact. Currently, we do not check the invariant, a field is set only once. This is yet another improvement proposal we could do -- maybe using Stable Values.

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

Commit messages:
 - Make all fields except one @Stable in SharedSecrets

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

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

From duke at openjdk.org  Mon Aug  4 17:53:59 2025
From: duke at openjdk.org (duke)
Date: Mon, 4 Aug 2025 17:53:59 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3]
In-Reply-To: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
Message-ID: <nWRvqmNuSZHF2n7PDySn4b2h3MnvhBUzl0SpblAwrUU=.eddfe4d6-fdef-4d79-9909-9a1fe15db353@github.com>

On Thu, 31 Jul 2025 21:32:16 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
>> 
>> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
>> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
>> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
>> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
>> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
>> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2

@missa-prime 
Your change (at version 3ab7ab3e752991e2eb7f43af68380f1e66be9bec) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3151813299

From rriggs at openjdk.org  Mon Aug  4 18:06:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Aug 2025 18:06:04 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v6]
In-Reply-To: <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
Message-ID: <eKIqkSeieZJDQQ-MrIF3bmPr4Ru6iQMuhrds2DDTFhs=.83566f80-2960-4c52-aa6f-8aed9fe8a525@github.com>

On Fri, 1 Aug 2025 19:05:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has 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 16 commits:
> 
>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>  - Spec update
>  - Supplementary/CanonEq tests
>  - flipped again, which was correct
>  - flipped the size check
>  - Address review comments
>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>  - tidying up
>  - test location
>  - spec update
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d

src/java.base/share/classes/java/text/DecimalFormat.java line 421:

> 419:  * returns a numerically greater value.
> 420:  *
> 421:  * @implNote The default implementation follows the LDML specification

You can remove "default".  `The implementation follows...`.
The default changes the sense to refer to the code implementing this class.

src/java.base/share/classes/java/text/DecimalFormat.java line 3522:

> 3520:         if (alen == 0) {
> 3521:             return true;
> 3522:         }

This seems suspect, a zero length affix seems like an error. And if there is an empty affix, subsequent code should not be doing replacement.

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 721:

> 719:      * {@return the lenient minus signs}
> 720:      */
> 721:     String getLenientMinusSign() {

Singular vs plural might be confusing. Is it a single char or a set of chars returned in a string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252223596
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252228223
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252195256

From missa at openjdk.org  Mon Aug  4 18:51:28 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 4 Aug 2025 18:51:28 GMT
Subject: Integrated: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <IRGVwRF-0hqAI3XnSOK1us9NNC6P-H6ka5hS_2Wjq7I=.e530c5c4-5a61-4c34-a8ee-7051e958845f@github.com>

On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
> 
> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.

This pull request has now been integrated.

Changeset: 05f8a6fc
Author:    Mohamed Issa <missa at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05f8a6fca87d472a80e5952ddc90d8fa6589c75c
Stats:     742 lines in 26 files changed: 739 ins; 0 del; 3 mod

8360559: Optimize Math.sinh for x86 64 bit platforms

Reviewed-by: sviswanathan, sparasa

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

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

From rriggs at openjdk.org  Mon Aug  4 19:11:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Aug 2025 19:11:16 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3]
In-Reply-To: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
Message-ID: <vyVkMQdZMj0GkWf5ARt2UnltthyPCwTXvffpGfDPpms=.374f29f8-eb73-4e39-a240-ee71302c97af@github.com>

On Thu, 31 Jul 2025 21:32:16 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
>> 
>> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
>> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
>> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
>> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
>> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
>> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2

This seems to be failing in the CI on the build of: linux-x64-debug-nopch

[2025-08-04T19:02:29,373Z] /......../workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp:293:27: error: 'stub_id' was not declared in this scope; did you mean 'StubId'?
[2025-08-04T19:02:29,373Z]   293 |   StubCodeMark mark(this, stub_id);
[2025-08-04T19:02:29,373Z]       |                           ^~~~~~~
[2025-08-04T19:02:29,373Z]       |                           StubId
[2025-08-04T19:02:29,373Z]

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3152016875

From missa at openjdk.org  Mon Aug  4 19:50:11 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 4 Aug 2025 19:50:11 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3]
In-Reply-To: <vyVkMQdZMj0GkWf5ARt2UnltthyPCwTXvffpGfDPpms=.374f29f8-eb73-4e39-a240-ee71302c97af@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
 <vyVkMQdZMj0GkWf5ARt2UnltthyPCwTXvffpGfDPpms=.374f29f8-eb73-4e39-a240-ee71302c97af@github.com>
Message-ID: <WUdDHLOp97AX6ZT5-0hJ9E65hVbhKAkDZezvFy1j8Vs=.df1bc921-830f-4a11-a864-6ea1f4f3aaeb@github.com>

On Mon, 4 Aug 2025 19:06:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This seems to be failing in the CI on the build of: linux-x64-debug-nopch
> 
> ```
> [2025-08-04T19:02:29,373Z] /......../workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp:293:27: error: 'stub_id' was not declared in this scope; did you mean 'StubId'?
> [2025-08-04T19:02:29,373Z]   293 |   StubCodeMark mark(this, stub_id);
> [2025-08-04T19:02:29,373Z]       |                           ^~~~~~~
> [2025-08-04T19:02:29,373Z]       |                           StubId
> [2025-08-04T19:02:29,373Z] 
> ```

Thanks for notification. It looks like an incorrect type declaration. I'll submit a fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3152125201

From bkilambi at openjdk.org  Mon Aug  4 20:10:09 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 4 Aug 2025 20:10:09 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <87722bascgvRzxbCm2Npiamp8TmwaGlqCB7rfkdNNFY=.6cb35d1f-2dec-4340-84e5-92ebd3d81921@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <sbCTlmYeppEWTNLRENsPxpa_gLh0SQq3Wh8B11F_Tcg=.a48c3679-4ba1-4594-ac0c-44f9d16c114f@github.com>
 <87722bascgvRzxbCm2Npiamp8TmwaGlqCB7rfkdNNFY=.6cb35d1f-2dec-4340-84e5-92ebd3d81921@github.com>
Message-ID: <eNWyBPxWAbSncA3Ua5C_1APwm3oScJojNXuzdTOmfrY=.af95105f-4afe-47f9-93b9-641b06f84265@github.com>

On Mon, 4 Aug 2025 15:51:59 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/VectorBitConversion.java line 67:
>> 
>>> 65: 
>>> 66:     @Benchmark
>>> 67:     public long[] doubleToLongBits() {
>> 
>> Would something like this be more concise (and maybe more readable as well) - 
>> 
>> @Benchmark
>> public long[] doubleToLongBits() {
>>     for (int i = 0; i < doubles.length; i++) {
>>         resultLongs[i] = Double.doubleToLongBits(doubles[i]);
>>     }
>>     return resultLongs;
>> }
>> 
>> 
>> The loop should still get vectorized (if vectorizable).
>> 
>> Same for other benchmarks.
>
> Maybe but there's a reason why I wrote these benchmark methods this way. Keeping each line doing one thing makes it easier to map each line to the assembly (e.g. `perfasm`) and related IR nodes (e.g. `PrintIdeal`). That IMO is more important than the conciseness of the benchmark. What do others think?

Makes sense. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2252475557

From dcubed at openjdk.org  Mon Aug  4 20:32:18 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 20:32:18 GMT
Subject: RFR: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86 64 bit
 platforms
Message-ID: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>

This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.

This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.

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

Commit messages:
 - Revert "8360559: Optimize Math.sinh for x86 64 bit platforms"

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

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

From ayang at openjdk.org  Mon Aug  4 20:34:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Aug 2025 20:34:04 GMT
Subject: RFR: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86 64
 bit platforms
In-Reply-To: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
References: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
Message-ID: <tzcHGOZp-5DSw6vsg-nAweD4vuR4xtlizo4KadwNyzc=.d3c18ea7-45ff-4014-9fe5-4e101e9702cd@github.com>

On Mon, 4 Aug 2025 20:21:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.
> 
> This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26628#pullrequestreview-3085667097

From dcubed at openjdk.org  Mon Aug  4 20:53:03 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 20:53:03 GMT
Subject: RFR: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86 64
 bit platforms
In-Reply-To: <tzcHGOZp-5DSw6vsg-nAweD4vuR4xtlizo4KadwNyzc=.d3c18ea7-45ff-4014-9fe5-4e101e9702cd@github.com>
References: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
 <tzcHGOZp-5DSw6vsg-nAweD4vuR4xtlizo4KadwNyzc=.d3c18ea7-45ff-4014-9fe5-4e101e9702cd@github.com>
Message-ID: <VVIJ_KFQwOnEbffpkm1PdNyI0LH2E5J1PXTTc3E067k=.d69e07c3-565e-48d8-ab22-6e88fe4ff289@github.com>

On Mon, 4 Aug 2025 20:31:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.
>> 
>> This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk - Thanks for the review! We may not do the [BACKOUT] since we have
a proper fix being reviewed and tested over here:
https://github.com/openjdk/jdk/pull/26629

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

PR Comment: https://git.openjdk.org/jdk/pull/26628#issuecomment-3152374123

From dcubed at openjdk.org  Mon Aug  4 21:38:08 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 21:38:08 GMT
Subject: RFR: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86 64
 bit platforms
In-Reply-To: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
References: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
Message-ID: <BuUPHLG09YQrKLxr-GeXuegKpr-g9ai8gDdsqbKzfTQ=.e54fc6aa-76f0-4cd3-b347-c80cf8bcbb0b@github.com>

On Mon, 4 Aug 2025 20:21:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.
> 
> This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.

Closing this [BACKOUT] PR in favor of the real fix in https://github.com/openjdk/jdk/pull/26629.

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

PR Comment: https://git.openjdk.org/jdk/pull/26628#issuecomment-3152471724

From dcubed at openjdk.org  Mon Aug  4 21:38:08 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 21:38:08 GMT
Subject: Withdrawn: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86
 64 bit platforms
In-Reply-To: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
References: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
Message-ID: <d3lXymbb3R1wU3Mgj_7QxbqdbKrxADVdi_Er5y6JhAU=.9dc9b1f1-e3fe-4ea8-aea7-17d4bf1d2cca@github.com>

On Mon, 4 Aug 2025 20:21:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.
> 
> This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Mon Aug  4 21:45:21 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 4 Aug 2025 21:45:21 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return
 true for NTFS directory junctions when links not followed
Message-ID: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>

Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.

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

Commit messages:
 - 8364277: Add sub-test to existing test
 - 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed

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

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

From naoto at openjdk.org  Mon Aug  4 23:57:28 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Aug 2025 23:57:28 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

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

  refrects review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/3682484d..31250ee4

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

  Stats: 64 lines in 6 files changed: 21 ins; 13 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

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

From naoto at openjdk.org  Mon Aug  4 23:57:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Aug 2025 23:57:30 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v6]
In-Reply-To: <eKIqkSeieZJDQQ-MrIF3bmPr4Ru6iQMuhrds2DDTFhs=.83566f80-2960-4c52-aa6f-8aed9fe8a525@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
 <eKIqkSeieZJDQQ-MrIF3bmPr4Ru6iQMuhrds2DDTFhs=.83566f80-2960-4c52-aa6f-8aed9fe8a525@github.com>
Message-ID: <lptJJdUHr0ZZyGxmaHpD6QRGXLKLYFxQ5DjtnXlVeXI=.b432abb4-f39d-4ff1-b294-7cfce5f50c34@github.com>

On Mon, 4 Aug 2025 17:58:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>>  - Spec update
>>  - Supplementary/CanonEq tests
>>  - flipped again, which was correct
>>  - flipped the size check
>>  - Address review comments
>>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>>  - tidying up
>>  - test location
>>  - spec update
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 3522:
> 
>> 3520:         if (alen == 0) {
>> 3521:             return true;
>> 3522:         }
> 
> This seems suspect, a zero length affix seems like an error. And if there is an empty affix, subsequent code should not be doing replacement.

This is expected. Since prefix/suffix in the format patterns are optional, empty prefix/suffix should match the text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252809269

From naoto at openjdk.org  Tue Aug  5 00:01:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 00:01:04 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
Message-ID: <eJu0sdtAbon0o_uibpr0DXHz9dJv7QYLvgmCj5KlQrQ=.102252d4-3c11-4ebd-88e6-19099b371c71@github.com>

On Mon, 4 Aug 2025 23:57:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refrects review comments

OK, I decided to explictly exclude those supplementary/normalization cases where the affix lengths would change. If we wanted to make it work with supplementary/normalization, it needs to account for the variable affix length and needs lots of changes in DecimalFormat/CompactNumberFormat, and I think not worth it (complex changes for non-existent leniency). So I adopted Justin's char based iteration (thanks!). Test has been modified to explicitly verify this behavior (for supplementary, normalization is obvious)

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

PR Comment: https://git.openjdk.org/jdk/pull/26580#issuecomment-3152835000

From asemenyuk at openjdk.org  Tue Aug  5 00:14:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Aug 2025 00:14:10 GMT
Subject: RFR: 8362352: Fix references to non-existing resource strings
Message-ID: <XP_5JIScg6g7W-qLJ22AOkY66QbqE-UYXzvuPmudDeE=.c2a36779-3af5-4173-ba97-a6d38ea78ffb@github.com>

Remove code referencing non-existing resource strings.

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

Commit messages:
 - 63696e96: <no commit message found>
 - Remove the reference to non-existing "message.app-image-dir-does-not-exist" resource string and redundant StandardBundlerParam.getPredefinedAppImage().
 - Remove redundant check from RuntimeBuilderBuilder. It duplicates the check in DeployParams.validate() and references deleted "message.runtime-image-dir-does-not-exist.advice" l10n key

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

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

From asemenyuk at openjdk.org  Tue Aug  5 00:14:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Aug 2025 00:14:10 GMT
Subject: RFR: 8362352: Fix references to non-existing resource strings
In-Reply-To: <XP_5JIScg6g7W-qLJ22AOkY66QbqE-UYXzvuPmudDeE=.c2a36779-3af5-4173-ba97-a6d38ea78ffb@github.com>
References: <XP_5JIScg6g7W-qLJ22AOkY66QbqE-UYXzvuPmudDeE=.c2a36779-3af5-4173-ba97-a6d38ea78ffb@github.com>
Message-ID: <dDpX6inMRkHOcvwA5NF8N18kIce0GvF1nlWRdEzjrek=.8fe9c499-57fd-4d27-9097-3540d1bacde9@github.com>

On Mon, 4 Aug 2025 16:49:32 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Remove code referencing non-existing resource strings.

@sashamatveev PTAL

The "The pull request body must not be empty." error is gone

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

PR Comment: https://git.openjdk.org/jdk/pull/26626#issuecomment-3151637328
PR Comment: https://git.openjdk.org/jdk/pull/26626#issuecomment-3152850265

From almatvee at openjdk.org  Tue Aug  5 00:14:11 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 5 Aug 2025 00:14:11 GMT
Subject: RFR: 8362352: Fix references to non-existing resource strings
In-Reply-To: <XP_5JIScg6g7W-qLJ22AOkY66QbqE-UYXzvuPmudDeE=.c2a36779-3af5-4173-ba97-a6d38ea78ffb@github.com>
References: <XP_5JIScg6g7W-qLJ22AOkY66QbqE-UYXzvuPmudDeE=.c2a36779-3af5-4173-ba97-a6d38ea78ffb@github.com>
Message-ID: <Ndn-tiNXNuvke7UhaizknuvoXuTxdrZ5BBZSUUITfmM=.02162ad1-dfcd-4914-98ac-7b9599b34649@github.com>

On Mon, 4 Aug 2025 16:49:32 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Remove code referencing non-existing resource strings.

You need to fix "The pull request body must not be empty.". Looks good otherwise.

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

PR Comment: https://git.openjdk.org/jdk/pull/26626#issuecomment-3152830759

From almatvee at openjdk.org  Tue Aug  5 01:02:13 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 5 Aug 2025 01:02:13 GMT
Subject: RFR: 8362352: Fix references to non-existing resource strings
In-Reply-To: <XP_5JIScg6g7W-qLJ22AOkY66QbqE-UYXzvuPmudDeE=.c2a36779-3af5-4173-ba97-a6d38ea78ffb@github.com>
References: <XP_5JIScg6g7W-qLJ22AOkY66QbqE-UYXzvuPmudDeE=.c2a36779-3af5-4173-ba97-a6d38ea78ffb@github.com>
Message-ID: <5Q__XBctEamFpImnpJCpJz9W_aENP5dt8y8lhLzYI90=.a2da40f1-0f0d-4d77-9e94-c86d92f1b3a6@github.com>

On Mon, 4 Aug 2025 16:49:32 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Remove code referencing non-existing resource strings.

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26626#pullrequestreview-3086186324

From almatvee at openjdk.org  Tue Aug  5 01:07:13 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 5 Aug 2025 01:07:13 GMT
Subject: RFR: 8359756: Bug in RuntimePackageTest.testName test
In-Reply-To: <88AI1ujHoRmWpdPIxeb-FZOzEokz7RHBlzEOVMUzoag=.bb55f71a-eb31-424f-b730-2c4bcb1fdca3@github.com>
References: <88AI1ujHoRmWpdPIxeb-FZOzEokz7RHBlzEOVMUzoag=.bb55f71a-eb31-424f-b730-2c4bcb1fdca3@github.com>
Message-ID: <U1DJxE8g8uRLA3xqut3xRNBw1EATvv-plrtxN7p02zI=.31b6267e-0689-4d0a-8f83-40af06b2c1d2@github.com>

On Sun, 3 Aug 2025 22:46:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix `RuntimePackageTest.testName()` test case.
> - Add `RuntimePackageTest.testFromBundle()` to cover the case of building a runtime package from a bundle on macOS. This test case was available in [SigningRuntimeImagePackageTest test](https://github.com/openjdk/jdk/blob/fc4755535d61c2fd4d9a2c9a673da148f742f035/test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java#L170), which is not a part of the standard test runs.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26607#pullrequestreview-3086192597

From asemenyuk at openjdk.org  Tue Aug  5 01:08:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Aug 2025 01:08:15 GMT
Subject: Integrated: 8362352: Fix references to non-existing resource strings
In-Reply-To: <XP_5JIScg6g7W-qLJ22AOkY66QbqE-UYXzvuPmudDeE=.c2a36779-3af5-4173-ba97-a6d38ea78ffb@github.com>
References: <XP_5JIScg6g7W-qLJ22AOkY66QbqE-UYXzvuPmudDeE=.c2a36779-3af5-4173-ba97-a6d38ea78ffb@github.com>
Message-ID: <YosnewO1JBmlG-a3YG05Nh51gt2UuHsI7gU3sZzhutQ=.bfc7ac50-88c2-49e6-933e-aae23a15ccd6@github.com>

On Mon, 4 Aug 2025 16:49:32 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Remove code referencing non-existing resource strings.

This pull request has now been integrated.

Changeset: 0f4c3dc9
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f4c3dc944212c63acee35b7be93767946397ec0
Stats:     41 lines in 3 files changed: 8 ins; 30 del; 3 mod

8362352: Fix references to non-existing resource strings

Reviewed-by: almatvee

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

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

From asemenyuk at openjdk.org  Tue Aug  5 01:13:22 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Aug 2025 01:13:22 GMT
Subject: Integrated: 8359756: Bug in RuntimePackageTest.testName test
In-Reply-To: <88AI1ujHoRmWpdPIxeb-FZOzEokz7RHBlzEOVMUzoag=.bb55f71a-eb31-424f-b730-2c4bcb1fdca3@github.com>
References: <88AI1ujHoRmWpdPIxeb-FZOzEokz7RHBlzEOVMUzoag=.bb55f71a-eb31-424f-b730-2c4bcb1fdca3@github.com>
Message-ID: <WakY0-LCcUydiDo-nPigFqnWY4Y_YaRAgCynM0gPBiA=.f9fb65b5-c1b7-429c-8c76-1d85144f3103@github.com>

On Sun, 3 Aug 2025 22:46:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix `RuntimePackageTest.testName()` test case.
> - Add `RuntimePackageTest.testFromBundle()` to cover the case of building a runtime package from a bundle on macOS. This test case was available in [SigningRuntimeImagePackageTest test](https://github.com/openjdk/jdk/blob/fc4755535d61c2fd4d9a2c9a673da148f742f035/test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java#L170), which is not a part of the standard test runs.

This pull request has now been integrated.

Changeset: 6b360ac9
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b360ac99af356613c6dd2cad0c2c84c5737519d
Stats:     151 lines in 2 files changed: 77 ins; 34 del; 40 mod

8359756: Bug in RuntimePackageTest.testName test

Reviewed-by: almatvee

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

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

From shaojin.wensj at alibaba-inc.com  Tue Aug  5 01:25:54 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Tue, 05 Aug 2025 09:25:54 +0800
Subject: =?UTF-8?B?UmVkdWNlIHNpemUgb2Ygai50LmYuRGF0ZVRpbWVQcmludENvbnRleHQ6OmFkanVzdA==?=
Message-ID: <62d992ec-5a3c-4436-be49-a692379402c4.shaojin.wensj@alibaba-inc.com>

By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
Below is the log message:
```
@ 7 java.time.format.DateTimePrintContext::adjust (382 bytes) failed to inline: hot method too big
```
We can extract the exception-generating code into two smaller methods, reducing the code size from 382 to 322, allowing C2 to inline the DateTimePrintContext::adjust method.
The refactored code looks like this:
```java
 private static TemporalAccessor adjust(final TemporalAccessor temporal, DateTimeFormatter formatter) {
 // ...
 if (overrideZone.normalized() instanceof ZoneOffset && temporal.isSupported(OFFSET_SECONDS) &&
 temporal.get(OFFSET_SECONDS) != overrideZone.getRules().getOffset(Instant.EPOCH).getTotalSeconds()) {
 throw unableApplyOverrideZone(temporal, overrideZone);
 }
 // ....
 if (f.isDateBased() && temporal.isSupported(f)) {
 throw unableApplyOverrideChronology(temporal, overrideChrono);
 // ...
 }
 private static DateTimeException unableApplyOverrideChronology(TemporalAccessor temporal, Chronology overrideChrono) {
 return new DateTimeException("Unable to apply override chronology '" + overrideChrono +
 "' because the temporal object being formatted contains date fields but" +
 " does not represent a whole date: " + temporal);
 }
 private static DateTimeException unableApplyOverrideZone(TemporalAccessor temporal, ZoneId overrideZone) {
 return new DateTimeException("Unable to apply override zone '" + overrideZone +
 "' because the temporal object being formatted has a different offset but" +
 " does not represent an instant: " + temporal);
 }
```
I submitted a draft Pull Request https://github.com/openjdk/jdk/pull/26633 <https://github.com/openjdk/jdk/pull/26633 > , Hope to get your feedback.
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250805/ab338af1/attachment.htm>

From almatvee at openjdk.org  Tue Aug  5 01:36:12 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 5 Aug 2025 01:36:12 GMT
Subject: RFR: 8364587: Update jpackage internal javadoc
In-Reply-To: <jK5OUpoMgcXi6MtSsFj0q0Q0sdFoah8QuTlWCNCQ4E0=.d0b1f753-563a-4114-92be-eab47bb12c7d@github.com>
References: <jK5OUpoMgcXi6MtSsFj0q0Q0sdFoah8QuTlWCNCQ4E0=.d0b1f753-563a-4114-92be-eab47bb12c7d@github.com>
Message-ID: <Oi0uRLREL6nBffwJANvbhAe2O2ZZA7xEHYtHzl3mgzc=.1c3b43a9-5d97-48e0-b111-65815ce9aa7f@github.com>

On Sun, 3 Aug 2025 23:08:17 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix javadoc errors in DefaultLauncherIcon, Launcher, and Application classes. Additionally, add javadoc to some methods of PackagingPipeline class.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26609#pullrequestreview-3086227545

From asemenyuk at openjdk.org  Tue Aug  5 01:46:07 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Aug 2025 01:46:07 GMT
Subject: Integrated: 8364587: Update jpackage internal javadoc
In-Reply-To: <jK5OUpoMgcXi6MtSsFj0q0Q0sdFoah8QuTlWCNCQ4E0=.d0b1f753-563a-4114-92be-eab47bb12c7d@github.com>
References: <jK5OUpoMgcXi6MtSsFj0q0Q0sdFoah8QuTlWCNCQ4E0=.d0b1f753-563a-4114-92be-eab47bb12c7d@github.com>
Message-ID: <-9zFDiY3M772SvYX0LCVKTFGDwNBoD-TFxju73i3tiQ=.dabfa563-3bba-4dce-85bc-cf46d83ca03c@github.com>

On Sun, 3 Aug 2025 23:08:17 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix javadoc errors in DefaultLauncherIcon, Launcher, and Application classes. Additionally, add javadoc to some methods of PackagingPipeline class.

This pull request has now been integrated.

Changeset: c0c7d39b
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0c7d39b59e646a51bf3a6729065cceda9b0a0ad
Stats:     35 lines in 4 files changed: 30 ins; 0 del; 5 mod

8364587: Update jpackage internal javadoc

Reviewed-by: almatvee

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

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

From galder at openjdk.org  Tue Aug  5 06:08:05 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 5 Aug 2025 06:08:05 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <7UqSdBPWH0SbdkhAUvF_qM10rK0oFsJXhUKWA3VlL14=.0c35e297-7276-468b-98c6-046e84897625@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <7UqSdBPWH0SbdkhAUvF_qM10rK0oFsJXhUKWA3VlL14=.0c35e297-7276-468b-98c6-046e84897625@github.com>
Message-ID: <Wl68Jl6BnrU0rxhQ0yk6oGFgzq6dg2BVg90XqyGZTPs=.987a580b-8bdd-4a19-8aad-be7a7a95498a@github.com>

On Fri, 1 Aug 2025 11:58:03 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> VectorNode::is_reinterpret_opcode returns true for Op_ReinterpretHF2S and Op_ReinterpretS2HF, which are very similar to the nodes in this PR, can you add these nodes to that method instead?

You're suggesting to modify `is_reinterpret_opcode` to be like this, and call that instead of `is_move_opcode`, right?


bool VectorNode::is_reinterpret_opcode(int opc) {
  switch (opc) {
    case Op_ReinterpretHF2S:
    case Op_ReinterpretS2HF:
    case Op_MoveF2I:
    case Op_MoveD2L:
    case Op_MoveL2D:
    case Op_MoveI2F:
      return true;
    default:
      return false;
  }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3153512422

From galder at openjdk.org  Tue Aug  5 06:08:06 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 5 Aug 2025 06:08:06 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <yIOUpfDrnLAiZmNc7ILrGSwROp1mgeChBwtXHzTJU9o=.a82140e3-af74-4ece-8850-fcece5abc6f0@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <yIOUpfDrnLAiZmNc7ILrGSwROp1mgeChBwtXHzTJU9o=.a82140e3-af74-4ece-8850-fcece5abc6f0@github.com>
Message-ID: <e0UjUOCmyDTo1bfDTHfz8498cqKbppXb8ZW9L7G9qcs=.f403d835-7dd0-40bf-854b-dd1a874a7aa8@github.com>

On Fri, 1 Aug 2025 12:46:01 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Although this is not in the scope of this patch, but I wonder if we could rename `ReinterpretS2HF` and `ReinterpretHF2S` to `MoveHF2S` and `MoveS2HF` to keep naming consistent with other types? WDYT @jatin-bhateja

That sounds reasonable to me

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

PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3153514145

From qamai at openjdk.org  Tue Aug  5 06:35:03 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 5 Aug 2025 06:35:03 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <Wl68Jl6BnrU0rxhQ0yk6oGFgzq6dg2BVg90XqyGZTPs=.987a580b-8bdd-4a19-8aad-be7a7a95498a@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <7UqSdBPWH0SbdkhAUvF_qM10rK0oFsJXhUKWA3VlL14=.0c35e297-7276-468b-98c6-046e84897625@github.com>
 <Wl68Jl6BnrU0rxhQ0yk6oGFgzq6dg2BVg90XqyGZTPs=.987a580b-8bdd-4a19-8aad-be7a7a95498a@github.com>
Message-ID: <mcYlVZnLh_y4PkzgmsCcerq7WcNCJRHB6VTPu5gKzww=.97654126-b27b-4289-bfa4-710b6bfda975@github.com>

On Tue, 5 Aug 2025 06:05:22 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> You're suggesting to modify `is_reinterpret_opcode` to be like this, and call that instead of `is_move_opcode`, right?

Yes, that's right. I believe `VectorReinterpret` should be implemented for all pairs of vector species where both the input and output species are implemented. So, `VectorReinterpretNode::implemented` is unnecessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3153680952

From alanb at openjdk.org  Tue Aug  5 06:56:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Aug 2025 06:56:10 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed
In-Reply-To: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
Message-ID: <WdbGr9mbqjL04ZvuEl3UgE_Y68UHPdQ1hslNdGK_pJk=.33f6976a-c9d6-4f3f-a457-bcdc507336f3@github.com>

On Mon, 4 Aug 2025 21:38:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.

On the surface, treating a NTFS directory junction as "other" make sense as they don't fit the file kinds known to the platform. The only reparse points that the JDK can sensibly deal with are symbolic links and Unix domain socket files.

My main concern is what might be depending on existing behavior and what inconsistencies will surface if we change this. Would it be possible to enumerate how some of the APIs behave before+after this change? I'm specifically wondering about toRealPath and Files.list/walk behave now and how they will behave with the change.

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

PR Comment: https://git.openjdk.org/jdk/pull/26631#issuecomment-3153735203

From dholmes at openjdk.org  Tue Aug  5 08:35:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 08:35:11 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

VM side seems reasonable. Java side looks a bit clunky but that is up to core-libs folk to evaluate.

General note: if comments start with a capital they should end with a period, and vice-versa. Extended comments should consist of full sentences. 

Thanks.

src/hotspot/share/classfile/javaClasses.cpp line 3078:

> 3076:   do {
> 3077:     // No backtrace available.
> 3078:     if (!iter.repeat()) return false;

Suggestion:

    if (!iter.repeat()) { 
       return false;
    }

src/hotspot/share/interpreter/bytecodeUtils.cpp line 346:

> 344: 
> 345:     if (found && is_parameter) {
> 346:       // Check MethodParameters for a name, if it carries a name

Suggestion:

      // check MethodParameters for a name, if it carries a name

src/hotspot/share/interpreter/bytecodeUtils.cpp line 354:

> 352:           char *var = cp->symbol_at(elem.name_cp_index)->as_C_string();
> 353:           os->print("%s", var);
> 354: 

No need for blank line

src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483:

> 1481:   // Is an explicit slot given?
> 1482:   bool explicit_search = slot >= 0;
> 1483:   if (explicit_search) {

Suggestion:

  if (slot >= 0) {

No need for the temporary local.

src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:

> 38:   // Slot can be nonnegative to indicate an explicit search for the source of null
> 39:   // If slot is negative (default), also search for the action that caused the NPE before
> 40:   // deriving the actual slot and source of null by code parsing

Suggestion:

  // Slot can be nonnegative to indicate an explicit search for the source of null.
  // If slot is negative (default), also search for the action that caused the NPE before
  // deriving the actual slot and source of null by code parsing.

Periods at the end of sentences in comments.

src/java.base/share/classes/java/lang/NullPointerException.java line 78:

> 76:     NullPointerException(int stackOffset, int searchSlot) {
> 77:         extendedMessageState = setupCustomBackTrace(stackOffset, searchSlot);
> 78:         this();

I thought `this()` had to come first in a constructor? Is this new in 25 or 26?

src/java.base/share/classes/java/lang/NullPointerException.java line 101:

> 99:             SEARCH_SLOT_MASK = SEARCH_SLOT_MAX << SEARCH_SLOT_SHIFT;
> 100: 
> 101:     // Access these fields in object monitor only

Suggestion:

    // Access these fields only while holding this object's monitor lock.

src/java.base/share/classes/java/lang/NullPointerException.java line 162:

> 160:     ///    and the search slot will be derived by bytecode tracing.  The message
> 161:     ///    will also include the action that caused the NPE besides the source of
> 162:     ///    the `null`.

Suggestion:

    ///    will also include the action that caused the NPE along with the source
    ///    of the `null`.

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

PR Review: https://git.openjdk.org/jdk/pull/26600#pullrequestreview-3087045581
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253509165
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253517408
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253519550
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253472224
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253481631
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253558481
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253541806
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253487877

From jsjolen at openjdk.org  Tue Aug  5 09:59:03 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 5 Aug 2025 09:59:03 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
Message-ID: <O1JJQxRIOgu1ja8EluwT-8ug6y-fP0kxUkRosHIycuw=.ac5d6ae7-3ca9-44fa-abf6-6b27f88699e5@github.com>

On Tue, 5 Aug 2025 08:32:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>
> src/java.base/share/classes/java/lang/NullPointerException.java line 78:
> 
>> 76:     NullPointerException(int stackOffset, int searchSlot) {
>> 77:         extendedMessageState = setupCustomBackTrace(stackOffset, searchSlot);
>> 78:         this();
> 
> I thought `this()` had to come first in a constructor? Is this new in 25 or 26?

https://openjdk.org/jeps/492

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253816429

From jsjolen at openjdk.org  Tue Aug  5 10:23:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 5 Aug 2025 10:23:07 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <DpevExdDMh5yWZXGeYw_IHBv9l0sxT-x3tn0DeAvh7M=.e41619ed-238a-4559-ad10-ae248b4e9ba9@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

Still reading this. A few comments, mostly intended to make this easier to grok for future readers. The actual logic seems fine from a first read.

src/java.base/share/classes/java/lang/NullPointerException.java line 159:

> 157:     ///    configurations to trace how a particular argument, which turns out to
> 158:     ///    be `null`, was evaluated.
> 159:     /// 2. `searchSlot < 0`, stack offset is 0 (a call to the nullary constructor)

Can `searchSlot == -1` here?

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

PR Review: https://git.openjdk.org/jdk/pull/26600#pullrequestreview-3087588630
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253882841

From jsjolen at openjdk.org  Tue Aug  5 10:23:08 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 5 Aug 2025 10:23:08 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
Message-ID: <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>

On Tue, 5 Aug 2025 07:55:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>
> src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483:
> 
>> 1481:   // Is an explicit slot given?
>> 1482:   bool explicit_search = slot >= 0;
>> 1483:   if (explicit_search) {
> 
> Suggestion:
> 
>   if (slot >= 0) {
> 
> No need for the temporary local.

If we don't adopt the enum I suggested, then I do prefer the naming of the condition through a variable. It gives you a hint of what the check is looking for, and not only what the check does.

> src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:
> 
>> 38:   // Slot can be nonnegative to indicate an explicit search for the source of null
>> 39:   // If slot is negative (default), also search for the action that caused the NPE before
>> 40:   // deriving the actual slot and source of null by code parsing
> 
> Suggestion:
> 
>   // Slot can be nonnegative to indicate an explicit search for the source of null.
>   // If slot is negative (default), also search for the action that caused the NPE before
>   // deriving the actual slot and source of null by code parsing.
> 
> Periods at the end of sentences in comments.

I'd like to see the description for `slot` pushed into an enum, and make any negative number except `-1` explicitly forbidden.

```c++
enum class NPESlot : int {
  // docs here
  None = -1,
  // docs here
  Explicit // Anything >= 0
};
bool get_NPE_message_at(outputStream* ss, Method* method, int bci, NPESlot slot) {
  if (slot != NPESlot::None) {
    // Explicit search
  }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253888922
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253865251

From galder at openjdk.org  Tue Aug  5 11:20:47 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 5 Aug 2025 11:20:47 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v2]
In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
Message-ID: <IsxmpUt5VNlS-1dUoY_b3z70tTe1-b8ZGY3D3WusaOg=.d0313d3b-d5c6-4e20-b9cf-eebf19ee772b@github.com>

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

Galder Zamarre?o has updated the pull request incrementally with three additional commits since the last revision:

 - Avoid VectorReinterpret::implemented
 - Refactor and add copyright header
 - Rephrase comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26457/files
  - new: https://git.openjdk.org/jdk/pull/26457/files/b6ec784e..dde8699b

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

  Stats: 307 lines in 8 files changed: 152 ins; 151 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26457/head:pull/26457

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

From pminborg at openjdk.org  Tue Aug  5 11:31:48 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Aug 2025 11:31:48 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v6]
In-Reply-To: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
Message-ID: <O9bCL7wLHTR3djQcZ3nVbo1abh4oBjbqFm5-9sY2jtk=.bcc93990-1400-460d-9377-65fd4435aed4@github.com>

> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Add a top-level section on string conversion
 - Merge branch 'master' into ms-getstrings-boundary-doc
 - Remove imp note
 - Add text on N octets
 - Improve wording
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update after comments
 - Add info for multi-octet Charsets

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25715/files
  - new: https://git.openjdk.org/jdk/pull/25715/files/5f5b1473..72ee9bb7

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

  Stats: 98262 lines in 2417 files changed: 56529 ins; 27369 del; 14364 mod
  Patch: https://git.openjdk.org/jdk/pull/25715.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25715/head:pull/25715

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

From pminborg at openjdk.org  Tue Aug  5 11:31:48 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Aug 2025 11:31:48 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v5]
In-Reply-To: <phBZll-SVauXppPx18CrOUu9JmwRsLDhOKdAeEVTUxA=.fa5a5068-a96e-4d61-89d8-fcd49bd5b6ba@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
 <phBZll-SVauXppPx18CrOUu9JmwRsLDhOKdAeEVTUxA=.fa5a5068-a96e-4d61-89d8-fcd49bd5b6ba@github.com>
Message-ID: <61yo76fOssulTtg9bmORWs1SIXwhQzpsQfeSRmcBTtU=.26c9531b-22f4-4d4a-9f4c-18ef8682d18d@github.com>

On Mon, 16 Jun 2025 16:58:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove imp note
>  - Add text on N octets

I've proposed a new top-level section:

<img width="1128" height="412" alt="image" src="https://github.com/user-attachments/assets/c498554b-fb67-4937-92b3-0cf18dfeed16" />

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

PR Comment: https://git.openjdk.org/jdk/pull/25715#issuecomment-3154819798

From galder at openjdk.org  Tue Aug  5 11:39:43 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 5 Aug 2025 11:39:43 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
Message-ID: <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:

  Check at the very least that auto vectorization is supported

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26457/files
  - new: https://git.openjdk.org/jdk/pull/26457/files/dde8699b..147633f9

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

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

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

From pminborg at openjdk.org  Tue Aug  5 11:50:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Aug 2025 11:50:35 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v10]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <b6a0VFalefPMuEY_AqkAuYFlE-Iv2PIc4_mcQYQQX00=.118b8fe0-225f-41fe-a0a6-36ce04b3af3a@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge branch 'master' into fill-overlap
 - Use Unsafe directly in benchmarks
 - Merge branch 'master' into fill-overlap
 - Use a fixed threashold for fill
 - Fix benchmark
 - Merge branch 'master' into fill-overlap
 - Merge branch 'master' into fill-overlap
 - Update test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update benchmark to reflect new fill method
 - Simplify
 - ... and 3 more: https://git.openjdk.org/jdk/compare/64ddaf04...8c63a303

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/c2583a50..8c63a303

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

  Stats: 98235 lines in 2417 files changed: 56512 ins; 27361 del; 14362 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

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

From rriggs at openjdk.org  Tue Aug  5 13:52:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 13:52:03 GMT
Subject: RFR: 8364540: Apply @Stable to Shared Secrets
In-Reply-To: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>
References: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>
Message-ID: <CXthYaM9OZBPjO7U_eRZbCw46Dihg8H7EBq9b-QhVYk=.c38e3747-5f01-4cc4-b936-dfd250b4a546@github.com>

On Mon, 4 Aug 2025 17:21:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to update the `SharedSecrets` class in `jdk.internal.access` to annotate all but one static field with the `@Stable` annotation.
> 
> The `@Stable` annotation was added to all static fields except for `javaAWTFontAccess`, which remains unannotated. This is because it can be set using several code paths.
> 
> No tests were changed or added, as this is an internal annotation adjustment with no expected behavioral impact.
> 
> This PR passes `tier1`, `tier2`, and `tier3` testing on multiple platforms.
> 
> In a future follow-up issue, we could identify fields in the implementations of the access classes that, in turn, are stable themselves. When this PR is integrated, it might be possible to remove local copies of access in classes to reduce bytecode size with little or no performance impact. Currently, we do not check the invariant, a field is set only once. This is yet another improvement proposal we could do -- maybe using Stable Values.

Looks good, thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26627#pullrequestreview-3088393663

From pminborg at openjdk.org  Tue Aug  5 14:04:26 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Aug 2025 14:04:26 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v11]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <54juS7Yn4dBxf74FPls56ytWrSdeQ_F1MAyBH0-G8Ak=.22b36bb3-6b07-46c0-8eeb-e8d858367293@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve performance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/8c63a303..13613237

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

  Stats: 64 lines in 4 files changed: 50 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

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

From pminborg at openjdk.org  Tue Aug  5 14:17:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Aug 2025 14:17:08 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v11]
In-Reply-To: <54juS7Yn4dBxf74FPls56ytWrSdeQ_F1MAyBH0-G8Ak=.22b36bb3-6b07-46c0-8eeb-e8d858367293@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <54juS7Yn4dBxf74FPls56ytWrSdeQ_F1MAyBH0-G8Ak=.22b36bb3-6b07-46c0-8eeb-e8d858367293@github.com>
Message-ID: <sOnAlzilVlmJhVrwQCwHWeL690K4DZG3eRgRiFMbAUI=.63a513a9-3f37-4fa5-b9a5-ad99af2319f6@github.com>

On Tue, 5 Aug 2025 14:04:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>> 
>> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
>> 
>> This PR passes tier1, tier2, and tier3 on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve performance

The new performance improvements gave some 8% better performance for smaller segments.

Before improvements


Benchmark                              (ELEM_SIZE)  Mode  Cnt  Score   Error  Units
SegmentBulkFill.nativeSegmentFillJava            2  avgt   30  1.322 ? 0.020  ns/op
SegmentBulkFill.nativeSegmentFillJava            3  avgt   30  1.313 ? 0.009  ns/op
SegmentBulkFill.nativeSegmentFillJava            4  avgt   30  1.323 ? 0.023  ns/op
SegmentBulkFill.nativeSegmentFillJava            5  avgt   30  1.309 ? 0.006  ns/op
SegmentBulkFill.nativeSegmentFillJava            6  avgt   30  1.310 ? 0.017  ns/op
SegmentBulkFill.nativeSegmentFillJava            7  avgt   30  1.308 ? 0.004  ns/op
SegmentBulkFill.nativeSegmentFillJava            8  avgt   30  1.312 ? 0.008  ns/op
SegmentBulkFill.nativeSegmentFillJava           12  avgt   30  1.316 ? 0.025  ns/op


After improvements


Benchmark                              (ELEM_SIZE)  Mode  Cnt  Score   Error  Units
SegmentBulkFill.nativeSegmentFillJava            2  avgt   30  1.230 ? 0.034  ns/op
SegmentBulkFill.nativeSegmentFillJava            3  avgt   30  1.228 ? 0.037  ns/op
SegmentBulkFill.nativeSegmentFillJava            4  avgt   30  1.243 ? 0.034  ns/op
SegmentBulkFill.nativeSegmentFillJava            5  avgt   30  1.230 ? 0.026  ns/op
SegmentBulkFill.nativeSegmentFillJava            6  avgt   30  1.224 ? 0.025  ns/op
SegmentBulkFill.nativeSegmentFillJava            7  avgt   30  1.232 ? 0.039  ns/op
SegmentBulkFill.nativeSegmentFillJava            8  avgt   30  1.208 ? 0.009  ns/op
SegmentBulkFill.nativeSegmentFillJava           12  avgt   30  1.242 ? 0.030  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-3155415358

From rriggs at openjdk.org  Tue Aug  5 14:22:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 14:22:05 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

src/hotspot/share/interpreter/bytecodeUtils.cpp line 1514:

> 1512:   return true;
> 1513: }
> 1514: 

Extra new line

src/java.base/share/classes/java/lang/NullPointerException.java line 75:

> 73: 
> 74:     /// Creates an NPE with a custom backtrace configuration.
> 75:     /// The exception has no message if detailed NPE is not enabled.

Don't mix markdown comments with regular javadoc comments, it just looks inconsistent without adding value.
Use regular // comments.

src/java.base/share/classes/java/lang/NullPointerException.java line 142:

> 140:     }
> 141: 
> 142:     // Methods below must be called in object monitor

This kind of warning should be on every method declaration, if separated from the method doc, it can be overlooked by future maintainers.

src/java.base/share/classes/java/lang/NullPointerException.java line 146:

> 144:     private void ensureMessageComputed() {
> 145:         if ((extendedMessageState & (MESSAGE_COMPUTED | CONSTRUCTOR_FINISHED)) == CONSTRUCTOR_FINISHED) {
> 146:             int stackOffset = (extendedMessageState & STACK_OFFSET_MASK) >> STACK_OFFSET_SHIFT;

This would be more readable if private utility methods were added that encapsulated the shift and masking, both for extraction and construction.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 637:

> 635:     /// Stack offset is the number of non-hidden frames to skip, pointing to the null-checking API.
> 636:     /// Search slot is the slot where the null-checked value is passed in.
> 637:     NullPointerException extendedNullPointerException(int stackOffset, int searchSlot);

Method should **not** be added to SharedSecrets solely for access by tests.
Tests can use @modules to gain access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2251763870
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254483182
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254486286
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254494309
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254508852

From liach at openjdk.org  Tue Aug  5 14:34:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:34:50 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <qFbIrj_vDeAq8NRzQsM2Z1emOVVveaLY9-irBY6AhTc=.842fd351-aba9-4ad8-a34f-65a622199d70@github.com>

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Web review
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26600/files
  - new: https://git.openjdk.org/jdk/pull/26600/files/5735b802..09233e9a

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

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

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

From liach at openjdk.org  Tue Aug  5 14:34:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:34:50 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
Message-ID: <Y80VX-2tPoUBRa-WvIwxrVoHo5nbC5FEgS430uF8fuk=.fefc80d4-9c95-4cc4-bd7f-4065317424a9@github.com>

On Tue, 5 Aug 2025 08:16:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Web review
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/interpreter/bytecodeUtils.cpp line 354:
> 
>> 352:           char *var = cp->symbol_at(elem.name_cp_index)->as_C_string();
>> 353:           os->print("%s", var);
>> 354: 
> 
> No need for blank line

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254528382

From liach at openjdk.org  Tue Aug  5 14:34:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:34:51 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
Message-ID: <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>

On Mon, 4 Aug 2025 14:58:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Web review
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/interpreter/bytecodeUtils.cpp line 1514:
> 
>> 1512:   return true;
>> 1513: }
>> 1514: 
> 
> Extra new line

Suggestion:

> src/java.base/share/classes/java/lang/NullPointerException.java line 75:
> 
>> 73: 
>> 74:     /// Creates an NPE with a custom backtrace configuration.
>> 75:     /// The exception has no message if detailed NPE is not enabled.
> 
> Don't mix markdown comments with regular javadoc comments, it just looks inconsistent without adding value.
> Use regular // comments.

Suggestion:

    // Creates an NPE with a custom backtrace configuration.
    // The exception has no message if detailed NPE is not enabled.

> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 637:
> 
>> 635:     /// Stack offset is the number of non-hidden frames to skip, pointing to the null-checking API.
>> 636:     /// Search slot is the slot where the null-checked value is passed in.
>> 637:     NullPointerException extendedNullPointerException(int stackOffset, int searchSlot);
> 
> Method should **not** be added to SharedSecrets solely for access by tests.
> Tests can use @modules to gain access.

This is intended to be an API directly called by future null-check APIs, like `Objects.requireNonNull` or `Checks.nullCheck`. I initially had code for rNN but decided to withhold that for a future patch since it involves CSR and other evaluations not related to this patch's efforts.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254529734
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254532646
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254537044

From liach at openjdk.org  Tue Aug  5 14:34:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:34:51 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
Message-ID: <tkRkYwC8-2p6lYMpypceROvLtksWkX_DeKUQmtXszcA=.c90ff7e1-9003-4938-9a47-0871d98b34f6@github.com>

On Tue, 5 Aug 2025 10:07:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:
>> 
>>> 38:   // Slot can be nonnegative to indicate an explicit search for the source of null
>>> 39:   // If slot is negative (default), also search for the action that caused the NPE before
>>> 40:   // deriving the actual slot and source of null by code parsing
>> 
>> Suggestion:
>> 
>>   // Slot can be nonnegative to indicate an explicit search for the source of null.
>>   // If slot is negative (default), also search for the action that caused the NPE before
>>   // deriving the actual slot and source of null by code parsing.
>> 
>> Periods at the end of sentences in comments.
>
> I'd like to see the description for `slot` pushed into an enum, and make any negative number except `-1` explicitly forbidden.
> 
> ```c++
> enum class NPESlot : int {
>   // docs here
>   None = -1,
>   // docs here
>   Explicit // Anything >= 0
> };
> bool get_NPE_message_at(outputStream* ss, Method* method, int bci, NPESlot slot) {
>   if (slot != NPESlot::None) {
>     // Explicit search
>   }
> }

I don't think I know how to use C++ enums. I tried to define this enum in bytecodeUtils.hpp and use it from jvm.cpp, and don't know how in any way I can ever express `BytecodeUtils::NullSlot slot = search_slot >= 0 ? search_slot : ???;` because `NullSlot::Search` or `BytecodeUtils::NullSlot::Search` or `BytecodeUtils::NullSlot.Search` are all erroneous. I don't think this may worth the hassle since the attempt to use C++ enum only creates more pain, unless you tell me how to use it properly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254525459

From pminborg at openjdk.org  Tue Aug  5 14:49:32 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Aug 2025 14:49:32 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v12]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <1OGCX1NdNZgPTnFQmB4uWAW_HDBz2AMR1VSzCnSJQtM=.32a21c8c-ccfd-4121-9389-5c15a4d276fe@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert the settable fill threshold

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/13613237..74bf8c56

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

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

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

From rriggs at openjdk.org  Tue Aug  5 14:56:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 14:56:03 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
 <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>
Message-ID: <pEd2HoPSaXF2YFTsfN9OdGy5AbFo2pVPblVzqDCDeL0=.df678328-6541-4ffc-b1f2-becedb965351@github.com>

On Tue, 5 Aug 2025 14:28:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 637:
>> 
>>> 635:     /// Stack offset is the number of non-hidden frames to skip, pointing to the null-checking API.
>>> 636:     /// Search slot is the slot where the null-checked value is passed in.
>>> 637:     NullPointerException extendedNullPointerException(int stackOffset, int searchSlot);
>> 
>> Method should **not** be added to SharedSecrets solely for access by tests.
>> Tests can use @modules to gain access.
>
> This is intended to be an API directly called by future null-check APIs, like `Objects.requireNonNull` or `Checks.nullCheck`. I initially had code for rNN but decided to withhold that for a future patch since it involves CSR and other evaluations not related to this patch's efforts.

Don't add APIs without uses; it speculative and the API may not be what is really needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254604180

From liach at openjdk.org  Tue Aug  5 15:07:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 15:07:13 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v3]
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <e-H-6DU67U-jnIXODbrZFIwc1lhfBWKnGMMDQZp3icg=.7a952975-977c-4e5c-8dbe-cf5426733f23@github.com>

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

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 14 additional commits since the last revision:

 - Use c++ enum classes per jdksjolen
 - Merge branch 'exp/requireNonNull-message-hacks' of github.com:liachmodded/jdk into exp/requireNonNull-message-hacks
 - Web review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Years
 - Roll back Objects.rNN for now
 - Review remarks
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Bork
 - Try generify the NPE tracing API
 - ... and 4 more: https://git.openjdk.org/jdk/compare/dc4f5978...9af7ee85

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26600/files
  - new: https://git.openjdk.org/jdk/pull/26600/files/09233e9a..9af7ee85

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

  Stats: 5643 lines in 151 files changed: 3341 ins; 1944 del; 358 mod
  Patch: https://git.openjdk.org/jdk/pull/26600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600

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

From liach at openjdk.org  Tue Aug  5 15:07:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 15:07:14 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v3]
In-Reply-To: <tkRkYwC8-2p6lYMpypceROvLtksWkX_DeKUQmtXszcA=.c90ff7e1-9003-4938-9a47-0871d98b34f6@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
 <tkRkYwC8-2p6lYMpypceROvLtksWkX_DeKUQmtXszcA=.c90ff7e1-9003-4938-9a47-0871d98b34f6@github.com>
Message-ID: <PNvKV4rwpdi4t9ia_UuybItWpKIO45Z6ZqGIMj9CKus=.0923e38f-929b-420d-8a6c-828094bac39b@github.com>

On Tue, 5 Aug 2025 14:24:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I'd like to see the description for `slot` pushed into an enum, and make any negative number except `-1` explicitly forbidden.
>> 
>> ```c++
>> enum class NPESlot : int {
>>   // docs here
>>   None = -1,
>>   // docs here
>>   Explicit // Anything >= 0
>> };
>> bool get_NPE_message_at(outputStream* ss, Method* method, int bci, NPESlot slot) {
>>   if (slot != NPESlot::None) {
>>     // Explicit search
>>   }
>> }
>
> I don't think I know how to use C++ enums. I tried to define this enum in bytecodeUtils.hpp and use it from jvm.cpp, and don't know how in any way I can ever express `BytecodeUtils::NullSlot slot = search_slot >= 0 ? search_slot : ???;` because `NullSlot::Search` or `BytecodeUtils::NullSlot::Search` or `BytecodeUtils::NullSlot.Search` are all erroneous. I don't think this may worth the hassle since the attempt to use C++ enum only creates more pain, unless you tell me how to use it properly.

I think I figured out how to use static_cast with C++ enum classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254630773

From liach at openjdk.org  Tue Aug  5 15:07:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 15:07:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v3]
In-Reply-To: <pEd2HoPSaXF2YFTsfN9OdGy5AbFo2pVPblVzqDCDeL0=.df678328-6541-4ffc-b1f2-becedb965351@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
 <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>
 <pEd2HoPSaXF2YFTsfN9OdGy5AbFo2pVPblVzqDCDeL0=.df678328-6541-4ffc-b1f2-becedb965351@github.com>
Message-ID: <pOYre3BM8bk2MGRLph2dEW0u8XSC1BVM3_PaMBywEZY=.d893ba55-1f8c-4f50-9123-96200cb33367@github.com>

On Tue, 5 Aug 2025 14:53:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This is intended to be an API directly called by future null-check APIs, like `Objects.requireNonNull` or `Checks.nullCheck`. I initially had code for rNN but decided to withhold that for a future patch since it involves CSR and other evaluations not related to this patch's efforts.
>
> Don't add APIs without uses; it speculative and the API may not be what is really needed.

Should I open a dependent PR to prove that this is exactly what we need to unblock [Objects::requireNonNull message enhancements](https://bugs.openjdk.org/browse/JDK-8233268)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254627867

From rriggs at openjdk.org  Tue Aug  5 15:17:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 15:17:12 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <bsYDcgavbXfmf2WP_iXtlEJGKPZppbq1yBGektW4cI0=.4e19234e-cd9a-40d7-add6-e6cbcf8ea01c@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
 <bsYDcgavbXfmf2WP_iXtlEJGKPZppbq1yBGektW4cI0=.4e19234e-cd9a-40d7-add6-e6cbcf8ea01c@github.com>
Message-ID: <XxpmQudu9kApTVI9haudSB_WKmuAnZiyad5EMZqYjJ8=.af2ddc70-c0f2-461e-8064-bf0f29574bcb@github.com>

On Mon, 4 Aug 2025 15:00:52 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore c2 optimization.
>
> src/hotspot/share/prims/jvm.cpp line 1744:
> 
>> 1742: JVM_END
>> 1743: 
>> 1744: JVM_ENTRY(jint, JVM_GetClassAccessFlags(JNIEnv *env, jclass cls))
> 
> What about the declaration in `jvm.h`? https://github.com/openjdk/jdk/blob/6c52b73465b0d0daeafc54c3c6cec3062bf490c5/src/hotspot/share/include/jvm.h#L610

Created issue https://bugs.openjdk.org/browse/JDK-8364750

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2254660805

From jaikiran.pai at oracle.com  Tue Aug  5 15:32:41 2025
From: jaikiran.pai at oracle.com (jaikiran.pai at oracle.com)
Date: Tue, 5 Aug 2025 21:02:41 +0530
Subject: Reduce size of j.t.f.DateTimePrintContext::adjust
In-Reply-To: <62d992ec-5a3c-4436-be49-a692379402c4.shaojin.wensj@alibaba-inc.com>
References: <62d992ec-5a3c-4436-be49-a692379402c4.shaojin.wensj@alibaba-inc.com>
Message-ID: <875b2431-182b-4918-b9db-fa7491c61f6b@oracle.com>

Hello Shaojin,

Looking at the proposed change, the proposal here appears to be to 
replace an inline "new DateTimeException(...)" call with a call to a new 
private method which returns a "new DateTimeException(...)", to please 
the hotspot compiler's inlining decision.

I think this isn't a useful change. Enabling the -XX:+PrintInlining will 
naturally print the runtime compiler's inlining decisions and there 
could be some/many logs which complain that the method couldn't be 
inlined. Changing the java code (like here) to closely handhold it to 
match the (unspecified) expectations of a particular (current) 
implementation of the runtime compiler shouldn't be the way to code in 
java language. Such changes, like the one here, won't help with the 
maintainability or the readability of the code.

-Jaikiran

On 05/08/25 6:55 am, wenshao wrote:
> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions 
> -XX:+PrintInlining` and analyzing the printed log information, and 
> found that the code size of the j.t.f.DateTimePrintContext::adjust 
> method is 382, which is greater than 325, causing inlining failure.
>
> Below is the log message:
> ```
> @ 7 java.time.format.DateTimePrintContext::adjust (382 bytes) ? failed 
> to inline: hot method too big
> ```
>
> We can extract the exception-generating code into two smaller methods, 
> reducing the code size from 382 to 322, allowing C2 to inline the 
> DateTimePrintContext::adjust method.
>
> The refactored code looks like this:
> ```java
> ? ? private static TemporalAccessor adjust(final TemporalAccessor 
> temporal, DateTimeFormatter formatter) {
> ? ? ? ? // ...
> ? ? ? ? if (overrideZone.normalized() instanceof ZoneOffset && 
> temporal.isSupported(OFFSET_SECONDS) &&
> temporal.get(OFFSET_SECONDS) != 
> overrideZone.getRules().getOffset(Instant.EPOCH).getTotalSeconds()) {
> ? ? ? ? ? ? throw unableApplyOverrideZone(temporal, overrideZone);
> ? ? ? ? }
> ? ? ? ? // ....
> ? ? ? ? if (f.isDateBased() && temporal.isSupported(f)) {
> ? ? ? ? ? ? throw unableApplyOverrideChronology(temporal, overrideChrono);
> ? ? ? ? // ...
> ? ? }
> ? ? private static DateTimeException 
> unableApplyOverrideChronology(TemporalAccessor temporal, Chronology 
> overrideChrono) {
> ? ? ? ? return new DateTimeException("Unable to apply override 
> chronology '" + overrideChrono +
> ? ? ? ? ? ? ? ? "' because the temporal object being formatted 
> contains date fields but" +
> ? ? ? ? ? ? ? ? " does not represent a whole date: " + temporal);
> ? ? }
> ? ? private static DateTimeException 
> unableApplyOverrideZone(TemporalAccessor temporal, ZoneId overrideZone) {
> ? ? ? ? return new DateTimeException("Unable to apply override zone '" 
> + overrideZone +
> ? ? ? ? ? ? ? ? "' because the temporal object being formatted has a 
> different offset but" +
> ? ? ? ? ? ? ? ? " does not represent an instant: " + temporal);
> ? ? }
> ```
>
> I submitted a draft Pull Request 
> https://github.com/openjdk/jdk/pull/26633?, Hope to get your feedback.
>
> -
> Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250805/8745e25e/attachment-0001.htm>

From cstein at openjdk.org  Tue Aug  5 16:03:07 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 5 Aug 2025 16:03:07 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <1XRUup7RXkUWm_2yscYV2M-m4ooHr70QdwcVVB7zxDI=.d641c6f9-9dd9-4da7-8599-a164274b9d93@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

Both tests seem to make hard assumptions on where binary files of `@library` classes are stored.

- [TestSPISigned.java#L60-L62](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java#L60-L62)
- [resexhausted003.java#L83-L96](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003.java#L83-L96)

The storage location changed due to https://bugs.openjdk.org/browse/CODETOOLS-7902847 - it might change again in the near future. Thus, both tests need to be updated to work correctly without relying on a specific location of compiled library classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3155714592

From pminborg at openjdk.org  Tue Aug  5 16:03:28 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Aug 2025 16:03:28 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v13]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <p00PzCZr2xBy_HtNGzkf9BxAFk0waLs8Yg_6bsujZpg=.f9de5567-9c4d-4d22-916a-d34d3d0588a5@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert the default value for the fill threshold

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/74bf8c56..8f7fb6dd

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

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

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

From liach at openjdk.org  Tue Aug  5 16:04:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 16:04:08 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update NPE per roger review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26600/files
  - new: https://git.openjdk.org/jdk/pull/26600/files/9af7ee85..4ba1f17c

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

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

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

From bpb at openjdk.org  Tue Aug  5 16:07:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Aug 2025 16:07:02 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed
In-Reply-To: <WdbGr9mbqjL04ZvuEl3UgE_Y68UHPdQ1hslNdGK_pJk=.33f6976a-c9d6-4f3f-a457-bcdc507336f3@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <WdbGr9mbqjL04ZvuEl3UgE_Y68UHPdQ1hslNdGK_pJk=.33f6976a-c9d6-4f3f-a457-bcdc507336f3@github.com>
Message-ID: <MavDpHT0UcQ7tNtmgsDH0WYTyLI_DssETTAiKrBvtxk=.8a0d56e0-5ade-4c24-8966-3ea1d621cb75@github.com>

On Tue, 5 Aug 2025 06:53:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to enumerate how some of the APIs behave before+after this change?

I will investigate this. Meanwhile I should note that all `jdk_nio` pass in the CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/26631#issuecomment-3155743847

From jlu at openjdk.org  Tue Aug  5 17:15:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Aug 2025 17:15:07 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
Message-ID: <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>

On Mon, 4 Aug 2025 23:57:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refrects review comments

Latest changes look good to me. I think ignoring supplementary/normalization is fine and it would have been excessive otherwise. I left some more minor comments.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 219:

> 217:  * </pre></blockquote>
> 218:  *
> 219:  * @implNote The implementation follows the LDML specification to enable loose

Suggestion:

 * @implNote The JDK Reference Implementation follows the LDML specification to enable loose

src/java.base/share/classes/java/text/DecimalFormat.java line 421:

> 419:  * returns a numerically greater value.
> 420:  *
> 421:  * @implNote The implementation follows the LDML specification to enable loose

Suggestion:

 * @implNote The JDK Reference Implementation follows the LDML specification to enable loose

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 719:

> 717: 
> 718:     /**
> 719:      * {@return the lenient minus signs} Multiple lenient minus signs

Do we have an idea of when a given locale would not have access to the lenient minus signs provided by parseLenient element? If the vast majority of times it will, then it is fine. Otherwise IMO, `getLenientMinusSigns()` should probably call out the fact that it may not always be a concatenation of multiple minus _signs_, and it may be a single minus _sign_ (as assigned by `minusSignText`). Since that detail is only apparent by digging around the code that assigns `lenientMinusSigns`.

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 720:

> 718:     /**
> 719:      * {@return the lenient minus signs} Multiple lenient minus signs
> 720:      * are concatenated to form the returned string.

The surrounding package private methods use since tags.

Suggestion:

     * are concatenated to form the returned string.
     * @since 26

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 852:

> 850: 
> 851:         // Lenient minus signs
> 852:         lenientMinusSigns = numberElements.length < 14 ? minusSignText : numberElements[13];

BTW, if I remove this check and always assign to `numberElements[13]`, I do not observe any failures in the java_text/Format suite. It would be nice to have an idea of why this check is needed. (I understand it is following the same length checks of monetarySeparator and monetaryGroupingSeparator.)

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

PR Review: https://git.openjdk.org/jdk/pull/26580#pullrequestreview-3086137609
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252827372
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254807654
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254847469
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254792967
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254846860

From rriggs at openjdk.org  Tue Aug  5 17:42:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 17:42:50 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
Message-ID: <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>

On Tue, 5 Aug 2025 00:12:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refrects review comments
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 219:
> 
>> 217:  * </pre></blockquote>
>> 218:  *
>> 219:  * @implNote The implementation follows the LDML specification to enable loose
> 
> Suggestion:
> 
>  * @implNote The JDK Reference Implementation follows the LDML specification to enable loose

However,  "The JDK Reference Implementation" is a very specific and separate deliverable of the JCP.
That's why I suggest just stating that lenient is enabled without trying to attach it to an artifact.
As at line 421.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254949045

From bpb at openjdk.org  Tue Aug  5 17:48:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Aug 2025 17:48:59 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
Message-ID: <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>

> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.

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

  8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26631/files
  - new: https://git.openjdk.org/jdk/pull/26631/files/c5794766..cf9eab46

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

  Stats: 12 lines in 3 files changed: 8 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26631.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26631/head:pull/26631

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

From rriggs at openjdk.org  Tue Aug  5 17:55:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 17:55:05 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
Message-ID: <0AgAaLT3JhkEFbK5q7INzdxBjPPlJUaTVBz9REtNzz4=.b0dced9c-49b1-42c3-af57-b4d58645383a@github.com>

On Mon, 4 Aug 2025 23:57:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refrects review comments

src/java.base/share/classes/java/text/DecimalFormat.java line 3518:

> 3516:      * @implNote The implementation does not account for lenient minuses
> 3517:      * in non-BMP ranges or normalizations, as these could change the affix
> 3518:      * length.

@implNote isn't really appropriate here since this is a non-javadoc method.
And I don't understand what "does not account" mean in this context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254956628

From rriggs at openjdk.org  Tue Aug  5 17:55:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 17:55:06 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
Message-ID: <IcLAo7eeyILz7PVdfKlMnGKWR7b-skbDyvFgRe5XRkU=.bae8b1f4-d0dd-4ae8-aa32-bac05a1beafd@github.com>

On Tue, 5 Aug 2025 16:28:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refrects review comments
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 720:
> 
>> 718:     /**
>> 719:      * {@return the lenient minus signs} Multiple lenient minus signs
>> 720:      * are concatenated to form the returned string.
> 
> The surrounding package private methods use since tags.
> 
> Suggestion:
> 
>      * are concatenated to form the returned string.
>      * @since 26

It might be clearer to say that each character of the string is a valid minus sign character.
If you want to preserve the option for full support for surrogates it could say codepoints instead of character.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254967444

From duke at openjdk.org  Tue Aug  5 18:20:04 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 5 Aug 2025 18:20:04 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
Message-ID: <BZNhxM3PUJfSxi-dtLF9C3_GttLTZsXz65bttyyUHyE=.99598566-a83d-43af-9230-ccc4456b2769@github.com>

On Tue, 5 Aug 2025 17:48:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test

test/lib/jdk/test/lib/util/FileUtils.java line 457:

> 455:         // Create a directory junction or a symbolic link
> 456:         if (IS_WINDOWS) {
> 457:             if (!nativeLibLoaded) {

Suggestion: Since this logic to load the FileUtils library is now used twice, why not move it into a helper method which might also be synchronized (if tests are executed in parallel).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255022423

From bpb at openjdk.org  Tue Aug  5 18:24:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Aug 2025 18:24:07 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <BZNhxM3PUJfSxi-dtLF9C3_GttLTZsXz65bttyyUHyE=.99598566-a83d-43af-9230-ccc4456b2769@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
 <BZNhxM3PUJfSxi-dtLF9C3_GttLTZsXz65bttyyUHyE=.99598566-a83d-43af-9230-ccc4456b2769@github.com>
Message-ID: <pwgbpcuVbkmVtA5k_ilr8ReRgw5tGlqWlImw2rbcCys=.75693e2b-dfe1-4185-b2ce-3e3ae769f373@github.com>

On Tue, 5 Aug 2025 18:17:32 GMT, Johannes D?bler <duke at openjdk.org> wrote:

> Since this logic to load the FileUtils library is now used twice, why not move it into a helper method

Sounds like a good idea. I'll investigate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255029517

From jlu at openjdk.org  Tue Aug  5 18:26:06 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Aug 2025 18:26:06 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <IcLAo7eeyILz7PVdfKlMnGKWR7b-skbDyvFgRe5XRkU=.bae8b1f4-d0dd-4ae8-aa32-bac05a1beafd@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <IcLAo7eeyILz7PVdfKlMnGKWR7b-skbDyvFgRe5XRkU=.bae8b1f4-d0dd-4ae8-aa32-bac05a1beafd@github.com>
Message-ID: <nCCgWWShuRVNzrf0KoUo34L7NiWDZj2yp2izVXGHDUQ=.7ccc8ff9-8d37-4747-adf3-e7d7dd61af45@github.com>

On Tue, 5 Aug 2025 17:49:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 720:
>> 
>>> 718:     /**
>>> 719:      * {@return the lenient minus signs} Multiple lenient minus signs
>>> 720:      * are concatenated to form the returned string.
>> 
>> The surrounding package private methods use since tags.
>> 
>> Suggestion:
>> 
>>      * are concatenated to form the returned string.
>>      * @since 26
>
> It might be clearer to say that each character of the string is a valid minus sign character.
> If you want to preserve the option for full support for surrogates it could say codepoints instead of character.

I agree. I think that is a good wording update which naturally covers both the single and multiple minus signs case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255034183

From rriggs at openjdk.org  Tue Aug  5 18:28:22 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 18:28:22 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close and
 be AutoCloseable
Message-ID: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@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.

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

Commit messages:
 - 8364361: [process] java.lang.Process should implement close and be AutoCloseable

Changes: https://git.openjdk.org/jdk/pull/26649/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364361
  Stats: 608 lines in 3 files changed: 604 ins; 0 del; 4 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 duke at openjdk.org  Tue Aug  5 18:33:05 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 5 Aug 2025 18:33:05 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
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: <r9iqLWmP3TjdgO-gvCohL6AGIICQV8DcXuzWgeEYvOg=.d89f35d4-de67-4e29-a832-274af8107369@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.

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

> 661:             // TBD: Log exceptions closing streams
> 662:             IOException ex = new IOException("exception closing process streams");
> 663:             exceptions.forEach((e) -> ex.addSuppressed(e));

Suggestion:

            exceptions.forEach(ex::addSuppressed);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255041896

From jlu at openjdk.org  Tue Aug  5 18:39:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Aug 2025 18:39:08 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>
Message-ID: <RywjGlwSqZ46Mh6g-c4i1RbCwD0McZBiQCTzq4jREp4=.4b92904e-c745-4a4f-85b2-fde0ceab2538@github.com>

On Tue, 5 Aug 2025 17:39:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/CompactNumberFormat.java line 219:
>> 
>>> 217:  * </pre></blockquote>
>>> 218:  *
>>> 219:  * @implNote The implementation follows the LDML specification to enable loose
>> 
>> Suggestion:
>> 
>>  * @implNote The JDK Reference Implementation follows the LDML specification to enable loose
>
> However,  "The JDK Reference Implementation" is a very specific and separate deliverable of the JCP.
> That's why I suggest just stating that lenient is enabled without trying to attach it to an artifact.
> As at line 421.

The way I interpreted this was that Naoto was not trying to imply that the default behavior of the class enabled loose matching of lenient minus parsing signs. Rather, he was describing that the JDK reference implementation of DecimalFormat and CompactNumberFormat support the ability for loose matching of minus sign patterns (and other JDKs need not implement this particular LMDL behavior).

If I interpreted that wrong and his intentions were the former, then I agree it is best to just mention leniency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255058461

From duke at openjdk.org  Tue Aug  5 18:40:08 2025
From: duke at openjdk.org (Rob Spoor)
Date: Tue, 5 Aug 2025 18:40:08 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
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: <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@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.

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

> 671:             }
> 672:         } catch (InterruptedException ie) {
> 673:             // Wait was interrupted; terminate the process

Shouldn't the thread's interrupted flag be restored?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255060792

From duke at openjdk.org  Tue Aug  5 18:45:05 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 5 Aug 2025 18:45:05 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
Message-ID: <Au-D6qYBegw3kIQtMd0YzE58pu9kLTkKEZvCwsm8kf8=.2622c9bd-094e-4ef3-8b5c-72a5c55b8b95@github.com>

On Tue, 5 Aug 2025 17:48:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test

test/lib/jdk/test/lib/util/FileUtils.java line 449:

> 447: 
> 448:     // Create a link from "junction" to the real path of "target"
> 449:     public static boolean createDirectoryJunction(String junction, String target)

Suggestion: Use Path as type for parameters `junction` and `target` to avoid Path|File->String->Path|File conversions (e.g. the only caller Basic.java already has a Path object for parameter junction, why convert to a String just to recreate a File inside `createDirectoryJunction`).

test/lib/jdk/test/lib/util/FileUtils.java line 463:

> 461:             return createWinDirectoryJunction(junction, target);
> 462:         } else {
> 463:             Files.createSymbolicLink(Path.of(junction), Path.of(target));

Suggestion: Junctions are Windows-only, so why not throw a RuntimeException for the non-windows case (and maybe also rename the method to something like `createWindowsDirectoryJunction`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255068530
PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255040929

From dfuchs at openjdk.org  Tue Aug  5 19:17:35 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 5 Aug 2025 19:17:35 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v12]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <SCsRMYq_YcUXak0vqS9nds-o8JCzef-RS8XmXCWqxkk=.422e19d8-d034-4bd4-a925-63f242f7734c@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 588 commits:

 - merge latest changes from master branch
 - qpack: modify Encoder.header to use DT lock, test headers cleanup.
 - merge latest from master branch
 - merge latest from master branch
 - Include peer's error information in exceptions thrown on connection close
 - Fix error IDs
 - Remove assertion error
 - Remove assertion errors from packet encryption
 - Remove assertion errors from retry packet handling
 - Remove assertion errors from initial key derivation
 - ... and 578 more: https://git.openjdk.org/jdk/compare/d906e450...83f8dad1

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=11
  Stats: 105164 lines in 470 files changed: 102303 ins; 1335 del; 1526 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From coleenp at openjdk.org  Tue Aug  5 19:30:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 5 Aug 2025 19:30:12 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <XxpmQudu9kApTVI9haudSB_WKmuAnZiyad5EMZqYjJ8=.af2ddc70-c0f2-461e-8064-bf0f29574bcb@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
 <bsYDcgavbXfmf2WP_iXtlEJGKPZppbq1yBGektW4cI0=.4e19234e-cd9a-40d7-add6-e6cbcf8ea01c@github.com>
 <XxpmQudu9kApTVI9haudSB_WKmuAnZiyad5EMZqYjJ8=.af2ddc70-c0f2-461e-8064-bf0f29574bcb@github.com>
Message-ID: <w6q2m3_BNHYfKHF63DJNf_A2TiizbTQDGCbdN_JX8k4=.c0ce5dc8-b4ae-4c76-a390-4d2f6f72b906@github.com>

On Tue, 5 Aug 2025 15:14:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1744:
>> 
>>> 1742: JVM_END
>>> 1743: 
>>> 1744: JVM_ENTRY(jint, JVM_GetClassAccessFlags(JNIEnv *env, jclass cls))
>> 
>> What about the declaration in `jvm.h`? https://github.com/openjdk/jdk/blob/6c52b73465b0d0daeafc54c3c6cec3062bf490c5/src/hotspot/share/include/jvm.h#L610
>
> Created issue https://bugs.openjdk.org/browse/JDK-8364750

Sorry I missed the declaration. Will fix it. Thanks for filing the bug Roger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2255153426

From bpb at openjdk.org  Tue Aug  5 19:31:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Aug 2025 19:31:04 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <Au-D6qYBegw3kIQtMd0YzE58pu9kLTkKEZvCwsm8kf8=.2622c9bd-094e-4ef3-8b5c-72a5c55b8b95@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
 <Au-D6qYBegw3kIQtMd0YzE58pu9kLTkKEZvCwsm8kf8=.2622c9bd-094e-4ef3-8b5c-72a5c55b8b95@github.com>
Message-ID: <h3fAGwAPBxd6hmyKu7DA1LfqQrfbfLAXoUcQ8bE_wYI=.eeb1d3b8-ce7b-4382-b7ac-6da4b36f4bbf@github.com>

On Tue, 5 Aug 2025 18:27:13 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test
>
> test/lib/jdk/test/lib/util/FileUtils.java line 463:
> 
>> 461:             return createWinDirectoryJunction(junction, target);
>> 462:         } else {
>> 463:             Files.createSymbolicLink(Path.of(junction), Path.of(target));
> 
> Suggestion: Junctions are Windows-only, so why not throw a RuntimeException for the non-windows case (and maybe also rename the method to something like `createWindowsDirectoryJunction`)

A `RuntimeException` for non-Windows, i.e., Unix, would be a test failure and we can't have that. I think it would be better to convert the test to JUnit 5 and use [@EnabledOnOs(OS.WINDOWS)](https://docs.junit.org/5.2.0/api/org/junit/jupiter/api/condition/EnabledOnOs.html), but that might not be in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255155387

From duke at openjdk.org  Tue Aug  5 19:31:05 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 5 Aug 2025 19:31:05 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
Message-ID: <RKfAa4LBqcf24RdbU62lU2DsY-WIR4bdX2jcP-pBfwI=.b5b5ab16-d660-4c37-bda9-b45aa01fa8ac@github.com>

On Tue, 5 Aug 2025 17:48:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test

test/lib/jdk/test/lib/util/libFileUtils.c line 167:

> 165:     lpInBuffer = NULL;
> 166: 
> 167:     if (result == 0) {

Suggestion: Would it be possible to avoid the dreaded goto

if ((result != 0) && (CloseHandle(hJunction) != 0)) {
    return JNI_TRUE;
}
...do error handling...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255151112

From rriggs at openjdk.org  Tue Aug  5 19:44:09 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 19:44:09 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <RywjGlwSqZ46Mh6g-c4i1RbCwD0McZBiQCTzq4jREp4=.4b92904e-c745-4a4f-85b2-fde0ceab2538@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>
 <RywjGlwSqZ46Mh6g-c4i1RbCwD0McZBiQCTzq4jREp4=.4b92904e-c745-4a4f-85b2-fde0ceab2538@github.com>
Message-ID: <owQ-_K_KjtaFQr7GFYri3wWxKEFIDI_eeTg1rwDg7vU=.ceb602b2-fefa-4651-83f6-16ec861a75e9@github.com>

On Tue, 5 Aug 2025 18:36:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> However,  "The JDK Reference Implementation" is a very specific and separate deliverable of the JCP.
>> That's why I suggest just stating that lenient is enabled without trying to attach it to an artifact.
>> As at line 421.
>
> The way I interpreted this was that Naoto was not trying to imply that the default behavior of the class enabled loose matching of lenient minus parsing signs. Rather, he was describing that the JDK reference implementation of DecimalFormat and CompactNumberFormat support the ability for loose matching of minus sign patterns (and other JDKs need not implement this particular LMDL behavior).
> 
> If I interpreted that wrong and his intentions were the former, then I agree it is best to just mention leniency.

The spec for enabling lenient matching in parsing of minus signs belongs with the other comments about leniency in the `parse()` method. Its behavior depends on the settings in the isStrict and setStrict methods.
It looks a bit out of context in the class javadoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255182114

From duke at openjdk.org  Tue Aug  5 19:44:09 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 5 Aug 2025 19:44:09 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <h3fAGwAPBxd6hmyKu7DA1LfqQrfbfLAXoUcQ8bE_wYI=.eeb1d3b8-ce7b-4382-b7ac-6da4b36f4bbf@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
 <Au-D6qYBegw3kIQtMd0YzE58pu9kLTkKEZvCwsm8kf8=.2622c9bd-094e-4ef3-8b5c-72a5c55b8b95@github.com>
 <h3fAGwAPBxd6hmyKu7DA1LfqQrfbfLAXoUcQ8bE_wYI=.eeb1d3b8-ce7b-4382-b7ac-6da4b36f4bbf@github.com>
Message-ID: <Cux26Wbx8g2l0Zdom0le95zg9AvWehhdXMXfB86THmo=.f56daf46-18f3-4268-9691-4607625170d9@github.com>

On Tue, 5 Aug 2025 19:28:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/FileUtils.java line 463:
>> 
>>> 461:             return createWinDirectoryJunction(junction, target);
>>> 462:         } else {
>>> 463:             Files.createSymbolicLink(Path.of(junction), Path.of(target));
>> 
>> Suggestion: Junctions are Windows-only, so why not throw a RuntimeException for the non-windows case (and maybe also rename the method to something like `createWindowsDirectoryJunction`)
>
> A `RuntimeException` for non-Windows, i.e., Unix, would be a test failure and we can't have that. I think it would be better to convert the test to JUnit 5 and use [@EnabledOnOs(OS.WINDOWS)](https://docs.junit.org/5.2.0/api/org/junit/jupiter/api/condition/EnabledOnOs.html), but that might not be in this PR.

Right, but this method is just a helper method not a test method and the caller, e.g. Basic.attributeReadWriteTests|checkAttributesOfJunction should only call it if on Windows.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255177168

From bpb at openjdk.org  Tue Aug  5 19:44:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Aug 2025 19:44:10 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <Cux26Wbx8g2l0Zdom0le95zg9AvWehhdXMXfB86THmo=.f56daf46-18f3-4268-9691-4607625170d9@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
 <Au-D6qYBegw3kIQtMd0YzE58pu9kLTkKEZvCwsm8kf8=.2622c9bd-094e-4ef3-8b5c-72a5c55b8b95@github.com>
 <h3fAGwAPBxd6hmyKu7DA1LfqQrfbfLAXoUcQ8bE_wYI=.eeb1d3b8-ce7b-4382-b7ac-6da4b36f4bbf@github.com>
 <Cux26Wbx8g2l0Zdom0le95zg9AvWehhdXMXfB86THmo=.f56daf46-18f3-4268-9691-4607625170d9@github.com>
Message-ID: <leZRqAVewr3QkMYiC0-y47qjVQoGTi6hPlUfJmagu2g=.8ffc6587-f61c-4202-8ac3-30d5347639b1@github.com>

On Tue, 5 Aug 2025 19:38:57 GMT, Johannes D?bler <duke at openjdk.org> wrote:

> Right, but this method is just a helper method

Okay, I'll look into this and the other suggestions. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255181551

From rriggs at openjdk.org  Tue Aug  5 20:00:07 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 20:00:07 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
In-Reply-To: <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
Message-ID: <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>

On Tue, 5 Aug 2025 18:37:42 GMT, Rob Spoor <duke 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.
>
> src/java.base/share/classes/java/lang/Process.java line 673:
> 
>> 671:             }
>> 672:         } catch (InterruptedException ie) {
>> 673:             // Wait was interrupted; terminate the process
> 
> Shouldn't the thread's interrupted flag be restored?

Regardless of an interrupt, the process is destroyed, so there is no use to propagate the interrupt.
It is debatable, whether or not and for how long to give the process time to exit on its own.
If the process has any of its state (files or sockets, etc.) to cleanup, destroying it might leave it in an unexpected state. All of the file descriptors/handles will be closed by the OS, but files might have been created. A robustly written application would/should be coded to deal with that inconsistent persistent state.
The Java process invoking the child can use `waitFor` get the exit status and wait for exit; generally it should not need to know anything about the child process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255216685

From acobbs at openjdk.org  Tue Aug  5 20:32:02 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 5 Aug 2025 20:32:02 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
In-Reply-To: <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
 <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>
Message-ID: <oDlurhdPmv9Nn-VscSC1es7h7S542pL5jkixeBKRESs=.8f493b01-e7ce-4faa-84f4-058782cc6a64@github.com>

On Tue, 5 Aug 2025 19:57:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Regardless of an interrupt, the process is destroyed, so there is no use to propagate the interrupt.

While it's true that it doesn't matter if the purpose of the interruption was only to interrupt the `close()` invocation, couldn't this `close()` operation be one of several different "shutdown" actions the thread is taking, some of which do throw `InterruptedException`, in which the purpose of the interruption is to interrupt any or all of them? In that case, you'd want the interrupt to "hang around" so it can happen if/when the next interruptible operation occurs.

In the example below, if the interruption just happens to occur during `Process.close()`, you want an `InterruptedException` to be thrown by `thing3.shutdown()` immediately (or as soon as possible):

try {
    thing1.shutdown();    // throws InterruptedException
    process2.close();     // does not throw InterruptedException
    thing3.shutdown();    // throws InterruptedException
} catch (InterruptedException e) {
   // bail out now
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255274208

From rriggs at openjdk.org  Tue Aug  5 21:09:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 21:09:06 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
In-Reply-To: <oDlurhdPmv9Nn-VscSC1es7h7S542pL5jkixeBKRESs=.8f493b01-e7ce-4faa-84f4-058782cc6a64@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
 <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>
 <oDlurhdPmv9Nn-VscSC1es7h7S542pL5jkixeBKRESs=.8f493b01-e7ce-4faa-84f4-058782cc6a64@github.com>
Message-ID: <Hl0uh85aN1_VqbP1JqyGknImXh8BrXKEzmuU9q_zAQo=.656f22de-f153-4355-94c7-fcb6d78743d4@github.com>

On Tue, 5 Aug 2025 20:29:08 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Regardless of an interrupt, the process is destroyed, so there is no use to propagate the interrupt.
>> It is debatable, whether or not and for how long to give the process time to exit on its own.
>> If the process has any of its state (files or sockets, etc.) to cleanup, destroying it might leave it in an unexpected state. All of the file descriptors/handles will be closed by the OS, but files might have been created. A robustly written application would/should be coded to deal with that inconsistent persistent state.
>> The Java process invoking the child can use `waitFor` get the exit status and wait for exit; generally it should not need to know anything about the child process.
>
>> Regardless of an interrupt, the process is destroyed, so there is no use to propagate the interrupt.
> 
> While it's true that it doesn't matter if the purpose of the interruption was only to interrupt the `close()` invocation, couldn't this `close()` operation be one of several different "shutdown" actions the thread is taking, some of which do throw `InterruptedException`, in which the purpose of the interruption is to interrupt any or all of them? In that case, you'd want the interrupt to "hang around" so it can happen if/when the next interruptible operation occurs.
> 
> In the example below, if the interruption just happens to occur during `Process.close()`, you want an `InterruptedException` to be thrown by `thing3.shutdown()` immediately (or as soon as possible):
> 
> try {
>     thing1.shutdown();    // throws InterruptedException
>     process2.close();     // does not throw InterruptedException
>     thing3.shutdown();    // throws InterruptedException
> } catch (InterruptedException e) {
>    // bail out now
> }

I'm a bit dubious about the code above because it does not appear to fully handle the InterruptedException.
If it is really shutting down then its just complicit in leaving the application is an unpredictable and probably unrecoverable state.

Propagating the checked exception reduces the usability of close() to the point that I would remove the waitFor.
It annoying enough already that `waitFor` throws InterruptedException and you have to write more code and maybe a loop to handle that interruption and what it means to the caller.
I would leave up to the caller to handle that case.
When used with try-with-resources, the exception handling/re-throwing is complicated enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255342872

From bpb at openjdk.org  Tue Aug  5 21:10:19 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Aug 2025 21:10:19 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed
In-Reply-To: <WdbGr9mbqjL04ZvuEl3UgE_Y68UHPdQ1hslNdGK_pJk=.33f6976a-c9d6-4f3f-a457-bcdc507336f3@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <WdbGr9mbqjL04ZvuEl3UgE_Y68UHPdQ1hslNdGK_pJk=.33f6976a-c9d6-4f3f-a457-bcdc507336f3@github.com>
Message-ID: <Ai63UbAeQNHLcUaLxB-IUACa-4g-c4_3Mveu2iyI_Eo=.e2ae18db-f6ea-451f-8d83-b1b38a360ae6@github.com>

On Tue, 5 Aug 2025 06:53:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm specifically wondering about toRealPath and Files.list/walk behave now and how they will behave with the change.

For a file tree rooted at dir

dir:
file1*  file2*  file3*  subdir/

dir/subdir:
file4*  file5*

and a directory junction `junction` whose target is `dir`, then for `p = Path.of("junction")`, the results of `p.toRealPath()`, `p.toRealPath(NOFOLLOW_LINKS)`, `Files.list(p)`, and `Files.walk(p, FOLLOW_LINKS)` are identical before and after this change. Only the results of `Files.walk(p)` differ and are as follows:

- **before**
```[junction, junction\file1, junction\file2, junction\file3, junction\subdir, junction\subdir\file4, junction\subdir\file5]```
- **after**
```[junction]```.

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

PR Comment: https://git.openjdk.org/jdk/pull/26631#issuecomment-3156651833

From scolebourne at joda.org  Tue Aug  5 21:15:33 2025
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 5 Aug 2025 22:15:33 +0100
Subject: Reduce size of j.t.f.DateTimePrintContext::adjust
In-Reply-To: <875b2431-182b-4918-b9db-fa7491c61f6b@oracle.com>
References: <62d992ec-5a3c-4436-be49-a692379402c4.shaojin.wensj@alibaba-inc.com>
 <875b2431-182b-4918-b9db-fa7491c61f6b@oracle.com>
Message-ID: <CACzrW9AygTRiknd7WoGkoqj=1toZxqOEW=cavxC7LWcJsab7eg@mail.gmail.com>

>From my perspective, the proposed change looks fine. Extracting out
error creation is a pretty common trick to get a performance gain
through additional inlining. I'd also note that it seems like the
method was identified as performance sensitive during the original
testing, as identified by the comments "early return is an
optimization".

Looking at the code now, I think the better inlining change would be
to introduce a new private method into the logic at the
common/uncommon point, something like this:

private static TemporalAccessor adjust(final TemporalAccessor
temporal, DateTimeFormatter formatter) {
  // normal case first (early return is an optimization)
  ...
  // ensure minimal change (early return is an optimization)
  ...
  adjust0(...)
}

private static TemporalAccessor adjust0(...) {
  // make adjustment
  ...
}

I suspect such a change would be more beneficial than the original proposal.

Stephen



On Tue, 5 Aug 2025 at 16:34, <jaikiran.pai at oracle.com> wrote:
>
> Hello Shaojin,
>
> Looking at the proposed change, the proposal here appears to be to replace an inline "new DateTimeException(...)" call with a call to a new private method which returns a "new DateTimeException(...)", to please the hotspot compiler's inlining decision.
>
> I think this isn't a useful change. Enabling the -XX:+PrintInlining will naturally print the runtime compiler's inlining decisions and there could be some/many logs which complain that the method couldn't be inlined. Changing the java code (like here) to closely handhold it to match the (unspecified) expectations of a particular (current) implementation of the runtime compiler shouldn't be the way to code in java language. Such changes, like the one here, won't help with the maintainability or the readability of the code.
>
> -Jaikiran
>
> On 05/08/25 6:55 am, wenshao wrote:
>
> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
>
> Below is the log message:
> ```
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> ```
>
> We can extract the exception-generating code into two smaller methods, reducing the code size from 382 to 322, allowing C2 to inline the DateTimePrintContext::adjust method.
>
> The refactored code looks like this:
> ```java
>     private static TemporalAccessor adjust(final TemporalAccessor temporal, DateTimeFormatter formatter) {
>         // ...
>         if (overrideZone.normalized() instanceof ZoneOffset && temporal.isSupported(OFFSET_SECONDS) &&
>                 temporal.get(OFFSET_SECONDS) != overrideZone.getRules().getOffset(Instant.EPOCH).getTotalSeconds()) {
>             throw unableApplyOverrideZone(temporal, overrideZone);
>         }
>         // ....
>         if (f.isDateBased() && temporal.isSupported(f)) {
>             throw unableApplyOverrideChronology(temporal, overrideChrono);
>         // ...
>     }
>     private static DateTimeException unableApplyOverrideChronology(TemporalAccessor temporal, Chronology overrideChrono) {
>         return new DateTimeException("Unable to apply override chronology '" + overrideChrono +
>                 "' because the temporal object being formatted contains date fields but" +
>                 " does not represent a whole date: " + temporal);
>     }
>     private static DateTimeException unableApplyOverrideZone(TemporalAccessor temporal, ZoneId overrideZone) {
>         return new DateTimeException("Unable to apply override zone '" + overrideZone +
>                 "' because the temporal object being formatted has a different offset but" +
>                 " does not represent an instant: " + temporal);
>     }
> ```
>
> I submitted a draft Pull Request https://github.com/openjdk/jdk/pull/26633 , Hope to get your feedback.
>
> -
> Shaojin Wen

From acobbs at openjdk.org  Tue Aug  5 21:48:05 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 5 Aug 2025 21:48:05 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
In-Reply-To: <Hl0uh85aN1_VqbP1JqyGknImXh8BrXKEzmuU9q_zAQo=.656f22de-f153-4355-94c7-fcb6d78743d4@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
 <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>
 <oDlurhdPmv9Nn-VscSC1es7h7S542pL5jkixeBKRESs=.8f493b01-e7ce-4faa-84f4-058782cc6a64@github.com>
 <Hl0uh85aN1_VqbP1JqyGknImXh8BrXKEzmuU9q_zAQo=.656f22de-f153-4355-94c7-fcb6d78743d4@github.com>
Message-ID: <oBF3eUakXaGz_3DZr7vb2yxGb_20NP0XDt6_xUg7i6A=.e9ce0946-6aea-4a69-ab2a-680b390537ad@github.com>

On Tue, 5 Aug 2025 21:06:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Regardless of an interrupt, the process is destroyed, so there is no use to propagate the interrupt.
>> 
>> While it's true that it doesn't matter if the purpose of the interruption was only to interrupt the `close()` invocation, couldn't this `close()` operation be one of several different "shutdown" actions the thread is taking, some of which do throw `InterruptedException`, in which the purpose of the interruption is to interrupt any or all of them? In that case, you'd want the interrupt to "hang around" so it can happen if/when the next interruptible operation occurs.
>> 
>> In the example below, if the interruption just happens to occur during `Process.close()`, you want an `InterruptedException` to be thrown by `thing3.shutdown()` immediately (or as soon as possible):
>> 
>> try {
>>     thing1.shutdown();    // throws InterruptedException
>>     process2.close();     // does not throw InterruptedException
>>     thing3.shutdown();    // throws InterruptedException
>> } catch (InterruptedException e) {
>>    // bail out now
>> }
>
> I'm a bit dubious about the code above because it does not appear to fully handle the InterruptedException.
> If it is really shutting down then its just complicit in leaving the application is an unpredictable and probably unrecoverable state.
> 
> Propagating the checked exception reduces the usability of close() to the point that I would remove the waitFor.
> It annoying enough already that `waitFor` throws InterruptedException and you have to write more code and maybe a loop to handle that interruption and what it means to the caller.
> I would leave up to the caller to handle that case.
> When used with try-with-resources, the exception handling/re-throwing is complicated enough.

You make some good points. Still, I think swallowing `InterruptException`'s in library code is generally considered to be wrong. According to _Java Concurrency in Practice_  ?7.1.3:

> If you don't want to or cannot propagate `InterruptedException`... you need to find another way to preserve the interruption request. The standard way to do this is to restore the interrupted status by calling interrupt again. What you should not do is swallow the `InterruptedException` by catching it and doing nothing in the catch block, unless your code is actually implementing the interruption policy for a thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255411803

From tschatzl at openjdk.org  Tue Aug  5 21:59:00 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 5 Aug 2025 21:59:00 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v46]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <8Ja1d6zTuDEThq0VR2UQfpY94bqnQql-mqIc-fa8ico=.0909c352-1208-481e-954b-8356f45e07ad@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl 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 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * remove unused G1DetachedRefinementStats_lock
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - ... and 53 more: https://git.openjdk.org/jdk/compare/d906e450...188fc811

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=45
  Stats: 7114 lines in 112 files changed: 2583 ins; 3587 del; 944 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

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

From naoto at openjdk.org  Tue Aug  5 22:35:58 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 22:35:58 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v8]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

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

  Refining docs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/31250ee4..b9b0820f

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

  Stats: 24 lines in 3 files changed: 10 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

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

From naoto at openjdk.org  Tue Aug  5 22:56:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 22:56:03 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <owQ-_K_KjtaFQr7GFYri3wWxKEFIDI_eeTg1rwDg7vU=.ceb602b2-fefa-4651-83f6-16ec861a75e9@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>
 <RywjGlwSqZ46Mh6g-c4i1RbCwD0McZBiQCTzq4jREp4=.4b92904e-c745-4a4f-85b2-fde0ceab2538@github.com>
 <owQ-_K_KjtaFQr7GFYri3wWxKEFIDI_eeTg1rwDg7vU=.ceb602b2-fefa-4651-83f6-16ec861a75e9@github.com>
Message-ID: <5b4PScAq8QXuOFqkhBsNMe2y7VyccYORtE_IIOkA-ro=.38736426-7fcd-4d26-a990-098721bb3b46@github.com>

On Tue, 5 Aug 2025 19:41:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The way I interpreted this was that Naoto was not trying to imply that the default behavior of the class enabled loose matching of lenient minus parsing signs. Rather, he was describing that the JDK reference implementation of DecimalFormat and CompactNumberFormat support the ability for loose matching of minus sign patterns (and other JDKs need not implement this particular LMDL behavior).
>> 
>> If I interpreted that wrong and his intentions were the former, then I agree it is best to just mention leniency.
>
> The spec for enabling lenient matching in parsing of minus signs belongs with the other comments about leniency in the `parse()` method. Its behavior depends on the settings in the isStrict and setStrict methods.
> It looks a bit out of context in the class javadoc.

Moved the description into each concrete classes' "Negative Subpattern" section, dropping the implNote and adding the link to the leniency section in `NumberFormat`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255492346

From naoto at openjdk.org  Tue Aug  5 22:56:05 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 22:56:05 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
Message-ID: <akqzBE4RPlOWiNXxFB1uksD4hPhVS5yxZUJMsgGYnzs=.c7d67a06-0d44-4a27-ac7e-fcd073247e37@github.com>

On Tue, 5 Aug 2025 16:53:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refrects review comments
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 719:
> 
>> 717: 
>> 718:     /**
>> 719:      * {@return the lenient minus signs} Multiple lenient minus signs
> 
> Do we have an idea of when a given locale would not have access to the lenient minus signs provided by parseLenient element? If the vast majority of times it will, then it is fine. Otherwise IMO, `getLenientMinusSigns()` should probably call out the fact that it may not always be a concatenation of multiple minus _signs_, and it may be a single minus _sign_ (as assigned by `minusSignText`). Since that detail is only apparent by digging around the code that assigns `lenientMinusSigns`.

The lenient minus signs are embedded in number elements for the Laitn script (latn.NumberElements), so they are mostly in each locale data.

> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 852:
> 
>> 850: 
>> 851:         // Lenient minus signs
>> 852:         lenientMinusSigns = numberElements.length < 14 ? minusSignText : numberElements[13];
> 
> BTW, if I remove this check and always assign to `numberElements[13]`, I do not observe any failures in the java_text/Format suite. It would be nice to have an idea of why this check is needed. (I understand it is following the same length checks of monetarySeparator and monetaryGroupingSeparator.)

The FALLBACK locale provider does not provide those elements, so the check is needed. Some tests in java/sun.util tests that specify HOST provider would fail without it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255492762
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255492528

From naoto at openjdk.org  Tue Aug  5 22:56:05 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 22:56:05 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <nCCgWWShuRVNzrf0KoUo34L7NiWDZj2yp2izVXGHDUQ=.7ccc8ff9-8d37-4747-adf3-e7d7dd61af45@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <IcLAo7eeyILz7PVdfKlMnGKWR7b-skbDyvFgRe5XRkU=.bae8b1f4-d0dd-4ae8-aa32-bac05a1beafd@github.com>
 <nCCgWWShuRVNzrf0KoUo34L7NiWDZj2yp2izVXGHDUQ=.7ccc8ff9-8d37-4747-adf3-e7d7dd61af45@github.com>
Message-ID: <c4BFgvOK7uP64cQbg3ocK_mRQZrmSkjZ5CXzl1KYcUo=.bc6d99bb-44a0-4234-93dc-a87e487746f9@github.com>

On Tue, 5 Aug 2025 18:23:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> It might be clearer to say that each character of the string is a valid minus sign character.
>> If you want to preserve the option for full support for surrogates it could say codepoints instead of character.
>
> I agree. I think that is a good wording update which naturally covers both the single and multiple minus signs case.

Clarified. (did not add @since, as this is an internal method)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255494170

From shaojin.wensj at alibaba-inc.com  Wed Aug  6 00:17:41 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Wed, 06 Aug 2025 08:17:41 +0800
Subject: =?UTF-8?B?5Zue5aSN77yaUmVkdWNlIHNpemUgb2Ygai50LmYuRGF0ZVRpbWVQcmludENvbnRleHQ6OmFk?=
 =?UTF-8?B?anVzdA==?=
In-Reply-To: <CACzrW9AygTRiknd7WoGkoqj=1toZxqOEW=cavxC7LWcJsab7eg@mail.gmail.com>
References: <62d992ec-5a3c-4436-be49-a692379402c4.shaojin.wensj@alibaba-inc.com>
 <875b2431-182b-4918-b9db-fa7491c61f6b@oracle.com>,
 <CACzrW9AygTRiknd7WoGkoqj=1toZxqOEW=cavxC7LWcJsab7eg@mail.gmail.com>
Message-ID: <b763260a-87e2-412e-ab06-0df3073ffa30.shaojin.wensj@alibaba-inc.com>

Thank you, Stephen, for your feedback.
Your suggestion is better; it will make the adjust method smaller (codeSize 143), allowing for more inlining within the same inline root.
I've made changes based on your suggestions in the draft pull request (https://github.com/openjdk/jdk/pull/26633 <https://github.com/openjdk/jdk/pull/26633 >). Could you please review this common/uncommon split and see if it's correct?
-
Shaojin Wen
------------------------------------------------------------------
????Stephen Colebourne <scolebourne at joda.org>
?????2025?8?6?(??) 05:16
????"core-libs-dev"<core-libs-dev at openjdk.org>
????Re: Reduce size of j.t.f.DateTimePrintContext::adjust
From my perspective, the proposed change looks fine. Extracting out
error creation is a pretty common trick to get a performance gain
through additional inlining. I'd also note that it seems like the
method was identified as performance sensitive during the original
testing, as identified by the comments "early return is an
optimization".
Looking at the code now, I think the better inlining change would be
to introduce a new private method into the logic at the
common/uncommon point, something like this:
private static TemporalAccessor adjust(final TemporalAccessor
temporal, DateTimeFormatter formatter) {
 // normal case first (early return is an optimization)
 ...
 // ensure minimal change (early return is an optimization)
 ...
 adjust0(...)
}
private static TemporalAccessor adjust0(...) {
 // make adjustment
 ...
}
I suspect such a change would be more beneficial than the original proposal.
Stephen
On Tue, 5 Aug 2025 at 16:34, <jaikiran.pai at oracle.com> wrote:
>
> Hello Shaojin,
>
> Looking at the proposed change, the proposal here appears to be to replace an inline "new DateTimeException(...)" call with a call to a new private method which returns a "new DateTimeException(...)", to please the hotspot compiler's inlining decision.
>
> I think this isn't a useful change. Enabling the -XX:+PrintInlining will naturally print the runtime compiler's inlining decisions and there could be some/many logs which complain that the method couldn't be inlined. Changing the java code (like here) to closely handhold it to match the (unspecified) expectations of a particular (current) implementation of the runtime compiler shouldn't be the way to code in java language. Such changes, like the one here, won't help with the maintainability or the readability of the code.
>
> -Jaikiran
>
> On 05/08/25 6:55 am, wenshao wrote:
>
> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
>
> Below is the log message:
> ```
> @ 7 java.time.format.DateTimePrintContext::adjust (382 bytes) failed to inline: hot method too big
> ```
>
> We can extract the exception-generating code into two smaller methods, reducing the code size from 382 to 322, allowing C2 to inline the DateTimePrintContext::adjust method.
>
> The refactored code looks like this:
> ```java
> private static TemporalAccessor adjust(final TemporalAccessor temporal, DateTimeFormatter formatter) {
> // ...
> if (overrideZone.normalized() instanceof ZoneOffset && temporal.isSupported(OFFSET_SECONDS) &&
> temporal.get(OFFSET_SECONDS) != overrideZone.getRules().getOffset(Instant.EPOCH).getTotalSeconds()) {
> throw unableApplyOverrideZone(temporal, overrideZone);
> }
> // ....
> if (f.isDateBased() && temporal.isSupported(f)) {
> throw unableApplyOverrideChronology(temporal, overrideChrono);
> // ...
> }
> private static DateTimeException unableApplyOverrideChronology(TemporalAccessor temporal, Chronology overrideChrono) {
> return new DateTimeException("Unable to apply override chronology '" + overrideChrono +
> "' because the temporal object being formatted contains date fields but" +
> " does not represent a whole date: " + temporal);
> }
> private static DateTimeException unableApplyOverrideZone(TemporalAccessor temporal, ZoneId overrideZone) {
> return new DateTimeException("Unable to apply override zone '" + overrideZone +
> "' because the temporal object being formatted has a different offset but" +
> " does not represent an instant: " + temporal);
> }
> ```
>
> I submitted a draft Pull Request https://github.com/openjdk/jdk/pull/26633 <https://github.com/openjdk/jdk/pull/26633 > , Hope to get your feedback.
>
> -
> Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250806/84f61a99/attachment.htm>

From bpb at openjdk.org  Wed Aug  6 01:11:48 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Aug 2025 01:11:48 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v3]
In-Reply-To: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
Message-ID: <boJq_ZpX00rKbmQ6KqCtwQXMEsrJBcjy7jviAQfyKNo=.b37daa06-4ba6-44ab-bd9c-d828e608ef14@github.com>

> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.

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

  8364277: Clean up per reviewer comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26631/files
  - new: https://git.openjdk.org/jdk/pull/26631/files/cf9eab46..ebd6f415

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

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

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

From bpb at openjdk.org  Wed Aug  6 01:14:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Aug 2025 01:14:10 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <Au-D6qYBegw3kIQtMd0YzE58pu9kLTkKEZvCwsm8kf8=.2622c9bd-094e-4ef3-8b5c-72a5c55b8b95@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
 <Au-D6qYBegw3kIQtMd0YzE58pu9kLTkKEZvCwsm8kf8=.2622c9bd-094e-4ef3-8b5c-72a5c55b8b95@github.com>
Message-ID: <BIBTL8QSM9jbUvDNPRjFMyadtmjggDefu0CpflBdk4k=.e0163563-085c-4516-9a5f-37312e0b98a9@github.com>

On Tue, 5 Aug 2025 18:41:44 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test
>
> test/lib/jdk/test/lib/util/FileUtils.java line 449:
> 
>> 447: 
>> 448:     // Create a link from "junction" to the real path of "target"
>> 449:     public static boolean createDirectoryJunction(String junction, String target)
> 
> Suggestion: Use Path as type for parameters `junction` and `target` to avoid Path|File->String->Path|File conversions (e.g. the only caller Basic.java already has a Path object for parameter junction, why convert to a String just to recreate a File inside `createDirectoryJunction`).

Done in ebd6f41.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255636088

From bpb at openjdk.org  Wed Aug  6 01:14:11 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Aug 2025 01:14:11 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <pwgbpcuVbkmVtA5k_ilr8ReRgw5tGlqWlImw2rbcCys=.75693e2b-dfe1-4185-b2ce-3e3ae769f373@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
 <BZNhxM3PUJfSxi-dtLF9C3_GttLTZsXz65bttyyUHyE=.99598566-a83d-43af-9230-ccc4456b2769@github.com>
 <pwgbpcuVbkmVtA5k_ilr8ReRgw5tGlqWlImw2rbcCys=.75693e2b-dfe1-4185-b2ce-3e3ae769f373@github.com>
Message-ID: <xWBQG__fa7HY3JkIrRAOZGBecosAfgilRpjqcquoiUo=.8214b77c-b3df-412c-acab-7aa922d526b7@github.com>

On Tue, 5 Aug 2025 18:21:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/FileUtils.java line 457:
>> 
>>> 455:         // Create a directory junction or a symbolic link
>>> 456:         if (IS_WINDOWS) {
>>> 457:             if (!nativeLibLoaded) {
>> 
>> Suggestion: Since this logic to load the FileUtils library is now used twice, why not move it into a helper method which might also be synchronized (if tests are executed in parallel).
>
>> Since this logic to load the FileUtils library is now used twice, why not move it into a helper method
> 
> Sounds like a good idea. I'll investigate.

Done in ebd6f41.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255635632

From bpb at openjdk.org  Wed Aug  6 01:14:11 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Aug 2025 01:14:11 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <leZRqAVewr3QkMYiC0-y47qjVQoGTi6hPlUfJmagu2g=.8ffc6587-f61c-4202-8ac3-30d5347639b1@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
 <Au-D6qYBegw3kIQtMd0YzE58pu9kLTkKEZvCwsm8kf8=.2622c9bd-094e-4ef3-8b5c-72a5c55b8b95@github.com>
 <h3fAGwAPBxd6hmyKu7DA1LfqQrfbfLAXoUcQ8bE_wYI=.eeb1d3b8-ce7b-4382-b7ac-6da4b36f4bbf@github.com>
 <Cux26Wbx8g2l0Zdom0le95zg9AvWehhdXMXfB86THmo=.f56daf46-18f3-4268-9691-4607625170d9@github.com>
 <leZRqAVewr3QkMYiC0-y47qjVQoGTi6hPlUfJmagu2g=.8ffc6587-f61c-4202-8ac3-30d5347639b1@github.com>
Message-ID: <cbAH13ndMR9Eo_avjrpOsUSgLSvC4jTs6FHgoKACaLQ=.29ca20b8-83b1-4681-a374-be4b76ece879@github.com>

On Tue, 5 Aug 2025 19:41:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Right, but this method is just a helper method not a test method and the caller, e.g. Basic.attributeReadWriteTests|checkAttributesOfJunction should only call it if on Windows.
>
>> Right, but this method is just a helper method
> 
> Okay, I'll look into this and the other suggestions. Thanks.

Done in ebd6f41.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255635876

From bpb at openjdk.org  Wed Aug  6 01:17:20 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Aug 2025 01:17:20 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <RKfAa4LBqcf24RdbU62lU2DsY-WIR4bdX2jcP-pBfwI=.b5b5ab16-d660-4c37-bda9-b45aa01fa8ac@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
 <RKfAa4LBqcf24RdbU62lU2DsY-WIR4bdX2jcP-pBfwI=.b5b5ab16-d660-4c37-bda9-b45aa01fa8ac@github.com>
Message-ID: <LhyoKYnBNLqNV0xqUQsnDkd9tQ8GP8jmMf3Iz16gKjs=.61878817-be46-44d8-ab61-2d25db1bf3cd@github.com>

On Tue, 5 Aug 2025 19:26:36 GMT, Johannes D?bler <duke at openjdk.org> wrote:

> Would it be possible to avoid the dreaded goto

I expect so, with some careful editing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255638428

From almatvee at openjdk.org  Wed Aug  6 02:26:10 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 6 Aug 2025 02:26:10 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test [v5]
In-Reply-To: <VYPyMj3UEHduM_UuuhPJ4O8juiCWKs0JUWsKMYQDBbE=.a2b454a0-aff4-4251-b4ec-362ccb1f263a@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
 <VYPyMj3UEHduM_UuuhPJ4O8juiCWKs0JUWsKMYQDBbE=.a2b454a0-aff4-4251-b4ec-362ccb1f263a@github.com>
Message-ID: <j9qVnYJX9z3HEsT6RLeu-fwa0KPzqnzzYyWjWKPHSL0=.83b987e0-c7b7-477d-8bbc-1c41ebe330d8@github.com>

On Mon, 4 Aug 2025 04:54:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
>> - Test shortcuts in the predefined app image.
>> 
>> Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.
>> 
>> Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.
>> 
>> Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.
>> 
>> Not directly related to the subject of the PR:
>>  - JPackageCommand: Added missing and removed redundant `verifyMutable()` calls. Converted "jpt-unpacked-folder" option into the member field. Added `JPackageCommand.createMutableCopy()` complementary to the existing `JPackageCommand.createImmutableCopy()`.
>>  - Refactor `TKit.waitForFileCreated()` to use classes from the `java.time` package.
>>  - Added `test/jdk/tools/jpackage/clean_test_output.sh` Bash script filtering test logs to minimize noise in diffs.
>> 
>> Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use TKit.waitForFileCreated() to await for test output file
>  - Use java.time.Duration and java.time.Instant in TKit.waitForFileCreated(). Make it public.

Looks good with minor comment.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 635:

> 633:                     return;
> 634:                 }
> 635:                 assertUnexpected(String.format("Timeout expired", remainderTimeout));

`"Timeout expired"` missing format?

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

PR Review: https://git.openjdk.org/jdk/pull/26584#pullrequestreview-3090170423
PR Review Comment: https://git.openjdk.org/jdk/pull/26584#discussion_r2255665599

From qamai at openjdk.org  Wed Aug  6 03:14:09 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Aug 2025 03:14:09 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
Message-ID: <MpYqVIapo3_CGmuo86MN3cXnSSnnsWgObODcqtxbOiw=.99bb1a22-c9aa-4843-b85b-d2af67e96c25@github.com>

On Tue, 5 Aug 2025 11:39:43 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
>> 
>> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
>> 
>> 
>> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
>> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
>> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
>> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
>> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
>> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
>> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
>> 
>> 
>> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
>> 
>> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.
>
> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check at the very least that auto vectorization is supported

Marked as reviewed by qamai (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26457#pullrequestreview-3090286501

From swen at openjdk.org  Wed Aug  6 05:02:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 6 Aug 2025 05:02:06 GMT
Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP
 replies if Connection is subsequently closed [v3]
In-Reply-To: <3srnJrm0Np7t0RzwkM2lKK9SuMWyQ1EeAR5m65EaD8I=.e1d7ae14-9117-437c-a3a6-027a76146a84@github.com>
References: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
 <3srnJrm0Np7t0RzwkM2lKK9SuMWyQ1EeAR5m65EaD8I=.e1d7ae14-9117-437c-a3a6-027a76146a84@github.com>
Message-ID: <e7IQh8qnUPOD4PMQo4F1vzsy2n8IfYbwYAVopsJiGvo=.a7e9e061-b3ee-42a2-abdb-592323a18307@github.com>

On Wed, 16 Jul 2025 11:30:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708?
>> 
>> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen.
>> 
>> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`.
>> 
>> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces.
>> 
>> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - merge latest from master branch
>  - merge latest from master branch
>  - add test
>  - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed

src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java line 144:

> 142:         // poll from 'replies' blocking queue ended-up with timeout
> 143:         if (result == null) {
> 144:             throw new IOException(String.format(TIMEOUT_MSG_FMT, millis));

Suggestion:

            throw new IOException("LDAP response read timed out, timeout used: %d ms.".formatted(millis));

TIMEOUT_MSG_FMT is only used once here, and defining a constant would make the code less readable.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java line 147:

> 145:         }
> 146:         if (result == CANCELLED_MARKER) {
> 147:             throw new CommunicationException("Request: " + msgId +

The current LdapRequest class should use a unified style to construct exception information, either using string concatenation or String.format. A class should not mix the two styles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2255863225
PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2255865709

From swen at openjdk.org  Wed Aug  6 05:06:11 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 6 Aug 2025 05:06:11 GMT
Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP
 replies if Connection is subsequently closed [v3]
In-Reply-To: <3srnJrm0Np7t0RzwkM2lKK9SuMWyQ1EeAR5m65EaD8I=.e1d7ae14-9117-437c-a3a6-027a76146a84@github.com>
References: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
 <3srnJrm0Np7t0RzwkM2lKK9SuMWyQ1EeAR5m65EaD8I=.e1d7ae14-9117-437c-a3a6-027a76146a84@github.com>
Message-ID: <ELZZtpx7c0cdnlALQ_rrc3iGWyJJE61NJLIFrI6lVzw=.06206555-9396-4ac1-ab2a-58ce00e2a532@github.com>

On Wed, 16 Jul 2025 11:30:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708?
>> 
>> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen.
>> 
>> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`.
>> 
>> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces.
>> 
>> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - merge latest from master branch
>  - merge latest from master branch
>  - add test
>  - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed

test/jdk/javax/naming/ldap/LdapClientConnTest.java line 110:

> 108:         try (final ExecutorService executor = Executors.newCachedThreadPool()) {
> 109:             for (int i = 1; i <= numTasks; i++) {
> 110:                 final String taskName = "task-" + i;

Suggestion:

                String taskName = "task-" + i;

Variables used only in the current block do not need to be final

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2255870041

From swen at openjdk.org  Wed Aug  6 05:18:04 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 6 Aug 2025 05:18:04 GMT
Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP
 replies if Connection is subsequently closed [v3]
In-Reply-To: <3srnJrm0Np7t0RzwkM2lKK9SuMWyQ1EeAR5m65EaD8I=.e1d7ae14-9117-437c-a3a6-027a76146a84@github.com>
References: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
 <3srnJrm0Np7t0RzwkM2lKK9SuMWyQ1EeAR5m65EaD8I=.e1d7ae14-9117-437c-a3a6-027a76146a84@github.com>
Message-ID: <qvYLhnAHxLrsH2N4cwvjXs7l1hsTXKH3n0MZtg1V10o=.e34b5469-01f4-4d9d-86a4-06bf1597befc@github.com>

On Wed, 16 Jul 2025 11:30:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708?
>> 
>> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen.
>> 
>> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`.
>> 
>> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces.
>> 
>> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - merge latest from master branch
>  - merge latest from master branch
>  - add test
>  - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed

src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java line 87:

> 85:                 ber.parseSeq(null);
> 86:                 ber.parseInt();
> 87:                 isLdapResResult = (ber.peekByte() == LdapClient.LDAP_REP_RESULT);

Other boolean type variables in the LdapRequest class do not have the `is` prefix. The local variable `isLdapResResult` here should also use the same style. We should not use two styles in one class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2255883785

From swen at openjdk.org  Wed Aug  6 05:27:14 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 6 Aug 2025 05:27:14 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v13]
In-Reply-To: <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
Message-ID: <xyPYYfvuC6ESA6jHdPEuB9gK_po4sOpF5ME-acayZyw=.632d1880-4706-4a27-adcb-f5d4b18d0780@github.com>

On Fri, 25 Jul 2025 07:40:46 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici 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 31 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Replace `requireNonNull` with implicit null checks to reduce bytecode size
>  - Add `@bug` tags
>  - Improve wording of `@param len`
>  - Make source array bound checks lenient too
>  - Cap destination array bounds
>  - Fix bit shifting
>  - Remove superseded `@throws` Javadoc
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Make `StringCoding` encoding intrinsics lenient
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/5917e59b...c322f0e0

src/java.base/share/classes/java/lang/StringCoding.java line 99:

> 97:      *         {@linkplain Preconditions#checkFromIndexSize(int, int, int, BiFunction) out of bounds}
> 98:      */
> 99:     static int countPositives(byte[] ba, int off, int len) {

If we name countPositives with parameter checking as countPositivesSB, this PR will have fewer changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2255894472

From stuefe at openjdk.org  Wed Aug  6 05:41:38 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Aug 2025 05:41:38 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default
Message-ID: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>

A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.

The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.

See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .

The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

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

Commit messages:
 - tolerate sigaction failing
 - Fixes
 - fix
 - start+repro-case

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

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

From duke at openjdk.org  Wed Aug  6 05:38:14 2025
From: duke at openjdk.org (duke)
Date: Wed, 6 Aug 2025 05:38:14 GMT
Subject: Withdrawn: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
In-Reply-To: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
References: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
Message-ID: <JsPt5BhIupIWjK0scH05UbWhnfvJm6PoXPAtUTqxTBQ=.1765744c-f2ac-4815-b518-a2ef7c782125@github.com>

On Wed, 14 May 2025 23:51:36 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner.
> 
> (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.)
> 
> In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical.
> 
> Details of note:
> 
> 1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same.
> 
> Thanks.
> 
> **Edit: (Re)viewers: due to there being a lot of indentation changes, you might consider enabling the "Hide whitespace" option on the "Files changed" tab. To my eye, it gives a better view of the changes.**

This pull request has been closed without being integrated.

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

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

From swen at openjdk.org  Wed Aug  6 05:52:09 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 6 Aug 2025 05:52:09 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v8]
In-Reply-To: <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
Message-ID: <-YJY-8webwGnyO0DUcRgJADfTRN2CSBvtsN611zLr6k=.be5c885a-e164-401b-a126-53813f94ba23@github.com>

On Tue, 5 Aug 2025 22:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refining docs

make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java line 860:

> 858:             if (currentContainer instanceof KeyContainer kc &&
> 859:                 kc.getKey().equals("number") &&
> 860:                 attributes.getValue("sample").equals("-")) {

Suggestion:

            if (currentContainer instanceof KeyContainer kc
                && kc.getKey().equals("number")
                && attributes.getValue("sample").equals("-")) {

Similar to lines 813 to 817 above, the `&&` operator is placed in front to make the style consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255928504

From dholmes at openjdk.org  Wed Aug  6 05:55:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Aug 2025 05:55:05 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
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: <Hw2Titji9Bh4Qr7Sd7MbgZr6UKnJdEgmzrzZUGYvnQo=.edbbf725-f714-4b7f-85f8-ad9c0f5fede1@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.

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

> 629:      * Streams should be {@code closed} when no longer needed.
> 630:      * Closing an already closed stream usually has no effect but is specific to the stream.
> 631:      * IOExceptions that occur when closing streams are ignored.

Suggestion:

     * Any {@code IOException} that occurs when closing a stream is ignored.

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

> 633:      * The process may already have exited or be in the process of exiting;
> 634:      * if it is {@linkplain #isAlive() alive}, it is {@linkplain #destroy destroyed}.
> 635:      * IOExceptions that occur when destroying the process are ignored.

Suggestion:

     * Any {@code IOException} that occurs when destroying the process is ignored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255930745
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255931623

From alanb at openjdk.org  Wed Aug  6 06:06:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Aug 2025 06:06:04 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v3]
In-Reply-To: <boJq_ZpX00rKbmQ6KqCtwQXMEsrJBcjy7jviAQfyKNo=.b37daa06-4ba6-44ab-bd9c-d828e608ef14@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <boJq_ZpX00rKbmQ6KqCtwQXMEsrJBcjy7jviAQfyKNo=.b37daa06-4ba6-44ab-bd9c-d828e608ef14@github.com>
Message-ID: <CA0750_pTQnBHm2tS91wGnyGyR8RfikoNfLaSrmKDUQ=.76279ed2-c813-43d7-afae-866b81673069@github.com>

On Wed, 6 Aug 2025 01:11:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364277: Clean up per reviewer comments

src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 419:

> 417:             return false;
> 418:         return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 &&
> 419:                 (fileAttrs & FILE_ATTRIBUTE_REPARSE_POINT) != 0);

Should this just check if reparseTag has the value IO_REPARSE_TAG_MOUNT_POINT?

src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 436:

> 434:         if (isSymbolicLink())
> 435:             return false;
> 436:         return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 &&

I assume it means that isDirectory no longer needs to use isSymbolicLink as the change means it will return false for all files that are reparse points.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255946387
PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255949663

From pminborg at openjdk.org  Wed Aug  6 06:32:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Aug 2025 06:32:52 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v14]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <ZneAoVqM7ccsL2YfYjaIxcPDSpiRZDjnWvJeOhdhaSM=.0c87769e-048b-488b-8b69-110eaf721b49@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix inverted logic error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/8f7fb6dd..1f454706

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

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

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

From jiefu at openjdk.org  Wed Aug  6 06:59:02 2025
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 6 Aug 2025 06:59:02 GMT
Subject: RFR: 8364597: Replace THL A29 Limited with Tencent
In-Reply-To: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
References: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
Message-ID: <08Gigv9qz5H5c80w-WLegQ_8KVI4xoY-kZ374S8t5ls=.35ded307-c917-4c1b-9ab0-032499140a67@github.com>

On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `THL A29 Limited` was a `Tencent` company but was dissolved.
> So, the copyright notes just use `Tencent` directly.

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26614#pullrequestreview-3090664823

From dholmes at openjdk.org  Wed Aug  6 07:01:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Aug 2025 07:01:06 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
Message-ID: <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>

On Tue, 5 Aug 2025 10:16:32 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483:
>> 
>>> 1481:   // Is an explicit slot given?
>>> 1482:   bool explicit_search = slot >= 0;
>>> 1483:   if (explicit_search) {
>> 
>> Suggestion:
>> 
>>   if (slot >= 0) {
>> 
>> No need for the temporary local.
>
> If we don't adopt the enum I suggested, then I do prefer the naming of the condition through a variable. It gives you a hint of what the check is looking for, and not only what the check does.

That is what comments are for.

>> src/java.base/share/classes/java/lang/NullPointerException.java line 78:
>> 
>>> 76:     NullPointerException(int stackOffset, int searchSlot) {
>>> 77:         extendedMessageState = setupCustomBackTrace(stackOffset, searchSlot);
>>> 78:         this();
>> 
>> I thought `this()` had to come first in a constructor? Is this new in 25 or 26?
>
> https://openjdk.org/jeps/492

And now final - https://openjdk.org/jeps/513

Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256053422
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256047794

From jsjolen at openjdk.org  Wed Aug  6 07:48:23 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 6 Aug 2025 07:48:23 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
 <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>
Message-ID: <7IGhtSwHIBGIY1j6nJCm3Sjv6l28aHypbC98PwPL_Ak=.5d270255-7419-4754-9775-9fc546dae1e2@github.com>

On Wed, 6 Aug 2025 06:57:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If we don't adopt the enum I suggested, then I do prefer the naming of the condition through a variable. It gives you a hint of what the check is looking for, and not only what the check does.
>
> That is what comments are for.

I'd rather explain things with code than with comments when possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256207131

From vyazici at openjdk.org  Wed Aug  6 08:13:07 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 6 Aug 2025 08:13:07 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
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: <j53EBJNkfP7fTEwuhVT5nT1UiagA0vOUDy1O9RN63rA=.7f2aed05-dc64-4793-a935-5bcad028f8ef@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.

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

> 643:      * The inputReader and inputStream from the process are closed.
> 644:      * The errorReader and errorStream from the process are closed.
> 645:      * The process is destroyed.

Suggestion:

     * The {@code outputWriter} and {@code outputStream} to the process are closed.
     * The {@code inputReader} and {@code inputStream} from the process are closed.
     * The {@code errorReader} and {@code errorStream} from the process are closed.
     * The process is destroyed.
     *

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

> 655:         List<IOException> exceptions = closeable.stream()
> 656:                 .map(Process::doClose)
> 657:                 .filter((Objects::nonNull))

Suggestion:

                .filter(Objects::nonNull)

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

> 666:         // Wait briefly for process to exit, if not exited immediately, destroy
> 667:         try {
> 668:             boolean alive = waitFor(Duration.ofMillis(2000));

Doesn't this go against the `the process is terminated without waiting` statement in the spec?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2256282397
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2256290785
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2256295388

From vyazici at openjdk.org  Wed Aug  6 08:21:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 6 Aug 2025 08:21:03 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
In-Reply-To: <oBF3eUakXaGz_3DZr7vb2yxGb_20NP0XDt6_xUg7i6A=.e9ce0946-6aea-4a69-ab2a-680b390537ad@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
 <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>
 <oDlurhdPmv9Nn-VscSC1es7h7S542pL5jkixeBKRESs=.8f493b01-e7ce-4faa-84f4-058782cc6a64@github.com>
 <Hl0uh85aN1_VqbP1JqyGknImXh8BrXKEzmuU9q_zAQo=.656f22de-f153-4355-94c7-fcb6d78743d4@github.com>
 <oBF3eUakXaGz_3DZr7vb2yxGb_20NP0XDt6_xUg7i6A=.e9ce0946-6aea-4a69-ab2a-680b390537ad@github.com>
Message-ID: <nr4a4rc8qfi7uZEdhpoykBGoclUN9go3hkXeSuhphrs=.c2a7a38f-5c6f-4129-b3f3-09cfbb5bbf7e@github.com>

On Tue, 5 Aug 2025 21:45:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> I'm a bit dubious about the code above because it does not appear to fully handle the InterruptedException.
>> If it is really shutting down then its just complicit in leaving the application is an unpredictable and probably unrecoverable state.
>> 
>> Propagating the checked exception reduces the usability of close() to the point that I would remove the waitFor.
>> It annoying enough already that `waitFor` throws InterruptedException and you have to write more code and maybe a loop to handle that interruption and what it means to the caller.
>> I would leave up to the caller to handle that case.
>> When used with try-with-resources, the exception handling/re-throwing is complicated enough.
>
> You make some good points. Still, I think swallowing `InterruptException`'s in library code is generally considered to be wrong. According to _Java Concurrency in Practice_  ?7.1.3:
> 
>> If you don't want to or cannot propagate `InterruptedException`... you need to find another way to preserve the interruption request. The standard way to do this is to restore the interrupted status by calling interrupt again. What you should not do is swallow the `InterruptedException` by catching it and doing nothing in the catch block, unless your code is actually implementing the interruption policy for a thread.

Can we simply restore the interrupt after `destroy()`?


} catch (InterruptedException _) {
    try { destroy(); }
    finally { Thread.currentThread.interrupt(); }    // Restore the interrupt
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2256323353

From vyazici at openjdk.org  Wed Aug  6 08:33:07 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 6 Aug 2025 08:33:07 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
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: <WNHZ2FgMphSO_tqzWPjK12q11GVXkSvEJkVzvvJuHrc=.151370d2-f377-4b15-a210-b87214e312f9@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.

src/java.base/share/classes/java/lang/snippet-files/ProcessExamples.java line 38:

> 36:                 Paddling with the river flow;
> 37:                 Chilling still, go slow.
> 38:                 """;

Nit: I'm not against Haiku, though `writer.write("Hello, world!");` can be enough to get the message across and save the reader (and the maintainer) 6 LoC.

src/java.base/share/classes/java/lang/snippet-files/ProcessExamples.java line 48:

> 46:             // Read all lines and print each
> 47:             List<String> lines = reader.readAllLines();
> 48:             lines.forEach(System.err::println);

Simplification suggestion:

Suggestion:

            reader.readAllLines().forEach(System.err::println);


Note that this will render the `j.u.List` import at the top redundant too.

src/java.base/share/classes/java/lang/snippet-files/ProcessExamples.java line 51:

> 49:             var status = p.waitFor();
> 50:             if (status != 0)
> 51:                 throw new RuntimeException("process status: " + status);

Suggestion:

                throw new RuntimeException("unexpected process status: " + status);

src/java.base/share/classes/java/lang/snippet-files/ProcessExamples.java line 53:

> 51:                 throw new RuntimeException("process status: " + status);
> 52:         } catch (Throwable t) {
> 53:             System.out.println("Process failed: " + t);

Shall we instead catch `Exception` here? Quoting from Effective Java:

> Do not catch `Throwable`. It is wrong to catch `Throwable`: it includes errors (such as `OutOfMemoryError`, `StackOverflowError`, etc.) that are not meant to be caught by applications.

Suggestion:

        } catch (Exception e) {
            System.out.println("Process failed: " + e);

test/jdk/java/lang/Process/ProcessCloseTest.java line 47:

> 45:  * @bug 8336479
> 46:  * @summary Tests for Process.close
> 47:  * @library /test/lib

Unless I'm mistaken, there are no `/test/lib` dependencies:

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2256334744
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2256356929
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2256342566
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2256350644
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2256365508

From vyazici at openjdk.org  Wed Aug  6 08:38:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 6 Aug 2025 08:38:05 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
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: <8LbZVwbaDxQAv7SDyJJTZnnej9U9cGITcrsAGfn9_Xg=.5b31258a-df07-462c-8f96-23d4021b5f23@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.

Great initiative @RogerRiggs! ? I'm looking forward to respond dozens of StackOverflow questions asking how to close a `Process` properly! :star_struck:

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

PR Comment: https://git.openjdk.org/jdk/pull/26649#issuecomment-3158243897

From pminborg at openjdk.org  Wed Aug  6 08:55:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Aug 2025 08:55:08 GMT
Subject: Integrated: 8364540: Apply @Stable to Shared Secrets
In-Reply-To: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>
References: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>
Message-ID: <n64JGYjGqgIktGoqBdsIgZ5UmMq-SWziI6OJdeyVo_E=.70addb5e-8010-44c9-b700-7f450e3ec8ec@github.com>

On Mon, 4 Aug 2025 17:21:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to update the `SharedSecrets` class in `jdk.internal.access` to annotate all but one static field with the `@Stable` annotation.
> 
> The `@Stable` annotation was added to all static fields except for `javaAWTFontAccess`, which remains unannotated. This is because it can be set using several code paths.
> 
> No tests were changed or added, as this is an internal annotation adjustment with no expected behavioral impact.
> 
> This PR passes `tier1`, `tier2`, and `tier3` testing on multiple platforms.
> 
> In a future follow-up issue, we could identify fields in the implementations of the access classes that, in turn, are stable themselves. When this PR is integrated, it might be possible to remove local copies of access in classes to reduce bytecode size with little or no performance impact. Currently, we do not check the invariant, a field is set only once. This is yet another improvement proposal we could do -- maybe using Stable Values.

This pull request has now been integrated.

Changeset: 9dffbc9c
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9dffbc9c4cfee7a1f023d548c12194bcf60e4ffd
Stats:     33 lines in 1 file changed: 3 ins; 0 del; 30 mod

8364540: Apply @Stable to Shared Secrets

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Wed Aug  6 08:56:10 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 6 Aug 2025 08:56:10 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
 <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>
Message-ID: <HrW_NNP6Azyhislt7LUrESvN985o0vS9ro5OxlIxTvo=.cbefb39d-456b-4c5f-9442-ed824608ecb4@github.com>

On Wed, 6 Aug 2025 06:55:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> https://openjdk.org/jeps/492
>
> And now final - https://openjdk.org/jeps/513
> 
> Thanks

It?s?necessary to?do?this?before the?`this()`/`super()`?call, as?the?`Throwable(?)` constructors?call `this.fillInStackTrace()`:
https://github.com/openjdk/jdk/blob/e304d37996b075b8b2b44b5762d7d242169add49/src/java.base/share/classes/java/lang/Throwable.java#L263-L264

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256443245

From pminborg at openjdk.org  Wed Aug  6 09:00:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Aug 2025 09:00:11 GMT
Subject: RFR: 8362893: Improve performance for MemorySegment::getString
 [v2]
In-Reply-To: <T8sNkm9vcL9kWvFNVzyURvVNdHqwfQYe2-rjEQ-Rt1Q=.f0711da8-4c35-4d1e-aa35-a8f18cf79d44@github.com>
References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>
 <T8sNkm9vcL9kWvFNVzyURvVNdHqwfQYe2-rjEQ-Rt1Q=.f0711da8-4c35-4d1e-aa35-a8f18cf79d44@github.com>
Message-ID: <UAGNxsXNKNqw2q9cQqKyyznbCf6WFLZHSwfgOwo0bzk=.5d232b23-e83a-42bb-b561-a1c3d630db3f@github.com>

On Mon, 28 Jul 2025 17:10:13 GMT, Philippe Marschall <duke at openjdk.org> wrote:

>> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor.
>> 
>> Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me.
>> 
>> I ran the tier1 test suite and it passes.
>> 
>> For performance analysis I ran.
>> 
>>     make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc"
>> 
>> on an AMD Ryzen 7 PRO 5750GE.
>> 
>> These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation.
>> 
>> 
>> Benchmark                                              (size)  Mode  Cnt     Score    Error   Units
>> 
>> ToJavaStringTest.panama_readString                          5  avgt   30    18.996 ?  0.044   ns/op
>> ToJavaStringTest.panama_readString                          5  avgt   30    13.851 ?  0.028   ns/op
>> 
>> ToJavaStringTest.panama_readString                         20  avgt   30    23.570 ?  0.050   ns/op
>> ToJavaStringTest.panama_readString                         20  avgt   30    18.401 ?  0.069   ns/op
>> 
>> ToJavaStringTest.panama_readString                        100  avgt   30    32.094 ?  0.207   ns/op
>> ToJavaStringTest.panama_readString                        100  avgt   30    24.427 ?  0.112   ns/op
>> 
>> ToJavaStringTest.panama_readString                        200  avgt   30    43.029 ?  0.185   ns/op
>> ToJavaStringTest.panama_readString                        200  avgt   30    31.914 ?  0.064   ns/op
>> 
>> ToJavaStringTest.panama_readString                        451  avgt   30    81.145 ?  0.403   ns/op
>> ToJavaStringTest.panama_readString                        451  avgt   30    58.975 ?  0.233   ns/op
>> 
>> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    72.000 ?  0.001    B/op
>> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    48.000 ?  0.001    B/op
>> 
>> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30   104.000 ?  0.001    B/op
>> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30    64.000 ?  0.001    B/op
>> 
>> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   264.000 ?  0.001    B/op
>> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   144.000 ?  0.0...
>
> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

The changes look good to me. I'd like one additional review as I have been involved in the loop on this one.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26493#pullrequestreview-3091460493

From chagedorn at openjdk.org  Wed Aug  6 09:49:06 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 6 Aug 2025 09:49:06 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
Message-ID: <0PSLJlyGUw_lGVqliV6ABJrwoNa9TNcwVuv6flDyAV8=.1f0993be-f97f-4aea-b619-81a096076c3e@github.com>

On Tue, 5 Aug 2025 11:39:43 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
>> 
>> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
>> 
>> 
>> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
>> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
>> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
>> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
>> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
>> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
>> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
>> 
>> 
>> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
>> 
>> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.
>
> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check at the very least that auto vectorization is supported

Internal testing of the latest commit looked good (not a review).

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

PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3158174352

From galder at openjdk.org  Wed Aug  6 09:49:08 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 6 Aug 2025 09:49:08 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <mcYlVZnLh_y4PkzgmsCcerq7WcNCJRHB6VTPu5gKzww=.97654126-b27b-4289-bfa4-710b6bfda975@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <7UqSdBPWH0SbdkhAUvF_qM10rK0oFsJXhUKWA3VlL14=.0c35e297-7276-468b-98c6-046e84897625@github.com>
 <Wl68Jl6BnrU0rxhQ0yk6oGFgzq6dg2BVg90XqyGZTPs=.987a580b-8bdd-4a19-8aad-be7a7a95498a@github.com>
 <mcYlVZnLh_y4PkzgmsCcerq7WcNCJRHB6VTPu5gKzww=.97654126-b27b-4289-bfa4-710b6bfda975@github.com>
Message-ID: <lWLTvGRnXfvyY12TqsAVn684pmN-G_ohrGXCGIxdGu4=.a76d49df-83cc-4474-8dd1-4678ce27208a@github.com>

On Tue, 5 Aug 2025 06:32:23 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>>> VectorNode::is_reinterpret_opcode returns true for Op_ReinterpretHF2S and Op_ReinterpretS2HF, which are very similar to the nodes in this PR, can you add these nodes to that method instead?
>> 
>> You're suggesting to modify `is_reinterpret_opcode` to be like this, and call that instead of `is_move_opcode`, right?
>> 
>> 
>> bool VectorNode::is_reinterpret_opcode(int opc) {
>>   switch (opc) {
>>     case Op_ReinterpretHF2S:
>>     case Op_ReinterpretS2HF:
>>     case Op_MoveF2I:
>>     case Op_MoveD2L:
>>     case Op_MoveL2D:
>>     case Op_MoveI2F:
>>       return true;
>>     default:
>>       return false;
>>   }
>> }
>
>> You're suggesting to modify `is_reinterpret_opcode` to be like this, and call that instead of `is_move_opcode`, right?
> 
> Yes, that's right. I believe `VectorReinterpret` should be implemented for all pairs of vector species where both the input and output species are implemented. So, `VectorReinterpretNode::implemented` is unnecessary.

@merykitty thanks for the approval. I've run tier1-3 tests for 147633f and they all passed, and the benchmark results are the same as in the description.

Thanks @chhagedorn for running the tests!

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

PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3158785367

From duke at openjdk.org  Wed Aug  6 10:37:38 2025
From: duke at openjdk.org (Johny Jose)
Date: Wed, 6 Aug 2025 10:37:38 GMT
Subject: RFR: 7191877: TEST_BUG:
 java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing
 intermittently
Message-ID: <6-Ej6gQDcrnV_LOQaLRCxO08mUVbbX_ZGPahC_ntK2k=.6e97cf50-3fec-4e0e-a4a9-8cc84ad4fc91@github.com>

The test was problem listed since jdk8 as intermittent failures were observed. For all the failed scenarios, number of objects left in leaseTable were less than or equal to 4. Though for most of the runs the number of objects left is less than 2, at times the tests are failing when the remaining objects are 3 or 4 (observed only on mac os). As per the code, the leak should be fixed if the number of objects left in the table is less than 11. I have updated the acceptable number of objects to 4 from 2, and is still at lower end compared to 11.

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

Commit messages:
 - 7191877: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently

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

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

From erikj at openjdk.org  Wed Aug  6 12:25:05 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Aug 2025 12:25:05 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <gRqOTSGg7cHFNKd3Z-MacgeE52i09SZ7L3G28NyPSDY=.df63d950-f2f6-453f-b098-c0513750b298@github.com>

On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

Build changes look trivially good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26615#pullrequestreview-3092284286

From duke at openjdk.org  Wed Aug  6 12:37:34 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 6 Aug 2025 12:37:34 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v18]
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <uqpPLDqBOW-qI8Ej_iol2cHxy6HzpiMnez3CfHb2_SQ=.7e4a3915-3204-4723-aceb-1fdf3c79a9f5@github.com>

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Fixes subtle false-positive with paths like /modules/modules/...

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/2e78d0db..c31b87d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=16-17

  Stats: 24 lines in 1 file changed: 5 ins; 6 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/26054.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26054/head:pull/26054

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

From sroy at openjdk.org  Wed Aug  6 13:43:17 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 6 Aug 2025 13:43:17 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy 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 cpuprocessload
 - Merge branch 'master' into cpuprocessload
 - Update UnixOperatingSystem.c
 - Merge branch 'openjdk:master' into cpuprocessload
 - cleanup
 - system cpu load
 -  restore problem list
 - cpu process load

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

Changes: https://git.openjdk.org/jdk/pull/25332/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=02
  Stats: 79 lines in 2 files changed: 73 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332

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

From mbaesken at openjdk.org  Wed Aug  6 13:51:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Aug 2025 13:51:04 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
Message-ID: <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>

On Wed, 6 Aug 2025 13:43:17 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy 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 cpuprocessload
>  - Merge branch 'master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - cleanup
>  - system cpu load
>  -  restore problem list
>  - cpu process load

test/jdk/ProblemList.txt line 558:

> 556: 
> 557: 
> 558: com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java     8364314 generic-all

Wondering - why is that added ? Is it intended ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2257230418

From sroy at openjdk.org  Wed Aug  6 14:13:05 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 6 Aug 2025 14:13:05 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
 <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>
Message-ID: <3Vwjg-ioaRzQHhcP2VoZTnDl9SSLk2BLlsoJ22Gia44=.5222663d-8705-47cc-a060-2b57f92f119a@github.com>

On Wed, 6 Aug 2025 13:48:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Suchismith Roy 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 cpuprocessload
>>  - Merge branch 'master' into cpuprocessload
>>  - Update UnixOperatingSystem.c
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - cleanup
>>  - system cpu load
>>  -  restore problem list
>>  - cpu process load
>
> test/jdk/ProblemList.txt line 558:
> 
>> 556: 
>> 557: 
>> 558: com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java     8364314 generic-all
> 
> Wondering - why is that added ? Is it intended ?

@MBaesken it was part of master branch. shall I remove it ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2257317031

From mbaesken at openjdk.org  Wed Aug  6 14:17:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Aug 2025 14:17:04 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <3Vwjg-ioaRzQHhcP2VoZTnDl9SSLk2BLlsoJ22Gia44=.5222663d-8705-47cc-a060-2b57f92f119a@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
 <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>
 <3Vwjg-ioaRzQHhcP2VoZTnDl9SSLk2BLlsoJ22Gia44=.5222663d-8705-47cc-a060-2b57f92f119a@github.com>
Message-ID: <t9JTli2Hboqs_ee-wUgti4h-Z5ofL2XjogYAmkr8FPs=.eb1845c7-e743-49a0-8002-82ab7d63bb50@github.com>

On Wed, 6 Aug 2025 14:10:44 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 558:
>> 
>>> 556: 
>>> 557: 
>>> 558: com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java     8364314 generic-all
>> 
>> Wondering - why is that added ? Is it intended ?
>
> @MBaesken it was part of master branch. shall I remove it ?

Did not expect this in your PR .
Bit unsure why it is there.

It is not here https://github.com/openjdk/jdk/blob/master/test/jdk/ProblemList.txt  so  why is it needed in your PR ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2257330020

From rriggs at openjdk.org  Wed Aug  6 14:20:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Aug 2025 14:20:04 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <wKIBeQ_VaoW_m2xBHhSmmXAAlQI31sgsyOcJIQxOuL4=.8d534cea-484f-4ceb-bb55-bc66e84a0fa5@github.com>

On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

src/java.base/unix/native/libjava/childproc.c line 429:

> 427:     }
> 428: 
> 429:     // Childs should be started with default signal disposition for SIGPIPE

Editorial: "Childs" -> Children for plural, "Child" for singular.  Here and in tests.

test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c line 60:

> 58:         struct sigaction act;
> 59:         if (sigaction(signals[n].sig, NULL, &act) != 0) {
> 60:             perror("sigaction");

The sigaction error message goes to stderr, so it is does not appear in line with the signal name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2257297399
PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2257335209

From acobbs at openjdk.org  Wed Aug  6 14:43:03 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 6 Aug 2025 14:43:03 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
In-Reply-To: <nr4a4rc8qfi7uZEdhpoykBGoclUN9go3hkXeSuhphrs=.c2a7a38f-5c6f-4129-b3f3-09cfbb5bbf7e@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
 <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>
 <oDlurhdPmv9Nn-VscSC1es7h7S542pL5jkixeBKRESs=.8f493b01-e7ce-4faa-84f4-058782cc6a64@github.com>
 <Hl0uh85aN1_VqbP1JqyGknImXh8BrXKEzmuU9q_zAQo=.656f22de-f153-4355-94c7-fcb6d78743d4@github.com>
 <oBF3eUakXaGz_3DZr7vb2yxGb_20NP0XDt6_xUg7i6A=.e9ce0946-6aea-4a69-ab2a-680b390537ad@github.com>
 <nr4a4rc8qfi7uZEdhpoykBGoclUN9go3hkXeSuhphrs=.c2a7a38f-5c6f-4129-b3f3-09cfbb5bbf7e@github.com>
Message-ID: <ZSI1AO4cd-yhU7awvJISkH1LUyPzqOeWW1dD9W7tzu8=.d6c2c355-a80f-49a1-9f73-d5d1baf6fb8c@github.com>

On Wed, 6 Aug 2025 08:18:03 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Can we simply restore the interrupt after destroy()?

That's the suggestion... but now I'm thinking the correct solution?here is to just have `close()` declared to throw `InterruptedException` and not catch anything. Then we are leaving it up to the caller to decide what to do, rather than being forced to make an assumption one way or another.

In practice, there seem to be two typical scenarios when shutting things down using methods that block and throw `InterruptedException` (e.g., `ExecutorService.html.awaitTermination()`, `Process.waitFor()`, etc.):

Scenario 1: You want to ensure everything is properly and completely shutdown.

In this scenario you ignore `InterruptedException`s until each shutdown step fully completes: if any step throws an `InterruptedException`, you make a note of it, loop back around and restart that step. You don't return until all steps are complete. Just before returning, if you were interrupted at any point, you re-interrupt the current thread so the interrupt is not lost. You are optimizing for completeness.

Scenario 2: You want to start shutting things down, but if you are interrupted, you want to immediately bail out.

As soon as an interrupt occurs, stop trying to shut things down and return. You are optimizing for speed.

The problem is that if `Process.close()` isn't declared to throw `InterruptedException`, then that makes it impossible to implement scenario 1 (regardless of whether you re-interrupt the thread) because the caller has no way of knowing whether the process actually did terminate. And if you don't re-interrupt the thread, you also make it impossible to implement scenario 2.

So in my estimation re-interrupting the thread is better than not re-interrupting the thread, but regardless of that, there is still a problem if `Process.close()` isn't declared to throw `InterruptedException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2257418786

From rriggs at openjdk.org  Wed Aug  6 14:43:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Aug 2025 14:43:05 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
In-Reply-To: <WNHZ2FgMphSO_tqzWPjK12q11GVXkSvEJkVzvvJuHrc=.151370d2-f377-4b15-a210-b87214e312f9@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <WNHZ2FgMphSO_tqzWPjK12q11GVXkSvEJkVzvvJuHrc=.151370d2-f377-4b15-a210-b87214e312f9@github.com>
Message-ID: <QelCKJgXgyfSZzUSdImiw9U6Dw6u7Q3L2JASq9jk7NA=.658099cc-b758-42ed-8ae8-cd0145add372@github.com>

On Wed, 6 Aug 2025 08:21:13 GMT, Volkan Yazici <vyazici 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.
>
> src/java.base/share/classes/java/lang/snippet-files/ProcessExamples.java line 38:
> 
>> 36:                 Paddling with the river flow;
>> 37:                 Chilling still, go slow.
>> 38:                 """;
> 
> Nit: I'm not against Haiku, though `writer.write("Hello, world!");` can be enough to get the message across and save the reader (and the maintainer) 6 LoC.

True, maybe too clever, but It should be more than 1 line. Hello world can be quite boring after 30 years.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2257423663

From sroy at openjdk.org  Wed Aug  6 15:08:18 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 6 Aug 2025 15:08:18 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v3]
In-Reply-To: <t9JTli2Hboqs_ee-wUgti4h-Z5ofL2XjogYAmkr8FPs=.eb1845c7-e743-49a0-8002-82ab7d63bb50@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <MwNZYWo3EJqcvO8_Zw2NI1xpXw0i4gQZaA1RIqkY_1I=.c4101671-23d0-4d05-9b7e-2aed20c766b5@github.com>
 <vhGIQaSa5NVpATx4FZLCVkC6UbRZrWOyTydhV4r67bE=.0faae477-b911-4749-96d5-556d1aa91276@github.com>
 <3Vwjg-ioaRzQHhcP2VoZTnDl9SSLk2BLlsoJ22Gia44=.5222663d-8705-47cc-a060-2b57f92f119a@github.com>
 <t9JTli2Hboqs_ee-wUgti4h-Z5ofL2XjogYAmkr8FPs=.eb1845c7-e743-49a0-8002-82ab7d63bb50@github.com>
Message-ID: <z6jl1VCywh4C1W_6JPu9leQ5WuTgOK5koOWggNP0jSA=.f308ab3c-b480-45cd-98ca-42abe4fb7398@github.com>

On Wed, 6 Aug 2025 14:14:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> @MBaesken it was part of master branch. shall I remove it ?
>
> Did not expect this in your PR .
> Bit unsure why it is there.
> 
> It is not here https://github.com/openjdk/jdk/blob/master/test/jdk/ProblemList.txt  so  why is it needed in your PR ?

@MBaesken  Not sure. It was showing as a conflict due a change from master, so I thought to keep it. Will remove it then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2257492886

From sroy at openjdk.org  Wed Aug  6 15:08:18 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 6 Aug 2025 15:08:18 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v4]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <_h4TBkuFudR5wTGue1oEaeqlZcPZfPnJcWmFdWboZfM=.5676751b-ad3b-4b37-9822-b17464c093dc@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Update ProblemList.txt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25332/files
  - new: https://git.openjdk.org/jdk/pull/25332/files/80a6dba6..e4c076f7

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

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

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

From rriggs at openjdk.org  Wed Aug  6 15:44:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Aug 2025 15:44:05 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
In-Reply-To: <j53EBJNkfP7fTEwuhVT5nT1UiagA0vOUDy1O9RN63rA=.7f2aed05-dc64-4793-a935-5bcad028f8ef@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <j53EBJNkfP7fTEwuhVT5nT1UiagA0vOUDy1O9RN63rA=.7f2aed05-dc64-4793-a935-5bcad028f8ef@github.com>
Message-ID: <dM1b7EXwcgPmYQblbEs8VZo8gfb2KVaa-MU1vzngknY=.1e1279d8-3146-4307-8c31-ffe0f5e861f1@github.com>

On Wed, 6 Aug 2025 08:09:56 GMT, Volkan Yazici <vyazici 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.
>
> src/java.base/share/classes/java/lang/Process.java line 668:
> 
>> 666:         // Wait briefly for process to exit, if not exited immediately, destroy
>> 667:         try {
>> 668:             boolean alive = waitFor(Duration.ofMillis(2000));
> 
> Doesn't this go against the `the process is terminated without waiting` statement in the spec?

The spec and the implementation were from different trains of thought at different times and are inconsistent.
The spec says no waiting; the implementation of the waitFor mixes in both some delay and the complexity associated with interrupts. The delay may not be long enough for a particular platform or application to achieve its attempt at being nice and is fragile. The fragility introduced is not worth the minimal benefit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2257594766

From rriggs at openjdk.org  Wed Aug  6 15:49:18 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Aug 2025 15:49:18 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable
In-Reply-To: <ZSI1AO4cd-yhU7awvJISkH1LUyPzqOeWW1dD9W7tzu8=.d6c2c355-a80f-49a1-9f73-d5d1baf6fb8c@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
 <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>
 <oDlurhdPmv9Nn-VscSC1es7h7S542pL5jkixeBKRESs=.8f493b01-e7ce-4faa-84f4-058782cc6a64@github.com>
 <Hl0uh85aN1_VqbP1JqyGknImXh8BrXKEzmuU9q_zAQo=.656f22de-f153-4355-94c7-fcb6d78743d4@github.com>
 <oBF3eUakXaGz_3DZr7vb2yxGb_20NP0XDt6_xUg7i6A=.e9ce0946-6aea-4a69-ab2a-680b390537ad@github.com>
 <nr4a4rc8qfi7uZEdhpoykBGoclUN9go3hkXeSuhphrs=.c2a7a38f-5c6f-4129-b3f3-09cfbb5bbf7e@github.com>
 <ZSI1AO4cd-yhU7awvJISkH1LUyPzqOeWW1dD9W7tzu8=.d6c2c355-a80f-49a1-9f73-d5d1baf6fb8c@github.com>
Message-ID: <DY_N79zvVkePBetjJavDmxf0L3tarChBP1wZY-DuwfM=.8ff571d9-af2d-41a8-a0ee-554e4868b1cb@github.com>

On Wed, 6 Aug 2025 14:38:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Can we simply restore the interrupt after `destroy()`?
>> 
>> 
>> } catch (InterruptedException _) {
>>     try { destroy(); }
>>     finally { Thread.currentThread.interrupt(); }    // Restore the interrupt
>> }
>
>> Can we simply restore the interrupt after destroy()?
> 
> That's the suggestion... but now I'm thinking the correct solution?here is to just have `close()` declared to throw `InterruptedException` and not catch anything. Then we are leaving it up to the caller to decide what to do, rather than being forced to make an assumption one way or another.
> 
> In practice, there seem to be two typical scenarios when shutting things down using methods that block and throw `InterruptedException` (e.g., `ExecutorService.html.awaitTermination()`, `Process.waitFor()`, etc.):
> 
> Scenario 1: You want to ensure everything is properly and completely shutdown.
> 
> In this scenario you ignore `InterruptedException`s until each shutdown step fully completes: if any step throws an `InterruptedException`, you make a note of it, loop back around and restart that step. You don't return until all steps are complete. Just before returning, if you were interrupted at any point, you re-interrupt the current thread so the interrupt is not lost. You are optimizing for completeness.
> 
> Scenario 2: You want to start shutting things down, but if you are interrupted, you want to immediately bail out.
> 
> As soon as an interrupt occurs, stop trying to shut things down and return. You are optimizing for speed.
> 
> The problem is that if `Process.close()` isn't declared to throw `InterruptedException`, then that makes it impossible to implement scenario 1 (regardless of whether you re-interrupt the thread) because the caller has no way of knowing whether the process actually did terminate. And if you don't re-interrupt the thread, you also make it impossible to implement scenario 2.
> 
> So in my estimation re-interrupting the thread is better than not re-interrupting the thread, but regardless of that, there is still a problem if `Process.close()` isn't declared to throw `InterruptedException`.

Indeed, the benefit of the attempt to be nice and not destroy the process too quickly is almost immediately overcome by the complexity of dealing with the side effects of the waitFor and the necessity to deal with interrupts both in the implementation and in the caller. Especially in an attempt to do something that the caller can do for themselves (calling waitFor).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2257605317

From pminborg at openjdk.org  Wed Aug  6 16:22:30 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Aug 2025 16:22:30 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v15]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <MLmlN6jd0DCsFXkbIKGpXaiBf-9oiesu1DxoXo7Whsg=.aa43a933-ee9b-4174-8882-1150893b873a@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:

 - Merge branch 'master' into fill-overlap
 - Fix inverted logic error
 - Revert the default value for the fill threshold
 - Revert the settable fill threshold
 - Improve performance
 - Merge branch 'master' into fill-overlap
 - Use Unsafe directly in benchmarks
 - Merge branch 'master' into fill-overlap
 - Use a fixed threashold for fill
 - Fix benchmark
 - ... and 8 more: https://git.openjdk.org/jdk/compare/8c025250...bbf08938

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/1f454706..bbf08938

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

  Stats: 3011 lines in 94 files changed: 1426 ins; 1332 del; 253 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

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

From bpb at openjdk.org  Wed Aug  6 17:39:25 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Aug 2025 17:39:25 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v4]
In-Reply-To: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
Message-ID: <-brKvHWh2bXqcbEOObF6pI7lZaS6P19CnWXppe4xt84=.4627fb30-7a31-45ed-b04e-a72fb2d2c7d0@github.com>

> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.

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

  8364277: 1) improve isDirectory[Junction] per Reviewer comments; 2) restructure native test code to remove the dreaded gotos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26631/files
  - new: https://git.openjdk.org/jdk/pull/26631/files/ebd6f415..481bdbcc

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

  Stats: 100 lines in 3 files changed: 31 ins; 35 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/26631.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26631/head:pull/26631

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

From bpb at openjdk.org  Wed Aug  6 17:39:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Aug 2025 17:39:27 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v3]
In-Reply-To: <CA0750_pTQnBHm2tS91wGnyGyR8RfikoNfLaSrmKDUQ=.76279ed2-c813-43d7-afae-866b81673069@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <boJq_ZpX00rKbmQ6KqCtwQXMEsrJBcjy7jviAQfyKNo=.b37daa06-4ba6-44ab-bd9c-d828e608ef14@github.com>
 <CA0750_pTQnBHm2tS91wGnyGyR8RfikoNfLaSrmKDUQ=.76279ed2-c813-43d7-afae-866b81673069@github.com>
Message-ID: <0C-F2471I42736TtBGckvNQ_C6pv3urTQTLQ-4zcIbk=.8ff4af39-4d0d-41c5-8cb2-b857f9a98d3c@github.com>

On Wed, 6 Aug 2025 06:01:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364277: Clean up per reviewer comments
>
> src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 419:
> 
>> 417:             return false;
>> 418:         return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 &&
>> 419:                 (fileAttrs & FILE_ATTRIBUTE_REPARSE_POINT) != 0);
> 
> Should this just check if reparseTag has the value IO_REPARSE_TAG_MOUNT_POINT?

So changed in 481bdbc.

> src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 436:
> 
>> 434:         if (isSymbolicLink())
>> 435:             return false;
>> 436:         return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 &&
> 
> I assume it means that isDirectory no longer needs to use isSymbolicLink as the change means it will return false for all files that are reparse points.

So changed in 481bdbc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2257849276
PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2257849755

From bpb at openjdk.org  Wed Aug  6 17:39:28 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Aug 2025 17:39:28 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v2]
In-Reply-To: <LhyoKYnBNLqNV0xqUQsnDkd9tQ8GP8jmMf3Iz16gKjs=.61878817-be46-44d8-ab61-2d25db1bf3cd@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <ojaIBZ8wV5HZpo9FodSpPMLNLtBl4-l6M5jjFeKo9lw=.fefa3838-93ab-4b35-892a-ad4d76680c76@github.com>
 <RKfAa4LBqcf24RdbU62lU2DsY-WIR4bdX2jcP-pBfwI=.b5b5ab16-d660-4c37-bda9-b45aa01fa8ac@github.com>
 <LhyoKYnBNLqNV0xqUQsnDkd9tQ8GP8jmMf3Iz16gKjs=.61878817-be46-44d8-ab61-2d25db1bf3cd@github.com>
Message-ID: <jnERsA4ZVXQb0e_YnsOlPzX5kXYrf_lOIXXAR8kr1Mg=.34c7f453-cecd-49d7-ae1b-e1e50795cbd1@github.com>

On Wed, 6 Aug 2025 01:14:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/libFileUtils.c line 167:
>> 
>>> 165:     lpInBuffer = NULL;
>>> 166: 
>>> 167:     if (result == 0) {
>> 
>> Suggestion: Would it be possible to avoid the dreaded goto
>> 
>> if ((result != 0) && (CloseHandle(hJunction) != 0)) {
>>     return JNI_TRUE;
>> }
>> ...do error handling...
>
>> Would it be possible to avoid the dreaded goto
> 
> I expect so, with some careful editing.

`goto`s removed in 481bdbc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2257848055

From cushon at openjdk.org  Wed Aug  6 17:49:26 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 6 Aug 2025 17:49:26 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <gDgAzVOWllN9McWLxfco_q2EfeioJS8IcZL5zkHDBjY=.21f01a62-6a26-4412-9dba-258f600bc5fc@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
 <gDgAzVOWllN9McWLxfco_q2EfeioJS8IcZL5zkHDBjY=.21f01a62-6a26-4412-9dba-258f600bc5fc@github.com>
Message-ID: <ynnV8JLgrimNvVvVKrLBc-_ICd3K9fR_y7fORH5brA4=.9ad760b7-afe8-4570-ac67-8a048da03522@github.com>

On Thu, 17 Jul 2025 15:23:10 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add @Override for clean() method
>>  - more commentary for reserveMemory
>
> src/java.base/share/classes/java/nio/BufferCleaner.java line 203:
> 
>> 201:     }
>> 202: 
>> 203:     private static final class CleaningThread extends Thread {
> 
> Similar to https://bugs.openjdk.org/browse/JDK-8346124, should this be creating an `InnocuousThread`?

I filed https://bugs.openjdk.org/browse/JDK-8364954

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2257877328

From alanb at openjdk.org  Wed Aug  6 18:32:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Aug 2025 18:32:17 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v3]
In-Reply-To: <0C-F2471I42736TtBGckvNQ_C6pv3urTQTLQ-4zcIbk=.8ff4af39-4d0d-41c5-8cb2-b857f9a98d3c@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <boJq_ZpX00rKbmQ6KqCtwQXMEsrJBcjy7jviAQfyKNo=.b37daa06-4ba6-44ab-bd9c-d828e608ef14@github.com>
 <CA0750_pTQnBHm2tS91wGnyGyR8RfikoNfLaSrmKDUQ=.76279ed2-c813-43d7-afae-866b81673069@github.com>
 <0C-F2471I42736TtBGckvNQ_C6pv3urTQTLQ-4zcIbk=.8ff4af39-4d0d-41c5-8cb2-b857f9a98d3c@github.com>
Message-ID: <58J2J4rqzVd5wTpMm7cf16SuQBGu0AtSoTRzoOMdyo0=.551b985d-5ef3-4945-85dd-9660103f90a1@github.com>

On Wed, 6 Aug 2025 17:34:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 419:
>> 
>>> 417:             return false;
>>> 418:         return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 &&
>>> 419:                 (fileAttrs & FILE_ATTRIBUTE_REPARSE_POINT) != 0);
>> 
>> Should this just check if reparseTag has the value IO_REPARSE_TAG_MOUNT_POINT?
>
> So changed in 481bdbc.

Thanks for these updates, the src changes look good now. I haven't looked at the test updates yet, will try to get to this soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2257960839

From rriggs at openjdk.org  Wed Aug  6 18:52:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Aug 2025 18:52:16 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
Message-ID: <0_Cs4qRmBwmfZE8qrUNZaRCtUfWqarRBdrzZjGEZvLM=.9a0b66f9-9a12-4296-9c90-304080e72886@github.com>

On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update NPE per roger review

A hotspot and 2 core-libs reviewers should have a chance to comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3161228199

From rriggs at openjdk.org  Wed Aug  6 18:52:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Aug 2025 18:52:17 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <pOYre3BM8bk2MGRLph2dEW0u8XSC1BVM3_PaMBywEZY=.d893ba55-1f8c-4f50-9123-96200cb33367@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
 <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>
 <pEd2HoPSaXF2YFTsfN9OdGy5AbFo2pVPblVzqDCDeL0=.df678328-6541-4ffc-b1f2-becedb965351@github.com>
 <pOYre3BM8bk2MGRLph2dEW0u8XSC1BVM3_PaMBywEZY=.d893ba55-1f8c-4f50-9123-96200cb33367@github.com>
Message-ID: <QoxZIbp0af4jJQThb2DXF42UnDjGi8raPFnr4jcCZjw=.d9184e90-4c44-4dc0-9307-12e3cec7220a@github.com>

On Tue, 5 Aug 2025 15:01:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Don't add APIs without uses; it speculative and the API may not be what is really needed.
>
> Should I open a dependent PR to prove that this is exactly what we need to unblock [Objects::requireNonNull message enhancements](https://bugs.openjdk.org/browse/JDK-8233268)?

Please update the description to note this is a pre-requsite for:
[JDK-8233268](https://bugs.openjdk.org/browse/JDK-8233268) Improve integration of Objects.requireNonNull and JEP 358 Helpful NPE

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2257996201

From naoto at openjdk.org  Wed Aug  6 19:02:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Aug 2025 19:02:52 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v9]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <VrFo_KT8vWATMfgnDkT3MU3BGPyBW1oCHbBoTRSVRI4=.2d313175-1e85-48b4-84ae-37a605db0643@github.com>

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

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

  Update make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java
  
  Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/b9b0820f..e0fb990a

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

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

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

From jlu at openjdk.org  Wed Aug  6 19:02:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 6 Aug 2025 19:02:52 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v8]
In-Reply-To: <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
Message-ID: <XAq82lnY12Fn2AANZ-PCYQ_c-omZCJAunJOlWlYmINw=.4fcbd21e-5965-4b1c-9870-ea76944b3921@github.com>

On Tue, 5 Aug 2025 22:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refining docs

src/java.base/share/classes/java/text/DecimalFormat.java line 310:

> 308:  * minimal digits, and other characteristics are all the same as the positive
> 309:  * pattern. That means that {@code "#,##0.0#;(#)"} produces precisely
> 310:  * the same behavior as {@code "#,##0.0#;(#,##0.0#)"}. In

I think it is appropriate to have this here since it regards the negative sub pattern. However, we should either  link to this info or add additional info in the parse method. (Since the `parse` method covers behavior when strict/lenient.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2258014200

From jlu at openjdk.org  Wed Aug  6 19:02:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 6 Aug 2025 19:02:53 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v7]
In-Reply-To: <akqzBE4RPlOWiNXxFB1uksD4hPhVS5yxZUJMsgGYnzs=.c7d67a06-0d44-4a27-ac7e-fcd073247e37@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <akqzBE4RPlOWiNXxFB1uksD4hPhVS5yxZUJMsgGYnzs=.c7d67a06-0d44-4a27-ac7e-fcd073247e37@github.com>
Message-ID: <8FTrupvQ067NOi7acXu_eYHTdGc930zdDzjJWnxtZiQ=.d93cfca8-ba0e-41ac-8385-f57d58c8bcbb@github.com>

On Tue, 5 Aug 2025 22:51:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 852:
>> 
>>> 850: 
>>> 851:         // Lenient minus signs
>>> 852:         lenientMinusSigns = numberElements.length < 14 ? minusSignText : numberElements[13];
>> 
>> BTW, if I remove this check and always assign to `numberElements[13]`, I do not observe any failures in the java_text/Format suite. It would be nice to have an idea of why this check is needed. (I understand it is following the same length checks of monetarySeparator and monetaryGroupingSeparator.)
>
> The FALLBACK locale provider does not provide those elements, so the check is needed. Some tests in java/sun.util tests that specify HOST provider would fail without it.

I did not check that test suite, thanks that's good to know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2258008674

From eirbjo at openjdk.org  Wed Aug  6 19:52:15 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 6 Aug 2025 19:52:15 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v9]
In-Reply-To: <VrFo_KT8vWATMfgnDkT3MU3BGPyBW1oCHbBoTRSVRI4=.2d313175-1e85-48b4-84ae-37a605db0643@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <VrFo_KT8vWATMfgnDkT3MU3BGPyBW1oCHbBoTRSVRI4=.2d313175-1e85-48b4-84ae-37a605db0643@github.com>
Message-ID: <0PRHJpzfsYxyE4aCPtGe36MbjfSc0R8OgibILfaawJ4=.331c60ef-1a9a-460f-a5b8-c5ca700de7cb@github.com>

On Wed, 6 Aug 2025 19:02:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

Nit: Maybe using ?lenient? instead of ?loose? in the JBS/PR title would provide a more precise, correct and searchable description of the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/26580#issuecomment-3161391423

From bpb at openjdk.org  Wed Aug  6 19:59:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Aug 2025 19:59:53 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v5]
In-Reply-To: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
Message-ID: <0_fTcRHQzc6aQs3Y_9iO__ygAcdP97VNH3eOVCMi_V8=.26d9cdbf-9fa5-487a-85de-03a15742d202@github.com>

> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.

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

  8364277: Ignore restricted warning building BUILD_TEST_LIB_JAR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26631/files
  - new: https://git.openjdk.org/jdk/pull/26631/files/481bdbcc..60f5315b

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

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

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

From naoto at openjdk.org  Wed Aug  6 20:24:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Aug 2025 20:24:32 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v10]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <fL10ZLA1KeHGufyjiTHLLC9HBCNzWEGFeXbv0klsLW8=.d9136fb0-a20e-41f3-a985-56aea04d19cc@github.com>

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

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

  Added description in `parse()`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/e0fb990a..a0c4b9cd

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

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

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

From naoto at openjdk.org  Wed Aug  6 20:28:21 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Aug 2025 20:28:21 GMT
Subject: RFR: 8363972: Lenient parsing of minus sign pattern in
 DecimalFormat/CompactNumberFormat [v8]
In-Reply-To: <XAq82lnY12Fn2AANZ-PCYQ_c-omZCJAunJOlWlYmINw=.4fcbd21e-5965-4b1c-9870-ea76944b3921@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
 <XAq82lnY12Fn2AANZ-PCYQ_c-omZCJAunJOlWlYmINw=.4fcbd21e-5965-4b1c-9870-ea76944b3921@github.com>
Message-ID: <xXwKPIJYe-BK7cir9kEnQW2mCccW8kTcUHz61Gk1FXs=.65c329f1-8203-4061-a2f7-83d4c8817d58@github.com>

On Wed, 6 Aug 2025 18:56:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refining docs
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 310:
> 
>> 308:  * minimal digits, and other characteristics are all the same as the positive
>> 309:  * pattern. That means that {@code "#,##0.0#;(#)"} produces precisely
>> 310:  * the same behavior as {@code "#,##0.0#;(#,##0.0#)"}. In
> 
> I think it is appropriate to have this here since it regards the negative sub pattern. However, we should either  link to this info or add additional info in the parse method. (Since the `parse` method covers behavior when strict/lenient.)

Since the leniency relates to not only `parse()` but also `is/setStrict()` methods, I wanted to consolidate the minus sign leniency in the class descrption. But yes describing it additionally in `parse()` would not hurt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2258215992

From duke at openjdk.org  Wed Aug  6 20:28:25 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 6 Aug 2025 20:28:25 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <U5RvuCphGAlVfxyUmcSZFtm-dm9PudIfA7--HMmSSOU=.e6eab399-8ee1-43e9-895d-ab0b9de66229@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
 <ogI0LDJwH7ochb54mGArTep8RqX0lnDPrffe9vFaHx4=.4c6560aa-583e-4679-9fdb-228a76198723@github.com>
 <BgPpj2f046zCLPM-I54DXWaQFa--XK0sb5HCrDsLuIc=.f548c27d-9fd1-41a4-a204-9e56ddc3b5d3@github.com>
 <E1vsxqCnRs23ckizuiD3OMGnjKC1BBn1HM4PzmWZbQ0=.de3a2a6a-c63c-44c6-8a2b-13d28224aa6f@github.com>
 <U5RvuCphGAlVfxyUmcSZFtm-dm9PudIfA7--HMmSSOU=.e6eab399-8ee1-43e9-895d-ab0b9de66229@github.com>
Message-ID: <cQ0ecsPGONSm4jP9xyNI2E02Xd04Ud7xOqq_EU1VAxo=.83e5bcc0-4abc-4072-9c30-7a5f45adb414@github.com>

On Fri, 1 Aug 2025 13:36:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> "is completed" is a non-directory type, "getLocation() failing" is a non-resource type. The abstract class is consistently saying "I'm not a thing of /that/ type" (because it isn't and these are the only answers it can give).
>> I don't think there's *any* risk or issue here. The abstract class is internal, clearly documented and overloaded exactly once by a trusted collaborator. Do you really think this is a "risk"? And if you do, please give your suggestion as to what would be better. Otherwise nothing is actionable here.
>
>> "is completed" is a non-directory type, "getLocation() failing" is a non-resource type.
> 
> If getLocation() by default throws a `IllegalStateException` stating that the `Node` is not a resource type, then I think it would be more accurate for `isCompleted()` to by default return `false` to match the claim that the `Node` is not a resource type.

Hmm, I see the argument, but then I have to make two additional overrides to make it return true in the cases where it's always, unconditionally, true. I don't like adding more code for no functional improvement though.

Remember that (unlike the current code) this change removes "isCompleted()" as a visible method, so it's only usable internally and cannot be used in unexpected ways. Outside of asserts, it's now called exactly once, so it's not hard to reason about it, however it's implemented.

I mean I could remove it from Node and only have it as a Directory method and use instanceof and a cast before calling it ... but it's more code in the actual business logic and doesn't achieve anything because the chance of misuse is zero, since everything would break if it was somehow used incorrectly.

Basically isComplete() == false => it's a directory that need its children populated.
So, I could flip the return value and name is "isIncompleteDirectory()" which is more precise (an "uglier" name draws attention to the fact it captures something about the special case nature of directories).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2258215768

From asemenyuk at openjdk.org  Wed Aug  6 22:00:41 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 6 Aug 2025 22:00:41 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test [v6]
In-Reply-To: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
Message-ID: <_FoTDBheh_MjVbNrKJEpOA5kOHaJjjVqSVjNHTjGkF8=.5ecc0ac8-6c17-4a93-a0e9-98e31f71be1a@github.com>

> - Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
> - Test shortcuts in the predefined app image.
> 
> Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.
> 
> Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.
> 
> Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.
> 
> Not directly related to the subject of the PR:
>  - JPackageCommand: Added missing and removed redundant `verifyMutable()` calls. Converted "jpt-unpacked-folder" option into the member field. Added `JPackageCommand.createMutableCopy()` complementary to the existing `JPackageCommand.createImmutableCopy()`.
>  - Refactor `TKit.waitForFileCreated()` to use classes from the `java.time` package.
>  - Added `test/jdk/tools/jpackage/clean_test_output.sh` Bash script filtering test logs to minimize noise in diffs.
> 
> Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 81 additional commits since the last revision:

 - TKit: bugfix
 - Merge branch 'master' into JDK-8334238
 - Merge branch 'JDK-8334238' of https://github.com/alexeysemenyukoracle/jdk into JDK-8334238
 - Use TKit.waitForFileCreated() to await for test output file
 - Use java.time.Duration and java.time.Instant in TKit.waitForFileCreated(). Make it public.
 - LauncherShortcut: add appImageFilePropertyName()
 - JPackageCommand: verify names of additional launcher are precisely recorded in .jpackage.xml file
 - JPackageCommand: remove path to the unpacked directory from the argument list as it interferes with extracting arguments with optional values.
 - clean_test_output.sh: better
 - AddLShortcutTest: make it a better fit for JDK-8308349
 - ... and 71 more: https://git.openjdk.org/jdk/compare/d8ceceb8...2d31e6a5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26584/files
  - new: https://git.openjdk.org/jdk/pull/26584/files/a95677ff..2d31e6a5

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

  Stats: 50369 lines in 1274 files changed: 29654 ins; 15371 del; 5344 mod
  Patch: https://git.openjdk.org/jdk/pull/26584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26584/head:pull/26584

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

From asemenyuk at openjdk.org  Wed Aug  6 22:00:41 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 6 Aug 2025 22:00:41 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test [v5]
In-Reply-To: <j9qVnYJX9z3HEsT6RLeu-fwa0KPzqnzzYyWjWKPHSL0=.83b987e0-c7b7-477d-8bbc-1c41ebe330d8@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
 <VYPyMj3UEHduM_UuuhPJ4O8juiCWKs0JUWsKMYQDBbE=.a2b454a0-aff4-4251-b4ec-362ccb1f263a@github.com>
 <j9qVnYJX9z3HEsT6RLeu-fwa0KPzqnzzYyWjWKPHSL0=.83b987e0-c7b7-477d-8bbc-1c41ebe330d8@github.com>
Message-ID: <sjsv6K5ABLKkiHJid2vO-Q4UGHFkGk3xfU97y1xCCPo=.3ee7f838-8ca0-41cb-bd7e-ff2e9f23263f@github.com>

On Wed, 6 Aug 2025 01:38:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use TKit.waitForFileCreated() to await for test output file
>>  - Use java.time.Duration and java.time.Instant in TKit.waitForFileCreated(). Make it public.
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 635:
> 
>> 633:                     return;
>> 634:                 }
>> 635:                 assertUnexpected(String.format("Timeout expired", remainderTimeout));
> 
> `"Timeout expired"` missing format?

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26584#discussion_r2258401566

From smarks at openjdk.org  Wed Aug  6 23:02:14 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 6 Aug 2025 23:02:14 GMT
Subject: RFR: 7191877: TEST_BUG:
 java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing
 intermittently
In-Reply-To: <6-Ej6gQDcrnV_LOQaLRCxO08mUVbbX_ZGPahC_ntK2k=.6e97cf50-3fec-4e0e-a4a9-8cc84ad4fc91@github.com>
References: <6-Ej6gQDcrnV_LOQaLRCxO08mUVbbX_ZGPahC_ntK2k=.6e97cf50-3fec-4e0e-a4a9-8cc84ad4fc91@github.com>
Message-ID: <2jw0UOrTJKzb60uSHKM-WatW33l9bhvK0D8dPRpAHyY=.c90773d8-6b43-413a-be67-3b2a81d571b7@github.com>

On Wed, 6 Aug 2025 10:29:45 GMT, Johny Jose <duke at openjdk.org> wrote:

> The test was problem listed since jdk8 as intermittent failures were observed. For all the failed scenarios, number of objects left in leaseTable were less than or equal to 4. Though for most of the runs the number of objects left is less than 2, at times the tests are failing when the remaining objects are 3 or 4 (observed only on mac os). As per the code, the leak should be fixed if the number of objects left in the table is less than 11. I have updated the acceptable number of objects to 4 from 2, and is still at lower end compared to 11.

Marked as reviewed by smarks (Reviewer).

Looks good. Thanks for reactivating this long-problem-listed test.

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

PR Review: https://git.openjdk.org/jdk/pull/26657#pullrequestreview-3094549347
PR Comment: https://git.openjdk.org/jdk/pull/26657#issuecomment-3161863981

From almatvee at openjdk.org  Wed Aug  6 23:38:21 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 6 Aug 2025 23:38:21 GMT
Subject: RFR: 8334238: Enhance AddLShortcutTest jpackage test [v6]
In-Reply-To: <_FoTDBheh_MjVbNrKJEpOA5kOHaJjjVqSVjNHTjGkF8=.5ecc0ac8-6c17-4a93-a0e9-98e31f71be1a@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
 <_FoTDBheh_MjVbNrKJEpOA5kOHaJjjVqSVjNHTjGkF8=.5ecc0ac8-6c17-4a93-a0e9-98e31f71be1a@github.com>
Message-ID: <bdHF0j04vB7YBX3SJh8OKYn02bDNtCx_gJOvyPHmhw0=.44389021-3f53-4c94-8def-48dcb1b9e347@github.com>

On Wed, 6 Aug 2025 22:00:41 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
>> - Test shortcuts in the predefined app image.
>> 
>> Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.
>> 
>> Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.
>> 
>> Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.
>> 
>> Not directly related to the subject of the PR:
>>  - JPackageCommand: Added missing and removed redundant `verifyMutable()` calls. Converted "jpt-unpacked-folder" option into the member field. Added `JPackageCommand.createMutableCopy()` complementary to the existing `JPackageCommand.createImmutableCopy()`.
>>  - Refactor `TKit.waitForFileCreated()` to use classes from the `java.time` package.
>>  - Added `test/jdk/tools/jpackage/clean_test_output.sh` Bash script filtering test logs to minimize noise in diffs.
>> 
>> Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 81 additional commits since the last revision:
> 
>  - TKit: bugfix
>  - Merge branch 'master' into JDK-8334238
>  - Merge branch 'JDK-8334238' of https://github.com/alexeysemenyukoracle/jdk into JDK-8334238
>  - Use TKit.waitForFileCreated() to await for test output file
>  - Use java.time.Duration and java.time.Instant in TKit.waitForFileCreated(). Make it public.
>  - LauncherShortcut: add appImageFilePropertyName()
>  - JPackageCommand: verify names of additional launcher are precisely recorded in .jpackage.xml file
>  - JPackageCommand: remove path to the unpacked directory from the argument list as it interferes with extracting arguments with optional values.
>  - clean_test_output.sh: better
>  - AddLShortcutTest: make it a better fit for JDK-8308349
>  - ... and 71 more: https://git.openjdk.org/jdk/compare/c2a45792...2d31e6a5

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26584#pullrequestreview-3094618056

From bpb at openjdk.org  Thu Aug  7 00:45:20 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Aug 2025 00:45:20 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v6]
In-Reply-To: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
Message-ID: <vaByyeLNRsRxlPUs9O1UEFhaFeFc5wNMFTf4XTKY4Rc=.51818e4b-b430-4d9c-9b52-b01710d2c6d1@github.com>

> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.

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

  8364277: Revert change to BuildTestLib.gmk; move @SuppressWarnings to correct place in FileUtils.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26631/files
  - new: https://git.openjdk.org/jdk/pull/26631/files/60f5315b..a30e0ce8

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

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

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

From rriggs at openjdk.org  Thu Aug  7 01:32:22 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Aug 2025 01:32:22 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <OHLCsMhBRugETXAn_zrDg4xtlWmdpDF-iCfa-75wmg4=.cc14a862-4442-474c-9a22-a09edf44e14b@github.com>

On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

While you're looking at childproc.c, can you update the comment at line 375 that references "closeDescriptors".
It got missed.  There's a separate bug for that [JDK-8364822](https://bugs.openjdk.org/browse/JDK-8364822) but if its convenient to fix.  tnx

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3162123827

From ghan at openjdk.org  Thu Aug  7 01:56:41 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 01:56:41 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
Message-ID: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>

Clean up some stale comment references.  Trivial changes.

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

Commit messages:
 - clean up some stale comment references

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

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

From asemenyuk at openjdk.org  Thu Aug  7 02:05:31 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Aug 2025 02:05:31 GMT
Subject: Integrated: 8334238: Enhance AddLShortcutTest jpackage test
In-Reply-To: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
References: <Lfom-lB7m2tFPgYMBfzreRUEobP_5ZaHIGetlYpiOvM=.7258a335-ff1e-4301-b13e-d8c91a040321@github.com>
Message-ID: <qXb5WsfJJPpBb0vObj0p4SNRp-LvYdvwGxcuP67qPpE=.e2cf93af-1c2b-43af-a1c6-202ae10c220e@github.com>

On Thu, 31 Jul 2025 22:42:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Enhance AddLShortcutTest to cover more combinations of shortcut configurations of the main and additional launchers.
> - Test shortcuts in the predefined app image.
> 
> Additionally, rework launcher verification: move launcher icon and shortcut verification code from AdditionalLauncher into LauncherVerifier. This way launcher verification code is encapsulated in a single class that is applied to the main and additional launchers.
> 
> Rework launcher shortcut verification on Windows: Read shortcuts from MSI tables. This allows testing of expected and actual shortcuts without installing the MSI. This refactoring removed duplicated checks of file associations: It was performed for every additional launcher; now it is executed for the main launcher only. File association is bound to the main launcher, there is no point to verify it as many times as the number of launchers.
> 
> Implement launching launchers through shortcuts on Linux and Windows. The new `AddLShortcutTest.testInvokeShortcuts` test uses this new functionality.
> 
> Not directly related to the subject of the PR:
>  - JPackageCommand: Added missing and removed redundant `verifyMutable()` calls. Converted "jpt-unpacked-folder" option into the member field. Added `JPackageCommand.createMutableCopy()` complementary to the existing `JPackageCommand.createImmutableCopy()`.
>  - Refactor `TKit.waitForFileCreated()` to use classes from the `java.time` package.
>  - Added `test/jdk/tools/jpackage/clean_test_output.sh` Bash script filtering test logs to minimize noise in diffs.
> 
> Compared traces of IconTest, AddlauncherTest, and AddLShortcutTest tests with and without this patch to verify no unexpected changes in the coverage.

This pull request has now been integrated.

Changeset: 7e484e2a
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e484e2a63e40740282b3da5d7b10e9f500bf6ab
Stats:     2823 lines in 23 files changed: 2093 ins; 492 del; 238 mod

8334238: Enhance AddLShortcutTest jpackage test

Reviewed-by: almatvee

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

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

From stuefe at openjdk.org  Thu Aug  7 05:41:45 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 05:41:45 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v2]
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <o9Yju5ZTNSqqICUfgspQYnm_paOYJhYEunhas2FXv3I=.cd59d9cf-c336-474a-b85b-7324302e5b03@github.com>

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Feedback Roger

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26615/files
  - new: https://git.openjdk.org/jdk/pull/26615/files/b607b252..fa1be838

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

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

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

From stuefe at openjdk.org  Thu Aug  7 06:09:15 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 06:09:15 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v2]
In-Reply-To: <o9Yju5ZTNSqqICUfgspQYnm_paOYJhYEunhas2FXv3I=.cd59d9cf-c336-474a-b85b-7324302e5b03@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <o9Yju5ZTNSqqICUfgspQYnm_paOYJhYEunhas2FXv3I=.cd59d9cf-c336-474a-b85b-7324302e5b03@github.com>
Message-ID: <_PzM_ySKqe40uJn5ZhSXJdVJ80J-Us8UbT0GGJW5lRw=.65632516-5765-41c8-b962-311f1351eb38@github.com>

On Thu, 7 Aug 2025 05:41:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
>> 
>> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
>> 
>> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
>> 
>> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Roger

@RogerRiggs Thanks for your review! Addressed in update.

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3162632014

From stuefe at openjdk.org  Thu Aug  7 06:09:17 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 06:09:17 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v2]
In-Reply-To: <wKIBeQ_VaoW_m2xBHhSmmXAAlQI31sgsyOcJIQxOuL4=.8d534cea-484f-4ceb-bb55-bc66e84a0fa5@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <wKIBeQ_VaoW_m2xBHhSmmXAAlQI31sgsyOcJIQxOuL4=.8d534cea-484f-4ceb-bb55-bc66e84a0fa5@github.com>
Message-ID: <0Q7gCa7CWceJqA7LCN3wxmWhVvxstuGGOzRBPKEGNkI=.396ad6ec-1650-426f-bf49-9b46c3f91453@github.com>

On Wed, 6 Aug 2025 14:04:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback Roger
>
> src/java.base/unix/native/libjava/childproc.c line 429:
> 
>> 427:     }
>> 428: 
>> 429:     // Childs should be started with default signal disposition for SIGPIPE
> 
> Editorial: "Childs" -> Children for plural, "Child" for singular.  Here and in tests.

Fixed

> test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c line 60:
> 
>> 58:         struct sigaction act;
>> 59:         if (sigaction(signals[n].sig, NULL, &act) != 0) {
>> 60:             perror("sigaction");
> 
> The sigaction error message goes to stderr, so it is does not appear in line with the signal name.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2259171437
PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2259171720

From stuefe at openjdk.org  Thu Aug  7 06:54:42 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 06:54:42 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v3]
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  fix comments about closeDescriptors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26615/files
  - new: https://git.openjdk.org/jdk/pull/26615/files/fa1be838..38648cb4

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

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

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

From duke at openjdk.org  Thu Aug  7 08:32:21 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 7 Aug 2025 08:32:21 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
In-Reply-To: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
Message-ID: <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>

On Thu, 7 Aug 2025 01:49:41 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Clean up some stale comment references.  Trivial changes.

src/hotspot/os/linux/os_linux.cpp line 4876:

> 4874:   // flag set.  If we don't set it, then careless 3rd party native code
> 4875:   // might fork and exec without closing all appropriate file descriptors
> 4876:   // , and this in turn might:

Shouldn't the comma go to the previous line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26667#discussion_r2259543717

From jpai at openjdk.org  Thu Aug  7 09:57:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Aug 2025 09:57:14 GMT
Subject: RFR: 8364315: Remove unused xml files from
 test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/xmlfiles
In-Reply-To: <FYHMZIOXmUBPoCikESitbrwWeJ7V_sceOQxIK7_FJyc=.390777f0-d637-4f73-be1b-c7e551b9edb6@github.com>
References: <FYHMZIOXmUBPoCikESitbrwWeJ7V_sceOQxIK7_FJyc=.390777f0-d637-4f73-be1b-c7e551b9edb6@github.com>
Message-ID: <5aI0xWt_d1Iiw3ARSdafF4N40fEGNRTh_-A4uQ2VA14=.7accad79-548c-453b-9e73-8dd42f2fe909@github.com>

On Fri, 1 Aug 2025 11:59:23 GMT, Ayush Rigal <duke at openjdk.org> wrote:

> There are number of unused files in the XML test code base. These are not used in any tests and are not referenced within the code base. They appear to be legacy files. These can be removed.

This looks OK to me, but please wait for Joe's @JoeWang-Java review before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26596#pullrequestreview-3096324027

From pminborg at openjdk.org  Thu Aug  7 10:12:47 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Aug 2025 10:12:47 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be improved
 using overlaps
Message-ID: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>

This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`similar ', similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.

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

Commit messages:
 - Add methods to ScopedMemoryAccess
 - remove file
 - Use overlapping copy

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

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

From ghan at openjdk.org  Thu Aug  7 10:19:14 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 10:19:14 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
In-Reply-To: <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>
Message-ID: <pVQ1LLaQXXVeAfFO-UyNENLU6tEUNjA38KaMmTHCfU8=.da47963b-d250-49f9-802a-880aab3b0f83@github.com>

On Thu, 7 Aug 2025 08:29:12 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> src/hotspot/os/linux/os_linux.cpp line 4876:
> 
>> 4874:   // flag set.  If we don't set it, then careless 3rd party native code
>> 4875:   // might fork and exec without closing all appropriate file descriptors
>> 4876:   // , and this in turn might:
> 
> Shouldn't the comma go to the previous line?

@fandreuz Thanks  for your comment! 

You're right to point this out ? I am not sure about the best placement either. I noticed that some other parts of the codebase use the same style (with the comma at the beginning of the line), so I followed that pattern here.

That said, I'm happy to adjust it if needed. Let's leave it to @kevinjwalls  to make the final call.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26667#discussion_r2259827846

From pminborg at openjdk.org  Thu Aug  7 10:26:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Aug 2025 10:26:15 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <b3nA9LRHkmCWCW8VUWMX1IKWUIuiJYO-3erTyn96EGQ=.3f1abfd3-a047-47a0-8b51-c43cde1828d9@github.com>

On Thu, 7 Aug 2025 10:05:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`similar ', similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.

Copy-overlap

Base


Benchmark                              (ELEM_SIZE)  Mode  Cnt        Score        Error  Units
SegmentBulkCopy.nativeSegmentCopyJava            2  avgt   30        3.184 ?      0.060  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            3  avgt   30        3.162 ?      0.046  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            4  avgt   30        3.344 ?      0.072  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            5  avgt   30        3.310 ?      0.055  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            6  avgt   30        3.328 ?      0.076  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            7  avgt   30        3.289 ?      0.086  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            8  avgt   30        4.139 ?      0.067  ns/op
SegmentBulkCopy.nativeSegmentCopyJava           12  avgt   30        4.709 ?      0.095  ns/op
SegmentBulkCopy.nativeSegmentCopyJava           16  avgt   30        4.173 ?      0.086  ns/op
SegmentBulkCopy.nativeSegmentCopyJava           24  avgt   30        4.239 ?      0.046  ns/op
SegmentBulkCopy.nativeSegmentCopyJava           64  avgt   30        4.860 ?      0.091  ns/op
SegmentBulkCopy.nativeSegmentCopyJava          512  avgt   30       14.844 ?      0.326  ns/op
SegmentBulkCopy.nativeSegmentCopyJava         4096  avgt   30       90.611 ?      1.788  ns/op
SegmentBulkCopy.nativeSegmentCopyJava        32768  avgt   30      711.792 ?     13.991  ns/op
SegmentBulkCopy.nativeSegmentCopyJava       262144  avgt   30     7605.349 ?    101.069  ns/op
SegmentBulkCopy.nativeSegmentCopyJava      2097152  avgt   30    63458.190 ?   1754.102  ns/op
SegmentBulkCopy.nativeSegmentCopyJava     16777216  avgt   30   552339.850 ?  20632.233  ns/op
SegmentBulkCopy.nativeSegmentCopyJava    134217728  avgt   30  4780611.167 ? 195940.736  ns/op


Patch


Benchmark                              (ELEM_SIZE)  Mode  Cnt        Score       Error  Units
SegmentBulkCopy.nativeSegmentCopyJava            2  avgt   30        2.826 ?     0.018  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            3  avgt   30        2.821 ?     0.015  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            4  avgt   30        2.807 ?     0.010  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            5  avgt   30        2.805 ?     0.008  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            6  avgt   30        2.814 ?     0.020  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            7  avgt   30        2.805 ?     0.007  ns/op
SegmentBulkCopy.nativeSegmentCopyJava            8  avgt   30        2.805 ?     0.006  ns/op
SegmentBulkCopy.nativeSegmentCopyJava           12  avgt   30        2.813 ?     0.023  ns/op
SegmentBulkCopy.nativeSegmentCopyJava           16  avgt   30        4.236 ?     0.039  ns/op
SegmentBulkCopy.nativeSegmentCopyJava           24  avgt   30        4.386 ?     0.038  ns/op
SegmentBulkCopy.nativeSegmentCopyJava           64  avgt   30        4.986 ?     0.018  ns/op
SegmentBulkCopy.nativeSegmentCopyJava          512  avgt   30       15.204 ?     0.200  ns/op
SegmentBulkCopy.nativeSegmentCopyJava         4096  avgt   30       91.607 ?     1.559  ns/op
SegmentBulkCopy.nativeSegmentCopyJava        32768  avgt   30      696.212 ?     2.265  ns/op
SegmentBulkCopy.nativeSegmentCopyJava       262144  avgt   30     7619.412 ?    60.848  ns/op
SegmentBulkCopy.nativeSegmentCopyJava      2097152  avgt   30    62158.186 ?   190.673  ns/op
SegmentBulkCopy.nativeSegmentCopyJava     16777216  avgt   30   544631.293 ?  5023.824  ns/op
SegmentBulkCopy.nativeSegmentCopyJava    134217728  avgt   30  4524477.559 ? 71723.200  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3163484185

From kevinw at openjdk.org  Thu Aug  7 10:28:15 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Aug 2025 10:28:15 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
In-Reply-To: <pVQ1LLaQXXVeAfFO-UyNENLU6tEUNjA38KaMmTHCfU8=.da47963b-d250-49f9-802a-880aab3b0f83@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>
 <pVQ1LLaQXXVeAfFO-UyNENLU6tEUNjA38KaMmTHCfU8=.da47963b-d250-49f9-802a-880aab3b0f83@github.com>
Message-ID: <w5Kuj-8piriXRgJZC8iuMVy8xY1Yl5hhaSL32MbbzTU=.337d36a8-8d32-47a4-afcf-058ac75191aa@github.com>

On Thu, 7 Aug 2025 10:17:05 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 4876:
>> 
>>> 4874:   // flag set.  If we don't set it, then careless 3rd party native code
>>> 4875:   // might fork and exec without closing all appropriate file descriptors
>>> 4876:   // , and this in turn might:
>> 
>> Shouldn't the comma go to the previous line?
>
> @fandreuz Thanks  for your comment! 
> 
> You're right to point this out ? I am not sure about the best placement either. I noticed that some other parts of the codebase use the same style (with the comma at the beginning of the line), so I followed that pattern here.
> 
> That said, I'm happy to adjust it if needed. Let's leave it to @kevinjwalls  to make the final call.

Hi, it's a good review comment, beginning a line with a comma is not normal, we should keep the comma on the previous line.

I see some javadoc that does this, but in the examples I found, there are slightly complex constructs on the previous line, so you can more easily see it's correct if comma is split, like:


 751      * {@code (CT1 ct1, ..., CTn ctn)}
 752      * , statically represented using varargs.


But javadoc is also reformatted for humans, so the comma will not be split in the version people read. 8-)
Here we should stay with the English style, and not separate the comma, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26667#discussion_r2259852367

From pminborg at openjdk.org  Thu Aug  7 10:32:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Aug 2025 10:32:13 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <WqwPUq1CCZ_aT5vZrqbCeD6g42xdBA5RZye0_EJweXs=.efeb7d08-5905-479e-bfa6-b0559b31b5c3@github.com>

On Thu, 7 Aug 2025 10:05:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`similar ', similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.

<img width="840" height="517" alt="image" src="https://github.com/user-attachments/assets/1ae82fe1-ebcd-472b-8180-1358033b7a2f" />

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

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3163503769

From ghan at openjdk.org  Thu Aug  7 11:24:30 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 11:24:30 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
Message-ID: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>

> Clean up some stale comment references.  Trivial changes.

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  Update os_linux.cpp
  
  a small fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26667/files
  - new: https://git.openjdk.org/jdk/pull/26667/files/0c7ef910..3b55134c

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

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

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

From ghan at openjdk.org  Thu Aug  7 11:27:13 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 11:27:13 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <w5Kuj-8piriXRgJZC8iuMVy8xY1Yl5hhaSL32MbbzTU=.337d36a8-8d32-47a4-afcf-058ac75191aa@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>
 <pVQ1LLaQXXVeAfFO-UyNENLU6tEUNjA38KaMmTHCfU8=.da47963b-d250-49f9-802a-880aab3b0f83@github.com>
 <w5Kuj-8piriXRgJZC8iuMVy8xY1Yl5hhaSL32MbbzTU=.337d36a8-8d32-47a4-afcf-058ac75191aa@github.com>
Message-ID: <u-nilYA8cEtqil1ccaRQHxnSpRh2635Y0EbWK_2zq_Y=.40080bc2-509c-404d-a3b4-b20f478503e8@github.com>

On Thu, 7 Aug 2025 10:25:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> @fandreuz Thanks  for your comment! 
>> 
>> You're right to point this out ? I am not sure about the best placement either. I noticed that some other parts of the codebase use the same style (with the comma at the beginning of the line), so I followed that pattern here.
>> 
>> That said, I'm happy to adjust it if needed. Let's leave it to @kevinjwalls  to make the final call.
>
> Hi, it's a good review comment, beginning a line with a comma is not normal, we should keep the comma on the previous line.
> 
> I see some javadoc that does this, but in the examples I found, there are slightly complex constructs on the previous line, so you can more easily see it's correct if comma is split, like:
> 
> 
>  751      * {@code (CT1 ct1, ..., CTn ctn)}
>  752      * , statically represented using varargs.
> 
> 
> But javadoc is also reformatted for humans, so the comma will not be split in the version people read. 8-)
> Here we should stay with the English style, and not separate the comma, thanks!

hi @kevinjwalls , thanks a lot for the detailed explanation ? that makes sense! I've updated the comment accordingly. Please take another look when you have time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26667#discussion_r2259983441

From jbhateja at openjdk.org  Thu Aug  7 12:37:17 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 7 Aug 2025 12:37:17 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
Message-ID: <98s1CQXUZuyBYN83myqlz01lNsEw3o7-v1DdVb3cNv4=.705802ff-2a68-4258-8f2b-fe5885ce32c5@github.com>

On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
>> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
>> 
>>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
>> 
>> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
>> 
>> Performance numbers:
>> 
>> 
>> System : 13th Gen Intel(R) Core(TM) i3-1315U
>> 
>> Baseline:
>> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
>> VectorSliceB...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating predicate checks

Adding additional notes on implementation:

  A) Slice:-
1.   New inline expander and C2 IR node VectorSlice for leaf level intrinsic corresponding to Vector.slice(int)
2.   Other interfaces of slice APIs.
     - Vector.slice(int, Vector)
          - The second vector argument is the background vector, which replaces the zero broadcasted vector of the base version of API. 
          - API internally calls the same intrinsic entry point as the base version.
      - Vector.slice(int, Vector, VectorMask)
          - This version of the API internally calls the above slice API with index and vector arguments, followed by an explicit blend with a broadcasted zero vector.
          
 Thus, current support implicitly covers all three 3 variants of slice APIs.


 B) Similar extensions to optimize Unslice with constant index:-

1.    Similar to slice, unslice also has three interfaces.
2.    Leaf-level interface only accepts an index argument. 
3.    Other variants of unslice accept unslice index, background vector, and part number.
4.    We can assume the receiver vector to be sliding over two contiguously placed background vectors.
5.    It's possible to implement all three variants of unslice using slice operations as follows.



jshell> // Input
jshell> vec
vec ==> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]
jshell> vec2
vec2 ==> [10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160]
jshell> bzvec
bzvec ==> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

jshell> // Case 1:
jshell> vec.unslice(4)
$79 ==> [0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
jshell> bzvec.slice(vec.length() - 4, vec)
$80 ==> [0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]

jshell> // Case 2:
jshell> vec.unslice(4, vec2, 0)
$81 ==> [10, 20, 30, 40, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
jshell> vec2.blend(vec2.slice(vec2.length() - 4, vec), VectorMask.fromLong(IntVector.SPECIES_512, ((1L << (vec.length() - 4)) - 1) << 4))
$82 ==> [10, 20, 30, 40, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]

jshell> // Case 3:
jshell> vec.unslice(4, vec2, 1)
$83 ==> [13, 14, 15, 16, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160]
jshell> vec2.blend(vec.slice(vec.length() - 4, vec2), VectorMask.fromLong(IntVector.SPECIES_512, ((1L << 4) - 1)))
$84 ==> [13, 14, 15, 16, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160]

jshell> // Case 4:
jshell> vec.unslice(4, vec2, 0, VectorMask.fromLong(IntVector.SPECIES_512, 0xFF))
$85 ==> [10, 20, 30, 40, 1, 2, 3, 4, 5, 6, 7, 8, 130, 140, 150, 160]
jshell> // Current Java fallback implementation for this version is based on slice and unslice operations.


To ease the review process, I plan to optimize the unslice API with a constant index by extending the newly added expander in a follow-up patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3163994472

From kevinw at openjdk.org  Thu Aug  7 13:52:16 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Aug 2025 13:52:16 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
Message-ID: <cZbCfNhsG5eOVaoaUngsUN2bUPlAyE_CRa8N4lJ0EnI=.cf436e3f-5c64-4d6d-a4f8-e30b45f40815@github.com>

On Thu, 7 Aug 2025 11:24:30 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update os_linux.cpp
>   
>   a small fix

Yes, looks good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26667#pullrequestreview-3097255422

From dl at openjdk.org  Thu Aug  7 14:03:40 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 7 Aug 2025 14:03:40 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
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: <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Avoid underutilization on resize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/c16c1282..8ecf3987

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

  Stats: 109 lines in 1 file changed: 23 ins; 19 del; 67 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  Thu Aug  7 14:05:20 2025
From: duke at openjdk.org (duke)
Date: Thu, 7 Aug 2025 14:05:20 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
Message-ID: <zpWUBVMYi7oMxMHO4XiioEY8_1lJPOTS3_ki1OsMp_k=.6a2fef50-5f57-4041-ba67-84ec54dc284c@github.com>

On Thu, 7 Aug 2025 11:24:30 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update os_linux.cpp
>   
>   a small fix

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26667#issuecomment-3164338669

From rriggs at openjdk.org  Thu Aug  7 14:09:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Aug 2025 14:09:16 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
Message-ID: <tdc7Jw7KTyE8lwfKkUSZFte-_w9jZ_0W7YtlNC948X0=.e3aeccd0-6d0a-4ecd-8009-604394d7e612@github.com>

On Thu, 7 Aug 2025 11:24:30 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update os_linux.cpp
>   
>   a small fix

Looks good, thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26667#pullrequestreview-3097333323

From ghan at openjdk.org  Thu Aug  7 14:09:17 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 14:09:17 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <cZbCfNhsG5eOVaoaUngsUN2bUPlAyE_CRa8N4lJ0EnI=.cf436e3f-5c64-4d6d-a4f8-e30b45f40815@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
 <cZbCfNhsG5eOVaoaUngsUN2bUPlAyE_CRa8N4lJ0EnI=.cf436e3f-5c64-4d6d-a4f8-e30b45f40815@github.com>
Message-ID: <FJ1Re04HWNzKGBEZu2S7EVfSNUnAMnEodIia_m28aH8=.6b725c35-7335-4902-9164-6aeae70bc4fe@github.com>

On Thu, 7 Aug 2025 13:49:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update os_linux.cpp
>>   
>>   a small fix
>
> Yes, looks good.

hi @kevinjwalls ,thank you for your review and approval.

I've run /integrate , please sponsor this change when you have time.

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

PR Comment: https://git.openjdk.org/jdk/pull/26667#issuecomment-3164350283

From asemenyuk at openjdk.org  Thu Aug  7 14:11:25 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Aug 2025 14:11:25 GMT
Subject: RFR: 8364984: Many jpackage tests are failing on Linux after
 JDK-8334238
Message-ID: <fxYIcUq3YwdOqpNCUSHlS033IsdWveTisdmF-RyAM3w=.d481acfc-9396-4285-8537-ebf123c7d1e4@github.com>

Fix NPE when `path.getParent()` in `LinuxHelper.getDesktopFiles()` returns null. The issue is deb-specific, there is no such problem with rpm packages.

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

Commit messages:
 - 8364984: Many jpackage tests are failing on Linux after JDK-8334238

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

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

From asemenyuk at openjdk.org  Thu Aug  7 14:11:26 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Aug 2025 14:11:26 GMT
Subject: RFR: 8364984: Many jpackage tests are failing on Linux after
 JDK-8334238
In-Reply-To: <fxYIcUq3YwdOqpNCUSHlS033IsdWveTisdmF-RyAM3w=.d481acfc-9396-4285-8537-ebf123c7d1e4@github.com>
References: <fxYIcUq3YwdOqpNCUSHlS033IsdWveTisdmF-RyAM3w=.d481acfc-9396-4285-8537-ebf123c7d1e4@github.com>
Message-ID: <dXHNUiMOVn75c8RYFzHmqzaxG7II5z9TZSLs4rhSIG8=.4396f06b-4e0d-4edf-9590-0089cf36c379@github.com>

On Thu, 7 Aug 2025 14:02:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix NPE when `path.getParent()` in `LinuxHelper.getDesktopFiles()` returns null. The issue is deb-specific, there is no such problem with rpm packages.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/26677#issuecomment-3164347700

From kevinw at openjdk.org  Thu Aug  7 14:14:21 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Aug 2025 14:14:21 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
Message-ID: <KtZ3o_DoS7RaswxmYAnvFI1bX1qvJAGpf5jgYzfbK5A=.16060ebf-a892-470a-8097-ea633d1925fa@github.com>

On Thu, 7 Aug 2025 11:24:30 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update os_linux.cpp
>   
>   a small fix

Thanks, great to have the second review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26667#issuecomment-3164366872

From ghan at openjdk.org  Thu Aug  7 14:14:22 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 14:14:22 GMT
Subject: Integrated: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
In-Reply-To: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
Message-ID: <sH5mj7S9U3rozNthAmnjGyjnc6vJvr_Rm5xMvzQPI-4=.46112ac2-70c0-4775-bdf0-a96bda5b494f@github.com>

On Thu, 7 Aug 2025 01:49:41 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Clean up some stale comment references.  Trivial changes.

This pull request has now been integrated.

Changeset: 83953c45
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83953c458eb65b2af184340dd460325f2b56e5b9
Stats:     8 lines in 4 files changed: 0 ins; 3 del; 5 mod

8364822: Comment cleanup, stale references to closeDescriptors and UNIXProcess.c

Reviewed-by: kevinw, rriggs

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

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

From rriggs at openjdk.org  Thu Aug  7 14:20:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Aug 2025 14:20:17 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v3]
In-Reply-To: <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>
Message-ID: <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>

On Thu, 7 Aug 2025 06:54:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
>> 
>> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
>> 
>> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
>> 
>> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments about closeDescriptors

It looks like I created a merge conflict by asking to fix these.  
Another PR https://git.openjdk.org/jdk/pull/26667 is also changing them. (At the time the other PR had not started).
The least chaos may be created by backing out those changes from this PR.  (Unless you like your words better than PR#26667).

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3164396666

From rriggs at openjdk.org  Thu Aug  7 14:30:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Aug 2025 14:30:27 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v7]
In-Reply-To: <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
Message-ID: <fuILCMJnF7DC-0i8uRA_7_OlNHeJoSgzrTUXXzzlO5M=.e5923e09-25f5-4317-b10f-7d8b88a17088@github.com>

On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec

Thanks for the implSpec update.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-3097418232

From qamai at openjdk.org  Thu Aug  7 15:38:20 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 7 Aug 2025 15:38:20 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
Message-ID: <bTJpTcRzuMMNGyqyMTGz0h063AqPbNbfQ7hH3h_oJW0=.45710115-a9ce-48ee-8638-307e66e6661b@github.com>

On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
>> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
>> 
>>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
>> 
>> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
>> 
>> Performance numbers:
>> 
>> 
>> System : 13th Gen Intel(R) Core(TM) i3-1315U
>> 
>> Baseline:
>> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
>> VectorSliceB...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating predicate checks

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 7138:

> 7136:      // res[255:128] = {src2[127:0]   , src1[255:128]}  >> SHIFT
> 7137:      vperm2i128(xtmp, src1, src2, 0x21);
> 7138:      vpalignr(dst, xtmp, src1, origin, Assembler::AVX_256bit);

If the slice amount is exactly 16, I think the `vpalignr` is unnecessary.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 7159:

> 7157: void C2_MacroAssembler::vector_slice_64B_op(XMMRegister dst, XMMRegister src1, XMMRegister src2,
> 7158:                                             XMMRegister xtmp, int origin, int vlen_enc) {
> 7159:   if (origin <= 16) {

If `origin` is divisible by `4`, then a single `valignd` is enough, am I right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2260699543
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2260702518

From asemenyuk at openjdk.org  Thu Aug  7 15:52:39 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Aug 2025 15:52:39 GMT
Subject: RFR: 8364564: Shortcut configuration is not recorded in .jpackage.xml
 file
Message-ID: <MhCnt1vlEqWvEo32SllLqONZUwKo-YJD80oEpN19kEY=.08edccd1-dc94-4472-87b1-59af941829a8@github.com>

- Add `LauncherShortcut` and `LauncherShortcutStartupDirectory` types to the model to define launcher shortcuts. For now `LauncherShortcutStartupDirectory` enum has a single value. It will be extended in [JDK-8308349](https://bugs.openjdk.org/browse/JDK-8308349) enhancement.
- Replace `WinLauncherMixin.shortcuts()` with `WinLauncherMixin.startMenuShortcut()` and `WinLauncherMixin.desktopShortcut()`.
- Remove redundant `StandardBundlerParam.SHORTCUT_HINT` and `StandardBundlerParam.MENU_HINT`; use "win-shortcut", "win-menu", and "linux-shortcut" values instead of "shortcut" and "menu" to store launcher shortcut configuration in the ".jpackage.xml" file.
- Add tests for launcher shortcut configuration in the ".jpackage.xml" file.

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

Commit messages:
 - LauncherShortcut: reflects changes in the implementation
 - Revert excessive changes of JDK-8308349 patch irrelevant to JDK-8364564
 - 8308349: missing working directory option for launcher when invoked from shortcuts
 - LauncherVerifier: add verifyInAppImageFile()
 - Merge branch 'master' into JDK-8334238
 - TKit: bugfix
 - Merge branch 'master' into JDK-8334238
 - Merge branch 'JDK-8334238' of https://github.com/alexeysemenyukoracle/jdk into JDK-8334238
 - Use TKit.waitForFileCreated() to await for test output file
 - Use java.time.Duration and java.time.Instant in TKit.waitForFileCreated(). Make it public.
 - ... and 76 more: https://git.openjdk.org/jdk/compare/bc3d8656...7ca2e942

Changes: https://git.openjdk.org/jdk/pull/26604/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26604&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364564
  Stats: 383 lines in 15 files changed: 262 ins; 54 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/26604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26604/head:pull/26604

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

From pminborg at openjdk.org  Thu Aug  7 16:05:20 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Aug 2025 16:05:20 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v7]
In-Reply-To: <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
Message-ID: <vc5DbMxqvt3xquCHgBzhKg9n0u5Aus70DXPOf0os_yA=.3ead2059-7017-4b36-9e4d-7a929efcc23e@github.com>

On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec

Maybe we can add some verbiage around why the first argument is returned if the values are equal? This relates to stable sorting algorithms and `min` and `max` can be viewed as a sorting algorithm with only two elements. So, min and max are stable in this sense and therefore amenable as a building block for more general stable sorting algorithms.

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

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-3164837186

From bpb at openjdk.org  Thu Aug  7 16:13:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Aug 2025 16:13:57 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v7]
In-Reply-To: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
Message-ID: <hvBLQhsII2NgBrcciTUsq3O6Kz0ifHh82Q7xN9xWMhY=.9f1eb7e8-027a-4ea8-a4c0-831c4e265456@github.com>

> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.

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

  8364277: Put IO_REPARSE_TAG_* constants in numerical order

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26631/files
  - new: https://git.openjdk.org/jdk/pull/26631/files/a30e0ce8..584e04e9

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

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

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

From alanb at openjdk.org  Thu Aug  7 16:13:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Aug 2025 16:13:57 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v6]
In-Reply-To: <vaByyeLNRsRxlPUs9O1UEFhaFeFc5wNMFTf4XTKY4Rc=.51818e4b-b430-4d9c-9b52-b01710d2c6d1@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <vaByyeLNRsRxlPUs9O1UEFhaFeFc5wNMFTf4XTKY4Rc=.51818e4b-b430-4d9c-9b52-b01710d2c6d1@github.com>
Message-ID: <w9kXOysaHNpIx-KvTsEE4L-vD2QXbAZvR_rObHRGniY=.66430bc0-de27-4632-b838-7223ca8b0858@github.com>

On Thu, 7 Aug 2025 00:45:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364277: Revert change to BuildTestLib.gmk; move @SuppressWarnings to correct place in FileUtils.java

I don't have any other comments. For the FileUtil test infra then we can probably replace the JNI with FFM codes at some point.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26631#pullrequestreview-3097818857

From bpb at openjdk.org  Thu Aug  7 16:13:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Aug 2025 16:13:57 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v6]
In-Reply-To: <w9kXOysaHNpIx-KvTsEE4L-vD2QXbAZvR_rObHRGniY=.66430bc0-de27-4632-b838-7223ca8b0858@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <vaByyeLNRsRxlPUs9O1UEFhaFeFc5wNMFTf4XTKY4Rc=.51818e4b-b430-4d9c-9b52-b01710d2c6d1@github.com>
 <w9kXOysaHNpIx-KvTsEE4L-vD2QXbAZvR_rObHRGniY=.66430bc0-de27-4632-b838-7223ca8b0858@github.com>
Message-ID: <6cd79hZcjbhBwWolEeJqexgluykpgQSdX2UFJGi3YOo=.21d62827-aced-4281-aeb5-334e9c31af56@github.com>

On Thu, 7 Aug 2025 16:02:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> For the FileUtil test infra then we can probably replace the JNI with FFM codes at some point.

I will put that on the list.

I just pushed another minor commit right after you approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/26631#issuecomment-3164852054

From alanb at openjdk.org  Thu Aug  7 16:13:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Aug 2025 16:13:57 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v7]
In-Reply-To: <hvBLQhsII2NgBrcciTUsq3O6Kz0ifHh82Q7xN9xWMhY=.9f1eb7e8-027a-4ea8-a4c0-831c4e265456@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <hvBLQhsII2NgBrcciTUsq3O6Kz0ifHh82Q7xN9xWMhY=.9f1eb7e8-027a-4ea8-a4c0-831c4e265456@github.com>
Message-ID: <xI9jZd3UXfilNkqCC00CugwRczLD7ycS-lpVs-h4ZpM=.33b9b28a-0305-4bdb-8719-53cbdf9e47b8@github.com>

On Thu, 7 Aug 2025 16:10:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364277: Put IO_REPARSE_TAG_* constants in numerical order

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26631#pullrequestreview-3097842635

From aivanov at openjdk.org  Thu Aug  7 16:15:19 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Aug 2025 16:15:19 GMT
Subject: RFR: 8358618: UnsupportedOperationException constructors javadoc
 is not clear [v3]
In-Reply-To: <fQlxwTv2P4mOsfMCzkBosXe9KdE0x3b6BWtHp_BoIxs=.6e538e5a-a8c5-40a7-a3c7-12cd4903d903@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
 <fQlxwTv2P4mOsfMCzkBosXe9KdE0x3b6BWtHp_BoIxs=.6e538e5a-a8c5-40a7-a3c7-12cd4903d903@github.com>
Message-ID: <lZ5gNliNJBRuD4sL1fTOBl1jVUhFXmAO_TsxdPzi7ho=.a3db1cd4-b2b0-4b92-afa1-a3726bd24cb6@github.com>

On Tue, 29 Jul 2025 15:00:11 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Alexey.

Overall, it looks good to me. What's left is agreeing on how the updated text is formatted in the source code.

I'm unsure if a CSR is required. The specification isn't updated substantially for `RuntimeException`; the changes for `UnsupportedOperationException` are quite substantial,  so submitting CSR would be a good idea to document the changes made.

src/java.base/share/classes/java/lang/UnsupportedOperationException.java line 60:

> 58:     /**
> 59:      * Constructs a new {@code UnsupportedOperationException} with the specified detail message and
> 60:      * cause.

Suggestion:

     * Constructs a new {@code UnsupportedOperationException} with the specified
     * detail message and cause.

I'm for wrapping the line after the word ?specified? to fit into 80 columns.

src/java.base/share/classes/java/lang/UnsupportedOperationException.java line 81:

> 79:      * Constructs a new {@code UnsupportedOperationException} with the specified cause and a detail
> 80:      * message of {@code (cause==null ? null : cause.toString())} (which
> 81:      * typically contains the class and detail message of {@code cause}).

This one is trickier. Wrapping the line will cause a ripple effect on the following lines, which I'd like to avoid or to minimise at least.
Suggestion:

     * Constructs a new {@code UnsupportedOperationException} with the specified
     * cause and a detail message of
     * {@code (cause==null ? null : cause.toString())} (which
     * typically contains the class and detail message of {@code cause}).

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26533#pullrequestreview-3097822567
PR Review Comment: https://git.openjdk.org/jdk/pull/26533#discussion_r2260779017
PR Review Comment: https://git.openjdk.org/jdk/pull/26533#discussion_r2260785918

From liach at openjdk.org  Thu Aug  7 16:29:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 7 Aug 2025 16:29:31 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
Message-ID: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>

JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.

This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.

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

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-cache-miss
 - Test
 - Cache miss when remove is called on another class

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

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

From shade at openjdk.org  Thu Aug  7 17:24:20 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Aug 2025 17:24:20 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
In-Reply-To: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
Message-ID: <p3N5XRDiL9Ut7BaAB2jOSQc2Ih8aw-5jhMtOPVtu8pI=.a18902bd-2a1a-416b-94e1-22a70120e149@github.com>

On Thu, 7 Aug 2025 16:23:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.
> 
> This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.

src/java.base/share/classes/java/lang/ClassValue.java line 479:

> 477:                     put(classValue.identity, updated);
> 478:                 }
> 479:                 // Add to the cache, to enable the fast path, next time.

A question: do we only care about `if (updated != entry)` path for this cache-add then? Should this code be moved into that block?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26679#discussion_r2260954863

From duke at openjdk.org  Thu Aug  7 17:51:24 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 7 Aug 2025 17:51:24 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]
In-Reply-To: <J4EUd7mG3iVgCDMaH6sIaV6ex2-RWv3RysXONHNfVPA=.a82ba9dc-cf61-4186-8c2d-166b561e684d@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>
 <8ntdUbcNZXlhpmPdasBRHkvBiJ_sytIXP144tDZ53JA=.95b23097-a3dd-43f7-986e-dcee4b2a6fb4@github.com>
 <J4EUd7mG3iVgCDMaH6sIaV6ex2-RWv3RysXONHNfVPA=.a82ba9dc-cf61-4186-8c2d-166b561e684d@github.com>
Message-ID: <CdgD298yaBHy7JuYjPTB-OOzuoIUq6O4_xiCmIBblMc=.18c46a7f-73b2-404b-b42a-61e676f7ae08@github.com>

On Thu, 8 May 2025 16:06:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ClassValue.java line 241:
>> 
>>> 239:                 } else {
>>> 240:                     throw ex instanceof Error err ? err : new Error(ex);
>>> 241:                 }
>> 
>> Hello Chen, i think this if/else for exception type checks can instead just be replaced with an unconditional `throw ex`;
>
> I tried that and failed compilation before

This?could also?use `jdk.internal.misc.Unsafe?::throwException?(Throwable)`:

Unsafe.getUnsafe().throwException(ex);
return null;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2261045331

From jlu at openjdk.org  Thu Aug  7 18:10:16 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 18:10:16 GMT
Subject: RFR: 8363972: Lenient parsing of minus sign pattern in
 DecimalFormat/CompactNumberFormat [v10]
In-Reply-To: <fL10ZLA1KeHGufyjiTHLLC9HBCNzWEGFeXbv0klsLW8=.d9136fb0-a20e-41f3-a985-56aea04d19cc@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <fL10ZLA1KeHGufyjiTHLLC9HBCNzWEGFeXbv0klsLW8=.d9136fb0-a20e-41f3-a985-56aea04d19cc@github.com>
Message-ID: <laSObByiKBK-Yt3AeQR__Ef9GWJ2NyPqe-q0NwA6FLM=.c56af02e-cc09-4281-8727-4af9e48928e8@github.com>

On Wed, 6 Aug 2025 20:24:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added description in `parse()`

The current form looks good to me, thanks for all the changes. Approved CSR as well.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26580#pullrequestreview-3098263842

From joehw at openjdk.org  Thu Aug  7 18:11:17 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 7 Aug 2025 18:11:17 GMT
Subject: RFR: 8364315: Remove unused xml files from
 test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/xmlfiles
In-Reply-To: <FYHMZIOXmUBPoCikESitbrwWeJ7V_sceOQxIK7_FJyc=.390777f0-d637-4f73-be1b-c7e551b9edb6@github.com>
References: <FYHMZIOXmUBPoCikESitbrwWeJ7V_sceOQxIK7_FJyc=.390777f0-d637-4f73-be1b-c7e551b9edb6@github.com>
Message-ID: <LTkZDYryawBbmfUGHjYhcktIL_jIrGAb_iZdxSEQ1Ms=.f446a9e8-a2ad-465d-a38c-2d8bb47bb128@github.com>

On Fri, 1 Aug 2025 11:59:23 GMT, Ayush Rigal <duke at openjdk.org> wrote:

> There are number of unused files in the XML test code base. These are not used in any tests and are not referenced within the code base. They appear to be legacy files. These can be removed.

Thanks Ayush, Jaikiran.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26596#pullrequestreview-3098268323

From asemenyuk at openjdk.org  Thu Aug  7 18:17:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Aug 2025 18:17:15 GMT
Subject: RFR: 8364564: Shortcut configuration is not recorded in
 .jpackage.xml file
In-Reply-To: <MhCnt1vlEqWvEo32SllLqONZUwKo-YJD80oEpN19kEY=.08edccd1-dc94-4472-87b1-59af941829a8@github.com>
References: <MhCnt1vlEqWvEo32SllLqONZUwKo-YJD80oEpN19kEY=.08edccd1-dc94-4472-87b1-59af941829a8@github.com>
Message-ID: <sfIHZQEsNwPTJC26-DxkCYhHmQxP6uQqRbmEz6BNKmI=.137c70ad-e412-46b2-938d-38faca6f1e7d@github.com>

On Sat, 2 Aug 2025 03:46:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Add `LauncherShortcut` and `LauncherShortcutStartupDirectory` types to the model to define launcher shortcuts. For now `LauncherShortcutStartupDirectory` enum has a single value. It will be extended in [JDK-8308349](https://bugs.openjdk.org/browse/JDK-8308349) enhancement.
> - Replace `WinLauncherMixin.shortcuts()` with `WinLauncherMixin.startMenuShortcut()` and `WinLauncherMixin.desktopShortcut()`.
> - Remove redundant `StandardBundlerParam.SHORTCUT_HINT` and `StandardBundlerParam.MENU_HINT`; use "win-shortcut", "win-menu", and "linux-shortcut" values instead of "shortcut" and "menu" to store launcher shortcut configuration in the ".jpackage.xml" file.
> - Add tests for launcher shortcut configuration in the ".jpackage.xml" file.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/26604#issuecomment-3165249709

From bpb at openjdk.org  Thu Aug  7 18:38:21 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Aug 2025 18:38:21 GMT
Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed [v7]
In-Reply-To: <hvBLQhsII2NgBrcciTUsq3O6Kz0ifHh82Q7xN9xWMhY=.9f1eb7e8-027a-4ea8-a4c0-831c4e265456@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
 <hvBLQhsII2NgBrcciTUsq3O6Kz0ifHh82Q7xN9xWMhY=.9f1eb7e8-027a-4ea8-a4c0-831c4e265456@github.com>
Message-ID: <Jp4Ry4AuX-p8hteFt4bmgEtrrffwbtX79vo7I52PdKo=.85c8affc-a392-40e1-8d18-143d9e2ddea0@github.com>

On Thu, 7 Aug 2025 16:13:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364277: Put IO_REPARSE_TAG_* constants in numerical order

CI tiers 1-3 passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26631#issuecomment-3165288250

From bpb at openjdk.org  Thu Aug  7 18:38:33 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Aug 2025 18:38:33 GMT
Subject: Integrated: 8364277: (fs) BasicFileAttributes.isDirectory and isOther
 return true for NTFS directory junctions when links not followed
In-Reply-To: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
References: <baOVUP-BhiPPvPrczO2y0_PIEoi40F_HYeFJpl_QFgE=.14ceb045-28af-4b35-a4d8-c0dc2c340947@github.com>
Message-ID: <NiDH0_aQRbw1EfUEjrR2uHmMvBz7CWK65uy4p8LI2OA=.8e1719ad-1933-441d-b86b-fd6b41883ba8@github.com>

On Mon, 4 Aug 2025 21:38:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`.

This pull request has now been integrated.

Changeset: 02e18711
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02e187119d0ca94d46e631a174c55db4945f3295
Stats:     236 lines in 6 files changed: 211 ins; 8 del; 17 mod

8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed

Reviewed-by: alanb

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

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

From liach at openjdk.org  Thu Aug  7 18:48:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 7 Aug 2025 18:48:23 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
In-Reply-To: <I8oIVZBjlxfVo_d2EtrfH2SoSaUA88vsSSheCiEP-0o=.625f7dd0-ebca-4b68-9b8e-3840b0f42deb@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
 <p3N5XRDiL9Ut7BaAB2jOSQc2Ih8aw-5jhMtOPVtu8pI=.a18902bd-2a1a-416b-94e1-22a70120e149@github.com>
 <I8oIVZBjlxfVo_d2EtrfH2SoSaUA88vsSSheCiEP-0o=.625f7dd0-ebca-4b68-9b8e-3840b0f42deb@github.com>
Message-ID: <Dzjj_OsWnyp_KZnKM9zdAMp4RcbOGpIj1FfMF4aivMU=.26ed85a0-ac62-4d72-ac2d-827fcd4f39c6@github.com>

On Thu, 7 Aug 2025 18:39:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ClassValue.java line 479:
>> 
>>> 477:                     put(classValue.identity, updated);
>>> 478:                 }
>>> 479:                 // Add to the cache, to enable the fast path, next time.
>> 
>> A question: do we only care about `if (updated != entry)` path for this cache-add then? Should this code be moved into that block?
>
> I think whenever we hit `readAccess`, it means we are missing this item in the cache and are already in this slow path. I pondered this may happen due to cache being too full too, in which case we have `updated == entry` in the backing map, so leaving it out of the if block should be correct.

Also, this cache mechanism was authored before JDK 8 introduced fast table cache in `ConcurrentHashMap`. In the long run, we may switch the ClassValueMap to a ConcurrentHashMap-derived structure, like a `ReferencedKeyMap`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26679#discussion_r2261143735

From liach at openjdk.org  Thu Aug  7 18:48:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 7 Aug 2025 18:48:21 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
In-Reply-To: <p3N5XRDiL9Ut7BaAB2jOSQc2Ih8aw-5jhMtOPVtu8pI=.a18902bd-2a1a-416b-94e1-22a70120e149@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
 <p3N5XRDiL9Ut7BaAB2jOSQc2Ih8aw-5jhMtOPVtu8pI=.a18902bd-2a1a-416b-94e1-22a70120e149@github.com>
Message-ID: <I8oIVZBjlxfVo_d2EtrfH2SoSaUA88vsSSheCiEP-0o=.625f7dd0-ebca-4b68-9b8e-3840b0f42deb@github.com>

On Thu, 7 Aug 2025 17:19:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.
>> 
>> This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.
>
> src/java.base/share/classes/java/lang/ClassValue.java line 479:
> 
>> 477:                     put(classValue.identity, updated);
>> 478:                 }
>> 479:                 // Add to the cache, to enable the fast path, next time.
> 
> A question: do we only care about `if (updated != entry)` path for this cache-add then? Should this code be moved into that block?

I think whenever we hit `readAccess`, it means we are missing this item in the cache and are already in this slow path. I pondered this may happen due to cache being too full too, in which case we have `updated == entry` in the backing map, so leaving it out of the if block should be correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26679#discussion_r2261142029

From jrose at openjdk.org  Thu Aug  7 18:49:47 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 7 Aug 2025 18:49:47 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v7]
In-Reply-To: <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
Message-ID: <CgLWIKCBlzj8sV4t76N-YetefFKG37XgmI8rRrCh244=.ac5c8739-6d4c-487d-a65d-73070935718e@github.com>

On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec

For users that want the partitioning behavior, just use a reversed argument order, right?


var c = x.min(a,b);
var d = x.min(b,a);
assert c!=d || a==b;

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

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-3165354008

From nbenalla at openjdk.org  Thu Aug  7 18:53:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 7 Aug 2025 18:53:57 GMT
Subject: RFR: 8358618: UnsupportedOperationException constructors javadoc
 is not clear [v3]
In-Reply-To: <lZ5gNliNJBRuD4sL1fTOBl1jVUhFXmAO_TsxdPzi7ho=.a3db1cd4-b2b0-4b92-afa1-a3726bd24cb6@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
 <fQlxwTv2P4mOsfMCzkBosXe9KdE0x3b6BWtHp_BoIxs=.6e538e5a-a8c5-40a7-a3c7-12cd4903d903@github.com>
 <lZ5gNliNJBRuD4sL1fTOBl1jVUhFXmAO_TsxdPzi7ho=.a3db1cd4-b2b0-4b92-afa1-a3726bd24cb6@github.com>
Message-ID: <otrwSFmuCg2X7DfBOzu_9jFdtZsQva0A82qgJ8RICxE=.9407abd2-0621-4235-ad05-446e14f5c153@github.com>

On Thu, 7 Aug 2025 16:06:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Alexey.
>
> src/java.base/share/classes/java/lang/UnsupportedOperationException.java line 81:
> 
>> 79:      * Constructs a new {@code UnsupportedOperationException} with the specified cause and a detail
>> 80:      * message of {@code (cause==null ? null : cause.toString())} (which
>> 81:      * typically contains the class and detail message of {@code cause}).
> 
> This one is trickier. Wrapping the line will cause a ripple effect on the following lines, which I'd like to avoid or to minimise at least.
> Suggestion:
> 
>      * Constructs a new {@code UnsupportedOperationException} with the specified
>      * cause and a detail message of
>      * {@code (cause==null ? null : cause.toString())} (which
>      * typically contains the class and detail message of {@code cause}).

FYI I will be clarifying the javadoc of the other subclasses of RuntimeException as well

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26533#discussion_r2261163670

From shade at openjdk.org  Thu Aug  7 19:33:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Aug 2025 19:33:12 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
In-Reply-To: <Dzjj_OsWnyp_KZnKM9zdAMp4RcbOGpIj1FfMF4aivMU=.26ed85a0-ac62-4d72-ac2d-827fcd4f39c6@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
 <p3N5XRDiL9Ut7BaAB2jOSQc2Ih8aw-5jhMtOPVtu8pI=.a18902bd-2a1a-416b-94e1-22a70120e149@github.com>
 <I8oIVZBjlxfVo_d2EtrfH2SoSaUA88vsSSheCiEP-0o=.625f7dd0-ebca-4b68-9b8e-3840b0f42deb@github.com>
 <Dzjj_OsWnyp_KZnKM9zdAMp4RcbOGpIj1FfMF4aivMU=.26ed85a0-ac62-4d72-ac2d-827fcd4f39c6@github.com>
Message-ID: <j_pHHyNIE3w2jY9ziSa5Mq1tS3ntmRSY20BVEj8buLs=.ba30a004-3826-4e87-b508-0304b35034fb@github.com>

On Thu, 7 Aug 2025 18:40:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I think whenever we hit `readAccess`, it means we are missing this item in the cache and are already in this slow path. I pondered this may happen due to cache being too full too, in which case we have `updated == entry` in the backing map, so leaving it out of the if block should be correct.
>
> Also, this cache mechanism was authored before JDK 8 introduced fast table cache in `ConcurrentHashMap`. In the long run, we may switch the ClassValueMap to a ConcurrentHashMap-derived structure, like a `ReferencedKeyMap`.

Ah, OK, so this is already slow path, good. But are we sure overwriting cache entry _with (the live version of) itself_ would not break things? Looking at `addToCache` implemenation, I am not 100% convinced it is safe. Please check?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26679#discussion_r2261237490

From almatvee at openjdk.org  Thu Aug  7 19:48:17 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 7 Aug 2025 19:48:17 GMT
Subject: RFR: 8364984: Many jpackage tests are failing on Linux after
 JDK-8334238
In-Reply-To: <fxYIcUq3YwdOqpNCUSHlS033IsdWveTisdmF-RyAM3w=.d481acfc-9396-4285-8537-ebf123c7d1e4@github.com>
References: <fxYIcUq3YwdOqpNCUSHlS033IsdWveTisdmF-RyAM3w=.d481acfc-9396-4285-8537-ebf123c7d1e4@github.com>
Message-ID: <0Bw2X0vaFUBrIq4N3iXE80gRGFb9GcqhZXG1qKjts78=.a2af9e41-d188-4dcf-99b9-48c389f10e46@github.com>

On Thu, 7 Aug 2025 14:02:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix NPE when `path.getParent()` in `LinuxHelper.getDesktopFiles()` returns null. The issue is deb-specific, there is no such problem with rpm packages.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26677#pullrequestreview-3098531203

From asemenyuk at openjdk.org  Thu Aug  7 19:59:18 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Aug 2025 19:59:18 GMT
Subject: Integrated: 8364984: Many jpackage tests are failing on Linux after
 JDK-8334238
In-Reply-To: <fxYIcUq3YwdOqpNCUSHlS033IsdWveTisdmF-RyAM3w=.d481acfc-9396-4285-8537-ebf123c7d1e4@github.com>
References: <fxYIcUq3YwdOqpNCUSHlS033IsdWveTisdmF-RyAM3w=.d481acfc-9396-4285-8537-ebf123c7d1e4@github.com>
Message-ID: <dQ7a2jCKxriwUEy_aH8PJCyBxT9Zow04EVh3D7XmEcA=.cb94937b-f379-473a-ae9b-7cc6c9054b21@github.com>

On Thu, 7 Aug 2025 14:02:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix NPE when `path.getParent()` in `LinuxHelper.getDesktopFiles()` returns null. The issue is deb-specific, there is no such problem with rpm packages.

This pull request has now been integrated.

Changeset: 244e6293
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/244e6293c3b332105658900639a9f3db7b21a9fe
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8364984: Many jpackage tests are failing on Linux after JDK-8334238

Reviewed-by: almatvee

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

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

From asemenyuk at openjdk.org  Thu Aug  7 20:14:30 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Aug 2025 20:14:30 GMT
Subject: RFR: 8364129: Rename libwixhelper
Message-ID: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>

Rename "libwixhelper" in "libmsica".

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

Commit messages:
 - 8364129: Rename libwixhelper

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

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

From erikj at openjdk.org  Thu Aug  7 20:21:10 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Aug 2025 20:21:10 GMT
Subject: RFR: 8364129: Rename libwixhelper
In-Reply-To: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
Message-ID: <DUa_B_ygYgZsHBD3d3wRKPfZNG4ZrTuTdRm4sqSyHaw=.d7368d5b-0d0f-43bc-aa51-9cf8dd0f317d@github.com>

On Thu, 7 Aug 2025 18:38:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Rename "libwixhelper" in "libmsica".

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26682#pullrequestreview-3098606661

From almatvee at openjdk.org  Thu Aug  7 20:48:12 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 7 Aug 2025 20:48:12 GMT
Subject: RFR: 8364129: Rename libwixhelper
In-Reply-To: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
Message-ID: <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>

On Thu, 7 Aug 2025 18:38:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Rename "libwixhelper" in "libmsica".

src/jdk.jpackage/windows/native/libwixhelper/libmsica.cpp line 1:

> 1: /*

Should we rename directory name as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26682#discussion_r2261362214

From liach at openjdk.org  Thu Aug  7 21:03:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 7 Aug 2025 21:03:10 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
In-Reply-To: <j_pHHyNIE3w2jY9ziSa5Mq1tS3ntmRSY20BVEj8buLs=.ba30a004-3826-4e87-b508-0304b35034fb@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
 <p3N5XRDiL9Ut7BaAB2jOSQc2Ih8aw-5jhMtOPVtu8pI=.a18902bd-2a1a-416b-94e1-22a70120e149@github.com>
 <I8oIVZBjlxfVo_d2EtrfH2SoSaUA88vsSSheCiEP-0o=.625f7dd0-ebca-4b68-9b8e-3840b0f42deb@github.com>
 <Dzjj_OsWnyp_KZnKM9zdAMp4RcbOGpIj1FfMF4aivMU=.26ed85a0-ac62-4d72-ac2d-827fcd4f39c6@github.com>
 <j_pHHyNIE3w2jY9ziSa5Mq1tS3ntmRSY20BVEj8buLs=.ba30a004-3826-4e87-b508-0304b35034fb@github.com>
Message-ID: <W1Xcs-_MFYrUqPpb4F0Jv7nNtN5wVvHJN6p1uJ_0SP0=.9cb07708-a14b-4a65-9fa5-1d5ab9bc1e7e@github.com>

On Thu, 7 Aug 2025 19:29:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Also, this cache mechanism was authored before JDK 8 introduced fast table cache in `ConcurrentHashMap`. In the long run, we may switch the ClassValueMap to a ConcurrentHashMap-derived structure, like a `ReferencedKeyMap`.
>
> Ah, OK, so this is already slow path, good. But are we sure overwriting cache entry _with (the live version of) itself_ would not break things? Looking at `addToCache` implemenation, I am not 100% convinced it is safe. Please check?

This was the code on JDK 24 GA:
https://github.com/openjdk/jdk/blob/6705a9255d28f351950e7fbca9d05e73942a4e27/src/java.base/share/classes/java/lang/ClassValue.java#L458-L468

This fix is essentially the same as the previous. The cache entry + version is like a bloom filter: if it exists and the version is right, we can ensure we get the right item. A cache entry with an invalid version is essentially invalid, but it stays in the cache unless accessed by cache update requests. Yes I know this may constitute a resource leak, which is tracked by https://bugs.openjdk.org/browse/JDK-8352622.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26679#discussion_r2261386354

From smarks at openjdk.org  Thu Aug  7 21:08:15 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 7 Aug 2025 21:08:15 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v7]
In-Reply-To: <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
Message-ID: <cxUKuBAnFqx0fbc9HAx9HRq0mI_yfROqDfWtq-k75fE=.923a22d8-8d28-4bb5-9245-17fe2a39af9f@github.com>

On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec

Intuitively, it feels to me like the invariant `min(a, b) == max(b, a)` would be useful when a and be compare equal. Still mulling this over....

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

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-3165699879

From erikj at openjdk.org  Thu Aug  7 21:11:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Aug 2025 21:11:12 GMT
Subject: RFR: 8364129: Rename libwixhelper
In-Reply-To: <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>
Message-ID: <zEzjSPPbjGEQBJJetvWWL0Q2-1C8YPF_yg2xNdkMZ0Q=.246e0a21-ad35-4e16-9c71-62bbbfc052bf@github.com>

On Thu, 7 Aug 2025 20:45:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Rename "libwixhelper" in "libmsica".
>
> src/jdk.jpackage/windows/native/libwixhelper/libmsica.cpp line 1:
> 
>> 1: /*
> 
> Should we rename directory name as well?

Without renaming the directory, I'm wondering how this could build at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26682#discussion_r2261397039

From duke at openjdk.org  Thu Aug  7 21:14:16 2025
From: duke at openjdk.org (Ayush Rigal)
Date: Thu, 7 Aug 2025 21:14:16 GMT
Subject: Integrated: 8364315: Remove unused xml files from
 test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/xmlfiles
In-Reply-To: <FYHMZIOXmUBPoCikESitbrwWeJ7V_sceOQxIK7_FJyc=.390777f0-d637-4f73-be1b-c7e551b9edb6@github.com>
References: <FYHMZIOXmUBPoCikESitbrwWeJ7V_sceOQxIK7_FJyc=.390777f0-d637-4f73-be1b-c7e551b9edb6@github.com>
Message-ID: <JvNA367qp-Umac8zR_IilboLlQNbzFwrs3XMRPmsHT0=.cb10ef2e-1a12-4f2a-91a2-e31079a7f9e9@github.com>

On Fri, 1 Aug 2025 11:59:23 GMT, Ayush Rigal <duke at openjdk.org> wrote:

> There are number of unused files in the XML test code base. These are not used in any tests and are not referenced within the code base. They appear to be legacy files. These can be removed.

This pull request has now been integrated.

Changeset: b8acbc3e
Author:    Ayush Rigal <ayush.rigal at oracle.com>
Committer: Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8acbc3ed8675ad4cc4b9dea69ee1e87c2a2ca45
Stats:     70 lines in 4 files changed: 0 ins; 70 del; 0 mod

8364315: Remove unused xml files from test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/xmlfiles

Reviewed-by: jpai, joehw

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

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

From jlu at openjdk.org  Thu Aug  7 21:53:23 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 21:53:23 GMT
Subject: RFR: 8364780: Ambiguity in DecimalFormatSymbols Unicode extension
 priority
Message-ID: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>

This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.

Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.

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

Commit messages:
 - copyright year
 - drive-by style changes
 - init

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

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

From darcy at openjdk.org  Thu Aug  7 22:01:14 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Aug 2025 22:01:14 GMT
Subject: RFR: 8358618: UnsupportedOperationException constructors javadoc
 is not clear [v3]
In-Reply-To: <fQlxwTv2P4mOsfMCzkBosXe9KdE0x3b6BWtHp_BoIxs=.6e538e5a-a8c5-40a7-a3c7-12cd4903d903@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
 <fQlxwTv2P4mOsfMCzkBosXe9KdE0x3b6BWtHp_BoIxs=.6e538e5a-a8c5-40a7-a3c7-12cd4903d903@github.com>
Message-ID: <QhhSQ_Y4uRh8pD65JsuJx9gayKlCaL8OayeMR0WPZ40=.916e1bcf-6df3-4953-81ff-8e581d79d041@github.com>

On Tue, 29 Jul 2025 15:00:11 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Alexey.

I think it is preferable for this PR to just update `UnsupportedOperationException` and leave any updates to `RuntimeException` to follow-up work.

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

PR Comment: https://git.openjdk.org/jdk/pull/26533#issuecomment-3165941804

From rriggs at openjdk.org  Thu Aug  7 22:05:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Aug 2025 22:05:55 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v2]
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: <KHzMuTmP9nQ47Myctv5PREoiPcgQNz7bb1PHzGZNZ9Q=.f1a2aa88-cf7a-4b1a-80bf-8a9f5c63391b@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:

  Updates from review comments:
   - Editorial improvements to javadoc
   - Exceptions that occur closing streams are quietly logged
     to the java.lang.Process system log as DEBUG
   - The prototype code attempting to wait for process exit is removed,
     it provided marginal benefit and raised complexity due to interrupt handling
   - Test updates for racy test cases that are not errors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/51355da2..c04ee6e2

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

  Stats: 128 lines in 4 files changed: 45 ins; 34 del; 49 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 rriggs at openjdk.org  Thu Aug  7 22:12:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Aug 2025 22:12:12 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v2]
In-Reply-To: <DY_N79zvVkePBetjJavDmxf0L3tarChBP1wZY-DuwfM=.8ff571d9-af2d-41a8-a0ee-554e4868b1cb@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
 <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>
 <oDlurhdPmv9Nn-VscSC1es7h7S542pL5jkixeBKRESs=.8f493b01-e7ce-4faa-84f4-058782cc6a64@github.com>
 <Hl0uh85aN1_VqbP1JqyGknImXh8BrXKEzmuU9q_zAQo=.656f22de-f153-4355-94c7-fcb6d78743d4@github.com>
 <oBF3eUakXaGz_3DZr7vb2yxGb_20NP0XDt6_xUg7i6A=.e9ce0946-6aea-4a69-ab2a-680b390537ad@github.com>
 <nr4a4rc8qfi7uZEdhpoykBGoclUN9go3hkXeSuhphrs=.c2a7a38f-5c6f-4129-b3f3-09cfbb5bbf7e@github.com>
 <ZSI1AO4cd-yhU7awvJISkH1LUyPzqOeWW1dD9W7tzu8=.d6c2c355-a80f-49a1-9f73-d5d1baf6fb8c@github.com>
 <DY_N79zvVkePBetjJavDmxf0L3tarChBP1wZY-DuwfM=.8ff571d9-af2d-41a8-a0ee-554e4868b1cb@github.com>
Message-ID: <ftzJH-LWJtr3fUli8jfCGMQZ_PJvVY636NiaL1QJOas=.90146b49-44b0-4237-84e8-e7d97f9e84a2@github.com>

On Wed, 6 Aug 2025 15:46:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Can we simply restore the interrupt after destroy()?
>> 
>> That's the suggestion... but now I'm thinking the correct solution?here is to just have `close()` declared to throw `InterruptedException` and not catch anything. Then we are leaving it up to the caller to decide what to do, rather than being forced to make an assumption one way or another.
>> 
>> In practice, there seem to be two typical scenarios when shutting things down using methods that block and throw `InterruptedException` (e.g., `ExecutorService.html.awaitTermination()`, `Process.waitFor()`, etc.):
>> 
>> Scenario 1: You want to ensure everything is properly and completely shutdown.
>> 
>> In this scenario you ignore `InterruptedException`s until each shutdown step fully completes: if any step throws an `InterruptedException`, you make a note of it, loop back around and restart that step. You don't return until all steps are complete. Just before returning, if you were interrupted at any point, you re-interrupt the current thread so the interrupt is not lost. You are optimizing for completeness.
>> 
>> Scenario 2: You want to start shutting things down, but if you are interrupted, you want to immediately bail out.
>> 
>> As soon as an interrupt occurs, stop trying to shut things down and return. You are optimizing for speed.
>> 
>> The problem is that if `Process.close()` isn't declared to throw `InterruptedException`, then that makes it impossible to implement scenario 1 (regardless of whether you re-interrupt the thread) because the caller has no way of knowing whether the process actually did terminate. And if you don't re-interrupt the thread, you also make it impossible to implement scenario 2.
>> 
>> So in my estimation re-interrupting the thread is better than not re-interrupting the thread, but regardless of that, there is still a problem if `Process.close()` isn't declared to throw `InterruptedException`.
>
> Indeed, the benefit of the attempt to be nice and not destroy the process too quickly is almost immediately overcome by the complexity of dealing with the side effects of the waitFor and the necessity to deal with interrupts both in the implementation and in the caller. Especially in an attempt to do something that the caller can do for themselves (calling waitFor).

The faulty implementation using waitFor is removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2261555962

From naoto at openjdk.org  Thu Aug  7 22:33:11 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Aug 2025 22:33:11 GMT
Subject: RFR: 8364780: Ambiguity in DecimalFormatSymbols Unicode extension
 priority
In-Reply-To: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
Message-ID: <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>

On Thu, 7 Aug 2025 21:47:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.
> 
> Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.

Thanks for cleaning this. This is definitely a leftover from [JDK-8186697](https://bugs.openjdk.org/browse/JDK-8186697). I think "cu" needs to have the same wording?

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 62:

> 60:  * your {@code DecimalFormat} and modify it.
> 61:  *
> 62:  * <p> The "rg" (region override) and "nu" (numbering system) {@code Locale}

Nit: extra space before "The"

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 93:

> 91:      */
> 92:     public DecimalFormatSymbols() {
> 93:         initialize(Locale.getDefault(Locale.Category.FORMAT));

Taking this opportunity, remove the surrounding spaces in the method itself: (L:817)

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

PR Review: https://git.openjdk.org/jdk/pull/26683#pullrequestreview-3098950525
PR Review Comment: https://git.openjdk.org/jdk/pull/26683#discussion_r2261559787
PR Review Comment: https://git.openjdk.org/jdk/pull/26683#discussion_r2261577832

From jlu at openjdk.org  Thu Aug  7 23:12:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 23:12:52 GMT
Subject: RFR: 8364780: Ambiguity in DecimalFormatSymbols Unicode extension
 priority [v2]
In-Reply-To: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
Message-ID: <ImEKgNnTaT7q4fFbDnfjcLBpnSr0laakJ1olywKN_fM=.669c94cf-7aac-4541-833a-c9a9abf6ffed@github.com>

> This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.
> 
> Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26683/files
  - new: https://git.openjdk.org/jdk/pull/26683/files/cc8766c2..78b223a1

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

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

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

From jlu at openjdk.org  Thu Aug  7 23:13:03 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 23:13:03 GMT
Subject: RFR: 8364780: Ambiguity in DecimalFormatSymbols Unicode extension
 priority [v2]
In-Reply-To: <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
 <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>
Message-ID: <1VnbrlavShyntUVeidofp3HvKiGbYRD3lR5zfY_5wcs=.92322406-1422-4f10-acd1-0b08c8a6a254@github.com>

On Thu, 7 Aug 2025 22:30:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect comments
>
> Thanks for cleaning this. This is definitely a leftover from [JDK-8186697](https://bugs.openjdk.org/browse/JDK-8186697). I think "cu" needs to have the same wording?

@naotoj You are right regarding "cu"; updated the PR as such. I am wondering if NumberFormat should also mention "cu" as well then under its own Unicode Extensions section, (which I can include in this change).

Let me know if the new wording changes make sense to you, or if you have a different way of implying that "nu" and "cu" both have priority over "rg" for their respective values.

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

PR Comment: https://git.openjdk.org/jdk/pull/26683#issuecomment-3166098671

From naoto at openjdk.org  Thu Aug  7 23:21:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Aug 2025 23:21:10 GMT
Subject: RFR: 8364780: Ambiguity in DecimalFormatSymbols Unicode extension
 priority [v2]
In-Reply-To: <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
 <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>
Message-ID: <4HXOlgVnTz7CJwc0PX5FmxIbCLttl1Hs39biCakF7qc=.4cbc152c-aaa4-4a7e-af70-8dfa13faeffd@github.com>

On Thu, 7 Aug 2025 22:30:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect comments
>
> Thanks for cleaning this. This is definitely a leftover from [JDK-8186697](https://bugs.openjdk.org/browse/JDK-8186697). I think "cu" needs to have the same wording?

> @naotoj You are right regarding "cu"; updated the PR as such. I am wondering if NumberFormat should also mention "cu" as well then under its own Unicode Extensions section, (which I can include in this change).

I think so. NumberFormat can also be affected by "cu" extension.

> Let me know if the new wording changes make sense to you, or if you have a different way of implying that "nu" and "cu" both have priority over "rg" for their respective values.

The wording is fine to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/26683#issuecomment-3166111072

From jlu at openjdk.org  Thu Aug  7 23:39:23 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 23:39:23 GMT
Subject: RFR: 8364780: Ambiguity in DecimalFormatSymbols Unicode extension
 priority [v3]
In-Reply-To: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
Message-ID: <6LGXcj0ZtmN5ptgfuAtg9uznc9gdAz6K78xzYrQjEOg=.93b9b720-d32b-48c2-a442-0b5134c24d53@github.com>

> This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.
> 
> Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Updating NumberFormat with cu as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26683/files
  - new: https://git.openjdk.org/jdk/pull/26683/files/78b223a1..3a1e6ab2

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

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

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

From asemenyuk at openjdk.org  Fri Aug  8 01:06:19 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 01:06:19 GMT
Subject: RFR: 8364129: Rename libwixhelper
In-Reply-To: <zEzjSPPbjGEQBJJetvWWL0Q2-1C8YPF_yg2xNdkMZ0Q=.246e0a21-ad35-4e16-9c71-62bbbfc052bf@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>
 <zEzjSPPbjGEQBJJetvWWL0Q2-1C8YPF_yg2xNdkMZ0Q=.246e0a21-ad35-4e16-9c71-62bbbfc052bf@github.com>
Message-ID: <-BIeyiFMGyJ7ENGH-11vvcurxCU6xidX0qa5QjeNgu8=.384c5cd9-7d84-47ed-970a-c459fe440fd4@github.com>

On Thu, 7 Aug 2025 21:08:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> src/jdk.jpackage/windows/native/libwixhelper/libmsica.cpp line 1:
>> 
>>> 1: /*
>> 
>> Should we rename directory name as well?
>
> Without renaming the directory, I'm wondering how this could build at all.

Good catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26682#discussion_r2261727643

From ghan at openjdk.org  Fri Aug  8 01:10:27 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Fri, 8 Aug 2025 01:10:27 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <tdc7Jw7KTyE8lwfKkUSZFte-_w9jZ_0W7YtlNC948X0=.e3aeccd0-6d0a-4ecd-8009-604394d7e612@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
 <tdc7Jw7KTyE8lwfKkUSZFte-_w9jZ_0W7YtlNC948X0=.e3aeccd0-6d0a-4ecd-8009-604394d7e612@github.com>
Message-ID: <YhEvAcC6nsSch04Gdaa5R1AS0ewHPcJOPGdtI3jCGTk=.a91bbd36-1a03-4997-8de2-4aabae1850f2@github.com>

On Thu, 7 Aug 2025 14:06:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update os_linux.cpp
>>   
>>   a small fix
>
> Looks good, thanks

hi @RogerRiggs, thank you for your review and approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/26667#issuecomment-3166268830

From acobbs at openjdk.org  Fri Aug  8 01:28:14 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 8 Aug 2025 01:28:14 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v2]
In-Reply-To: <ftzJH-LWJtr3fUli8jfCGMQZ_PJvVY636NiaL1QJOas=.90146b49-44b0-4237-84e8-e7d97f9e84a2@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <R9djEMdpTORfo7LzjkZjZ7wGetw5Q_3MFLsC3XPN9G4=.6b02c703-0af5-44e8-9747-289b5b671de3@github.com>
 <fGgMuuUXwrqGsCIJcO_YtXSZjkbLkyflGH69cQByJ3M=.9810f1cb-fae1-4f40-8efe-41a1629521a1@github.com>
 <oDlurhdPmv9Nn-VscSC1es7h7S542pL5jkixeBKRESs=.8f493b01-e7ce-4faa-84f4-058782cc6a64@github.com>
 <Hl0uh85aN1_VqbP1JqyGknImXh8BrXKEzmuU9q_zAQo=.656f22de-f153-4355-94c7-fcb6d78743d4@github.com>
 <oBF3eUakXaGz_3DZr7vb2yxGb_20NP0XDt6_xUg7i6A=.e9ce0946-6aea-4a69-ab2a-680b390537ad@github.com>
 <nr4a4rc8qfi7uZEdhpoykBGoclUN9go3hkXeSuhphrs=.c2a7a38f-5c6f-4129-b3f3-09cfbb5bbf7e@github.com>
 <ZSI1AO4cd-yhU7awvJISkH1LUyPzqOeWW1dD9W7tzu8=.d6c2c355-a80f-49a1-9f73-d5d1baf6fb8c@github.com>
 <DY_N79zvVkePBetjJavDmxf0L3tarChBP1wZY-DuwfM=.8ff571d9-af2d-41a8-a0ee-554e4868b1cb@github.com>
 <ftzJH-LWJtr3fUli8jfCGMQZ_PJvVY636NiaL1QJOas=.90146b49-44b0-4237-84e8-e7d97f9e84a2@github.com>
Message-ID: <Xo9xCho-r6PMerSZY4IofEJUvTS0BMYccfKslo5MK8g=.daf5646b-f114-4373-824c-7f8d16a0f432@github.com>

On Thu, 7 Aug 2025 22:09:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The faulty implementation using waitFor is removed.

I agree this makes more sense: in `close()` the process and the three I/O streams are being shutdown immediately (i.e., ungracefully if necessary). This kind of "abrupt close" is the appropriate last ditch action when trying to wrap up a try-with-resources block.

On the other hand, if the caller wants a more graceful shutdown of the process and/or the I/O streams (even if they are also using try-with-resources) then they can do that manually themselves, using `waitFor()` or whatever.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2261744520

From jjiang at openjdk.org  Fri Aug  8 02:31:15 2025
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 8 Aug 2025 02:31:15 GMT
Subject: Integrated: 8364597: Replace THL A29 Limited with Tencent
In-Reply-To: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
References: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
Message-ID: <lUxnGf2cVXWfHR38WmZQVPwfzfBnjtOcc2Re_omkeGw=.c64c63b7-e7dd-48e1-b6f7-f0a1ebefaf56@github.com>

On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `THL A29 Limited` was a `Tencent` company but was dissolved.
> So, the copyright notes just use `Tencent` directly.

This pull request has now been integrated.

Changeset: 4c9eadda
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c9eaddaef83c6ba30e27ae3e0d16caeeec206cb
Stats:     67 lines in 58 files changed: 0 ins; 9 del; 58 mod

8364597: Replace THL A29 Limited with Tencent

Reviewed-by: jiefu

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

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

From almatvee at openjdk.org  Fri Aug  8 02:55:14 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 8 Aug 2025 02:55:14 GMT
Subject: RFR: 8364564: Shortcut configuration is not recorded in
 .jpackage.xml file
In-Reply-To: <MhCnt1vlEqWvEo32SllLqONZUwKo-YJD80oEpN19kEY=.08edccd1-dc94-4472-87b1-59af941829a8@github.com>
References: <MhCnt1vlEqWvEo32SllLqONZUwKo-YJD80oEpN19kEY=.08edccd1-dc94-4472-87b1-59af941829a8@github.com>
Message-ID: <DT3bZHT72zbmQ1C-XL03WnAI-6cwW3Io6Y14-E-PuKw=.d9711ee7-2f3f-4750-aaab-139fd1004573@github.com>

On Sat, 2 Aug 2025 03:46:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Add `LauncherShortcut` and `LauncherShortcutStartupDirectory` types to the model to define launcher shortcuts. For now `LauncherShortcutStartupDirectory` enum has a single value. It will be extended in [JDK-8308349](https://bugs.openjdk.org/browse/JDK-8308349) enhancement.
> - Replace `WinLauncherMixin.shortcuts()` with `WinLauncherMixin.startMenuShortcut()` and `WinLauncherMixin.desktopShortcut()`.
> - Remove redundant `StandardBundlerParam.SHORTCUT_HINT` and `StandardBundlerParam.MENU_HINT`; use "win-shortcut", "win-menu", and "linux-shortcut" values instead of "shortcut" and "menu" to store launcher shortcut configuration in the ".jpackage.xml" file.
> - Add tests for launcher shortcut configuration in the ".jpackage.xml" file.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26604#pullrequestreview-3099314206

From stuefe at openjdk.org  Fri Aug  8 05:25:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 05:25:02 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v4]
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

Thomas Stuefe 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
 - fix comments about closeDescriptors
 - Feedback Roger
 - tolerate sigaction failing
 - Fixes
 - fix
 - start+repro-case

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

Changes: https://git.openjdk.org/jdk/pull/26615/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26615&range=03
  Stats: 196 lines in 5 files changed: 195 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26615/head:pull/26615

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

From stuefe at openjdk.org  Fri Aug  8 05:25:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 05:25:02 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v3]
In-Reply-To: <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>
 <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>
Message-ID: <8ow-rAWzGKO5n8jjb63h28wf-woWRT04Z0L1vI1qWgM=.0ccb6e34-75b6-42b3-aee5-40d1085e5a16@github.com>

On Thu, 7 Aug 2025 14:17:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It looks like I created a merge conflict by asking to fix these. Another PR https://git.openjdk.org/jdk/pull/26667 is also changing them. (At the time the other PR had not started). The least chaos may be created by backing out those changes from this PR. (Unless you like your words better than PR#26667).

Okay, I removed my comments again.

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3166614792

From shade at openjdk.org  Fri Aug  8 08:45:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 8 Aug 2025 08:45:13 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
In-Reply-To: <W1Xcs-_MFYrUqPpb4F0Jv7nNtN5wVvHJN6p1uJ_0SP0=.9cb07708-a14b-4a65-9fa5-1d5ab9bc1e7e@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
 <p3N5XRDiL9Ut7BaAB2jOSQc2Ih8aw-5jhMtOPVtu8pI=.a18902bd-2a1a-416b-94e1-22a70120e149@github.com>
 <I8oIVZBjlxfVo_d2EtrfH2SoSaUA88vsSSheCiEP-0o=.625f7dd0-ebca-4b68-9b8e-3840b0f42deb@github.com>
 <Dzjj_OsWnyp_KZnKM9zdAMp4RcbOGpIj1FfMF4aivMU=.26ed85a0-ac62-4d72-ac2d-827fcd4f39c6@github.com>
 <j_pHHyNIE3w2jY9ziSa5Mq1tS3ntmRSY20BVEj8buLs=.ba30a004-3826-4e87-b508-0304b35034fb@github.com>
 <W1Xcs-_MFYrUqPpb4F0Jv7nNtN5wVvHJN6p1uJ_0SP0=.9cb07708-a14b-4a65-9fa5-1d5ab9bc1e7e@github.com>
Message-ID: <ox1YxCoITuARE_TbGAPpV5TfbztZu2IzPKEflb22UXs=.7112ef6e-f8ab-4e9c-9e38-60a1076832f6@github.com>

On Thu, 7 Aug 2025 21:00:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ah, OK, so this is already slow path, good. But are we sure overwriting cache entry _with (the live version of) itself_ would not break things? Looking at `addToCache` implemenation, I am not 100% convinced it is safe. Please check?
>
> This was the code on JDK 24 GA:
> https://github.com/openjdk/jdk/blob/6705a9255d28f351950e7fbca9d05e73942a4e27/src/java.base/share/classes/java/lang/ClassValue.java#L458-L468
> 
> This fix is essentially the same as the previous. The cache entry + version is like a bloom filter: if it exists and the version is right, we can ensure we get the right item. A cache entry with an invalid version is essentially invalid, but it stays in the cache unless accessed by cache update requests. Yes I know this may constitute a resource leak, which is tracked by https://bugs.openjdk.org/browse/JDK-8352622.

OK, thanks, that is convincing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26679#discussion_r2262324768

From pminborg at openjdk.org  Fri Aug  8 09:36:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 8 Aug 2025 09:36:14 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v2]
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <UJmXmFaUB38DbtFUhX9z0omvJVwIuR51w4H9oRlUeuc=.28ee40a2-395e-48e1-b6ef-f6470b831f07@github.com>

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
> 
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Optimize copy for certain lengths

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26672/files
  - new: https://git.openjdk.org/jdk/pull/26672/files/7d4c7881..b60832ce

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

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

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

From pminborg at openjdk.org  Fri Aug  8 09:40:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 8 Aug 2025 09:40:13 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v2]
In-Reply-To: <UJmXmFaUB38DbtFUhX9z0omvJVwIuR51w4H9oRlUeuc=.28ee40a2-395e-48e1-b6ef-f6470b831f07@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <UJmXmFaUB38DbtFUhX9z0omvJVwIuR51w4H9oRlUeuc=.28ee40a2-395e-48e1-b6ef-f6470b831f07@github.com>
Message-ID: <TLgRm3Qk5O7NhvcKAgpV6fyR9Pn8n7VAMz4NMQUbx9I=.0c6876e2-8844-4c95-b34e-3f233e070e3d@github.com>

On Fri, 8 Aug 2025 09:36:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize copy for certain lengths

The latest version improves performance further:

Bytes | Base | Patch | Iprovement
-- | -- | -- | --
2 | 3.184 | 2.836 | 10.93%
3 | 3.162 | 2.833 | 10.40%
4 | 3.344 | 2.839 | 15.10%
5 | 3.31 | 2.83 | 14.50%
6 | 3.328 | 2.846 | 14.48%
7 | 3.289 | 2.841 | 13.62%
8 | 4.139 | 2.834 | 31.53%
12 | 4.709 | 2.837 | 39.75%
16 | 4.173 | 3.749 | 10.16%
24 | 4.239 | 4.097 | 3.35%
64 | 4.86 | 4.716 | 2.96%

<img width="828" height="519" alt="image" src="https://github.com/user-attachments/assets/74d4aa1b-17f7-4ae6-9ff0-8e68f243be10" />

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

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3167220028

From rsunderbabu at openjdk.org  Fri Aug  8 09:40:24 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Fri, 8 Aug 2025 09:40:24 GMT
Subject: RFR: 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 frequently fails with SerialGC
Message-ID: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>

VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue. During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.

Testing: Tiers1,2,3 and other ties where the test runs.

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

Commit messages:
 - 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java frequently fails with SerialGC

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

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

From shade at openjdk.org  Fri Aug  8 09:43:15 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 8 Aug 2025 09:43:15 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
In-Reply-To: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
Message-ID: <NSlQFUO5rnYtYs966LlMQQ9BJbw1qONzrxQAI3tqW8Y=.8f67db89-6fd6-4e9b-9801-a70641e35ec3@github.com>

On Thu, 7 Aug 2025 16:23:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.
> 
> This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.

Looks reasonable to me, thanks! This would need to be eventually backported to JDK 25u.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26679#pullrequestreview-3100145422

From lbourges at openjdk.org  Fri Aug  8 10:02:16 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 8 Aug 2025 10:02:16 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v2]
In-Reply-To: <UJmXmFaUB38DbtFUhX9z0omvJVwIuR51w4H9oRlUeuc=.28ee40a2-395e-48e1-b6ef-f6470b831f07@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <UJmXmFaUB38DbtFUhX9z0omvJVwIuR51w4H9oRlUeuc=.28ee40a2-395e-48e1-b6ef-f6470b831f07@github.com>
Message-ID: <zEghdx6hyoouGRdnvE4YswDCoQZ0TWv_7MYcPvz36mU=.3ccb591f-6a0c-45db-82c7-a8efd2aad642@github.com>

On Fri, 8 Aug 2025 09:36:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize copy for certain lengths

Great win!

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

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3167295128

From alanb at openjdk.org  Fri Aug  8 10:48:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Aug 2025 10:48:15 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v2]
In-Reply-To: <KHzMuTmP9nQ47Myctv5PREoiPcgQNz7bb1PHzGZNZ9Q=.f1a2aa88-cf7a-4b1a-80bf-8a9f5c63391b@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <KHzMuTmP9nQ47Myctv5PREoiPcgQNz7bb1PHzGZNZ9Q=.f1a2aa88-cf7a-4b1a-80bf-8a9f5c63391b@github.com>
Message-ID: <7JywI1LBZ8WJr1y5fkvJH2_v3seCfRd-bjKb2DZFguU=.7e8c22d9-3b97-4220-8ae0-ebe1f80cc51f@github.com>

On Thu, 7 Aug 2025 22:05:55 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:
> 
>   Updates from review comments:
>    - Editorial improvements to javadoc
>    - Exceptions that occur closing streams are quietly logged
>      to the java.lang.Process system log as DEBUG
>    - The prototype code attempting to wait for process exit is removed,
>      it provided marginal benefit and raised complexity due to interrupt handling
>    - Test updates for racy test cases that are not errors

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

> 653:         quietClose(outputWriter != null ? outputWriter : getOutputStream());
> 654:         quietClose(inputReader != null ? inputReader  : getInputStream());
> 655:         quietClose(errorReader != null ? errorReader : getErrorStream());

Async close of process stream is a complicated here. Do you have a summary on how it behaves on both Unix and Windows? I'm thinking about the deferred close code in particular. (I don't have an issue with close throwing away the exceptions, I'm just not 100% sure that async close is reliable in the first place).

> Closing an already closed stream usually has no effect but is specific to the stream.

I wonder if we could specify Process::close to be idempotent. That would mean we couldn't attempt to re-close if a first close of stream failed or had some other side effect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2262608881

From nbenalla at openjdk.org  Fri Aug  8 10:56:11 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 8 Aug 2025 10:56:11 GMT
Subject: RFR: 8358618: UnsupportedOperationException constructors javadoc
 is not clear [v3]
In-Reply-To: <lZ5gNliNJBRuD4sL1fTOBl1jVUhFXmAO_TsxdPzi7ho=.a3db1cd4-b2b0-4b92-afa1-a3726bd24cb6@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
 <fQlxwTv2P4mOsfMCzkBosXe9KdE0x3b6BWtHp_BoIxs=.6e538e5a-a8c5-40a7-a3c7-12cd4903d903@github.com>
 <lZ5gNliNJBRuD4sL1fTOBl1jVUhFXmAO_TsxdPzi7ho=.a3db1cd4-b2b0-4b92-afa1-a3726bd24cb6@github.com>
Message-ID: <3r7K4JuZ5JD_TftOhst0NVzTtJ0BYRv77lag78Rw0_s=.5b76cd8c-bee5-411e-a99e-794951fcfa60@github.com>

On Thu, 7 Aug 2025 16:04:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Alexey.
>
> src/java.base/share/classes/java/lang/UnsupportedOperationException.java line 60:
> 
>> 58:     /**
>> 59:      * Constructs a new {@code UnsupportedOperationException} with the specified detail message and
>> 60:      * cause.
> 
> Suggestion:
> 
>      * Constructs a new {@code UnsupportedOperationException} with the specified
>      * detail message and cause.
> 
> I'm for wrapping the line after the word ?specified? to fit into 80 columns.

Thanks for catching this, I use 100 character wrapping so I didn't notice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26533#discussion_r2262626169

From nbenalla at openjdk.org  Fri Aug  8 11:01:09 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 8 Aug 2025 11:01:09 GMT
Subject: RFR: 8358618: UnsupportedOperationException constructors javadoc
 is not clear [v4]
In-Reply-To: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
Message-ID: <7J21y9GDvVNl9gin_zJX1zERHdhOa1CwlWHht2gb4GQ=.5983618a-2e4f-43c6-b8eb-6c24bfac4417@github.com>

> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  revert changes to RuntimeException.java
  Wrap lines at 80 chars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26533/files
  - new: https://git.openjdk.org/jdk/pull/26533/files/965d5263..c11e9dbb

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

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

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

From myankelevich at openjdk.org  Fri Aug  8 11:30:12 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 8 Aug 2025 11:30:12 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v2]
In-Reply-To: <UJmXmFaUB38DbtFUhX9z0omvJVwIuR51w4H9oRlUeuc=.28ee40a2-395e-48e1-b6ef-f6470b831f07@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <UJmXmFaUB38DbtFUhX9z0omvJVwIuR51w4H9oRlUeuc=.28ee40a2-395e-48e1-b6ef-f6470b831f07@github.com>
Message-ID: <LVIEsDrn0qrY6Uv9dRQ7i2gNu3ubHGlk9JaVa0cYsJA=.db52bc4e-3853-4012-b2a2-c57bbc48ad48@github.com>

On Fri, 8 Aug 2025 09:36:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize copy for certain lengths

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkCopy.java line 49:

> 47: @State(Scope.Thread)
> 48: @OutputTimeUnit(TimeUnit.NANOSECONDS)
> 49: @Fork(value = 3)

Nit: could you please update the copyright

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26672#discussion_r2262693639

From aturbanov at openjdk.org  Fri Aug  8 12:42:13 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 8 Aug 2025 12:42:13 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
In-Reply-To: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
Message-ID: <PgL95Eqofkgv8--APA4miTFX9-ASBGaB1cOdk1paRSY=.cddcd6a2-ad74-4f91-bcca-d4189cec13eb@github.com>

On Thu, 7 Aug 2025 16:23:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.
> 
> This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.

test/jdk/java/lang/invoke/ClassValueTest.java line 484:

> 482:     // unrelated entry is removed
> 483:     @Test
> 484:     public void cacheRefreshTest() throws Throwable {

All other test methods in this class use test* naming. Let's follow it for consistency

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26679#discussion_r2262867735

From pminborg at openjdk.org  Fri Aug  8 12:52:26 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 8 Aug 2025 12:52:26 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v3]
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <_dlH0IjRLKHcUH9rIVwsqQ8bDU01c-DzHAvbH1XjNso=.436fb74c-2527-4fb4-bf37-3a6216d2c58d@github.com>

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
> 
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add a branchless overlaps method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26672/files
  - new: https://git.openjdk.org/jdk/pull/26672/files/b60832ce..fc4f00bb

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

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

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

From asemenyuk at openjdk.org  Fri Aug  8 13:01:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 13:01:52 GMT
Subject: RFR: 8364129: Rename libwixhelper [v2]
In-Reply-To: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
Message-ID: <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>

> Rename "libwixhelper" in "libmsica".

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

  Rename libwixhelper dir

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26682/files
  - new: https://git.openjdk.org/jdk/pull/26682/files/358c24e6..60b30953

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

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

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

From asemenyuk at openjdk.org  Fri Aug  8 13:01:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 13:01:52 GMT
Subject: RFR: 8364129: Rename libwixhelper [v2]
In-Reply-To: <-BIeyiFMGyJ7ENGH-11vvcurxCU6xidX0qa5QjeNgu8=.384c5cd9-7d84-47ed-970a-c459fe440fd4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>
 <zEzjSPPbjGEQBJJetvWWL0Q2-1C8YPF_yg2xNdkMZ0Q=.246e0a21-ad35-4e16-9c71-62bbbfc052bf@github.com>
 <-BIeyiFMGyJ7ENGH-11vvcurxCU6xidX0qa5QjeNgu8=.384c5cd9-7d84-47ed-970a-c459fe440fd4@github.com>
Message-ID: <z3TWLCzoXuNpQkZnPCaZW5SqQA6VWuaFoPG6d0dOwOM=.6c704418-369d-446a-b8e1-a0cbe0593300@github.com>

On Fri, 8 Aug 2025 01:03:58 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Without renaming the directory, I'm wondering how this could build at all.
>
> Good catch!

> Without renaming the directory, I'm wondering how this could build at all.

It did, but fortunately one windows test failed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26682#discussion_r2262904670

From pminborg at openjdk.org  Fri Aug  8 13:25:27 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 8 Aug 2025 13:25:27 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v4]
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <LySAnsAPi6NdYJ04UFVOywDf6a2-HS7jYTW7traho3A=.b0988f84-4c1c-428d-b403-1e697afaaac9@github.com>

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
> 
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26672/files
  - new: https://git.openjdk.org/jdk/pull/26672/files/fc4f00bb..c37cd69d

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

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

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

From vyazici at openjdk.org  Fri Aug  8 13:38:31 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 13:38:31 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v2]
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <6LY-pGXEYGVLE2sAYTG8175PvnICXFoHw4velrtLk8E=.dc8a5a32-5c4f-44fa-a281-c5516a22b4bb@github.com>

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

Volkan Yazici 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:

 - Group `String` methods by `doReplace` argument
 - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
 - Replace `requireNonNull` with implicit null checks
 - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
 - Improve docs of touched methods and add NPE checks
 - Convert IAE-throwing methods into CCE-throwing ones
 - Rename `JavaLangAccess::*NoRepl` methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26413/files
  - new: https://git.openjdk.org/jdk/pull/26413/files/5f555a68..1fb8582e

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

  Stats: 18798 lines in 552 files changed: 11544 ins; 5896 del; 1358 mod
  Patch: https://git.openjdk.org/jdk/pull/26413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26413/head:pull/26413

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

From erikj at openjdk.org  Fri Aug  8 13:39:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Aug 2025 13:39:12 GMT
Subject: RFR: 8364129: Rename libwixhelper [v2]
In-Reply-To: <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>
Message-ID: <ZVPIc6oMMeqfOsD9pOOq_e0UxqU87z8u4D-E4_3Aaos=.bf541b49-941c-4aba-be84-2625e40b8f7c@github.com>

On Fri, 8 Aug 2025 13:01:52 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Rename "libwixhelper" in "libmsica".
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename libwixhelper dir

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26682#pullrequestreview-3100868948

From vyazici at openjdk.org  Fri Aug  8 13:51:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 13:51:10 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <WObG1v-uiiW5td-qzSA06iRjh3U8fzfnKqX4DZf3gLE=.f63ef6b7-0e32-4345-8bec-24e7925b2b20@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <WObG1v-uiiW5td-qzSA06iRjh3U8fzfnKqX4DZf3gLE=.f63ef6b7-0e32-4345-8bec-24e7925b2b20@github.com>
Message-ID: <4vNV2kY5DmMEoWtuq40MzP2BnudJysIwgcjxJpldxBY=.735cf122-f7bb-4d4c-a2ff-7d49cf86d0bf@github.com>

On Tue, 29 Jul 2025 13:25:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> If CCE should have a constructor with a message, it can be added if you have a clear idea how it would be used.

Motivated by @RogerRiggs inquiries, and @AlanBateman's below remark,

> Another high level comment from a first read is that it feels like there are two forms needed. One form is REPLACE action and doesn't throw. The other is REPORT action and throws CharacterCodingException.

grouped `String` methods by `doReplace` argument in 1fb8582e3f9. There are several `String` methods of the following form:

    private static byte[] encode8859_1(..., boolean doReplace) {
        // ...
        if (!doReplace) {
            throwUnmappable(sp);
        }
        // ...
     }

We want to make `doReplace = false` case visible in the function footprint, and this resulted in:

    private static byte[] encode8859_1(..., boolean doReplace) throws CCE { ... }

Though this propagates the checked `CCE` even for `doReplace = true`. To avoid this, I've grouped methods by `doReplace` argument into two:

    private static byte[] encode8859_1(...) { ... }
    private static byte[] encode8859_1NoReplacement(...) throws CCE { ... }

As a result,

1. `doReplace = true` call-sites invoke `encode8859_1()`, replacement *will* occur, and there is no checked `CCE` thrown
2. `doReplace = false` call-sites invoke `encode8859_1NoReplacement()`, replacement will *not* occur, and `CCE` needs to be handled

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

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3167985180

From cjplummer at openjdk.org  Fri Aug  8 14:21:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 8 Aug 2025 14:21:17 GMT
Subject: RFR: 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 frequently fails with SerialGC
In-Reply-To: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
References: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
Message-ID: <igwpweeSKNcZAGqeloIADzgXs5Yxwbip-K-jG53OL4s=.fddd0e98-a506-4771-af0c-4f3d41dcaa45@github.com>

On Fri, 8 Aug 2025 09:32:51 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue. During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

The changes are fine, but I'm not so sure it is appropriate to use JDK-8313655 for this PR. Perhaps create a subtask to re-enable SerialGC use, and close JDK-8313655 as "Cannot Reproduce"

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

PR Review: https://git.openjdk.org/jdk/pull/26690#pullrequestreview-3101036718

From rriggs at openjdk.org  Fri Aug  8 15:07:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Aug 2025 15:07:17 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v4]
In-Reply-To: <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>
Message-ID: <tTtYOfGIYxI6b1zdtvFiD60sX1hxyfse8vL3omdTLE8=.7a4766ba-180a-44f1-a382-efa2ab8d345c@github.com>

On Fri, 8 Aug 2025 05:25:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
>> 
>> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
>> 
>> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
>> 
>> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.
>
> Thomas Stuefe 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
>  - fix comments about closeDescriptors
>  - Feedback Roger
>  - tolerate sigaction failing
>  - Fixes
>  - fix
>  - start+repro-case

Looks good, Thanks.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26615#pullrequestreview-3101175850

From stuefe at openjdk.org  Fri Aug  8 15:25:15 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 15:25:15 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v3]
In-Reply-To: <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>
 <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>
Message-ID: <3qqEGFbrUy-TCwnzUT1vPGmbCS8zuIL5iZAn-ylmKeg=.8b43f058-920b-4064-8897-3bad11bbe23c@github.com>

On Thu, 7 Aug 2025 14:17:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix comments about closeDescriptors
>
> It looks like I created a merge conflict by asking to fix these.  
> Another PR https://git.openjdk.org/jdk/pull/26667 is also changing them. (At the time the other PR had not started).
> The least chaos may be created by backing out those changes from this PR.  (Unless you like your words better than PR#26667).

Thanks @RogerRiggs and @erikj79 !

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3168292525

From rriggs at openjdk.org  Fri Aug  8 15:30:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Aug 2025 15:30:17 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v4]
In-Reply-To: <gRqOTSGg7cHFNKd3Z-MacgeE52i09SZ7L3G28NyPSDY=.df63d950-f2f6-453f-b098-c0513750b298@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <gRqOTSGg7cHFNKd3Z-MacgeE52i09SZ7L3G28NyPSDY=.df63d950-f2f6-453f-b098-c0513750b298@github.com>
Message-ID: <jl0Mu2cqAqBMQyp8pLNMSnvFUIrW_xawO7eggnWG_T8=.dc29c76e-1d40-4e94-8388-8b3513c5144a@github.com>

On Wed, 6 Aug 2025 12:22:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Thomas Stuefe 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
>>  - fix comments about closeDescriptors
>>  - Feedback Roger
>>  - tolerate sigaction failing
>>  - Fixes
>>  - fix
>>  - start+repro-case
>
> Build changes look trivially good.

@erikj79 Please re-review; Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3168308584

From rriggs at openjdk.org  Fri Aug  8 15:55:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Aug 2025 15:55:16 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v2]
In-Reply-To: <7JywI1LBZ8WJr1y5fkvJH2_v3seCfRd-bjKb2DZFguU=.7e8c22d9-3b97-4220-8ae0-ebe1f80cc51f@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <KHzMuTmP9nQ47Myctv5PREoiPcgQNz7bb1PHzGZNZ9Q=.f1a2aa88-cf7a-4b1a-80bf-8a9f5c63391b@github.com>
 <7JywI1LBZ8WJr1y5fkvJH2_v3seCfRd-bjKb2DZFguU=.7e8c22d9-3b97-4220-8ae0-ebe1f80cc51f@github.com>
Message-ID: <wjlUniJmhcmiI_fOxwarGoYsIcFP7pi9Zzg4BtqfJJI=.84d1e67c-031f-47af-814b-2365a21d09b2@github.com>

On Fri, 8 Aug 2025 10:45:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates from review comments:
>>    - Editorial improvements to javadoc
>>    - Exceptions that occur closing streams are quietly logged
>>      to the java.lang.Process system log as DEBUG
>>    - The prototype code attempting to wait for process exit is removed,
>>      it provided marginal benefit and raised complexity due to interrupt handling
>>    - Test updates for racy test cases that are not errors
>
> src/java.base/share/classes/java/lang/Process.java line 655:
> 
>> 653:         quietClose(outputWriter != null ? outputWriter : getOutputStream());
>> 654:         quietClose(inputReader != null ? inputReader  : getInputStream());
>> 655:         quietClose(errorReader != null ? errorReader : getErrorStream());
> 
> Async close of process stream is a complicated here. Do you have a summary on how it behaves on both Unix and Windows? I'm thinking about the deferred close code in particular. (I don't have an issue with close throwing away the exceptions, I'm just not 100% sure that async close is reliable in the first place).
> 
>> Closing an already closed stream usually has no effect but is specific to the stream.
> 
> I wonder if we could specify Process::close to be idempotent. That would mean we couldn't attempt to re-close if a first close of stream failed or had some other side effect.

That would remove any question about behavior without having to delve into the details of every stream close.
Down at the bottom of every process stream is a FileDescriptor holding either an fd (Linux) or a handle (Windows).
This is true for all the redirects whether to files, pipes, or inherited (stdin, stdout, stderr). The FileDescritor.close method is very careful to impotently close and reset the fd/handle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2263336699

From rriggs at openjdk.org  Fri Aug  8 16:07:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Aug 2025 16:07:11 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v4]
In-Reply-To: <LySAnsAPi6NdYJ04UFVOywDf6a2-HS7jYTW7traho3A=.b0988f84-4c1c-428d-b403-1e697afaaac9@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <LySAnsAPi6NdYJ04UFVOywDf6a2-HS7jYTW7traho3A=.b0988f84-4c1c-428d-b403-1e697afaaac9@github.com>
Message-ID: <nSTF7HbN6TzYMd9jBf14oetXa5OwlTUT_zeuV3n8TAU=.5703b535-92de-4a21-8ffc-778aac3f14f1@github.com>

On Fri, 8 Aug 2025 13:25:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

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

> 264: 
> 265:             // The below computation is a branchless equivalent to
> 266:             // `return (thisStart < thatEnd && thisEnd > thatStart)?1:0;`. Here is how:

It would be pretty cool if C2 could do the optimization of branch-less computations like these.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26672#discussion_r2263379446

From naoto at openjdk.org  Fri Aug  8 16:44:14 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Aug 2025 16:44:14 GMT
Subject: RFR: 8364780: Unicode extension clarifications for
 NumberFormat/DecimalFormatSymbols [v3]
In-Reply-To: <6LGXcj0ZtmN5ptgfuAtg9uznc9gdAz6K78xzYrQjEOg=.93b9b720-d32b-48c2-a442-0b5134c24d53@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
 <6LGXcj0ZtmN5ptgfuAtg9uznc9gdAz6K78xzYrQjEOg=.93b9b720-d32b-48c2-a442-0b5134c24d53@github.com>
Message-ID: <sKgwE2gHLcqXRsvblteZmFO-TrI6dCvxv3HgnCEJ3YE=.0ec354fe-4a2a-46fe-87fb-0c8935d7082a@github.com>

On Thu, 7 Aug 2025 23:39:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.
>> 
>> Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating NumberFormat with cu as well

LGTM. Reviewed the CSR too.

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 64:

> 62:  * <p>The "rg" (region override), "nu" (numbering system), and "cu" (currency)
> 63:  * {@code Locale} <a href="../util/Locale.html#def_locale_extension">Unicode
> 64:  * extensions</a> are supported which may override values within the symbols.

This can be replaced with `{@link Locale##def_locale_extension Unicode extensions}`. There are multiple locations for this, and it is obviously out of this PR's scope, it can be cleaned up with a separate issue.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26683#pullrequestreview-3101534352
PR Review Comment: https://git.openjdk.org/jdk/pull/26683#discussion_r2263516692

From erikj at openjdk.org  Fri Aug  8 16:45:14 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Aug 2025 16:45:14 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v4]
In-Reply-To: <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>
Message-ID: <sFOmhm5igHPr1NEe0LNX5PyoALGswpKczW-Fb55Pz6w=.4bd8da8a-f834-4893-b440-abc8f743aea5@github.com>

On Fri, 8 Aug 2025 05:25:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
>> 
>> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
>> 
>> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
>> 
>> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.
>
> Thomas Stuefe 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
>  - fix comments about closeDescriptors
>  - Feedback Roger
>  - tolerate sigaction failing
>  - Fixes
>  - fix
>  - start+repro-case

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26615#pullrequestreview-3101549262

From jlu at openjdk.org  Fri Aug  8 16:53:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 8 Aug 2025 16:53:11 GMT
Subject: RFR: 8364780: Unicode extension clarifications for
 NumberFormat/DecimalFormatSymbols [v3]
In-Reply-To: <sKgwE2gHLcqXRsvblteZmFO-TrI6dCvxv3HgnCEJ3YE=.0ec354fe-4a2a-46fe-87fb-0c8935d7082a@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
 <6LGXcj0ZtmN5ptgfuAtg9uznc9gdAz6K78xzYrQjEOg=.93b9b720-d32b-48c2-a442-0b5134c24d53@github.com>
 <sKgwE2gHLcqXRsvblteZmFO-TrI6dCvxv3HgnCEJ3YE=.0ec354fe-4a2a-46fe-87fb-0c8935d7082a@github.com>
Message-ID: <ZA7pmYCNH4pkgVpQNQbil821_dNAB7kl1zLniKFINkg=.3a142211-e818-4360-92c0-71315142cee1@github.com>

On Fri, 8 Aug 2025 16:38:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating NumberFormat with cu as well
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 64:
> 
>> 62:  * <p>The "rg" (region override), "nu" (numbering system), and "cu" (currency)
>> 63:  * {@code Locale} <a href="../util/Locale.html#def_locale_extension">Unicode
>> 64:  * extensions</a> are supported which may override values within the symbols.
> 
> This can be replaced with `{@link Locale##def_locale_extension Unicode extensions}`. There are multiple locations for this, and it is obviously out of this PR's scope, it can be cleaned up with a separate issue.

Filed https://bugs.openjdk.org/browse/JDK-8365175 for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26683#discussion_r2263547997

From liach at openjdk.org  Fri Aug  8 17:08:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:08:13 GMT
Subject: RFR: 8358618: UnsupportedOperationException constructors javadoc
 is not clear [v4]
In-Reply-To: <7J21y9GDvVNl9gin_zJX1zERHdhOa1CwlWHht2gb4GQ=.5983618a-2e4f-43c6-b8eb-6c24bfac4417@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
 <7J21y9GDvVNl9gin_zJX1zERHdhOa1CwlWHht2gb4GQ=.5983618a-2e4f-43c6-b8eb-6c24bfac4417@github.com>
Message-ID: <bMz1Ml2gmf3OUF-IebUbV-w-cUCMp0TqVtUTOc9oYko=.633db1c8-dee2-4221-a993-1299443f4de1@github.com>

On Fri, 8 Aug 2025 11:01:09 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to RuntimeException.java
>   Wrap lines at 80 chars

Looks fine to me. Please wait for another core library reviewer.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26533#pullrequestreview-3101611976

From liach at openjdk.org  Fri Aug  8 17:20:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:20:32 GMT
Subject: Integrated: 8361300: Document exceptions for Unsafe offset methods
In-Reply-To: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <h5tsZvQTBJNKoWcnrlBmLBv-LOCO3j6mo0N6ZGE1WWg=.6019aa43-4732-4d4d-90c5-4882b7561460@github.com>

On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems.

This pull request has now been integrated.

Changeset: cd50d78d
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd50d78d447f9f39065bc844fb3041cba2db32db
Stats:     194 lines in 9 files changed: 177 ins; 2 del; 15 mod

8361300: Document exceptions for Unsafe offset methods

Reviewed-by: jrose, vyazici

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

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

From liach at openjdk.org  Fri Aug  8 17:20:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:20:31 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v7]
In-Reply-To: <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <aOCU5NJ2P0wxlSAWTWaGS6Q66YI7tVREUA-NIlWwD0I=.e11162ad-41a8-4b00-8a56-c8565695bd69@github.com>
Message-ID: <_f0F0TelD59D692SyGfWUo-xvhueaHvc7OryTMU_FaY=.f5b71b29-2602-4f02-adc4-5bfee2a400e7@github.com>

On Fri, 1 Aug 2025 16:16:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update advised by volkan

Thanks for the reviews.

As a final note, I decide to keep the in C++ unsafe checks for now; the unsafe.cpp seems to indicate there are more contracts that I cannot verify right now, for things like offset conversions. So I will integrate this patch as-is.

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

PR Comment: https://git.openjdk.org/jdk/pull/25945#issuecomment-3168776977

From liach at openjdk.org  Fri Aug  8 17:31:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:31:52 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank [v2]
In-Reply-To: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
Message-ID: <Ue1fpO_xK2nRg6PF-yWG2wsGJBTxLdjkIAhPSG5U6is=.a507e633-adc4-4f0c-a54c-78a02d697bd7@github.com>

> JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.
> 
> This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.

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

 - Rename test
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-cache-miss
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-cache-miss
 - Test
 - Cache miss when remove is called on another class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26679/files
  - new: https://git.openjdk.org/jdk/pull/26679/files/2556e54e..01110262

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

  Stats: 1195 lines in 101 files changed: 591 ins; 322 del; 282 mod
  Patch: https://git.openjdk.org/jdk/pull/26679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26679/head:pull/26679

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

From liach at openjdk.org  Fri Aug  8 17:32:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:32:17 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v2]
In-Reply-To: <6LY-pGXEYGVLE2sAYTG8175PvnICXFoHw4velrtLk8E=.dc8a5a32-5c4f-44fa-a281-c5516a22b4bb@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <6LY-pGXEYGVLE2sAYTG8175PvnICXFoHw4velrtLk8E=.dc8a5a32-5c4f-44fa-a281-c5516a22b4bb@github.com>
Message-ID: <GYMlMXwoAVU4hBdebtau5SDWtPDT5MLeQ92r_2Qio8k=.e439853e-faa8-470a-afdc-0c8c5644d083@github.com>

On Fri, 8 Aug 2025 13:38:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> Volkan Yazici 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:
> 
>  - Group `String` methods by `doReplace` argument
>  - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
>  - Replace `requireNonNull` with implicit null checks
>  - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
>  - Improve docs of touched methods and add NPE checks
>  - Convert IAE-throwing methods into CCE-throwing ones
>  - Rename `JavaLangAccess::*NoRepl` methods

src/java.base/share/classes/java/lang/String.java line 855:

> 853:         int len = val.length >> coder;  // assume LATIN1=0/UTF16=1;
> 854:         int en = scale(len, ce.maxBytesPerChar());
> 855:         // Fast-path with `ArrayEncoder` implies replacement.

I recommend documenting this on ArrayEncoder instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2263641162

From rriggs at openjdk.org  Fri Aug  8 17:40:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Aug 2025 17:40:12 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v2]
In-Reply-To: <wjlUniJmhcmiI_fOxwarGoYsIcFP7pi9Zzg4BtqfJJI=.84d1e67c-031f-47af-814b-2365a21d09b2@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <KHzMuTmP9nQ47Myctv5PREoiPcgQNz7bb1PHzGZNZ9Q=.f1a2aa88-cf7a-4b1a-80bf-8a9f5c63391b@github.com>
 <7JywI1LBZ8WJr1y5fkvJH2_v3seCfRd-bjKb2DZFguU=.7e8c22d9-3b97-4220-8ae0-ebe1f80cc51f@github.com>
 <wjlUniJmhcmiI_fOxwarGoYsIcFP7pi9Zzg4BtqfJJI=.84d1e67c-031f-47af-814b-2365a21d09b2@github.com>
Message-ID: <fapIVKkvCrxNKvdkqLKnf3cMRZ8Vvz6vhfVSPghtSBI=.cf1f6f17-069a-46d2-9348-964c81c6a7dc@github.com>

On Fri, 8 Aug 2025 15:52:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Process.java line 655:
>> 
>>> 653:         quietClose(outputWriter != null ? outputWriter : getOutputStream());
>>> 654:         quietClose(inputReader != null ? inputReader  : getInputStream());
>>> 655:         quietClose(errorReader != null ? errorReader : getErrorStream());
>> 
>> Async close of process stream is a complicated here. Do you have a summary on how it behaves on both Unix and Windows? I'm thinking about the deferred close code in particular. (I don't have an issue with close throwing away the exceptions, I'm just not 100% sure that async close is reliable in the first place).
>> 
>>> Closing an already closed stream usually has no effect but is specific to the stream.
>> 
>> I wonder if we could specify Process::close to be idempotent. That would mean we couldn't attempt to re-close if a first close of stream failed or had some other side effect.
>
> That would remove any question about behavior without having to delve into the details of every stream close.
> Down at the bottom of every process stream is a FileDescriptor holding either an fd (Linux) or a handle (Windows).
> This is true for all the redirects whether to files, pipes, or inherited (stdin, stdout, stderr). The FileDescritor.close method is very careful to impotently close and reset the fd/handle.

I will note that when used in try-with-resources, making Process::close idempotent will not keep the streams from being closed twice.
T-W-R will close the streams as declared thru T-W-R variables, delegating the close() down through the streams to the Process streams. Later, Process::close will close the underlying writers or streams, in some cases for the second time.
The only place where idempotent will come into play is when called directly and then possibly later by T-W-R.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2263655091

From rriggs at openjdk.org  Fri Aug  8 17:45:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Aug 2025 17:45:12 GMT
Subject: RFR: 8358618: UnsupportedOperationException constructors javadoc
 is not clear [v4]
In-Reply-To: <7J21y9GDvVNl9gin_zJX1zERHdhOa1CwlWHht2gb4GQ=.5983618a-2e4f-43c6-b8eb-6c24bfac4417@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
 <7J21y9GDvVNl9gin_zJX1zERHdhOa1CwlWHht2gb4GQ=.5983618a-2e4f-43c6-b8eb-6c24bfac4417@github.com>
Message-ID: <bFjf_L_gEC44OvYlDg4FSEsCvIpSRpzOMTy5b7trhQg=.40ba25ea-775a-48fb-ba7f-ce6757b3e604@github.com>

On Fri, 8 Aug 2025 11:01:09 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to RuntimeException.java
>   Wrap lines at 80 chars

Looks good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26533#pullrequestreview-3101716242

From asotona at openjdk.org  Fri Aug  8 17:47:10 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 8 Aug 2025 17:47:10 GMT
Subject: RFR: 8361730: The
 CodeBuilder.trying(BlockCodeBuilder,CatchBuilder) method generates corrupted
 bytecode in certain cases
In-Reply-To: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
References: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
Message-ID: <a4b7Rm1k5JY1-pc_2DSf1R8rYUbjnsUlFrD0Bjpy8Yo=.dd00c495-03aa-467f-9463-05a494838b83@github.com>

On Fri, 1 Aug 2025 18:05:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> Explicitly document that BlockCodeBuilder expects control flow to continue after it merges back to the parent block, so failure to do that by the users can lead to malformed code. This is better than introducing complex and costly analysis.

Looks good to me, thanks.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26602#pullrequestreview-3101719566

From liach at openjdk.org  Fri Aug  8 17:55:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:55:13 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank [v2]
In-Reply-To: <Ue1fpO_xK2nRg6PF-yWG2wsGJBTxLdjkIAhPSG5U6is=.a507e633-adc4-4f0c-a54c-78a02d697bd7@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
 <Ue1fpO_xK2nRg6PF-yWG2wsGJBTxLdjkIAhPSG5U6is=.a507e633-adc4-4f0c-a54c-78a02d697bd7@github.com>
Message-ID: <buR9-gC1sOSJYHF-WH1pXvukxm4cqA4-5stEpXME3KI=.fd90ea7c-5d8e-4964-bfb0-5e3c78462e01@github.com>

On Fri, 8 Aug 2025 17:31:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.
>> 
>> This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.
>
> 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 five additional commits since the last revision:
> 
>  - Rename test
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-cache-miss
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-cache-miss
>  - Test
>  - Cache miss when remove is called on another class

On a side note, I finished the benchmarks and verified this patch backported to jdk25 eliminates the observed regression. (The pagerank bench cannot run on 26 due to Spark's dependency on the removed jdk.internal Cleaner)

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

PR Comment: https://git.openjdk.org/jdk/pull/26679#issuecomment-3168856797

From aivanov at openjdk.org  Fri Aug  8 18:04:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Aug 2025 18:04:11 GMT
Subject: RFR: 8358618: UnsupportedOperationException constructors javadoc
 is not clear [v4]
In-Reply-To: <7J21y9GDvVNl9gin_zJX1zERHdhOa1CwlWHht2gb4GQ=.5983618a-2e4f-43c6-b8eb-6c24bfac4417@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
 <7J21y9GDvVNl9gin_zJX1zERHdhOa1CwlWHht2gb4GQ=.5983618a-2e4f-43c6-b8eb-6c24bfac4417@github.com>
Message-ID: <cIszBjFocSKJbXwYg5Vd0Pwf_5uzrkD1F5k3AV-yH7Y=.8e82c37d-4b6f-4450-baf0-4df878b50263@github.com>

On Fri, 8 Aug 2025 11:01:09 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to RuntimeException.java
>   Wrap lines at 80 chars

Marked as reviewed by aivanov (Reviewer).

> Looks fine to me. Please wait for another core library reviewer.
> 
> /reviewer 2 reviewers

@liach You had to use the [`/reviewers` command](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers).

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

PR Review: https://git.openjdk.org/jdk/pull/26533#pullrequestreview-3101756593
PR Comment: https://git.openjdk.org/jdk/pull/26533#issuecomment-3168887406

From liach at openjdk.org  Fri Aug  8 18:54:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 18:54:13 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
Message-ID: <TKZUMJoAPB3DQvLV_lw9olioidoxBtQA4sNDC6DKZgA=.65005d16-127a-4d42-b154-648004f0833b@github.com>

On Tue, 5 Aug 2025 14:11:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update NPE per roger review
>
> src/java.base/share/classes/java/lang/NullPointerException.java line 142:
> 
>> 140:     }
>> 141: 
>> 142:     // Methods below must be called in object monitor
> 
> This kind of warning should be on every method declaration, if separated from the method doc, it can be overlooked by future maintainers.

Done.

> src/java.base/share/classes/java/lang/NullPointerException.java line 146:
> 
>> 144:     private void ensureMessageComputed() {
>> 145:         if ((extendedMessageState & (MESSAGE_COMPUTED | CONSTRUCTOR_FINISHED)) == CONSTRUCTOR_FINISHED) {
>> 146:             int stackOffset = (extendedMessageState & STACK_OFFSET_MASK) >> STACK_OFFSET_SHIFT;
> 
> This would be more readable if private utility methods were added that encapsulated the shift and masking, both for extraction and construction.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2263783470
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2263782482

From liach at openjdk.org  Fri Aug  8 18:54:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 18:54:14 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <DpevExdDMh5yWZXGeYw_IHBv9l0sxT-x3tn0DeAvh7M=.e41619ed-238a-4559-ad10-ae248b4e9ba9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <DpevExdDMh5yWZXGeYw_IHBv9l0sxT-x3tn0DeAvh7M=.e41619ed-238a-4559-ad10-ae248b4e9ba9@github.com>
Message-ID: <pKJv-ubY7vjR26WI2q9WrYYKfVtAjEanq_nuBRh_Vcw=.2cdd722d-45da-42e1-b1a0-dc3208dd7e4a@github.com>

On Tue, 5 Aug 2025 10:14:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update NPE per roger review
>
> src/java.base/share/classes/java/lang/NullPointerException.java line 159:
> 
>> 157:     ///    configurations to trace how a particular argument, which turns out to
>> 158:     ///    be `null`, was evaluated.
>> 159:     /// 2. `searchSlot < 0`, stack offset is 0 (a call to the nullary constructor)
> 
> Can `searchSlot == -1` here?

I think the code handles all < 0 cases so using that is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2263781125

From jlu at openjdk.org  Fri Aug  8 20:52:21 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 8 Aug 2025 20:52:21 GMT
Subject: RFR: 8364781: Re-examine DigitList digits resizing during parsing
Message-ID: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>

This PR changes the DigitList resizing from adding increments of 100 to a doubling resizing approach. This helps with performance of larger String values during `DecimalFormat` parsing. See the comment on the associated JBS issue for further detail.

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

Commit messages:
 - init

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

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

From almatvee at openjdk.org  Fri Aug  8 21:01:17 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 8 Aug 2025 21:01:17 GMT
Subject: RFR: 8364129: Rename libwixhelper [v2]
In-Reply-To: <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>
Message-ID: <7x2El6yrGCX6moklfttc-g1-yfTriCod1RM1DrrXt6k=.4e1325b8-ed13-4b2a-b086-e8afb3081f5c@github.com>

On Fri, 8 Aug 2025 13:01:52 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Rename "libwixhelper" in "libmsica".
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename libwixhelper dir

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26682#pullrequestreview-3102135060

From asemenyuk at openjdk.org  Fri Aug  8 21:45:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 21:45:15 GMT
Subject: Integrated: 8364129: Rename libwixhelper
In-Reply-To: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
Message-ID: <Ru5SqHXDuHm_VELNoIEdW3dOvAhZrHK1y9Vbn3-vL9Q=.8b6f6501-4a8b-4846-afcf-963b24d828b3@github.com>

On Thu, 7 Aug 2025 18:38:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Rename "libwixhelper" in "libmsica".

This pull request has now been integrated.

Changeset: c1c01556
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1c0155604cbb6c42a220d391a88b029776bdb95
Stats:     11 lines in 7 files changed: 0 ins; 0 del; 11 mod

8364129: Rename libwixhelper

Reviewed-by: erikj, almatvee

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

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

From asemenyuk at openjdk.org  Fri Aug  8 22:15:23 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 22:15:23 GMT
Subject: Integrated: 8364564: Shortcut configuration is not recorded in
 .jpackage.xml file
In-Reply-To: <MhCnt1vlEqWvEo32SllLqONZUwKo-YJD80oEpN19kEY=.08edccd1-dc94-4472-87b1-59af941829a8@github.com>
References: <MhCnt1vlEqWvEo32SllLqONZUwKo-YJD80oEpN19kEY=.08edccd1-dc94-4472-87b1-59af941829a8@github.com>
Message-ID: <bDPu8ccYHj280xIQkFSnJ6Vwh7HsDLg8mfLQBz0p3B8=.573f4f0d-da1b-4ac5-96a6-1500ba5df876@github.com>

On Sat, 2 Aug 2025 03:46:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Add `LauncherShortcut` and `LauncherShortcutStartupDirectory` types to the model to define launcher shortcuts. For now `LauncherShortcutStartupDirectory` enum has a single value. It will be extended in [JDK-8308349](https://bugs.openjdk.org/browse/JDK-8308349) enhancement.
> - Replace `WinLauncherMixin.shortcuts()` with `WinLauncherMixin.startMenuShortcut()` and `WinLauncherMixin.desktopShortcut()`.
> - Remove redundant `StandardBundlerParam.SHORTCUT_HINT` and `StandardBundlerParam.MENU_HINT`; use "win-shortcut", "win-menu", and "linux-shortcut" values instead of "shortcut" and "menu" to store launcher shortcut configuration in the ".jpackage.xml" file.
> - Add tests for launcher shortcut configuration in the ".jpackage.xml" file.

This pull request has now been integrated.

Changeset: 8ad1fcc4
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ad1fcc48a4ba49ffde6dfbb851dbb3f56077dec
Stats:     383 lines in 15 files changed: 262 ins; 54 del; 67 mod

8364564: Shortcut configuration is not recorded in .jpackage.xml file

Reviewed-by: almatvee

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

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

From liach at openjdk.org  Fri Aug  8 22:38:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 22:38:12 GMT
Subject: RFR: 8364781: Re-examine DigitList digits resizing during parsing
In-Reply-To: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
References: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
Message-ID: <vxWaEyLMWHdHWiVQYg-ibpIQlYloBolITrkRAIdPL_k=.7cb373a7-fe4f-4043-ba05-bfc3378e517b@github.com>

On Fri, 8 Aug 2025 20:46:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR changes the DigitList resizing from adding increments of 100 to a doubling resizing approach. This helps with performance of larger String values during `DecimalFormat` parsing. See the comment on the associated JBS issue for further detail.

src/java.base/share/classes/java/text/DigitList.java line 157:

> 155:         if (count == digits.length) {
> 156:             char[] data = new char[count > Integer.MAX_VALUE / 2 ?
> 157:                     Integer.MAX_VALUE : count * 2];

I think you can use `ArraysSupport.newLength(count, 1, count)` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26705#discussion_r2264086346

From naoto at openjdk.org  Fri Aug  8 22:47:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Aug 2025 22:47:47 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601 date
 formats
Message-ID: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>

`Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

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

Commit messages:
 - initial commit

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

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

From asemenyuk at openjdk.org  Fri Aug  8 22:59:38 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 22:59:38 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts
Message-ID: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>

- Support a new "app-dir" value of `win-shortcut`, `win-menu`, and `linux-shortcut` properties in additional launcher property files.
- Support an optional value of `--win-shortcut`, `--win-menu`, and `--linux-shortcut` CLI options. The valid value is "app-dir".

If a value of any property/CLI option from the above list is set to "app-dir", the startup directory of the corresponding shortcut will be set to the "app" subdirectory of the installation directory.

If a CLI option from the above list doesn't have a value, the startup directory of the corresponding shortcut for the main launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.

If a value of a property from the above list evaluates to `true`, the startup directory of the corresponding shortcut for the additional launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.

Added test cases to AddLShortcut test implicitly.

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

Commit messages:
 - Fix javadoc
 - Remove jdk.jpackage.test.LauncherShortcut.StartupDirectory.INSTALL_DIR and jdk.jpackage.internal.model.LauncherShortcutStartupDirectory.INSTALL_DIR
 - Add ParseUtils to the model.
 - Adjust tests for JDK-8308349
 - 8308349: missing working directory option for launcher when invoked from shortcuts

Changes: https://git.openjdk.org/jdk/pull/26707/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26707&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308349
  Stats: 178 lines in 13 files changed: 143 ins; 9 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26707.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26707/head:pull/26707

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

From stevenschlansker at gmail.com  Fri Aug  8 23:10:00 2025
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Fri, 8 Aug 2025 16:10:00 -0700
Subject: Generic type signatures in MethodRepository have many copies of
 simple class names
Message-ID: <FC1D50CF-6C71-4250-937F-CB4821E1303B@gmail.com>

Hello core-libs-dev, happy Friday!

While diagnosing an out of memory situation in our application, I noticed a surprising source of memory usage.
While this is not so severe to actually cause our OOM, it seems wasteful and I thought to bring it to your attention.

We use reflection-based technologies like Jackson JSON and RESTEasy that retrieve generic type information from many of our classes.
Our profiler provides diagnostics of wasted space due to duplicate objects, particularly Strings.

The analysis highlights many thousands of copies of String instances holding the full name of a class, e.g. "java.util.Optional"
or "com.mycompany.Id". The path to GC route looks like:

String <- sun.reflect.generics.tree.SimpleClassTypeSignature <- Object[] <- ArrayList <- ClassTypeSignature <- MethodTypeSignature <- MethodRepository <- Method

Seeing how these SimpleClassTypeSignature instances are created, it looks like they come from the sun.reflect.generics.parser.SignatureParser which calls
`input.substring(mark, index)`, possibly with a call to `replace('/', '.')` to munge the package name. In all but the simplest of cases, this will return a new String
for every call.

Since this String is representing a Class name, the cardinality should by its nature be very low. For each unique type, there will be many methods referring to it.
Additionally, this generic information is lazy-loaded at most once per Method object.

Therefore, SimpleClassTypeSignature.n seems like a natural place to apply String.intern(), for example changing:

public static SimpleClassTypeSignature make(String n,
    boolean dollar,
    TypeArgument[] tas){
        return new SimpleClassTypeSignature(n, dollar, tas);
}

to intern the name:

public static SimpleClassTypeSignature make(String n,
    boolean dollar,
    TypeArgument[] tas){
        return new SimpleClassTypeSignature(n.intern(), dollar, tas);
}

With any luck, maybe this can even share the same string instance as the class itself uses.
Am I correct in thinking this would be a moderately nice improvement, for a relatively cheap cost?
Or perhaps there's some reason this isn't a good idea?

Thank you for your thoughts on the subject,
Steven


From jlu at openjdk.org  Fri Aug  8 23:28:48 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 8 Aug 2025 23:28:48 GMT
Subject: RFR: 8364781: Re-examine DigitList digits resizing during parsing
 [v2]
In-Reply-To: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
References: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
Message-ID: <UBP3my1TDFYTza7tEbJYZIa_z0sAAPI_X7HLpQNEAmU=.1019b10f-3440-4781-8b33-f2aa7c2df942@github.com>

> This PR changes the DigitList resizing from adding increments of 100 to a doubling resizing approach. This helps with performance of larger String values during `DecimalFormat` parsing. See the comment on the associated JBS issue for further detail.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Chen review - replace with ArraysSupport

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26705/files
  - new: https://git.openjdk.org/jdk/pull/26705/files/4361aa02..df40560e

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

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

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

From liach at openjdk.org  Fri Aug  8 23:28:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 23:28:48 GMT
Subject: RFR: 8364781: Re-examine DigitList digits resizing during parsing
 [v2]
In-Reply-To: <UBP3my1TDFYTza7tEbJYZIa_z0sAAPI_X7HLpQNEAmU=.1019b10f-3440-4781-8b33-f2aa7c2df942@github.com>
References: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
 <UBP3my1TDFYTza7tEbJYZIa_z0sAAPI_X7HLpQNEAmU=.1019b10f-3440-4781-8b33-f2aa7c2df942@github.com>
Message-ID: <jX1mF9mY09eKlYD0AlTZFvBbtPCv-QbPWT4zNnoQEIU=.29cfb89d-ddfb-47d4-9c75-4b5ea51bfb35@github.com>

On Fri, 8 Aug 2025 23:25:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR changes the DigitList resizing from adding increments of 100 to a doubling resizing approach. This helps with performance of larger String values during `DecimalFormat` parsing. See the comment on the associated JBS issue for further detail.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen review - replace with ArraysSupport

Looks right.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26705#pullrequestreview-3102311416

From jlu at openjdk.org  Fri Aug  8 23:28:48 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 8 Aug 2025 23:28:48 GMT
Subject: RFR: 8364781: Re-examine DigitList digits resizing during parsing
 [v2]
In-Reply-To: <vxWaEyLMWHdHWiVQYg-ibpIQlYloBolITrkRAIdPL_k=.7cb373a7-fe4f-4043-ba05-bfc3378e517b@github.com>
References: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
 <vxWaEyLMWHdHWiVQYg-ibpIQlYloBolITrkRAIdPL_k=.7cb373a7-fe4f-4043-ba05-bfc3378e517b@github.com>
Message-ID: <4A7TYXU3f-V-HSXqh0hc0ouiSwYD25j80pP-E0xfYlI=.4d20fc0c-8578-4905-aafa-ee76713556d5@github.com>

On Fri, 8 Aug 2025 22:35:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chen review - replace with ArraysSupport
>
> src/java.base/share/classes/java/text/DigitList.java line 157:
> 
>> 155:         if (count == digits.length) {
>> 156:             char[] data = new char[count > Integer.MAX_VALUE / 2 ?
>> 157:                     Integer.MAX_VALUE : count * 2];
> 
> I think you can use `ArraysSupport.newLength(count, 1, count)` instead.

Did not know we had that, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26705#discussion_r2264122792

From almatvee at openjdk.org  Fri Aug  8 23:40:15 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 8 Aug 2025 23:40:15 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts
In-Reply-To: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
Message-ID: <pYUWAVVsTBigwd4yMKr0Fp2L3m7X88eeMXDP6Zj045A=.4a8944d8-8904-49eb-ba97-104d2f1bb806@github.com>

On Fri, 8 Aug 2025 22:37:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Support a new "app-dir" value of `win-shortcut`, `win-menu`, and `linux-shortcut` properties in additional launcher property files.
> - Support an optional value of `--win-shortcut`, `--win-menu`, and `--linux-shortcut` CLI options. The valid value is "app-dir".
> 
> If a value of any property/CLI option from the above list is set to "app-dir", the startup directory of the corresponding shortcut will be set to the "app" subdirectory of the installation directory.
> 
> If a CLI option from the above list doesn't have a value, the startup directory of the corresponding shortcut for the main launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
> 
> If a value of a property from the above list evaluates to `true`, the startup directory of the corresponding shortcut for the additional launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
> 
> Added test cases to AddLShortcut test implicitly.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java line 486:

> 484:         }
> 485: 
> 486:         private static Runnable createArgumentWithOptionalValueAction(String option) {

I am not sure, but did you test case when `--win-menu` or `--win-shortcut` or `--linux-shortcut` is last argument without value? With new code `var value = popArg();` will be `""` and we will call `setOptionValue(option, value)`. Before change it will be set to `true`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26707#discussion_r2264123444

From rsunderbabu at openjdk.org  Sat Aug  9 02:18:25 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Sat, 9 Aug 2025 02:18:25 GMT
Subject: RFR: 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 frequently fails with SerialGC
In-Reply-To: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
References: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
Message-ID: <-mfxynujKG2a7Rx6fSZtduqymXvOuZy6xQImqiW73I4=.4523382a-ce85-48b8-b4b0-dbc8ffda3373@github.com>

On Fri, 8 Aug 2025 09:32:51 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue. During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

I will create another PR for this with appropriate bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/26690#issuecomment-3169660825

From rsunderbabu at openjdk.org  Sat Aug  9 02:18:26 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Sat, 9 Aug 2025 02:18:26 GMT
Subject: Withdrawn: 8313655: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 frequently fails with SerialGC
In-Reply-To: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
References: <nKSsdqJgNEqXiATOFfB6MqBe8bBIazOBUAY5wVzBx5s=.a04a4886-5aa2-4346-b609-317fd3245304@github.com>
Message-ID: <4eQoeVE9loHBFvr30_-qJPLnZEvVko_o645lWJxv1PI=.7cccf392-f6af-4165-a5ef-7640c57e7571@github.com>

On Fri, 8 Aug 2025 09:32:51 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue. During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

This pull request has been closed without being integrated.

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

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

From jrose at openjdk.org  Sat Aug  9 02:32:16 2025
From: jrose at openjdk.org (John R Rose)
Date: Sat, 9 Aug 2025 02:32:16 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank [v2]
In-Reply-To: <Ue1fpO_xK2nRg6PF-yWG2wsGJBTxLdjkIAhPSG5U6is=.a507e633-adc4-4f0c-a54c-78a02d697bd7@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
 <Ue1fpO_xK2nRg6PF-yWG2wsGJBTxLdjkIAhPSG5U6is=.a507e633-adc4-4f0c-a54c-78a02d697bd7@github.com>
Message-ID: <3B5jdhwawJ6Bwm9aRMQNDZo_EwzhG0qryGM-lzbuGRA=.55319a47-e5b1-4ae4-8da3-df4998a9232f@github.com>

On Fri, 8 Aug 2025 17:31:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.
>> 
>> This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.
>
> 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 five additional commits since the last revision:
> 
>  - Rename test
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-cache-miss
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-cache-miss
>  - Test
>  - Cache miss when remove is called on another class

Nice whitebox test.

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

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26679#pullrequestreview-3102398544

From rsunderbabu at openjdk.org  Sat Aug  9 03:34:30 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Sat, 9 Aug 2025 03:34:30 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
Message-ID: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>

VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.

Testing: Tiers1,2,3 and other ties where the test runs.

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

Commit messages:
 - 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java Re-enable SerialGC flag on debuggee process

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

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

From swen at openjdk.org  Sat Aug  9 05:17:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 05:17:55 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
Message-ID: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>

By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.


@ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big


By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

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

Commit messages:
 - from @jodastephen
 - from @jodastephen
 - Separate exception handling into two separate methods to make codeSize < 325

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

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

From vyazici at openjdk.org  Sat Aug  9 05:17:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Sat, 9 Aug 2025 05:17:55 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <m9Iko23FLJq2bePRvN7yKMILTNUOgrgXS6be0lpTLFM=.296782c3-8c78-4bfc-83f2-f40a9447a8af@github.com>

On Tue, 5 Aug 2025 01:23:17 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

Would you mind sharing the details about the performance improvement you observed, please? On which platforms? Using which benchmarks? (Any in `test/micro/org/openjdk/bench/java/time/format`?)

Using 99425bc, I can observe a noteworthy improvement on all tested platforms:

| Benchmark | Linux aarch64 | Linux x64 | MacOSX aarch64 | MacOSX x64 | Windows x64 |
| --------- |:-------------:|:---------:|:--------------:|:----------:|:-----------:|
| DateTimeFormatterBench.formatInstants-pattern:HH_mm_ss | 0.75% | 7.33% | 7.60% | 8.30% | 9.16% |
| DateTimeFormatterBench.formatInstants-pattern:HH_mm_ss_SSS | 1.13% | 0.74% | 10.24% | 4.03% | -2.67% |
| DateTimeFormatterBench.formatInstants-pattern:yyyy_MM_ddTHH_mm_ss | 0.17% | 14.31% | 9.00% | 13.69% | 18.66% |
| DateTimeFormatterBench.formatInstants-pattern:yyyy_MM_ddTHH_mm_ss_SSS | -0.66% | 3.26% | 5.98% | 2.91% | -1.12% |
| DateTimeFormatterBench.formatZonedDateTime-pattern:HH_mm_ss | 5.17% | 6.54% | -1.61% | 1.55% | 7.25% |
| DateTimeFormatterBench.formatZonedDateTime-pattern:HH_mm_ss_SSS | 3.99% | 1.45% | 4.14% | 1.79% | 1.36% |
| DateTimeFormatterBench.formatZonedDateTime-pattern:yyyy_MM_ddTHH_mm_ss | 2.13% | 15.56% | -2.01% | 2.72% | 17.47% |
| DateTimeFormatterBench.formatZonedDateTime-pattern:yyyy_MM_ddTHH_mm_ss_SSS | 2.41% | 1.54% | 1.43% | 2.29% | 1.61% |
| DateTimeFormatterWithPaddingBench.formatWithPadding | 0.88% | 2.52% | 16.97% | 3.91% | 1.30% |
| DateTimeFormatterWithPaddingBench.formatWithPaddingLengthOne | -0.80% | 6.28% | 3.21% | 5.32% | 6.09% |
| DateTimeFormatterWithPaddingBench.formatWithPaddingLengthZero | 4.87% | 3.11% | 31.32% | 11.31% | 4.12% |

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

PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3154162461
PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3167557811

From swen at openjdk.org  Sat Aug  9 05:17:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 05:17:55 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <Wdop9f_vC6k8leNgy18topOueJCbEWIJpzYoCMZ8aoI=.60a17ea5-ace0-4782-a1dd-e257e88e739c@github.com>

On Tue, 5 Aug 2025 01:23:17 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

By running DateTimeFormatterBench, we can see that the current proposal can improve performance by about 5% in multiple scenarios. The detailed data is as follows

# 1. Running performance test scripts

# before
git checkout 158e59ab9184127089f9693ce256001f64b5945c
make test TEST="micro:java.time.format.DateTimeFormatterBench"

# after
git checkout 0278bba135bed6e99a9e9f99cb656275c27f8465
make test TEST="micro:java.time.format.DateTimeFormatterBench"


# 2. Performance results in multiple architectures
## 2.1. MacBook M1 Pro (aarch64)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  15.053 ? 0.281  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  10.664 ? 0.119  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   8.994 ? 0.579  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.943 ? 0.370  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  22.938 ? 0.056  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  15.882 ? 0.144  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  13.302 ? 0.518  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  10.153 ? 0.075  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  16.083 ? 0.178  ops/ms +6.84%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  11.548 ? 0.171  ops/ms +8.28%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   9.835 ? 0.064  ops/ms +9.35%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.344 ? 0.308  ops/ms +5.77%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  22.500 ? 0.147  ops/ms -1.90%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  16.592 ? 0.086  ops/ms +4.47%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  13.182 ? 0.829  ops/ms -0.90%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  10.127 ? 0.140  ops/ms -0.25%


## 2.2. aliyun_c8y (aarch64 CPU Aliyun_Yitian 710)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15   9.916 ? 0.073  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   7.416 ? 0.013  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   6.248 ? 0.082  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   4.988 ? 0.042  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  13.653 ? 0.073  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15   9.435 ? 0.033  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15   7.550 ? 0.145  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.096 ? 0.301  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  10.897 ? 0.047  ops/ms +9.89%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   7.449 ? 0.086  ops/ms +0.44%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   6.979 ? 0.025  ops/ms +11.69%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   4.950 ? 0.024  ops/ms -0.76%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  14.206 ? 0.206  ops/ms +4.05%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15   9.957 ? 0.182  ops/ms +5.53%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15   7.705 ? 0.093  ops/ms +2.05%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.222 ? 0.235  ops/ms +2.06%


## 2.3. OrangePi 5 (aarch64 CPU RK3588)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt  Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  6.118 ? 0.417  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  4.312 ? 0.202  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15  4.047 ? 0.107  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  2.773 ? 0.204  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  9.228 ? 0.232  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  5.640 ? 0.223  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  5.109 ? 0.076  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  3.407 ? 0.168  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt  Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  6.080 ? 0.451  ops/ms -0.62%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  4.341 ? 0.219  ops/ms +0.67%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15  4.009 ? 0.207  ops/ms -0.93%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  2.928 ? 0.104  ops/ms +5.58%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  9.670 ? 0.139  ops/ms +4.78%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  5.835 ? 0.234  ops/ms +3.45%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  5.149 ? 0.153  ops/ms +0.78%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  3.553 ? 0.131  ops/ms +4.28%


## 2.4 aliyun_c9i (x64 CPU Intel Xeon Granite Rapids)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  15.718 ? 1.343  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  11.758 ? 0.638  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15  10.529 ? 0.057  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.945 ? 0.304  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  20.441 ? 0.067  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  13.975 ? 0.062  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  11.721 ? 0.070  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   8.604 ? 0.073  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  16.745 ? 0.129  ops/ms +6.53%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  11.571 ? 1.085  ops/ms -1.52%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15  10.591 ? 0.046  ops/ms +0.58%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.899 ? 0.323  ops/ms -0.57%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  20.993 ? 0.082  ops/ms +2.70%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  14.123 ? 0.094  ops/ms +1.05%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  11.781 ? 0.054  ops/ms +0.51%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   8.723 ? 0.055  ops/ms +1.38%



## 2.5 MacBook 2019 (x64 intel i9)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  12.393 ? 0.985  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   9.658 ? 0.220  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   8.321 ? 0.098  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.575 ? 0.073  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  18.946 ? 0.387  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  12.156 ? 0.316  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15   9.980 ? 0.115  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.729 ? 0.160  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  13.942 ? 0.257  ops/ms +12.49%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   9.882 ? 0.327  ops/ms +2.42%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   9.234 ? 0.240  ops/ms +10.97%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.594 ? 0.074  ops/ms +2.89%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  19.482 ? 0.385  ops/ms +2.82%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  12.917 ? 0.244  ops/ms +6.26%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  10.196 ? 0.142  ops/ms +2.16%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.793 ? 0.136  ops/ms +8.28%

* Run the test script

make test TEST="micro:java.time.format.DateTimeFormatterWithPaddingBench"


* Test results on aliyun_c9i (x64 CPU Intel Xeon Granite Rapids)


-# before
-Benchmark                                                       Mode  Cnt      Score     Error   Units
-DateTimeFormatterWithPaddingBench.formatWithPadding            thrpt   15  11823.795 ? 221.488  ops/ms
-DateTimeFormatterWithPaddingBench.formatWithPaddingLengthOne   thrpt   15  34634.499 ?  91.144  ops/ms
-DateTimeFormatterWithPaddingBench.formatWithPaddingLengthZero  thrpt   15  39070.959 ? 198.192  ops/ms

+# after
+Benchmark                                                       Mode  Cnt      Score     Error   Units
+DateTimeFormatterWithPaddingBench.formatWithPadding            thrpt   15  12257.729 ?  49.449  ops/ms +3.67%
+DateTimeFormatterWithPaddingBench.formatWithPaddingLengthOne   thrpt   15  37689.494 ? 117.526  ops/ms +8.82%
+DateTimeFormatterWithPaddingBench.formatWithPaddingLengthZero  thrpt   15  43628.181 ? 493.395  ops/ms +11.66%


In DateTimeFormatterWithPaddingBench, I found that this proposal improved performance even more.

This is because DateTimeFormatter is statically defined as final, and DateTimeFormatter::getChronology and DateTimeFormatter::getZone used in the adjust method are final fields. This eliminates dead code branches during inlining by the C2 optimizer.

* The following code is the formatter definition in DateTimeFormatterWithPaddingBench. The modifiers of the fields FORMATTER_WITH_PADDING/FORMATTER_WITH_PADDING_ZERO/FORMATTER_WITH_PADDING_ONE are static final.

public class DateTimeFormatterWithPaddingBench {

    private static final DateTimeFormatter FORMATTER_WITH_PADDING = new DateTimeFormatterBuilder()
            .appendLiteral("Date:")
            .padNext(20, ' ')
            .append(DateTimeFormatter.ISO_DATE)
            .toFormatter();

    private static final DateTimeFormatter FORMATTER_WITH_PADDING_ZERO = new DateTimeFormatterBuilder()
            .appendLiteral("Year:")
            .padNext(4)
            .appendValue(ChronoField.YEAR)
            .toFormatter();

    private static final DateTimeFormatter FORMATTER_WITH_PADDING_ONE = new DateTimeFormatterBuilder()
            .appendLiteral("Year:")
            .padNext(5)
            .appendValue(ChronoField.YEAR)
            .toFormatter();


* In the DateTimeFormatter related code, the modifiers of the chrono/zone fields are also final

final class DateTimeFormatter {
	private final Chronology chrono;
	private final ZoneId zone;

    public Chronology getChronology() {
        return chrono;
    }

    public ZoneId getZone() {
        return zone;
    }
}


* The following code in the DateTimePrintContext::adjust method uses chrono and zone. When adjust can be inlined, dead code branches can be eliminated to improve performance.


final class DateTimePrintContext {
    private static TemporalAccessor adjust(final TemporalAccessor temporal, DateTimeFormatter formatter) {
        Chronology overrideChrono = formatter.getChronology();
        ZoneId overrideZone = formatter.getZone();
        if (overrideChrono == null && overrideZone == null) {
            return temporal;
        }
        // ....
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3155866814
PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3158585653

From scolebourne at openjdk.org  Sat Aug  9 05:17:56 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sat, 9 Aug 2025 05:17:56 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>

On Tue, 5 Aug 2025 01:23:17 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 152:

> 150:                 return chrono.zonedDateTime(Instant.from(temporal), overrideZone);
> 151:             }
> 152:         }

Have you tested the split at different locations? I would expect line 143 or line 130 to perform best. There may be a case for splitting multiple times. You will also need a comment to indicate why the method is split.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2256531178

From swen at openjdk.org  Sat Aug  9 05:17:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 05:17:56 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
In-Reply-To: <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>
Message-ID: <un3Gj_C38VJpZWEoR2FzXs_YyJ5DJAO1ihghn3tSbAc=.659182be-6f21-422f-b150-175970f4b3a4@github.com>

On Wed, 6 Aug 2025 09:20:30 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
>> 
>> 
>> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
>> 
>> 
>> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.
>
> src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 152:
> 
>> 150:                 return chrono.zonedDateTime(Instant.from(temporal), overrideZone);
>> 151:             }
>> 152:         }
> 
> Have you tested the split at different locations? I would expect line 143 or line 130 to perform best. There may be a case for splitting multiple times. You will also need a comment to indicate why the method is split.

In theory, the smaller the method, the greater the opportunity for performance improvement, but in DateTimeFormatterWithPaddingBench and DateTimeFormatterBench, the improvement is the same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2256949893

From rriggs at openjdk.org  Sat Aug  9 05:17:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 9 Aug 2025 05:17:56 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <KglEougN2PRMrtlte1UnYv10ezjSvhe9AAuq7tzu-ow=.50d3bfcb-ed85-4216-b706-bb161e35ac71@github.com>

On Tue, 5 Aug 2025 01:23:17 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

Do you intend to move this PR from Draft to Open?

src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 164:

> 162:     }
> 163: 
> 164:     private static TemporalAccessor adjust(

Please fold the parameters into fewer (1) lines and briefly document the rationale for the internal method.

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

PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3168340810
PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2263021841

From swen at openjdk.org  Sat Aug  9 05:55:11 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 05:55:11 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
In-Reply-To: <KglEougN2PRMrtlte1UnYv10ezjSvhe9AAuq7tzu-ow=.50d3bfcb-ed85-4216-b706-bb161e35ac71@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <KglEougN2PRMrtlte1UnYv10ezjSvhe9AAuq7tzu-ow=.50d3bfcb-ed85-4216-b706-bb161e35ac71@github.com>
Message-ID: <l_8A8PeHldebcTEOgrchJIez2NQwwAlmP3GgVe8nqYo=.da686020-eea6-4ce8-bdb2-8a4a20be345a@github.com>

On Fri, 8 Aug 2025 13:42:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
>> 
>> 
>> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
>> 
>> 
>> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.
>
> src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 164:
> 
>> 162:     }
>> 163: 
>> 164:     private static TemporalAccessor adjust(
> 
> Please fold the parameters into fewer (1) lines and briefly document the rationale for the internal method.

If the third adjust method parameter is placed on the same line, the line will have 195 characters (it is generally recommended to be less than 120).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2264536335

From swen at openjdk.org  Sat Aug  9 12:13:13 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 12:13:13 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
 [v2]
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <tlIMAnT3TCZd7sApMtTt6gJJ_wvdA_z7rj3z0ds9J9w=.e7d61469-290e-4349-a6b7-6c4b3f377674@github.com>

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

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

  add java doc comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26633/files
  - new: https://git.openjdk.org/jdk/pull/26633/files/99425bcb..170cf788

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

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

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

From duke at openjdk.org  Sat Aug  9 13:55:09 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 9 Aug 2025 13:55:09 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <55UQCywpNB4OPfqAgJhIcrJa9AIgxxQRe_gxZKWHj14=.9c7f3a6b-73d2-4b66-9054-a4dccc7c57ae@github.com>

On Fri, 8 Aug 2025 22:37:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

How?about using different patterns for?parsing and?printing instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3170782773

From lmesnik at openjdk.org  Sat Aug  9 17:11:10 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 9 Aug 2025 17:11:10 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
In-Reply-To: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
References: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
Message-ID: <Rswh6lxqrKkn3UX_6ltI5lg9OJZ1xFA8y3OD-ChAj6g=.24c47c16-789e-4f60-bb33-3fe6e3928835@github.com>

On Sat, 9 Aug 2025 03:27:26 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26711#pullrequestreview-3103148814

From cjplummer at openjdk.org  Sat Aug  9 18:51:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 9 Aug 2025 18:51:09 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
In-Reply-To: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
References: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
Message-ID: <57h-7acHOmEpH5iOC8KXRiPoXx8SmpNfW_CE4zvoYQI=.37ca57a2-afd0-44d6-a79d-b3daf8548822@github.com>

On Sat, 9 Aug 2025 03:27:26 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

Looks good. BTW, you could have still used the old PR and just changed the title to reflect the new CR.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26711#pullrequestreview-3103206850

From liach at openjdk.org  Sat Aug  9 23:45:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 9 Aug 2025 23:45:17 GMT
Subject: RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank [v2]
In-Reply-To: <Ue1fpO_xK2nRg6PF-yWG2wsGJBTxLdjkIAhPSG5U6is=.a507e633-adc4-4f0c-a54c-78a02d697bd7@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
 <Ue1fpO_xK2nRg6PF-yWG2wsGJBTxLdjkIAhPSG5U6is=.a507e633-adc4-4f0c-a54c-78a02d697bd7@github.com>
Message-ID: <O0GbrjYnULCNfrv5sYKGbKmlMoAEeG-FiWjOaJsX2Ig=.92f4ffda-e209-4cf5-ac69-62ea4cd39a09@github.com>

On Fri, 8 Aug 2025 17:31:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.
>> 
>> This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.
>
> 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 five additional commits since the last revision:
> 
>  - Rename test
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-cache-miss
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-cache-miss
>  - Test
>  - Cache miss when remove is called on another class

Thanks for the reviews. On a side note, a release note for this regression is written for 25. I will integrate to facilitate backport into 25u.

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

PR Comment: https://git.openjdk.org/jdk/pull/26679#issuecomment-3172241024

From liach at openjdk.org  Sat Aug  9 23:48:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 9 Aug 2025 23:48:20 GMT
Subject: Integrated: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9%
 regression in Renaissance-PageRank
In-Reply-To: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
References: <5eMjwzWNxXeeSbZSN8gLFXgtmxIT8omPahhujwZWvFM=.f3da351e-b713-4652-b831-addc11272139@github.com>
Message-ID: <fbct8p4oZGA191EYF8ccLTxEsFDK70biy2KiHCj4Jg8=.9a0e208f-d076-45e6-8ac7-4771ceac75e3@github.com>

On Thu, 7 Aug 2025 16:23:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> JDK-8351996, PR #24043, updated java.lang.ClassValue, but accidentally missed a piece of cache refresh code that is meaningful when the cache is speculatively invalidated by `remove` calls.
> 
> This caused a significant regression in the [PageRank](https://github.com/renaissance-benchmarks/renaissance/blob/master/benchmarks/apache-spark/src/main/scala/org/renaissance/apache/spark/PageRank.scala) benchmark, primarily because Scala array creation like `Array.fill` uses `scala.reflect.ClassTag` which uses `ClassValue`, making `ClassValue.get` a hot code path for every array creation.

This pull request has now been integrated.

Changeset: e13b4c8d
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e13b4c8de944ab14a1d12f6251e83f4fdd9e0198
Stats:     75 lines in 2 files changed: 69 ins; 5 del; 1 mod

8358535: Changes in ClassValue (JDK-8351996) caused a 1-9% regression in Renaissance-PageRank

Reviewed-by: jrose, shade

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

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

From liach at openjdk.org  Sun Aug 10 01:17:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Aug 2025 01:17:54 GMT
Subject: RFR: 8364751: ConstantBootstraps.explicitCast contradictory
 specification for null-to-primitive
Message-ID: <3FkADEF7XBhLXhzquFIsu2nVkpkGg6b8XBKp-X-Gk70=.d63a9bbf-095b-4947-a541-fbdcee3a1484@github.com>

ConstantBootstraps.explicitCast behaves like a snippet of code in its specification. However, in the rest of the nominal spec, it incorrectly assumes a null `value` and a primitive `dstType` results in a ClassCastException instead of the zero value of that primitive type. This is inconsistent with that snippet and the actual code behavior.

The specification is fixed, the test for `explicitCast` is merged into the main `ConstantBootstraps` test, and a new unit test case for `value = null` and `dstType = char.class` is added, verifying the outcome is `'u0000'`.

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

Commit messages:
 - Update and consolidate tests
 - 8364751: ConstantBootstraps.explicitCast violates doc contracts for null-to-int

Changes: https://git.openjdk.org/jdk/pull/26714/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26714&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364751
  Stats: 131 lines in 3 files changed: 43 ins; 79 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26714.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26714/head:pull/26714

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

From duke at openjdk.org  Sun Aug 10 02:25:22 2025
From: duke at openjdk.org (duke)
Date: Sun, 10 Aug 2025 02:25:22 GMT
Subject: RFR: 8365184: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 Re-enable SerialGC flag on debuggee process
In-Reply-To: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
References: <zO5JSHeDLmlwU9YVsKyATphCvWFmi_nJnkVQsU2dI4Q=.cd2e17ca-f21a-4c38-b50e-5aae7d532eeb@github.com>
Message-ID: <aoaSuYf6jWm-DSIadUXwABlguAZsr8uIBuUyDe4Kmj4=.da625844-3ebf-4f1d-a5c5-5d996524b3e0@github.com>

On Sat, 9 Aug 2025 03:27:26 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> VM argument UseSerialGC was not allowed while launching the debuggee process due to classloader related issue (JDK-8313655). During the effort to improve the test's handling of the issue, it was observed that SerialGC doesn't cause any issue any more. This could possibly due to improved handling of ClassLoaderData or SerialGC.
> After extensively testing the argument in various platforms and for many iterations, it was decided to allow the argument here on.
> 
> Testing: Tiers1,2,3 and other ties where the test runs.

@rsunderbabu 
Your change (at version 93b4cbefde03500f53f53516ede6b31650b31118) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26711#issuecomment-3172309271

From liach at openjdk.org  Sun Aug 10 02:34:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Aug 2025 02:34:12 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
 [v2]
In-Reply-To: <un3Gj_C38VJpZWEoR2FzXs_YyJ5DJAO1ihghn3tSbAc=.659182be-6f21-422f-b150-175970f4b3a4@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>
 <un3Gj_C38VJpZWEoR2FzXs_YyJ5DJAO1ihghn3tSbAc=.659182be-6f21-422f-b150-175970f4b3a4@github.com>
Message-ID: <PbnDP5Bvcje1gjtjpxjwsXUIC7rs4aZHl-SPFGAjMH4=.b9c036be-d2c6-4814-905d-ed2595c940b4@github.com>

On Wed, 6 Aug 2025 12:10:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 152:
>> 
>>> 150:                 return chrono.zonedDateTime(Instant.from(temporal), overrideZone);
>>> 151:             }
>>> 152:         }
>> 
>> Have you tested the split at different locations? I would expect line 143 or line 130 to perform best. There may be a case for splitting multiple times. You will also need a comment to indicate why the method is split.
>
> In theory, the smaller the method, the greater the opportunity for performance improvement, but in DateTimeFormatterWithPaddingBench and DateTimeFormatterBench, the improvement is the same.

This depends on how often Formatters override chrono and zone, and how often these overrides are no-op so we can still fast return. if both shortcuts are significant, it may well be reasonable to set up a series of small shortcut methods and end with a "slow tail" (See the example of `ClassValue::get`, `getFromBackup`, and `getFromHashMap`).

Given that example, I recommend renaming the two new split `adjust` into `adjustWithOverride` and `adjustSlow` to distinguish from the actual `adjust` method.

In addition, I agree with @jodastephen that line 130 intuitively seems like the best place to break methods. Do you know if the "if have zone and instant" case is so frequent that it should be included in the 2nd method instead of the 3rd? The goal of inlining, as far as I know, is to include minimal hot code to be compiled, instead of tweaking the method size so it exactly falls into FreqInlineSize, so the less code to compile for C2 the better and faster it compiles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2265087021

From swen at openjdk.org  Sun Aug 10 03:36:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 10 Aug 2025 03:36:06 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
 [v3]
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <y8vmYNc7ul7YQHkujvSffSg692k4JyJHzVXhfUnrOVg=.bbeb8e03-acd9-4126-b1b5-904c4525575f@github.com>

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

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

  from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26633/files
  - new: https://git.openjdk.org/jdk/pull/26633/files/170cf788..22ae4c83

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

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

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

From swen at openjdk.org  Sun Aug 10 05:10:14 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 10 Aug 2025 05:10:14 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
 [v3]
In-Reply-To: <PbnDP5Bvcje1gjtjpxjwsXUIC7rs4aZHl-SPFGAjMH4=.b9c036be-d2c6-4814-905d-ed2595c940b4@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>
 <un3Gj_C38VJpZWEoR2FzXs_YyJ5DJAO1ihghn3tSbAc=.659182be-6f21-422f-b150-175970f4b3a4@github.com>
 <PbnDP5Bvcje1gjtjpxjwsXUIC7rs4aZHl-SPFGAjMH4=.b9c036be-d2c6-4814-905d-ed2595c940b4@github.com>
Message-ID: <o9Kfa0-VjE_In8KhVsXDyMWVdGhwxIvz2dj_uxBlmeE=.acecab70-0f34-46f5-9dc5-13ae34dd7849@github.com>

On Sun, 10 Aug 2025 02:31:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In theory, the smaller the method, the greater the opportunity for performance improvement, but in DateTimeFormatterWithPaddingBench and DateTimeFormatterBench, the improvement is the same.
>
> This depends on how often Formatters override chrono and zone, and how often these overrides are no-op so we can still fast return. if both shortcuts are significant, it may well be reasonable to set up a series of small shortcut methods and end with a "slow tail" (See the example of `ClassValue::get`, `getFromBackup`, and `getFromHashMap`).
> 
> Given that example, I recommend renaming the two new split `adjust` into `adjustWithOverride` and `adjustSlow` to distinguish from the actual `adjust` method.
> 
> In addition, I agree with @jodastephen that line 130 intuitively seems like the best place to break methods. Do you know if the "if have zone and instant" case is so frequent that it should be included in the 2nd method instead of the 3rd? The goal of inlining, as far as I know, is to include minimal hot code to be compiled, instead of tweaking the method size so it exactly falls into FreqInlineSize, so the less code to compile for C2 the better and faster it compiles.

The `adjust` method has a code size of 27, covering the most common scenarios and capable of handling C1.

The `adjustWithOverride` method has a code size of 123, which can also be handled by C2 and covers the use of formatters with zones in the DateTimeFormatterBench.

This split ensures a balanced approach to startup performance and optimizations for the most common scenarios.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2265116221

From epeter at openjdk.org  Sun Aug 10 05:26:22 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Sun, 10 Aug 2025 05:26:22 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
Message-ID: <phlaY7VkRoWWwDzsnKw3JxaaU-lZk3tXFo8KCEtbn3Q=.3ccdd4ac-d61c-4c4c-b679-7bab67072ee1@github.com>

On Tue, 5 Aug 2025 11:39:43 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
>> 
>> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
>> 
>> 
>> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
>> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
>> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
>> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
>> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
>> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
>> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
>> 
>> 
>> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
>> 
>> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.
>
> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check at the very least that auto vectorization is supported

src/hotspot/share/opto/superword.cpp line 1635:

> 1633:     } else if (VectorNode::is_convert_opcode(opc)) {
> 1634:       retValue = VectorCastNode::implemented(opc, size, velt_basic_type(p0->in(1)), velt_basic_type(p0));
> 1635:     } else if (VectorNode::is_reinterpret_opcode(opc)) {

How does this affect `Op_ReinterpretHF2S` that is also in `VectorNode::is_reinterpret_opcode`?
I'm afraid that we need to test this with hardware or Intel's SDE, to make sure we have it running on a VM that actually supports Float16. Otherwise these instructions may not be used, and hence not tested right.

@galderz Can you run the relevant tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2265119804

From liach at openjdk.org  Sun Aug 10 14:48:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Aug 2025 14:48:13 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v2]
In-Reply-To: <6LY-pGXEYGVLE2sAYTG8175PvnICXFoHw4velrtLk8E=.dc8a5a32-5c4f-44fa-a281-c5516a22b4bb@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <6LY-pGXEYGVLE2sAYTG8175PvnICXFoHw4velrtLk8E=.dc8a5a32-5c4f-44fa-a281-c5516a22b4bb@github.com>
Message-ID: <Iudu5Hd27oKKWyBmvwKQn2wxRfJmRagkrViyynfhQLw=.ffe0cd32-4ac2-431f-8977-94b418a1bb70@github.com>

On Fri, 8 Aug 2025 13:38:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> Volkan Yazici 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:
> 
>  - Group `String` methods by `doReplace` argument
>  - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
>  - Replace `requireNonNull` with implicit null checks
>  - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
>  - Improve docs of touched methods and add NPE checks
>  - Convert IAE-throwing methods into CCE-throwing ones
>  - Rename `JavaLangAccess::*NoRepl` methods

Review still in progress, feel free to ping me more more...

src/java.base/share/classes/java/lang/String.java line 949:

> 947:     static byte[] getBytesNoReplacement(String s, Charset cs) throws CharacterCodingException {
> 948:         Objects.requireNonNull(s, "s");
> 949:         Objects.requireNonNull(cs, "cs");

#26600 and subsequent PRs will add variable name reporting, so you can omit the string message to reduce bytecode size.

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

PR Review: https://git.openjdk.org/jdk/pull/26413#pullrequestreview-3101693404
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2263645886

From tvaleev at openjdk.org  Sun Aug 10 17:13:13 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 10 Aug 2025 17:13:13 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v7]
In-Reply-To: <vc5DbMxqvt3xquCHgBzhKg9n0u5Aus70DXPOf0os_yA=.3ead2059-7017-4b36-9e4d-7a929efcc23e@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
 <vc5DbMxqvt3xquCHgBzhKg9n0u5Aus70DXPOf0os_yA=.3ead2059-7017-4b36-9e4d-7a929efcc23e@github.com>
Message-ID: <6CxweWAMlWQ90cCILoDNr2v3gWmb95SX_iDY4jb9cQY=.cebebb5c-680f-416f-bf4c-e4b7649f5dfc@github.com>

On Thu, 7 Aug 2025 16:02:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @implSpec
>
> Maybe we can add some verbiage around why the first argument is returned if the values are equal? This relates to stable sorting algorithms and `min` and `max` can be viewed as a sorting algorithm with only two elements. So, min and max are stable in this sense and therefore amenable as a building block for more general stable sorting algorithms.

@minborg I think this would make the javadoc unnecessarily verbose. 

@rose00 yes, this totally makes sense.

@stuart-marks I see at least two 'consistency' arguments for current implementation:
1. Similar methods `BinaryOperator::minBy` and `BinaryOperator::maxBy` return both the first argument if they are equal
2. Guava's `Ordering::min` and `Ordering::max` also return the first argument, so their contract will be compatible with newly proposed methods (this is important, as `Ordering extends Comparator`). While Guava is a third-party library, it's quite popular in Java world, so it's reasonable to take it into account.

And I agree that `min(a, b) == max(b, a)` invariant does not look very useful in practice. In general, intuition expects the first argument to be returned (see the @minborg 's note about stable sorting).

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

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-3172773692

From jd at civilian-framework.org  Sun Aug 10 21:29:53 2025
From: jd at civilian-framework.org (=?UTF-8?Q?Johannes_D=C3=B6bler?=)
Date: Sun, 10 Aug 2025 23:29:53 +0200
Subject: Generic type signatures in MethodRepository have many copies of
 simple class names
In-Reply-To: <FC1D50CF-6C71-4250-937F-CB4821E1303B@gmail.com>
References: <FC1D50CF-6C71-4250-937F-CB4821E1303B@gmail.com>
Message-ID: <a64d370b-6a16-49c4-83c3-8af76d7bafcc@civilian-framework.org>

Hi Steven,

I think you are onto something. Given this example

> public class TypeParamsDemo {
> ??? public static void main(String[] args) throws Exception {
> ??????? Method method =?TypeParamsDemo.class.getMethod("getList", 
> Set.class);
> ??????? TypeVariable<Method>[] tp = method.getTypeParameters();
> ??? }
>
> ??? public <T extends Number> List<T> getList(Set<T> set) {
> ??????? return new ArrayList<>(set);
> ??? }
> }

Then:
tp[0].bounds[0].path[0].name is "java.lang.Number" and? is a newly 
created String parsed from the type signature 
"<T:Ljava/lang/Number;>(Ljava/util/Set<TT;>;)Ljava/util/List<TT;>;".
The result of method.getTypeParameters() is cached in 
Method.genericInfo, so once initialized by a caller (e.g. by 
Jackson/REST easy) it won't go away.
Imho interning the class name should be fine since it refers to an 
existing class.

Best
Johannes


On 09/08/2025 01:10, Steven Schlansker wrote:
> Hello core-libs-dev, happy Friday!
>
> While diagnosing an out of memory situation in our application, I noticed a surprising source of memory usage.
> While this is not so severe to actually cause our OOM, it seems wasteful and I thought to bring it to your attention.
>
> We use reflection-based technologies like Jackson JSON and RESTEasy that retrieve generic type information from many of our classes.
> Our profiler provides diagnostics of wasted space due to duplicate objects, particularly Strings.
>
> The analysis highlights many thousands of copies of String instances holding the full name of a class, e.g. "java.util.Optional"
> or "com.mycompany.Id". The path to GC route looks like:
>
> String <- sun.reflect.generics.tree.SimpleClassTypeSignature <- Object[] <- ArrayList <- ClassTypeSignature <- MethodTypeSignature <- MethodRepository <- Method
>
> Seeing how these SimpleClassTypeSignature instances are created, it looks like they come from the sun.reflect.generics.parser.SignatureParser which calls
> `input.substring(mark, index)`, possibly with a call to `replace('/', '.')` to munge the package name. In all but the simplest of cases, this will return a new String
> for every call.
>
> Since this String is representing a Class name, the cardinality should by its nature be very low. For each unique type, there will be many methods referring to it.
> Additionally, this generic information is lazy-loaded at most once per Method object.
>
> Therefore, SimpleClassTypeSignature.n seems like a natural place to apply String.intern(), for example changing:
>
> public static SimpleClassTypeSignature make(String n,
>      boolean dollar,
>      TypeArgument[] tas){
>          return new SimpleClassTypeSignature(n, dollar, tas);
> }
>
> to intern the name:
>
> public static SimpleClassTypeSignature make(String n,
>      boolean dollar,
>      TypeArgument[] tas){
>          return new SimpleClassTypeSignature(n.intern(), dollar, tas);
> }
>
> With any luck, maybe this can even share the same string instance as the class itself uses.
> Am I correct in thinking this would be a moderately nice improvement, for a relatively cheap cost?
> Or perhaps there's some reason this isn't a good idea?
>
> Thank you for your thoughts on the subject,
> Steven
>


From xgong at openjdk.org  Mon Aug 11 03:10:17 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 11 Aug 2025 03:10:17 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
Message-ID: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com>

On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
>> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
>> 
>>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
>> 
>> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
>> 
>> Performance numbers:
>> 
>> 
>> System : 13th Gen Intel(R) Core(TM) i3-1315U
>> 
>> Baseline:
>> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
>> VectorSliceB...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating predicate checks

Thanks for your work @jatin-bhateja! This PR also provides help on AArch64 that we also have plan to do the same intrinsifaction in our side.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1667:

> 1665: bool LibraryCallKit::inline_vector_slice() {
> 1666:   const TypeInt*     origin         = gvn().type(argument(0))->isa_int();
> 1667:   const TypeInstPtr* vector_klass = gvn().type(argument(1))->isa_instptr();

Code style:
Suggestion:

  const TypeInt*     origin       = gvn().type(argument(0))->isa_int();
  const TypeInstPtr* vector_klass = gvn().type(argument(1))->isa_instptr();

src/hotspot/share/opto/vectorIntrinsics.cpp line 1700:

> 1698: 
> 1699:   if (!arch_supports_vector(Op_VectorSlice, num_elem, elem_bt, VecMaskNotUsed)) {
> 1700:     log_if_needed("  ** not supported: arity=2 op=slice vlen=%d etype=%s ismask=useload/none",

`ismask=useload/none` is not necessary here?

src/hotspot/share/opto/vectorIntrinsics.cpp line 1714:

> 1712:   }
> 1713: 
> 1714:   Node* origin_node = gvn().intcon(origin->get_con() * type2aelembytes(elem_bt));

Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes.

Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such requirement. WDYT?

src/hotspot/share/opto/vectornode.hpp line 1719:

> 1717: class VectorSliceNode : public VectorNode {
> 1718:  public:
> 1719:   VectorSliceNode(Node* vec1, Node* vec2, Node* origin, const TypeVect* vt)

Do we have specific value for `origin` like zero or vlen? If so, maybe simply Identity is better to be added as well.

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

PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3103877319
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265568519
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265573060
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265579342
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265580768

From xgong at openjdk.org  Mon Aug 11 03:14:12 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 11 Aug 2025 03:14:12 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
Message-ID: <cKfMB03HU_UVleFKpPzuot9c1S0uc7QBNxzImvIWEeM=.69cf2c37-b3cf-4e59-a4c5-b6b34d341444@github.com>

On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
>> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
>> 
>>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
>> 
>> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
>> 
>> Performance numbers:
>> 
>> 
>> System : 13th Gen Intel(R) Core(TM) i3-1315U
>> 
>> Baseline:
>> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
>> VectorSliceB...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating predicate checks

test/micro/org/openjdk/bench/jdk/incubator/vector/VectorSliceBenchmark.java line 36:

> 34: @State(Scope.Thread)
> 35: @Fork(jvmArgs = {"--add-modules=jdk.incubator.vector"})
> 36: public class VectorSliceBenchmark {

I remember that it has the micro benchmarks for slice/unslice under `test/micro/org/openjdk/bench/jdk/incubator/vector/operation` on panama-vector. Can we reuse those JMHs to check the benchmark improvement?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265592754

From liach at openjdk.org  Mon Aug 11 04:54:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Aug 2025 04:54:10 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives [v2]
In-Reply-To: <RAEVEwPQn9HITx6gFkIQ-J0jRPhaju86-SmeTFuIxUA=.613dbc86-fdae-4e18-af47-658aba03b557@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
 <RAEVEwPQn9HITx6gFkIQ-J0jRPhaju86-SmeTFuIxUA=.613dbc86-fdae-4e18-af47-658aba03b557@github.com>
Message-ID: <qiOlrR05hxJYdnPgdT5QRFXpZC5CXXJA_74-dIzauYg=.c7429345-8bc4-4426-9f71-e51ae2c499b3@github.com>

On Fri, 1 Aug 2025 13:15:29 GMT, Brett Okken <duke at openjdk.org> wrote:

>> As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coding conventions

On second thought, even though Roger's concern is valid, I think the current shape is the best for this code. All usages of `JavaLangAccess.inflateBytesToChars` already exhibit the same pattern as the code here. A separate heuristic for this method would increase our maintenance cost for uncertain gains.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26597#pullrequestreview-3104041492

From pminborg at openjdk.org  Mon Aug 11 06:20:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Aug 2025 06:20:16 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v4]
In-Reply-To: <nSTF7HbN6TzYMd9jBf14oetXa5OwlTUT_zeuV3n8TAU=.5703b535-92de-4a21-8ffc-778aac3f14f1@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <LySAnsAPi6NdYJ04UFVOywDf6a2-HS7jYTW7traho3A=.b0988f84-4c1c-428d-b403-1e697afaaac9@github.com>
 <nSTF7HbN6TzYMd9jBf14oetXa5OwlTUT_zeuV3n8TAU=.5703b535-92de-4a21-8ffc-778aac3f14f1@github.com>
Message-ID: <E96e9quB6jJoILyo8SxkdkPTxoNut53_59xzlF2fIV8=.362b6755-301e-4a9e-8d38-6b5d568aa32f@github.com>

On Fri, 8 Aug 2025 16:04:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 266:
> 
>> 264: 
>> 265:             // The below computation is a branchless equivalent to
>> 266:             // `return (thisStart < thatEnd && thisEnd > thatStart)?1:0;`. Here is how:
> 
> It would be pretty cool if C2 could do the optimization of branch-less computations like these.

Yes. My thought as well. I will make some inquiries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26672#discussion_r2265780689

From pminborg at openjdk.org  Mon Aug 11 06:28:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Aug 2025 06:28:11 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v4]
In-Reply-To: <LySAnsAPi6NdYJ04UFVOywDf6a2-HS7jYTW7traho3A=.b0988f84-4c1c-428d-b403-1e697afaaac9@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <LySAnsAPi6NdYJ04UFVOywDf6a2-HS7jYTW7traho3A=.b0988f84-4c1c-428d-b403-1e697afaaac9@github.com>
Message-ID: <r75K2f3OJOxqvNu07RR9zbYRED4H-zYpRd84QteRcvg=.b9a02e68-c545-49e3-999b-db6f5ee55240@github.com>

On Fri, 8 Aug 2025 13:25:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

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

> 255:     // Returns 1 if the regions overlap, otherwise 0.
> 256:     @ForceInline
> 257:     int overlaps(AbstractMemorySegmentImpl that) {

This modification provides a 10% total (i.e., for copy) performance improvement across all platforms for some likely common copy sizes like 16 and 24.

Branching is sometimes an expensive operation that can disrupt the execution pipeline. With this, we avoid some branching. On the flip side, now both the expressions are always executed (in their branchless form). All things considered, this seems to be a win performance-wise at the expense of more complex code.

So, there is a tradeoff to consider.

I've tried to mitigate code complexity by commenting in the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26672#discussion_r2265793851

From jbhateja at openjdk.org  Mon Aug 11 06:39:57 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 11 Aug 2025 06:39:57 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v3]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <PUof24HJ0idOTBTqlcQY40KoYjj0-SxF2cEtAvndChw=.6e6348d2-db96-43de-b8d0-14802c346b26@github.com>

> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
> 
>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
> 
> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
> 
> Performance numbers:
> 
> 
> System : 13th Gen Intel(R) Core(TM) i3-1315U
> 
> Baseline:
> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Jatin Bhateja 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 branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
 - Updating predicate checks
 - Fixes for failing regressions
 -  Optimizing AVX2 backend and some re-factoring
 - new benchmark
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8303762
 - 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction

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

Changes: https://git.openjdk.org/jdk/pull/24104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=02
  Stats: 747 lines in 32 files changed: 664 ins; 0 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/24104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104

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

From vyazici at openjdk.org  Mon Aug 11 09:12:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 09:12:20 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <DSOlcRGOZfhCrFYl8vDxGlyVcwfVf_HNqr8XoYcl0Bo=.8ec0f273-e39f-498e-af5c-ad87106e6616@github.com>

On Fri, 8 Aug 2025 22:37:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Shall we accompany the changes with a set of tests that verifies `java.time.Instant::parse` against all all ISO 8601 date formats?

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

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3173872658

From ihse at openjdk.org  Mon Aug 11 09:39:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:39:21 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <gk7J2fluyshhY0YHFZDnWaXMOdnMtH42y1z7FGthfwU=.498019c5-643c-46fb-b744-c3c0bb1b8140@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3104868381

From redestad at openjdk.org  Mon Aug 11 11:14:20 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Aug 2025 11:14:20 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v13]
In-Reply-To: <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
Message-ID: <7vrt6sWpiQUWUchiSTMUByRbe8q1Tcd_VcfkJP4MaB0=.3ee3b5f9-7188-446b-bd9a-12233fda0488@github.com>

On Fri, 25 Jul 2025 07:40:46 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici 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 31 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Replace `requireNonNull` with implicit null checks to reduce bytecode size
>  - Add `@bug` tags
>  - Improve wording of `@param len`
>  - Make source array bound checks lenient too
>  - Cap destination array bounds
>  - Fix bit shifting
>  - Remove superseded `@throws` Javadoc
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Make `StringCoding` encoding intrinsics lenient
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/9a1823bd...c322f0e0

src/hotspot/share/opto/library_call.cpp line 964:

> 962: 
> 963:   if (bailout->req() > 1) {
> 964:     bailout = _gvn.transform(bailout)->as_Region();

Should this be done only for the case where it's needed, i.e., in the `if (halt)` branch? Not sure it has any side-effect but it seems prudent not to change the default code more than necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266374676

From cstein at openjdk.org  Mon Aug 11 11:35:12 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 11 Aug 2025 11:35:12 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v2]
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <J5fF6P9MhXKy2H2Xb4CDVdpED-zOGHHHrehDggSdsUs=.0d938d3d-cfcb-465b-bfdf-a13575113eb7@github.com>

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

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update to use correct library directories
  
  See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26261/files
  - new: https://git.openjdk.org/jdk/pull/26261/files/bf7b033b..b5112c32

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

  Stats: 30 lines in 2 files changed: 8 ins; 19 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261

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

From cstein at openjdk.org  Mon Aug 11 11:35:13 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 11 Aug 2025 11:35:13 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <45gc5UsWc5d6aePWF_7SSX0ERJTTvklTXBukRdjqhCc=.1cf0046e-b697-4fce-9751-e8eade48a49e@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

I updated both tests to be agnostic about the location to where `jtreg` puts library classes into. See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3174373256

From ihse at openjdk.org  Mon Aug 11 11:53:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 11:53:32 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
 <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>
Message-ID: <W9fd7acETIm00eLAGe0bFbH9KDJDdLqNVvSZ39jvWP0=.e3431808-2011-4bea-a544-f4654ec39b96@github.com>

On Fri, 1 Aug 2025 17:12:55 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove problemlisting
>
> make/StaticLibs.gmk line 163:
> 
>> 161: # $2: The launcher name
>> 162: define SetupRelauncher
>> 163:   $1_$2_LAUNCHER_ARGS_LINE :=  $$(shell cat $$(SUPPORT_OUTPUTDIR)/static-native/relaunchers/$1/$2-relauncher-arguments.txt)
> 
> `$(call ReadFile, ...)`
> 
> also, double space?

That was nicer. Had forgotten about it. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2266464765

From ihse at openjdk.org  Mon Aug 11 11:53:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 11:53:31 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v4]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <yzZilmhHHlxVz4xjLSV47S9QcjTANrUnm2ABuLHAf4w=.bbabcde8-fd53-44cf-afb9-f5c167f42679@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 16 commits:

 - Use ReadFile instead
 - Merge branch 'master' into static-relaunchers
 - Remove problemlisting
 - Merge branch 'master' into static-relaunchers
 - Improve windows runtime lib copying
 - Fix linux launcher to allow relaunching
 - Copy Windows runtime libs
 - Merge branch 'master' into static-relaunchers
 - Merge branch 'master' into static-relaunchers
 - Add cast for Windows
 - ... and 6 more: https://git.openjdk.org/jdk/compare/a60e523f...84585f7a

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

Changes: https://git.openjdk.org/jdk/pull/24380/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=03
  Stats: 817 lines in 14 files changed: 628 ins; 143 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 mbaesken at openjdk.org  Mon Aug 11 11:58:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Aug 2025 11:58:29 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
Message-ID: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>

When using asan - enabled binaries, the following tests fail (on Linux x86_64).
This one uses ulimit in a way problematic with asan :
vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java

 ```
stdout: [];
 stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v

 exitValue = 134


This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
tools/launcher/TooSmallStackSize.java

PASSED: got expected error message with stack size of 16k
PASSED: got expected error message with stack size of 64k
Test output:
*** exitValue = 139
FAILED: VM failed to launch with minimum allowed stack size of 136k

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

Commit messages:
 - JDK-8365240

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

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

From pminborg at openjdk.org  Mon Aug 11 12:41:27 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Aug 2025 12:41:27 GMT
Subject: RFR: 8365203: defineClass with direct buffer can cause use-after-free
Message-ID: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>

### Description
This PR proposes to update the `ClassLoader` implementation to properly guard access to the provided `ByteBuffer` when defining a class using `defineClass(String, ByteBuffer, ...)`. Specifically, calls to `SharedSecrets.getJavaNioAccess().acquireSession(ByteBuffer)` and `releaseSession(ByteBuffer)` have been introduced to ensure safe and consistent buffer access throughout the native class definition process, even in the case of a `ByteBuffer` is backed by a `MemorySegment`.

### Impact
This modification is internal to the `ClassLoader` implementation and does not affect the public API.
Improves the robustness and security of class loading from buffers.

### Testing
Tier 1, 2, and 3 JDK tests pass on multiple platforms.

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

Commit messages:
 - Add test
 - Update copyright year
 - Guard ClassLoader::defineClass2

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

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

From pminborg at openjdk.org  Mon Aug 11 12:41:27 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Aug 2025 12:41:27 GMT
Subject: RFR: 8365203: defineClass with direct buffer can cause
 use-after-free
In-Reply-To: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
References: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
Message-ID: <6XFyBWJ_26eIeHy7qXSo7Uoe-v9tfkq-RB-SJyhNJE8=.5bfadef9-080b-4598-ba46-295dd51dfc1e@github.com>

On Mon, 11 Aug 2025 11:33:19 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> ### Description
> This PR proposes to update the `ClassLoader` implementation to properly guard access to the provided `ByteBuffer` when defining a class using `defineClass(String, ByteBuffer, ...)`. Specifically, calls to `SharedSecrets.getJavaNioAccess().acquireSession(ByteBuffer)` and `releaseSession(ByteBuffer)` have been introduced to ensure safe and consistent buffer access throughout the native class definition process, even in the case of a `ByteBuffer` is backed by a `MemorySegment`.
> 
> ### Impact
> This modification is internal to the `ClassLoader` implementation and does not affect the public API.
> Improves the robustness and security of class loading from buffers.
> 
> ### Testing
> Tier 1, 2, and 3 JDK tests pass on multiple platforms.

src/java.base/share/classes/java/lang/ClassLoader.java line 1054:

> 1052:         String source = defineClassSourceLocation(protectionDomain);
> 1053: 
> 1054:         SharedSecrets.getJavaNioAccess().acquireSession(b);

Now that the fields in `SharedSecrets` are `@Stable`, we do not have to make a local copy in a `static final` field.

test/jdk/java/lang/ClassLoader/defineClass/GuardByteBuffer.java line 43:

> 41: 
> 42:     @Test
> 43:     void guardCrash() throws InterruptedException {

I was not able to reproduce the crash using this test on a Mac. The original reproducer worked on a Windows machine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26724#discussion_r2266596901
PR Review Comment: https://git.openjdk.org/jdk/pull/26724#discussion_r2266592416

From redestad at openjdk.org  Mon Aug 11 12:46:19 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Aug 2025 12:46:19 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v13]
In-Reply-To: <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
Message-ID: <PsjK6fTQPOEVAT46TS_KT2U5ccoAO_Z0ojRP2qCllPo=.15e89fd7-5c60-4cff-b47b-a7ba3560cc67@github.com>

On Fri, 25 Jul 2025 07:40:46 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici 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 31 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Replace `requireNonNull` with implicit null checks to reduce bytecode size
>  - Add `@bug` tags
>  - Improve wording of `@param len`
>  - Make source array bound checks lenient too
>  - Cap destination array bounds
>  - Fix bit shifting
>  - Remove superseded `@throws` Javadoc
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Make `StringCoding` encoding intrinsics lenient
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/502f1129...c322f0e0

src/hotspot/share/opto/library_call.cpp line 946:

> 944:                                                  Node* count,
> 945:                                                  bool char_count,
> 946:                                                  bool halt) {

Could we rename this to something more descriptive such as `halt_on_oob`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266616962

From coffeys at openjdk.org  Mon Aug 11 12:57:10 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 11 Aug 2025 12:57:10 GMT
Subject: RFR: 7191877: TEST_BUG:
 java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing
 intermittently
In-Reply-To: <6-Ej6gQDcrnV_LOQaLRCxO08mUVbbX_ZGPahC_ntK2k=.6e97cf50-3fec-4e0e-a4a9-8cc84ad4fc91@github.com>
References: <6-Ej6gQDcrnV_LOQaLRCxO08mUVbbX_ZGPahC_ntK2k=.6e97cf50-3fec-4e0e-a4a9-8cc84ad4fc91@github.com>
Message-ID: <afGdjpPp6BC5abb2JQ6xNRXyN0w8ZwBFmfHB5IOwisQ=.61548d20-2d1c-477e-ba67-ed73a2acedb5@github.com>

On Wed, 6 Aug 2025 10:29:45 GMT, Johny Jose <duke at openjdk.org> wrote:

> The test was problem listed since jdk8 as intermittent failures were observed. For all the failed scenarios, number of objects left in leaseTable were less than or equal to 4. Though for most of the runs the number of objects left is less than 2, at times the tests are failing when the remaining objects are 3 or 4 (observed only on mac os). As per the code, the leak should be fixed if the number of objects left in the table is less than 11. I have updated the acceptable number of objects to 4 from 2, and is still at lower end compared to 11.

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26657#pullrequestreview-3105703235

From jpai at openjdk.org  Mon Aug 11 13:19:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 11 Aug 2025 13:19:19 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v18]
In-Reply-To: <uqpPLDqBOW-qI8Ej_iol2cHxy6HzpiMnez3CfHb2_SQ=.7e4a3915-3204-4723-aceb-1fdf3c79a9f5@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <uqpPLDqBOW-qI8Ej_iol2cHxy6HzpiMnez3CfHb2_SQ=.7e4a3915-3204-4723-aceb-1fdf3c79a9f5@github.com>
Message-ID: <KwDSCeQPGMW2pijbAO7d8hJvBDT2cgFJWVVnfgrS1YA=.1fd3e8b3-f832-4ceb-8892-6113f5b7715e@github.com>

On Wed, 6 Aug 2025 12:37:34 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes subtle false-positive with paths like /modules/modules/...

Hello David, thank you for the updates. These updated changes look good to me.

I have briefly looked at the tests but haven't paid close attention to those details. It would be good to have a tier1, tier2, tier3 run done in our CI before integration.

Given the area of this change, please wait for Alan or Roger's approval before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-3105834234

From jpai at openjdk.org  Mon Aug 11 13:23:20 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 11 Aug 2025 13:23:20 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <cQ0ecsPGONSm4jP9xyNI2E02Xd04Ud7xOqq_EU1VAxo=.83e5bcc0-4abc-4072-9c30-7a5f45adb414@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
 <ogI0LDJwH7ochb54mGArTep8RqX0lnDPrffe9vFaHx4=.4c6560aa-583e-4679-9fdb-228a76198723@github.com>
 <BgPpj2f046zCLPM-I54DXWaQFa--XK0sb5HCrDsLuIc=.f548c27d-9fd1-41a4-a204-9e56ddc3b5d3@github.com>
 <E1vsxqCnRs23ckizuiD3OMGnjKC1BBn1HM4PzmWZbQ0=.de3a2a6a-c63c-44c6-8a2b-13d28224aa6f@github.com>
 <U5RvuCphGAlVfxyUmcSZFtm-dm9PudIfA7--HMmSSOU=.e6eab399-8ee1-43e9-895d-ab0b9de66229@github.com>
 <cQ0ecsPGONSm4jP9xyNI2E02Xd04Ud7xOqq_EU1VAxo=.83e5bcc0-4abc-4072-9c30-7a5f45adb414@github.com>
Message-ID: <oyfqjDWS9UoZ6Dg-Sr8pmZ9SzKJbAiqChCKT_233R0Y=.f31e727f-057a-4fb1-aabb-e92b414000d2@github.com>

On Wed, 6 Aug 2025 20:25:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>>> "is completed" is a non-directory type, "getLocation() failing" is a non-resource type.
>> 
>> If getLocation() by default throws a `IllegalStateException` stating that the `Node` is not a resource type, then I think it would be more accurate for `isCompleted()` to by default return `false` to match the claim that the `Node` is not a resource type.
>
> Hmm, I see the argument, but then I have to make two additional overrides to make it return true in the cases where it's always, unconditionally, true. I don't like adding more code for no functional improvement though.
> 
> Remember that (unlike the current code) this change removes "isCompleted()" as a visible method, so it's only usable internally and cannot be used in unexpected ways. Outside of asserts, it's now called exactly once, so it's not hard to reason about it, however it's implemented.
> 
> I mean I could remove it from Node and only have it as a Directory method and use instanceof and a cast before calling it ... but it's more code in the actual business logic and doesn't achieve anything because the chance of misuse is zero, since everything would break if it was somehow used incorrectly.
> 
> Basically isComplete() == false => it's a directory that need its children populated.
> So, I could flip the return value and name is "isIncompleteDirectory()" which is more precise (an "uglier" name draws attention to the fact it captures something about the special case nature of directories).

I think it's OK in the current form you have. Having this class `abstract` would have forced the implementing classes to be sure about what they want to return from these methods, but as you note, this is an internal interface (implemented by very specific/few classes) and you have added the method javadocs to them. So it's OK in its current form.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2266752232

From duke at openjdk.org  Mon Aug 11 13:35:13 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 11 Aug 2025 13:35:13 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives
In-Reply-To: <LEbHkOhn5zKsiTkx2JqQDwLnDbKa3QXYDi2154TIpPQ=.9f0e0bfa-00c1-4427-a33c-85861d6e247e@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
 <v5rMHbV1UT7DJUJYjmRDSzQAkc_C2g_vWWGT8W50DiE=.9e7e7b2f-adfb-4194-86aa-adf9716c6613@github.com>
 <LEbHkOhn5zKsiTkx2JqQDwLnDbKa3QXYDi2154TIpPQ=.9f0e0bfa-00c1-4427-a33c-85861d6e247e@github.com>
Message-ID: <99s71XLMoJAiiSueuQ6mD-1N7Z6mOzs1XVnh88863RY=.78e22868-dc22-4e20-b8b7-96c085cc410a@github.com>

On Fri, 1 Aug 2025 16:12:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Benchmark on win64
>> 
>> Baseline:
>> 
>> 
>> Benchmark                           (charsetName)  Mode  Cnt      Score     Error  Units
>> StringEncode.encodeAllMixed                 UTF-8  avgt   10  20067.519 ?? 528.152  ns/op
>> StringEncode.encodeAsciiLong                UTF-8  avgt   10  12115.389 ?? 307.491  ns/op
>> StringEncode.encodeAsciiShort               UTF-8  avgt   10     70.098 ??   1.696  ns/op
>> StringEncode.encodeLatin1LongEnd            UTF-8  avgt   10   1974.391 ?? 162.405  ns/op
>> StringEncode.encodeLatin1LongOnly           UTF-8  avgt   10    270.097 ??  13.840  ns/op
>> StringEncode.encodeLatin1LongStart          UTF-8  avgt   10   1876.366 ??  51.971  ns/op
>> StringEncode.encodeLatin1Mixed              UTF-8  avgt   10   4973.070 ?? 130.426  ns/op
>> StringEncode.encodeLatin1Short              UTF-8  avgt   10     96.227 ??   2.816  ns/op
>> StringEncode.encodeShortMixed               UTF-8  avgt   10    360.586 ??   8.691  ns/op
>> StringEncode.encodeUTF16LongEnd             UTF-8  avgt   10   1534.748 ??  34.584  ns/op
>> StringEncode.encodeUTF16LongOnly            UTF-8  avgt   10    528.919 ??  15.143  ns/op
>> StringEncode.encodeUTF16LongStart           UTF-8  avgt   10   2275.117 ??  50.152  ns/op
>> StringEncode.encodeUTF16Mixed               UTF-8  avgt   10   4398.943 ?? 116.607  ns/op
>> StringEncode.encodeUTF16Short               UTF-8  avgt   10    152.219 ??   8.677  ns/op
>> 
>> 
>> 
>> Patch:
>> 
>> Benchmark                           (charsetName)  Mode  Cnt      Score     Error  Units
>> StringEncode.encodeAllMixed                 UTF-8  avgt   10  18876.056 ?? 330.644  ns/op
>> StringEncode.encodeAsciiLong                UTF-8  avgt   10  12040.590 ?? 165.905  ns/op
>> StringEncode.encodeAsciiShort               UTF-8  avgt   10     69.895 ??   0.318  ns/op
>> StringEncode.encodeLatin1LongEnd            UTF-8  avgt   10    574.455 ??  14.769  ns/op
>> StringEncode.encodeLatin1LongOnly           UTF-8  avgt   10    284.553 ??   1.886  ns/op
>> StringEncode.encodeLatin1LongStart          UTF-8  avgt   10   2230.789 ??  11.043  ns/op
>> StringEncode.encodeLatin1Mixed              UTF-8  avgt   10   3278.998 ??  96.779  ns/op
>> StringEncode.encodeLatin1Short              UTF-8  avgt   10     99.332 ??   1.977  ns/op
>> StringEncode.encodeShortMixed               UTF-8  avgt   10    378.183 ??  17.504  ns/op
>> StringEncode.encodeUTF16LongEnd             UTF-8  avgt   10   1531.960 ??  19.300  ns/op
>> StringEncode.encodeUTF16LongOnly            U...
>
> @bokken FYI to make JMH comparison easier, you can let JMH generate JSON reports, upload them to github gists, and use https://jmh.morethan.io/ to compare the two results from two gists.

@liach / @RogerRiggs I have been experimenting locally with other options which are a bit more complex:
https://github.com/bokken/jdk/commits/string-utf8-mincopylength/
This seems like maybe a decent balance of complexity vs gain: https://github.com/bokken/jdk/commit/ee9d9e3496052fd5084f989bd7181504989d812b

I am continuing to evaluate various options.

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

PR Comment: https://git.openjdk.org/jdk/pull/26597#issuecomment-3174871115

From vyazici at openjdk.org  Mon Aug 11 13:47:41 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 13:47:41 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v14]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <FqQZN9LLVypXF8467vZ86otxassb4ma9_geoLpfv3q4=.4ff5fb4e-d286-43fb-852d-1a871b054e3c@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Rename `generate_string_range_check::halt` to `halt_on_oob`
 - Move `->asRegion()` after `if (halt)`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/c322f0e0..9b721bb9

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

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

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

From vyazici at openjdk.org  Mon Aug 11 13:47:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 13:47:44 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v13]
In-Reply-To: <PsjK6fTQPOEVAT46TS_KT2U5ccoAO_Z0ojRP2qCllPo=.15e89fd7-5c60-4cff-b47b-a7ba3560cc67@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
 <PsjK6fTQPOEVAT46TS_KT2U5ccoAO_Z0ojRP2qCllPo=.15e89fd7-5c60-4cff-b47b-a7ba3560cc67@github.com>
Message-ID: <aep9gHlIyiEGvIeXBsXkCFrALcZPrFKRjHTOZX0kux0=.5e57e7d3-30a7-43ed-9cda-662c921b83ab@github.com>

On Mon, 11 Aug 2025 12:43:38 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Volkan Yazici 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 31 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Replace `requireNonNull` with implicit null checks to reduce bytecode size
>>  - Add `@bug` tags
>>  - Improve wording of `@param len`
>>  - Make source array bound checks lenient too
>>  - Cap destination array bounds
>>  - Fix bit shifting
>>  - Remove superseded `@throws` Javadoc
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Make `StringCoding` encoding intrinsics lenient
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/357546c1...c322f0e0
>
> src/hotspot/share/opto/library_call.cpp line 946:
> 
>> 944:                                                  Node* count,
>> 945:                                                  bool char_count,
>> 946:                                                  bool halt) {
> 
> Could we rename this to something more descriptive such as `halt_on_oob`?

Changed as requested in 9b721bb9fee.

> src/hotspot/share/opto/library_call.cpp line 964:
> 
>> 962: 
>> 963:   if (bailout->req() > 1) {
>> 964:     bailout = _gvn.transform(bailout)->as_Region();
> 
> Should this be done only for the case where it's needed, i.e., in the `if (halt)` branch? Not sure it has any side-effect but it seems prudent not to change the default code more than necessary.

Changed as requested in 4d2a7a39c50.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266824420
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266823319

From tats.u at live.jp  Mon Aug 11 13:54:13 2025
From: tats.u at live.jp (Uchino Tatsunori)
Date: Mon, 11 Aug 2025 13:54:13 +0000
Subject: I'd like add no-argument overloads to CharSequence, String, and
 StringBuilder  (JDK-8364007)
Message-ID: <TYVPR01MB11356758C6F8D586191C3061B9120A@TYVPR01MB11356.jpnprd01.prod.outlook.com>

Dear core-libs developers,

I'd like to add the following overloads:

? Character.codePointCount(CharSequence seq)
? Character.codePointCount(char[] a)
? String.codePointCount(int beginIndex)
? StringBuffer.codePointCount()
? StringBuilder.codePointCount()

and created a patch (https://github.com/openjdk/jdk/pull/26461).

Why:

There have already been similar overloads with the start and end indicies by JSR 204 (JDK-4985217). They are thought to have been designed with a priority on versatility. They make the specification of indices mandatory, but have the following disadvantages:

1. The string expression have to be written twice. Unlike C#, Java has no equivalent of extended methods.
2. Unneccesary boundary checks are mixed in.
3. The most userland code tries to calculate the number of code points in the entire stirng.
4. Some other languages can count the number of code points in a single function without extra arguments (e.g. len() in Python3)

For 3., e.g.:

? VARCHAR in MySQL & PostgreSQL counts the number of characters in the unit of code points. e.g. VARCHAR(20) means that the limit is 20 code points, not 20 UTF-16 code units (20 chars in Java)
? NIST Special Publication 800-63B stiplates that the password length must be counted as the unit of code points. (Quote from https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers : "For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.")

I would like to get agreement on these changes and would like to know what I have to do outside of GitHub (e.g how to submit CSRs). If you have a GitHub account, it would be helpful if you could reply to the PR. If not, you can reply directly to this email.

Best Regards,

Tatsunori Uchino 
https://github.com/tats-u/

From vyazici at openjdk.org  Mon Aug 11 13:56:18 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 13:56:18 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v13]
In-Reply-To: <xyPYYfvuC6ESA6jHdPEuB9gK_po4sOpF5ME-acayZyw=.632d1880-4706-4a27-adcb-f5d4b18d0780@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
 <xyPYYfvuC6ESA6jHdPEuB9gK_po4sOpF5ME-acayZyw=.632d1880-4706-4a27-adcb-f5d4b18d0780@github.com>
Message-ID: <ID6qi60wy2qzYdfOxPObg8ymCQWoF4K1n_L2ugtDNu8=.0f410a35-7a22-4138-869f-40246c0ecfc6@github.com>

On Wed, 6 Aug 2025 05:24:41 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Volkan Yazici 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 31 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Replace `requireNonNull` with implicit null checks to reduce bytecode size
>>  - Add `@bug` tags
>>  - Improve wording of `@param len`
>>  - Make source array bound checks lenient too
>>  - Cap destination array bounds
>>  - Fix bit shifting
>>  - Remove superseded `@throws` Javadoc
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Make `StringCoding` encoding intrinsics lenient
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/565028e3...c322f0e0
>
> src/java.base/share/classes/java/lang/StringCoding.java line 99:
> 
>> 97:      *         {@linkplain Preconditions#checkFromIndexSize(int, int, int, BiFunction) out of bounds}
>> 98:      */
>> 99:     static int countPositives(byte[] ba, int off, int len) {
> 
> If we name countPositives with parameter checking as countPositivesSB, this PR will have fewer changes.

I presume you mean we would not need to touch `vmIntrinsics.hpp` and such. I discussed this with @cl4es, and we decided to keep the _"`foo` for method, and `foo0` for intrinsic candidate"_ convention, since this matches the existing one. Unless more experienced maintainers tell do to otherwise, I will stick to the current style.

@wenshao, nevertheless, thanks so much for your kind review(s). Please keep them coming. ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266851757

From epeter at openjdk.org  Mon Aug 11 14:06:13 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 11 Aug 2025 14:06:13 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v4]
In-Reply-To: <LySAnsAPi6NdYJ04UFVOywDf6a2-HS7jYTW7traho3A=.b0988f84-4c1c-428d-b403-1e697afaaac9@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <LySAnsAPi6NdYJ04UFVOywDf6a2-HS7jYTW7traho3A=.b0988f84-4c1c-428d-b403-1e697afaaac9@github.com>
Message-ID: <ijINS55nAiua-2eJyPlXkR65HM_ZuE-EMRJvzgcRv9A=.44d097d8-f731-4e2d-ab1b-7dec8157cce4@github.com>

On Fri, 8 Aug 2025 13:25:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

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

> 268:             // We can subtract (non-negative) thatEnd on both sides:
> 269:             // (thisStart < thatEnd) -> (thisStart - thatEnd < 0). In the same way we can say:
> 270:             // (thatStart < thisEnd) -> (thatStart - thisEnd < 0).

You are only stating the assumption that `thatEnd` is non-negative.
But I think you need all 4 values to be non-negative.

As a counter-example, assume:

thatEnd = 1
thisStart = Long.MIN_VALUE

thisStart < thatEnd = true
but
(thisStart - thatEnd < 0) = (Long.MAX_VALUE < 0) = false

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26672#discussion_r2266880849

From galder at openjdk.org  Mon Aug 11 14:09:19 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 11 Aug 2025 14:09:19 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <phlaY7VkRoWWwDzsnKw3JxaaU-lZk3tXFo8KCEtbn3Q=.3ccdd4ac-d61c-4c4c-b679-7bab67072ee1@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
 <phlaY7VkRoWWwDzsnKw3JxaaU-lZk3tXFo8KCEtbn3Q=.3ccdd4ac-d61c-4c4c-b679-7bab67072ee1@github.com>
Message-ID: <t1HL1C_N0S0Z2EBVUqSrTs24kKDKM-Cng9EwnWTfBTQ=.2d2c1afb-699f-443e-a015-4b04ea3f96db@github.com>

On Sun, 10 Aug 2025 05:23:23 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check at the very least that auto vectorization is supported
>
> src/hotspot/share/opto/superword.cpp line 1635:
> 
>> 1633:     } else if (VectorNode::is_convert_opcode(opc)) {
>> 1634:       retValue = VectorCastNode::implemented(opc, size, velt_basic_type(p0->in(1)), velt_basic_type(p0));
>> 1635:     } else if (VectorNode::is_reinterpret_opcode(opc)) {
> 
> How does this affect `Op_ReinterpretHF2S` that is also in `VectorNode::is_reinterpret_opcode`?
> I'm afraid that we need to test this with hardware or Intel's SDE, to make sure we have it running on a VM that actually supports Float16. Otherwise these instructions may not be used, and hence not tested right.
> 
> @galderz Can you run the relevant tests?

Would you run specific tiers in those platforms? Just hotspot compiler? Or individual tests such as `ConvF2HFIdealizationTests` and `TestFloat16ScalarOperations`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2266889792

From epeter at openjdk.org  Mon Aug 11 14:14:14 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 11 Aug 2025 14:14:14 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <t1HL1C_N0S0Z2EBVUqSrTs24kKDKM-Cng9EwnWTfBTQ=.2d2c1afb-699f-443e-a015-4b04ea3f96db@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
 <phlaY7VkRoWWwDzsnKw3JxaaU-lZk3tXFo8KCEtbn3Q=.3ccdd4ac-d61c-4c4c-b679-7bab67072ee1@github.com>
 <t1HL1C_N0S0Z2EBVUqSrTs24kKDKM-Cng9EwnWTfBTQ=.2d2c1afb-699f-443e-a015-4b04ea3f96db@github.com>
Message-ID: <BJp73aGLKqCh1cR-XZHFIHCIaXuGzvtIjMhYgOol_fs=.40b4accf-53ae-47fd-8334-7a124aacaf74@github.com>

On Mon, 11 Aug 2025 14:06:41 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> src/hotspot/share/opto/superword.cpp line 1635:
>> 
>>> 1633:     } else if (VectorNode::is_convert_opcode(opc)) {
>>> 1634:       retValue = VectorCastNode::implemented(opc, size, velt_basic_type(p0->in(1)), velt_basic_type(p0));
>>> 1635:     } else if (VectorNode::is_reinterpret_opcode(opc)) {
>> 
>> How does this affect `Op_ReinterpretHF2S` that is also in `VectorNode::is_reinterpret_opcode`?
>> I'm afraid that we need to test this with hardware or Intel's SDE, to make sure we have it running on a VM that actually supports Float16. Otherwise these instructions may not be used, and hence not tested right.
>> 
>> @galderz Can you run the relevant tests?
>
> Would you run specific tiers in those platforms? Just hotspot compiler? Or individual tests such as `ConvF2HFIdealizationTests` and `TestFloat16ScalarOperations`?

Honestly, I don't know, I'd have to do the research myself. Probably focusing on the Float16 tests would be good enough. No other test would really use Float16, so running anything else would not be that useful probably.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2266903230

From ihse at openjdk.org  Mon Aug 11 14:21:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 14:21:12 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
 <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>
Message-ID: <Tw5maFbJaPI5q0x-o44DqHICHN-dvxUQyUGaW4IbCLU=.abca2f27-d43f-48bd-9b92-c950002dbf0e@github.com>

On Fri, 1 Aug 2025 14:33:43 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove problemlisting
>
> make/ModuleWrapper.gmk line 82:
> 
>> 80:     TARGETS += $(LAUNCHERS_LIST)
>> 81:   endif
>> 82: endif
> 
> I think it would be cleaner if this could be kept in LauncherCommon.gmk and avoid having ModuleWrapper.gmk involved in this. I think it can be done relatively easily. In SetupBuildLauncherBody, instead of constructing the variable `$(MODULE)_INCLUDED_LAUNCHERS`, declare dependencies for `$(LAUNCHER_LIST)`, something like this:
> 
> $(LAUNCHER_LIST): $$($1)
> TARGETS += $(LAUNCHER_LIST)
> 
> 
> Then put the the recipe for `$(LAUNCHER_LIST)` at the end of LauncherCommon.gmk. The $(LAUNCHER_LIST) value will sometimes be added to TARGETS multiple times, but that's ok I think.

Hm. I put it there since it was the only place where we could be sure we know *all* launchers for a module. I could have each launcher add itself to the list, but then I either need to check if it is already there, or we will just append to the list each time we rebuild. And we risk a race when several launchers build at the same time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2266920768

From ihse at openjdk.org  Mon Aug 11 14:21:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 14:21:12 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <Tw5maFbJaPI5q0x-o44DqHICHN-dvxUQyUGaW4IbCLU=.abca2f27-d43f-48bd-9b92-c950002dbf0e@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
 <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>
 <Tw5maFbJaPI5q0x-o44DqHICHN-dvxUQyUGaW4IbCLU=.abca2f27-d43f-48bd-9b92-c950002dbf0e@github.com>
Message-ID: <A71apIJFIXpdfoYfRLzA4q3qLNvmvj0A8_sQHqTpCBU=.bfeb0c07-3ce7-45e7-9cbd-3a6abb767756@github.com>

On Mon, 11 Aug 2025 14:17:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/ModuleWrapper.gmk line 82:
>> 
>>> 80:     TARGETS += $(LAUNCHERS_LIST)
>>> 81:   endif
>>> 82: endif
>> 
>> I think it would be cleaner if this could be kept in LauncherCommon.gmk and avoid having ModuleWrapper.gmk involved in this. I think it can be done relatively easily. In SetupBuildLauncherBody, instead of constructing the variable `$(MODULE)_INCLUDED_LAUNCHERS`, declare dependencies for `$(LAUNCHER_LIST)`, something like this:
>> 
>> $(LAUNCHER_LIST): $$($1)
>> TARGETS += $(LAUNCHER_LIST)
>> 
>> 
>> Then put the the recipe for `$(LAUNCHER_LIST)` at the end of LauncherCommon.gmk. The $(LAUNCHER_LIST) value will sometimes be added to TARGETS multiple times, but that's ok I think.
>
> Hm. I put it there since it was the only place where we could be sure we know *all* launchers for a module. I could have each launcher add itself to the list, but then I either need to check if it is already there, or we will just append to the list each time we rebuild. And we risk a race when several launchers build at the same time.

I could also create a separate file for each launcher with a name pattern and gather up all these files in StaticLibs.gmk, but then I will get problems with left-over such files, for e.g. if incrementally building after removing a launcher. Not a common scenario, I agree, but it seems like a worse solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2266924514

From ihse at openjdk.org  Mon Aug 11 14:25:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 14:25:13 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <A71apIJFIXpdfoYfRLzA4q3qLNvmvj0A8_sQHqTpCBU=.bfeb0c07-3ce7-45e7-9cbd-3a6abb767756@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
 <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>
 <Tw5maFbJaPI5q0x-o44DqHICHN-dvxUQyUGaW4IbCLU=.abca2f27-d43f-48bd-9b92-c950002dbf0e@github.com>
 <A71apIJFIXpdfoYfRLzA4q3qLNvmvj0A8_sQHqTpCBU=.bfeb0c07-3ce7-45e7-9cbd-3a6abb767756@github.com>
Message-ID: <J6-ABR3b34n5S3W1zHMSr_TxRNAnRioKaN6oIZljRuo=.4f116d02-f16e-4b43-9f07-63207cba38e0@github.com>

On Mon, 11 Aug 2025 14:18:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hm. I put it there since it was the only place where we could be sure we know *all* launchers for a module. I could have each launcher add itself to the list, but then I either need to check if it is already there, or we will just append to the list each time we rebuild. And we risk a race when several launchers build at the same time.
>
> I could also create a separate file for each launcher with a name pattern and gather up all these files in StaticLibs.gmk, but then I will get problems with left-over such files, for e.g. if incrementally building after removing a launcher. Not a common scenario, I agree, but it seems like a worse solution.

This solution was modeled on how we create `module-included-libs.txt`. I agree that it is a bit hacky to inject this kind of stuff in ModuleWrapper, but I can't see how we can do it more cleanly. That's the only point at which we know the entire module for a phase. 

Maybe we can improve optics by doing a more official-looking "hook" for injecting functionality at pre-/post- whole-module processing? That would keep ModuleWrapper slimmer and without all the current specialized hooks, and make the name "wrapper" more relevant.

Or, we could rename the makefile to indicate better that it does a lot more than just wraps a file. (I have no good suggestions right now.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2266936847

From liach at openjdk.org  Mon Aug 11 14:38:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Aug 2025 14:38:13 GMT
Subject: RFR: 8365203: defineClass with direct buffer can cause
 use-after-free
In-Reply-To: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
References: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
Message-ID: <RkFuGn6KZ3egC3pzmTvVLTknx6VSakKY2h6FCXs8emU=.8d59f849-5d65-47f4-b96f-377d8e107cf2@github.com>

On Mon, 11 Aug 2025 11:33:19 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> ### Description
> This PR proposes to update the `ClassLoader` implementation to properly guard access to the provided `ByteBuffer` when defining a class using `defineClass(String, ByteBuffer, ...)`. Specifically, calls to `SharedSecrets.getJavaNioAccess().acquireSession(ByteBuffer)` and `releaseSession(ByteBuffer)` have been introduced to ensure safe and consistent buffer access throughout the native class definition process, even in the case of a `ByteBuffer` is backed by a `MemorySegment`.
> 
> ### Impact
> This modification is internal to the `ClassLoader` implementation and does not affect the public API.
> Improves the robustness and security of class loading from buffers.
> 
> ### Testing
> Tier 1, 2, and 3 JDK tests pass on multiple platforms.

src/java.base/share/classes/java/lang/ClassLoader.java line 1057:

> 1055:         try {
> 1056:             Class<?> c = defineClass2(this, name, b, b.position(), len, protectionDomain, source);
> 1057:             postDefineClass(c, protectionDomain);

Should we leave postDefineClass out of this acquire-release scope? I don't see any reason including this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26724#discussion_r2266981328

From alanb at openjdk.org  Mon Aug 11 14:57:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Aug 2025 14:57:11 GMT
Subject: RFR: 8365203: defineClass with direct buffer can cause
 use-after-free
In-Reply-To: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
References: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
Message-ID: <Uz_SFCgJfh1Xk3ePl4Qgt_4ktOJNsMY_3fXu0FdlFv8=.a782ba28-14f8-4474-a864-a662852c2b05@github.com>

On Mon, 11 Aug 2025 11:33:19 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> ### Description
> This PR proposes to update the `ClassLoader` implementation to properly guard access to the provided `ByteBuffer` when defining a class using `defineClass(String, ByteBuffer, ...)`. Specifically, calls to `SharedSecrets.getJavaNioAccess().acquireSession(ByteBuffer)` and `releaseSession(ByteBuffer)` have been introduced to ensure safe and consistent buffer access throughout the native class definition process, even in the case of a `ByteBuffer` is backed by a `MemorySegment`.
> 
> ### Impact
> This modification is internal to the `ClassLoader` implementation and does not affect the public API.
> Improves the robustness and security of class loading from buffers.
> 
> ### Testing
> Tier 1, 2, and 3 JDK tests pass on multiple platforms.

test/jdk/java/lang/ClassLoader/defineClass/GuardByteBuffer.java line 58:

> 56:         };
> 57:         final List<Thread> threads = new ArrayList<>();
> 58:         for (int i = 0; i < Runtime.getRuntime().availableProcessors(); i++) {

This means all cores spinning for 20s - we'll have to see if it causes any side effects and slow down of other tests that happen to run at the same time in other agent VMs (make run-test uses concurrency by default).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26724#discussion_r2267040749

From alanb at openjdk.org  Mon Aug 11 15:02:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Aug 2025 15:02:12 GMT
Subject: RFR: 8365203: defineClass with direct buffer can cause
 use-after-free
In-Reply-To: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
References: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
Message-ID: <wjBf2jPhcMfsYVa76zjo5Gs5MVbLqPkYgevYsvDqn9M=.1684474c-8eb1-4f2c-a32d-54fdfc04d26b@github.com>

On Mon, 11 Aug 2025 11:33:19 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> ### Description
> This PR proposes to update the `ClassLoader` implementation to properly guard access to the provided `ByteBuffer` when defining a class using `defineClass(String, ByteBuffer, ...)`. Specifically, calls to `SharedSecrets.getJavaNioAccess().acquireSession(ByteBuffer)` and `releaseSession(ByteBuffer)` have been introduced to ensure safe and consistent buffer access throughout the native class definition process, even in the case of a `ByteBuffer` is backed by a `MemorySegment`.
> 
> ### Impact
> This modification is internal to the `ClassLoader` implementation and does not affect the public API.
> Improves the robustness and security of class loading from buffers.
> 
> ### Testing
> Tier 1, 2, and 3 JDK tests pass on multiple platforms.

The change looks okay.  One thing to check if whether we have tests for JNI GetDirectBufferAddress when the byte buffer is a view of a memory segment.

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

PR Comment: https://git.openjdk.org/jdk/pull/26724#issuecomment-3175258539

From alanb at openjdk.org  Mon Aug 11 15:02:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Aug 2025 15:02:14 GMT
Subject: RFR: 8365203: defineClass with direct buffer can cause
 use-after-free
In-Reply-To: <RkFuGn6KZ3egC3pzmTvVLTknx6VSakKY2h6FCXs8emU=.8d59f849-5d65-47f4-b96f-377d8e107cf2@github.com>
References: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
 <RkFuGn6KZ3egC3pzmTvVLTknx6VSakKY2h6FCXs8emU=.8d59f849-5d65-47f4-b96f-377d8e107cf2@github.com>
Message-ID: <F-ooQc7-EtlkU8KP2Quf96kXj_lQJhNUWlbT2dFhNYk=.4be0eeab-4b7d-4ea4-8bf9-3a88c83d3e89@github.com>

On Mon, 11 Aug 2025 14:35:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ### Description
>> This PR proposes to update the `ClassLoader` implementation to properly guard access to the provided `ByteBuffer` when defining a class using `defineClass(String, ByteBuffer, ...)`. Specifically, calls to `SharedSecrets.getJavaNioAccess().acquireSession(ByteBuffer)` and `releaseSession(ByteBuffer)` have been introduced to ensure safe and consistent buffer access throughout the native class definition process, even in the case of a `ByteBuffer` is backed by a `MemorySegment`.
>> 
>> ### Impact
>> This modification is internal to the `ClassLoader` implementation and does not affect the public API.
>> Improves the robustness and security of class loading from buffers.
>> 
>> ### Testing
>> Tier 1, 2, and 3 JDK tests pass on multiple platforms.
>
> src/java.base/share/classes/java/lang/ClassLoader.java line 1057:
> 
>> 1055:         try {
>> 1056:             Class<?> c = defineClass2(this, name, b, b.position(), len, protectionDomain, source);
>> 1057:             postDefineClass(c, protectionDomain);
> 
> Should we leave postDefineClass out of this acquire-release scope? I don't see any reason including this.

I don't think it matters here because something looking to close the arena around the time that it wants to defineClass with memory allocated from that arena is broken.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26724#discussion_r2267048060

From liach at openjdk.org  Mon Aug 11 15:02:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Aug 2025 15:02:15 GMT
Subject: RFR: 8365203: defineClass with direct buffer can cause
 use-after-free
In-Reply-To: <Uz_SFCgJfh1Xk3ePl4Qgt_4ktOJNsMY_3fXu0FdlFv8=.a782ba28-14f8-4474-a864-a662852c2b05@github.com>
References: <NrPOnlpUrGJ1-J_ePyrSjHOMNngLnR570-M3xOjA548=.9260048c-bff5-4915-a2e0-6c42fb8c5a76@github.com>
 <Uz_SFCgJfh1Xk3ePl4Qgt_4ktOJNsMY_3fXu0FdlFv8=.a782ba28-14f8-4474-a864-a662852c2b05@github.com>
Message-ID: <9z6SMoYgitBKN6CEB651qcICv4DA4S6lm_QysYKcgq0=.76556c3a-ec36-4e3c-bc26-213a5cec0b14@github.com>

On Mon, 11 Aug 2025 14:55:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ### Description
>> This PR proposes to update the `ClassLoader` implementation to properly guard access to the provided `ByteBuffer` when defining a class using `defineClass(String, ByteBuffer, ...)`. Specifically, calls to `SharedSecrets.getJavaNioAccess().acquireSession(ByteBuffer)` and `releaseSession(ByteBuffer)` have been introduced to ensure safe and consistent buffer access throughout the native class definition process, even in the case of a `ByteBuffer` is backed by a `MemorySegment`.
>> 
>> ### Impact
>> This modification is internal to the `ClassLoader` implementation and does not affect the public API.
>> Improves the robustness and security of class loading from buffers.
>> 
>> ### Testing
>> Tier 1, 2, and 3 JDK tests pass on multiple platforms.
>
> test/jdk/java/lang/ClassLoader/defineClass/GuardByteBuffer.java line 58:
> 
>> 56:         };
>> 57:         final List<Thread> threads = new ArrayList<>();
>> 58:         for (int i = 0; i < Runtime.getRuntime().availableProcessors(); i++) {
> 
> This means all cores spinning for 20s - we'll have to see if it causes any side effects and slow down of other tests that happen to run at the same time in other agent VMs (make run-test uses concurrency by default).

Indeed, tier 1 tests are recommended to run for 10 seconds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26724#discussion_r2267053263

From alanb at openjdk.org  Mon Aug 11 15:13:24 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Aug 2025 15:13:24 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v18]
In-Reply-To: <uqpPLDqBOW-qI8Ej_iol2cHxy6HzpiMnez3CfHb2_SQ=.7e4a3915-3204-4723-aceb-1fdf3c79a9f5@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <uqpPLDqBOW-qI8Ej_iol2cHxy6HzpiMnez3CfHb2_SQ=.7e4a3915-3204-4723-aceb-1fdf3c79a9f5@github.com>
Message-ID: <wBv627sN-bIPKRdAEnFTNeZsuZ04NeS63TTZPGvKycI=.a33a2106-988d-454b-907a-281190f99012@github.com>

On Wed, 6 Aug 2025 12:37:34 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes subtle false-positive with paths like /modules/modules/...

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-3106349476

From alanb at openjdk.org  Mon Aug 11 15:13:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Aug 2025 15:13:25 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <sNBpZtqIkSRRcdba2W-6bF4bRuSStHbJAdAEZxGFigw=.1e2952fa-1ec8-4523-89c6-aaacac4dbdbd@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
 <ZCubiy1lnVL4QSQOkBZA8m90BWYKiezNwUmyin6ojCs=.bda6dd80-6f27-498b-84fd-1fbc386ee2f5@github.com>
 <sNBpZtqIkSRRcdba2W-6bF4bRuSStHbJAdAEZxGFigw=.1e2952fa-1ec8-4523-89c6-aaacac4dbdbd@github.com>
Message-ID: <qlcZ4xmkNYVl2H_OauaOE7Zy2CpDw8CLU8H0GZKXkZQ=.4966545e-fc76-49b8-8660-412eb38c1174@github.com>

On Tue, 29 Jul 2025 17:52:27 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 257:
>> 
>>> 255:     private static Stream<ModuleInfo.Attributes> allModuleAttributes() {
>>> 256:         // System reader is a singleton and should not be closed by callers.
>>> 257:         ImageReader reader = SystemImage.reader();
>> 
>> The changes to SystemModuleFinders looks okay but I think we should drop the "System reader is a singleton and should not be closed by callers" here as it sets doubt that the ImageReader might be closed.
>
> I mean without that, as a reader of the code who doesn't know details, I'd definitely be questioning why a closeable object (ImageReader) is being obtained and used, but not closed. I probably even added it because I'd had to dig around the code to understand that it was actually correct to not close it here.
> 
> Perhaps the docs for SystemImage (currently `Holder class for the ImageReader.` could be improved to make the lifecycle clear and benefit all callers of `reader()` ?)

Maybe, or the singleton returned by SystemImage.reader() is non-closeable. My only comment for now is tha the "should not be called by callers." is confusing here and would be better to remove. We do do this in the next change in the area if you want.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2267081379

From stuefe at openjdk.org  Mon Aug 11 15:41:19 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 11 Aug 2025 15:41:19 GMT
Subject: Integrated: 8364611: (process) Child process SIGPIPE signal
 disposition should be default
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <uXXN0TqeSpoNZI-AZQCKYctsO-wuKFU1mZVxcRIvHpY=.760ce15c-30da-4a08-8f34-944dc3bd1d75@github.com>

On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

This pull request has now been integrated.

Changeset: bdb1646a
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bdb1646a1e39bae0535efe3f593e7fc0545e4114
Stats:     196 lines in 5 files changed: 195 ins; 0 del; 1 mod

8364611: (process) Child process SIGPIPE signal disposition should be default

Reviewed-by: erikj, rriggs

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

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

From vklang at openjdk.org  Mon Aug 11 15:53:13 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Aug 2025 15:53:13 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v4]
In-Reply-To: <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
Message-ID: <P8-_U_0Qaphz4yYIzH244CKPGC4nkpqxrRW8_TsWGI8=.ca228c90-5820-4a0b-8f38-2ed221a72fbe@github.com>

On Tue, 22 Jul 2025 07:10:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
>> 
>> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a new method to StableValueImpl for improved speed

src/java.base/share/classes/java/util/ImmutableCollections.java line 1677:

> 1675: 
> 1676:                 private LazyMapIterator(StableMapEntrySet<K, V> outer) {
> 1677:                     this.underlyingHolder = outer.outer.underlyingHolder;

Might be worth a comment explaining the "outer.outer" part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2267207161

From vklang at openjdk.org  Mon Aug 11 15:57:14 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Aug 2025 15:57:14 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v4]
In-Reply-To: <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
Message-ID: <bHZwy3Z9m1Jb2ts2aT5CGgnSJNxaopPUx31hso5w--c=.67ee338b-d508-45d5-bbd3-e914551eea19@github.com>

On Tue, 22 Jul 2025 07:10:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
>> 
>> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a new method to StableValueImpl for improved speed

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 174:

> 172:                     // Reduce the counter and if it reaches zero, clear the reference
> 173:                     // to the underlying holder.
> 174:                     underlyingHolder.countDown();

Doesn't the code here imply that if the underlying supplier/function etc throws an exception, the underlyingHolder won't get counted down, and will leak?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2267226348

From pminborg at openjdk.org  Mon Aug 11 16:24:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Aug 2025 16:24:53 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v5]
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <t2lhlqaB2Pbf9wfCHc3gnITtKJp5bGZbtt6VrI9Vf3U=.19ef055a-b727-4250-bbca-1c726da174f8@github.com>

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
> 
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Simplify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26672/files
  - new: https://git.openjdk.org/jdk/pull/26672/files/c37cd69d..c93a3fea

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

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

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

From pminborg at openjdk.org  Mon Aug 11 16:31:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Aug 2025 16:31:17 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v6]
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <CzTx08v5uJEFUXOihNMdC5nFMxYpX78s8MHMEE25m2s=.df97d05e-5467-4373-b030-9de3e61c9521@github.com>

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
> 
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26672/files
  - new: https://git.openjdk.org/jdk/pull/26672/files/c93a3fea..9c52870b

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

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

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

From naoto at openjdk.org  Mon Aug 11 16:42:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Aug 2025 16:42:09 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats
In-Reply-To: <55UQCywpNB4OPfqAgJhIcrJa9AIgxxQRe_gxZKWHj14=.9c7f3a6b-73d2-4b66-9054-a4dccc7c57ae@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <55UQCywpNB4OPfqAgJhIcrJa9AIgxxQRe_gxZKWHj14=.9c7f3a6b-73d2-4b66-9054-a4dccc7c57ae@github.com>
Message-ID: <lv1IywieSZztKrtgYlvOXSob_8GB8Vqsvpyer7wt5n0=.a2393b7c-792d-4da9-86d9-8aa6890d4b8c@github.com>

On Sat, 9 Aug 2025 13:52:45 GMT, ExE Boss <duke at openjdk.org> wrote:

> How?about using different patterns for?parsing and?printing instead?

In fact, the current `DateTimeFormatterBuilder.InstantPrinterParser` already use different behavior for formatting, i.e., only print time in "Z" (no offset).

The following change:

--- a/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
+++ b/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
@@ -3887,7 +3887,7 @@ public int parse(DateTimeParseContext context, CharSequence text, int position)
                     .appendValue(MINUTE_OF_HOUR, 2).appendLiteral(':')
                     .appendValue(SECOND_OF_MINUTE, 2)
                     .appendFraction(NANO_OF_SECOND, minDigits, maxDigits, true)
-                    .appendOffsetId()
+                    .appendOffset("+HH:mm:ss", "Z")
                     .toFormatter().toPrinterParser(false);
             DateTimeParseContext newContext = context.copy();
             int pos = parser.parse(newContext, text, position);

will parse hour-only offset for `Instant.parse()` but I am not sure we would go for this, as other `ISO` formatters all use "MM" for minutes. @jodastephen any suggestions?

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

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3175834055

From stevenschlansker at gmail.com  Mon Aug 11 16:44:46 2025
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Mon, 11 Aug 2025 09:44:46 -0700
Subject: Generic type signatures in MethodRepository have many copies of
 simple class names
In-Reply-To: <a64d370b-6a16-49c4-83c3-8af76d7bafcc@civilian-framework.org>
References: <FC1D50CF-6C71-4250-937F-CB4821E1303B@gmail.com>
 <a64d370b-6a16-49c4-83c3-8af76d7bafcc@civilian-framework.org>
Message-ID: <14C49006-FC38-4610-8D77-F0D7A3D1429C@gmail.com>


> On Aug 10, 2025, at 2:29?PM, Johannes D?bler <jd at civilian-framework.org> wrote:
> 
> Hi Steven,
> 
> I think you are onto something. Given this example
> 
>> public class TypeParamsDemo {
>>     public static void main(String[] args) throws Exception {
>>         Method method = TypeParamsDemo.class.getMethod("getList", Set.class);
>>         TypeVariable<Method>[] tp = method.getTypeParameters();
>>     }
>> 
>>     public <T extends Number> List<T> getList(Set<T> set) {
>>         return new ArrayList<>(set);
>>     }
>> }
> 
> Then:
> tp[0].bounds[0].path[0].name is "java.lang.Number" and  is a newly created String parsed from the type signature "<T:Ljava/lang/Number;>(Ljava/util/Set<TT;>;)Ljava/util/List<TT;>;".
> The result of method.getTypeParameters() is cached in Method.genericInfo, so once initialized by a caller (e.g. by Jackson/REST easy) it won't go away.
> Imho interning the class name should be fine since it refers to an existing class.
> 
> Best
> Johannes
> 

Thank you for your analysis Johannes.
I've opened https://github.com/openjdk/jdk/pull/26730 with my proposed change.

> 
> On 09/08/2025 01:10, Steven Schlansker wrote:
>> Hello core-libs-dev, happy Friday!
>> 
>> While diagnosing an out of memory situation in our application, I noticed a surprising source of memory usage.
>> While this is not so severe to actually cause our OOM, it seems wasteful and I thought to bring it to your attention.
>> 
>> We use reflection-based technologies like Jackson JSON and RESTEasy that retrieve generic type information from many of our classes.
>> Our profiler provides diagnostics of wasted space due to duplicate objects, particularly Strings.
>> 
>> The analysis highlights many thousands of copies of String instances holding the full name of a class, e.g. "java.util.Optional"
>> or "com.mycompany.Id". The path to GC route looks like:
>> 
>> String <- sun.reflect.generics.tree.SimpleClassTypeSignature <- Object[] <- ArrayList <- ClassTypeSignature <- MethodTypeSignature <- MethodRepository <- Method
>> 
>> Seeing how these SimpleClassTypeSignature instances are created, it looks like they come from the sun.reflect.generics.parser.SignatureParser which calls
>> `input.substring(mark, index)`, possibly with a call to `replace('/', '.')` to munge the package name. In all but the simplest of cases, this will return a new String
>> for every call.
>> 
>> Since this String is representing a Class name, the cardinality should by its nature be very low. For each unique type, there will be many methods referring to it.
>> Additionally, this generic information is lazy-loaded at most once per Method object.
>> 
>> Therefore, SimpleClassTypeSignature.n seems like a natural place to apply String.intern(), for example changing:
>> 
>> public static SimpleClassTypeSignature make(String n,
>>     boolean dollar,
>>     TypeArgument[] tas){
>>         return new SimpleClassTypeSignature(n, dollar, tas);
>> }
>> 
>> to intern the name:
>> 
>> public static SimpleClassTypeSignature make(String n,
>>     boolean dollar,
>>     TypeArgument[] tas){
>>         return new SimpleClassTypeSignature(n.intern(), dollar, tas);
>> }
>> 
>> With any luck, maybe this can even share the same string instance as the class itself uses.
>> Am I correct in thinking this would be a moderately nice improvement, for a relatively cheap cost?
>> Or perhaps there's some reason this isn't a good idea?
>> 
>> Thank you for your thoughts on the subject,
>> Steven
>> 
> 


From vklang at openjdk.org  Mon Aug 11 16:46:10 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Aug 2025 16:46:10 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
Message-ID: <tai9dYJU7s932a-n60B_cTr2kBuA7GEibvlojpdsnG0=.090a0c73-4d79-4437-bbec-ead83e5c7896@github.com>

On Thu, 7 Aug 2025 14:03:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid underutilization on resize

src/java.base/share/classes/java/lang/VirtualThread.java line 324:

> 322:         } else {
> 323:             executor.execute(task);
> 324:         }

Is this worth special-casing?IIRC FJP::submit adapts the task if needed already.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2267395539

From vklang at openjdk.org  Mon Aug 11 16:46:11 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Aug 2025 16:46:11 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <tai9dYJU7s932a-n60B_cTr2kBuA7GEibvlojpdsnG0=.090a0c73-4d79-4437-bbec-ead83e5c7896@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
 <tai9dYJU7s932a-n60B_cTr2kBuA7GEibvlojpdsnG0=.090a0c73-4d79-4437-bbec-ead83e5c7896@github.com>
Message-ID: <0XRklHR3aLzgLwtfuw5JMMowA7dFsqU2z9-lvzXotNY=.12575164-9910-4a2e-95aa-19db014ac14a@github.com>

On Mon, 11 Aug 2025 16:40:28 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid underutilization on resize
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 324:
> 
>> 322:         } else {
>> 323:             executor.execute(task);
>> 324:         }
> 
> Is this worth special-casing?IIRC FJP::submit adapts the task if needed already.

Ah, this is about getting a `AdaptedRunnableAction` rather than a `RunnableExecuteAction` (where the latter is an InterruptibleTask, and the former isn't). Sounds worth of a comment here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2267400540

From naoto at openjdk.org  Mon Aug 11 16:47:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Aug 2025 16:47:09 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats
In-Reply-To: <DSOlcRGOZfhCrFYl8vDxGlyVcwfVf_HNqr8XoYcl0Bo=.8ec0f273-e39f-498e-af5c-ad87106e6616@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <DSOlcRGOZfhCrFYl8vDxGlyVcwfVf_HNqr8XoYcl0Bo=.8ec0f273-e39f-498e-af5c-ad87106e6616@github.com>
Message-ID: <DXfslHuZDSV4zDO08UEoFH1y2bCnWtzWOQVpAsOp7QA=.2c0ea2b6-08cc-4f67-bf3a-9ba917efcbfe@github.com>

On Mon, 11 Aug 2025 09:09:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Shall we accompany the changes with a set of tests that verifies `java.time.Instant::parse` against all all ISO 8601 date formats?

I don't think `Instant.parse()` allows all permitted zone offset styles in ISO, only allowing "+HH:MM:ss" in strict mode. If the user wants to allow all of the format, they would be able to create a custom formatter in lenient mode and use the pattern "+HH" for offset parsing.

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

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3175848523

From duke at openjdk.org  Mon Aug 11 17:10:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 11 Aug 2025 17:10:19 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <qlcZ4xmkNYVl2H_OauaOE7Zy2CpDw8CLU8H0GZKXkZQ=.4966545e-fc76-49b8-8660-412eb38c1174@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
 <ZCubiy1lnVL4QSQOkBZA8m90BWYKiezNwUmyin6ojCs=.bda6dd80-6f27-498b-84fd-1fbc386ee2f5@github.com>
 <sNBpZtqIkSRRcdba2W-6bF4bRuSStHbJAdAEZxGFigw=.1e2952fa-1ec8-4523-89c6-aaacac4dbdbd@github.com>
 <qlcZ4xmkNYVl2H_OauaOE7Zy2CpDw8CLU8H0GZKXkZQ=.4966545e-fc76-49b8-8660-412eb38c1174@github.com>
Message-ID: <4QwpT5CW3_7wbZ5Yu7_LNcURUavKRXMgJuxEwZ2zq-o=.7d33877f-ad5e-4b0a-9441-5b52a1c0e8c5@github.com>

On Mon, 11 Aug 2025 15:09:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I mean without that, as a reader of the code who doesn't know details, I'd definitely be questioning why a closeable object (ImageReader) is being obtained and used, but not closed. I probably even added it because I'd had to dig around the code to understand that it was actually correct to not close it here.
>> 
>> Perhaps the docs for SystemImage (currently `Holder class for the ImageReader.` could be improved to make the lifecycle clear and benefit all callers of `reader()` ?)
>
> Maybe, or the singleton returned by SystemImage.reader() is non-closeable. My only comment for now is tha the "should not be called by callers." is confusing here and would be better to remove. We do do this in the next change in the area if you want.

The comment is there because that line is:
a) right above a try-catch block and
b) comes with a "click here to put this into a try-with-resources block" lint action in an IDE

So, at a glance, it looks like it's a simple mistake that it's not a resource in the following try-block.
It just feels tempting for a future maintainer to mistakenly "fix it".

That's the "job" of the comment, to catch when someone is about to do that.
I reworded slightly though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2267466083

From darcy at openjdk.org  Mon Aug 11 17:16:12 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 11 Aug 2025 17:16:12 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v4]
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <fJp28z_O_To0_VEch7ovZwhGbTSsW3zg8EGVwQJdhQM=.4a9b0fb2-02b5-41bc-8fa0-229424654be0@github.com>

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Cleanup and respond to review comments.
 - Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26341/files
  - new: https://git.openjdk.org/jdk/pull/26341/files/5e1233b7..0746addd

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

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

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

From asemenyuk at openjdk.org  Mon Aug 11 17:18:13 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 11 Aug 2025 17:18:13 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts
In-Reply-To: <pYUWAVVsTBigwd4yMKr0Fp2L3m7X88eeMXDP6Zj045A=.4a8944d8-8904-49eb-ba97-104d2f1bb806@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
 <pYUWAVVsTBigwd4yMKr0Fp2L3m7X88eeMXDP6Zj045A=.4a8944d8-8904-49eb-ba97-104d2f1bb806@github.com>
Message-ID: <usagn3BNmZCeuB5BxXg_xnCoKw4m9oZEAfxds5Sbwpo=.04b8c4ea-5ab4-48e2-8af3-52f94fdab0a0@github.com>

On Fri, 8 Aug 2025 23:23:02 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Support a new "app-dir" value of `win-shortcut`, `win-menu`, and `linux-shortcut` properties in additional launcher property files.
>> - Support an optional value of `--win-shortcut`, `--win-menu`, and `--linux-shortcut` CLI options. The valid value is "app-dir".
>> 
>> If a value of any property/CLI option from the above list is set to "app-dir", the startup directory of the corresponding shortcut will be set to the "app" subdirectory of the installation directory.
>> 
>> If a CLI option from the above list doesn't have a value, the startup directory of the corresponding shortcut for the main launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
>> 
>> If a value of a property from the above list evaluates to `true`, the startup directory of the corresponding shortcut for the additional launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
>> 
>> Added test cases to AddLShortcut test implicitly.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java line 486:
> 
>> 484:         }
>> 485: 
>> 486:         private static Runnable createArgumentWithOptionalValueAction(String option) {
> 
> I am not sure, but did you test case when `--win-menu` or `--win-shortcut` or `--linux-shortcut` is last argument without value? With new code `var value = popArg();` will be `""` and we will call `setOptionValue(option, value)`. Before change it will be set to `true`.

You are right. I reworked the tests, and they start failing if the last argument is `--win-menu`, `--win-shortcut`, or `--linux-shortcut`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26707#discussion_r2267483513

From erikj at openjdk.org  Mon Aug 11 17:23:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 11 Aug 2025 17:23:11 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <J6-ABR3b34n5S3W1zHMSr_TxRNAnRioKaN6oIZljRuo=.4f116d02-f16e-4b43-9f07-63207cba38e0@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
 <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>
 <Tw5maFbJaPI5q0x-o44DqHICHN-dvxUQyUGaW4IbCLU=.abca2f27-d43f-48bd-9b92-c950002dbf0e@github.com>
 <A71apIJFIXpdfoYfRLzA4q3qLNvmvj0A8_sQHqTpCBU=.bfeb0c07-3ce7-45e7-9cbd-3a6abb767756@github.com>
 <J6-ABR3b34n5S3W1zHMSr_TxRNAnRioKaN6oIZljRuo=.4f116d02-f16e-4b43-9f07-63207cba38e0@github.com>
Message-ID: <VLEgFaeir6ZFohN9Htx5dB1GXkEQiavrlbmp-8y_4ow=.213bb36b-5a36-45fb-acb0-cb164d70eef1@github.com>

On Mon, 11 Aug 2025 14:23:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I could also create a separate file for each launcher with a name pattern and gather up all these files in StaticLibs.gmk, but then I will get problems with left-over such files, for e.g. if incrementally building after removing a launcher. Not a common scenario, I agree, but it seems like a worse solution.
>
> This solution was modeled on how we create `module-included-libs.txt`. I agree that it is a bit hacky to inject this kind of stuff in ModuleWrapper, but I can't see how we can do it more cleanly. That's the only point at which we know the entire module for a phase. 
> 
> Maybe we can improve optics by doing a more official-looking "hook" for injecting functionality at pre-/post- whole-module processing? That would keep ModuleWrapper slimmer and without all the current specialized hooks, and make the name "wrapper" more relevant.
> 
> Or, we could rename the makefile to indicate better that it does a lot more than just wraps a file. (I have no good suggestions right now.)

I'm not sure what you mean here. I described a solution that keeps it in LauncherCommon without creating races.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2267491796

From duke at openjdk.org  Mon Aug 11 17:30:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 11 Aug 2025 17:30:08 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v19]
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <obYr16Uyj6A8HHAuKSmdSJslAdhk4y1tzWD-DnWcDIg=.440726d7-7050-4a2a-9adb-aab9fe366f43@github.com>

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Small comment tweak.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/c31b87d8..ca26e00b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=17-18

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

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

From iris at openjdk.org  Mon Aug 11 17:38:12 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 11 Aug 2025 17:38:12 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v2]
In-Reply-To: <J5fF6P9MhXKy2H2Xb4CDVdpED-zOGHHHrehDggSdsUs=.0d938d3d-cfcb-465b-bfdf-a13575113eb7@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <J5fF6P9MhXKy2H2Xb4CDVdpED-zOGHHHrehDggSdsUs=.0d938d3d-cfcb-465b-bfdf-a13575113eb7@github.com>
Message-ID: <3cVhuiuq1cW-XgONMnkCje3LI6yOMIxTmmiH5AStlTY=.e6a50bf3-0a7e-437b-bd66-3f6b59353b74@github.com>

On Mon, 11 Aug 2025 11:35:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to use correct library directories
>   
>   See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3106980594

From jbhateja at openjdk.org  Mon Aug 11 18:02:34 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 11 Aug 2025 18:02:34 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v4]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <4omqHrPtNFE0UWmulPymwsUHXRpd9EBhgJvOpRyXxJQ=.dacad6cd-5a3e-4671-9543-98f04e1b7e73@github.com>

> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
> 
>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
> 
> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
> 
> Performance numbers:
> 
> 
> System : 13th Gen Intel(R) Core(TM) i3-1315U
> 
> Baseline:
> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolutions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24104/files
  - new: https://git.openjdk.org/jdk/pull/24104/files/e7c7374b..405de56f

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

  Stats: 389 lines in 9 files changed: 373 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104

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

From duke at openjdk.org  Mon Aug 11 18:11:13 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 11 Aug 2025 18:11:13 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v4]
In-Reply-To: <bHZwy3Z9m1Jb2ts2aT5CGgnSJNxaopPUx31hso5w--c=.67ee338b-d508-45d5-bbd3-e914551eea19@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
 <bHZwy3Z9m1Jb2ts2aT5CGgnSJNxaopPUx31hso5w--c=.67ee338b-d508-45d5-bbd3-e914551eea19@github.com>
Message-ID: <GnqfVrsdRG-6p0dvT3Wn9Uhg_9R-ySPOb_-MFdECADg=.ff5fe2ae-3600-425e-bf65-54f74cf4f249@github.com>

On Mon, 11 Aug 2025 15:55:02 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a new method to StableValueImpl for improved speed
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 174:
> 
>> 172:                     // Reduce the counter and if it reaches zero, clear the reference
>> 173:                     // to the underlying holder.
>> 174:                     underlyingHolder.countDown();
> 
> Doesn't the code here imply that if the underlying supplier/function etc throws an exception, the underlyingHolder won't get counted down, and will leak?

No, because the?stable?value doesn?t?get?set in?that?case, so?the?supplier/function will?be?called?again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2267601572

From naoto at openjdk.org  Mon Aug 11 18:32:12 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Aug 2025 18:32:12 GMT
Subject: RFR: 8364781: Re-examine DigitList digits resizing during parsing
 [v2]
In-Reply-To: <UBP3my1TDFYTza7tEbJYZIa_z0sAAPI_X7HLpQNEAmU=.1019b10f-3440-4781-8b33-f2aa7c2df942@github.com>
References: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
 <UBP3my1TDFYTza7tEbJYZIa_z0sAAPI_X7HLpQNEAmU=.1019b10f-3440-4781-8b33-f2aa7c2df942@github.com>
Message-ID: <d5QMzoJOgqlwNbqNBWl3E5fZVSjgTI5NslNHZ_6upqU=.b30bc032-6a42-4101-8a3a-f3a581fb7f9a@github.com>

On Fri, 8 Aug 2025 23:28:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR changes the DigitList resizing from adding increments of 100 to a doubling resizing approach. This helps with performance of larger String values during `DecimalFormat` parsing. See the comment on the associated JBS issue for further detail.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen review - replace with ArraysSupport

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26705#pullrequestreview-3107154345

From darcy at openjdk.org  Mon Aug 11 19:22:11 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 11 Aug 2025 19:22:11 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v5]
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <_ZI_AqjrCzDPKCN1KNx0NEXQho7fmFQUB4kwiVyz5bg=.c851bc0d-9d8f-43ab-a83a-204e2010e048@github.com>

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Small refinement and add test cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26341/files
  - new: https://git.openjdk.org/jdk/pull/26341/files/0746addd..f0c9b486

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

  Stats: 28 lines in 3 files changed: 19 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26341.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26341/head:pull/26341

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

From darcy at openjdk.org  Mon Aug 11 19:22:12 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 11 Aug 2025 19:22:12 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <2QPg2jhLs2gjJ36zA9srFUx0LRTtNwzqBIqQ5xud_zg=.c5abe69b-6a57-4c44-9009-50e3a04bf918@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
 <l2JxavYCqhe0c7Kh0YsmJARsKVbF7rtsQRFjWjp2NZE=.3c22c5f4-473c-4dc4-885a-914d9e636a9c@github.com>
 <2QPg2jhLs2gjJ36zA9srFUx0LRTtNwzqBIqQ5xud_zg=.c5abe69b-6a57-4c44-9009-50e3a04bf918@github.com>
Message-ID: <CuQXsFmHKS6sZysdL1t1lsoyY2WqL3sd06BHqIhwMTg=.a7685339-8f42-49f2-ab76-5c4bdd698df6@github.com>

On Fri, 18 Jul 2025 16:54:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > This array unrolling looks right to me.
> 
> I'll write a regression test case to make sure.

Catching up after JVMLS, added a few test cases for pow and exp code that was changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3176525790

From lmesnik at openjdk.org  Mon Aug 11 19:42:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 11 Aug 2025 19:42:13 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <MDTaRBhA3Sm7TH8B647RYyPhjUqq4KEpltnW78YHvwY=.bb4124b3-0674-4c59-818d-675f7bfd994e@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26725#pullrequestreview-3107524814

From liach at openjdk.org  Mon Aug 11 19:56:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Aug 2025 19:56:14 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v5]
In-Reply-To: <_ZI_AqjrCzDPKCN1KNx0NEXQho7fmFQUB4kwiVyz5bg=.c851bc0d-9d8f-43ab-a83a-204e2010e048@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <_ZI_AqjrCzDPKCN1KNx0NEXQho7fmFQUB4kwiVyz5bg=.c851bc0d-9d8f-43ab-a83a-204e2010e048@github.com>
Message-ID: <sCBeHcLwb5qVKiStWhu5U-WsTcnPUSMrgguODJtH1y4=.22afb2b5-0328-4966-8f40-113ea1ea2647@github.com>

On Mon, 11 Aug 2025 19:22:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small refinement and add test cases

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26341#pullrequestreview-3107567988

From duke at openjdk.org  Mon Aug 11 20:03:17 2025
From: duke at openjdk.org (duke)
Date: Mon, 11 Aug 2025 20:03:17 GMT
Subject: Withdrawn: 8357089: Remove VFORK launch mechanism from Process
 implementation (linux)
In-Reply-To: <lg36ykgPsg2YFoiAxnovr7Ix3GPbUBYWFsjE8i5wl5s=.fe37a5a0-223a-4b8f-810f-e529420bf46b@github.com>
References: <lg36ykgPsg2YFoiAxnovr7Ix3GPbUBYWFsjE8i5wl5s=.fe37a5a0-223a-4b8f-810f-e529420bf46b@github.com>
Message-ID: <cgx_D5gGwnYUj_SuqBrBgTC1dgGDD0NEUXyQW4C9EdU=.fe16f07e-f3c5-4f25-b76d-a2ad9f9c0e40@github.com>

On Thu, 12 Jun 2025 04:11:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> (for JDK 26)
> 
> Note: This PR is a continuation of the old PR here: https://github.com/openjdk/jdk/pull/25260; had to close the old one since I had Skara problems after the JDK25 split-off.
> 
> See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the ratio behind this removal.
> 
> Patch
> 
> - removes all code handling the VFORK mode.
> - removes or clarifies comments explaining use of vfork by the JVM.
> - we now print out an error message to stderr if the user still specifies -Djdk.lang.Process.launchMechanism=vfork.

This pull request has been closed without being integrated.

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

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

From asemenyuk at openjdk.org  Mon Aug 11 21:03:36 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 11 Aug 2025 21:03:36 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts [v2]
In-Reply-To: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
Message-ID: <mSQYqd7fAqDRbl93CqXjSRK2WtcTC80vOZ8bgYJNwU0=.46eace3c-5c14-422a-9bfd-7c9d0cdb03ff@github.com>

> - Support a new "app-dir" value of `win-shortcut`, `win-menu`, and `linux-shortcut` properties in additional launcher property files.
> - Support an optional value of `--win-shortcut`, `--win-menu`, and `--linux-shortcut` CLI options. The valid value is "app-dir".
> 
> If a value of any property/CLI option from the above list is set to "app-dir", the startup directory of the corresponding shortcut will be set to the "app" subdirectory of the installation directory.
> 
> If a CLI option from the above list doesn't have a value, the startup directory of the corresponding shortcut for the main launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
> 
> If a value of a property from the above list evaluates to `true`, the startup directory of the corresponding shortcut for the additional launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
> 
> Added test cases to AddLShortcut test implicitly.

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

  Arguments, LinuxHelper: bugfix; AddLShortcutTest: better test coverage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26707/files
  - new: https://git.openjdk.org/jdk/pull/26707/files/9f5da718..42922ecd

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

  Stats: 55 lines in 3 files changed: 49 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26707.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26707/head:pull/26707

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

From almatvee at openjdk.org  Mon Aug 11 21:43:10 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 11 Aug 2025 21:43:10 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts [v2]
In-Reply-To: <mSQYqd7fAqDRbl93CqXjSRK2WtcTC80vOZ8bgYJNwU0=.46eace3c-5c14-422a-9bfd-7c9d0cdb03ff@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
 <mSQYqd7fAqDRbl93CqXjSRK2WtcTC80vOZ8bgYJNwU0=.46eace3c-5c14-422a-9bfd-7c9d0cdb03ff@github.com>
Message-ID: <M37sXbYH0Zze3wTe4-aTQVhGVkjPGwJdV4A6gfnJlXI=.036ad13d-6ff1-43ed-b22a-2555edbcf0f0@github.com>

On Mon, 11 Aug 2025 21:03:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Support a new "app-dir" value of `win-shortcut`, `win-menu`, and `linux-shortcut` properties in additional launcher property files.
>> - Support an optional value of `--win-shortcut`, `--win-menu`, and `--linux-shortcut` CLI options. The valid value is "app-dir".
>> 
>> If a value of any property/CLI option from the above list is set to "app-dir", the startup directory of the corresponding shortcut will be set to the "app" subdirectory of the installation directory.
>> 
>> If a CLI option from the above list doesn't have a value, the startup directory of the corresponding shortcut for the main launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
>> 
>> If a value of a property from the above list evaluates to `true`, the startup directory of the corresponding shortcut for the additional launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
>> 
>> Added test cases to AddLShortcut test implicitly.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Arguments, LinuxHelper: bugfix; AddLShortcutTest: better test coverage

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26707#pullrequestreview-3107873128

From chen.l.liang at oracle.com  Mon Aug 11 22:29:46 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 11 Aug 2025 22:29:46 +0000
Subject: I'd like add no-argument overloads to CharSequence, String, and
 StringBuilder  (JDK-8364007)
In-Reply-To: <TYVPR01MB11356758C6F8D586191C3061B9120A@TYVPR01MB11356.jpnprd01.prod.outlook.com>
References: <TYVPR01MB11356758C6F8D586191C3061B9120A@TYVPR01MB11356.jpnprd01.prod.outlook.com>
Message-ID: <SJ2PR10MB766948E7FF95F8E1862CD113A228A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Uchino, I think your request is sensible in general.

Do you intend to require a beginIndex for the codePointCount for String? I think a no-arg version suffices.

Also forwarding this to i18n-dev as it is the locale-related list.

P.S. When you reply, make sure you click "Reply all" so all the recipients of this current mail gets your reply. Otherwise, the reply is only sent to me, and others on the list won't see your reply.

Regards, Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Uchino Tatsunori <tats.u at live.jp>
Sent: Monday, August 11, 2025 6:54 AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: I'd like add no-argument overloads to CharSequence, String, and StringBuilder (JDK-8364007)

Dear core-libs developers,

I'd like to add the following overloads:

? Character.codePointCount(CharSequence seq)
? Character.codePointCount(char[] a)
? String.codePointCount(int beginIndex)
? StringBuffer.codePointCount()
? StringBuilder.codePointCount()

and created a patch (https://github.com/openjdk/jdk/pull/26461).

Why:

There have already been similar overloads with the start and end indicies by JSR 204 (JDK-4985217). They are thought to have been designed with a priority on versatility. They make the specification of indices mandatory, but have the following disadvantages:

1. The string expression have to be written twice. Unlike C#, Java has no equivalent of extended methods.
2. Unneccesary boundary checks are mixed in.
3. The most userland code tries to calculate the number of code points in the entire stirng.
4. Some other languages can count the number of code points in a single function without extra arguments (e.g. len() in Python3)

For 3., e.g.:

? VARCHAR in MySQL & PostgreSQL counts the number of characters in the unit of code points. e.g. VARCHAR(20) means that the limit is 20 code points, not 20 UTF-16 code units (20 chars in Java)
? NIST Special Publication 800-63B stiplates that the password length must be counted as the unit of code points. (Quote from https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers : "For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.")

I would like to get agreement on these changes and would like to know what I have to do outside of GitHub (e.g how to submit CSRs). If you have a GitHub account, it would be helpful if you could reply to the PR. If not, you can reply directly to this email.

Best Regards,

Tatsunori Uchino
https://github.com/tats-u/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250811/dbac2adf/attachment-0001.htm>

From tats.u at live.jp  Mon Aug 11 23:37:48 2025
From: tats.u at live.jp (Uchino Tatsunori)
Date: Tue, 12 Aug 2025 08:37:48 +0900
Subject: I'd like add no-argument overloads to CharSequence, String, and
 StringBuilder  (JDK-8364007)
In-Reply-To: <SJ2PR10MB766948E7FF95F8E1862CD113A228A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <TYVPR01MB11356224F9CB1EF0786E2E6829128A@TYVPR01MB11356.jpnprd01.prod.outlook.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250812/2af56ad0/attachment.htm>

From darcy at openjdk.org  Mon Aug 11 23:48:17 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 11 Aug 2025 23:48:17 GMT
Subject: Integrated: 8362376: Use @Stable annotation in Java FDLIBM
 implementation
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <HUlV8oRbSKyEYYS0PqL9ITr9xTyaGVjqzZXZWLPJc_4=.c596e9c5-b4f6-4bf0-9648-c150de3b45e6@github.com>

On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

This pull request has now been integrated.

Changeset: 9593730a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9593730a23f465d26ba7b310d5b0c5d3b4ee4326
Stats:     58 lines in 3 files changed: 33 ins; 5 del; 20 mod

8362376: Use @Stable annotation in Java FDLIBM implementation

Reviewed-by: liach, rgiulietti

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

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

From asemenyuk at openjdk.org  Tue Aug 12 00:46:44 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 12 Aug 2025 00:46:44 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts [v3]
In-Reply-To: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
Message-ID: <TIq_tfAAqSVZsfNEGTTO6AnpmIVsSRI7m1b68xeCwG0=.e1e33826-dbec-4f54-a341-3b908768f073@github.com>

> - Support a new "app-dir" value of `win-shortcut`, `win-menu`, and `linux-shortcut` properties in additional launcher property files.
> - Support an optional value of `--win-shortcut`, `--win-menu`, and `--linux-shortcut` CLI options. The valid value is "app-dir".
> 
> If a value of any property/CLI option from the above list is set to "app-dir", the startup directory of the corresponding shortcut will be set to the "app" subdirectory of the installation directory.
> 
> If a CLI option from the above list doesn't have a value, the startup directory of the corresponding shortcut for the main launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
> 
> If a value of a property from the above list evaluates to `true`, the startup directory of the corresponding shortcut for the additional launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
> 
> Added test cases to AddLShortcut test implicitly.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - Blessed modifiers order
 - Rework AddLShortcutTest.test() to verify the working directory in which one of the additional launchers is started when invoked through a shortcut.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26707/files
  - new: https://git.openjdk.org/jdk/pull/26707/files/42922ecd..557c2439

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

  Stats: 144 lines in 3 files changed: 80 ins; 19 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/26707.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26707/head:pull/26707

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

From asemenyuk at openjdk.org  Tue Aug 12 00:55:16 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 12 Aug 2025 00:55:16 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts [v2]
In-Reply-To: <M37sXbYH0Zze3wTe4-aTQVhGVkjPGwJdV4A6gfnJlXI=.036ad13d-6ff1-43ed-b22a-2555edbcf0f0@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
 <mSQYqd7fAqDRbl93CqXjSRK2WtcTC80vOZ8bgYJNwU0=.46eace3c-5c14-422a-9bfd-7c9d0cdb03ff@github.com>
 <M37sXbYH0Zze3wTe4-aTQVhGVkjPGwJdV4A6gfnJlXI=.036ad13d-6ff1-43ed-b22a-2555edbcf0f0@github.com>
Message-ID: <4ABC0-ELJVGdOBn7fDTGjy8eSzsqtMkRUvv0DaZyhkU=.90494fcb-e285-44ab-a8c6-59edea05aa43@github.com>

On Mon, 11 Aug 2025 21:40:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Arguments, LinuxHelper: bugfix; AddLShortcutTest: better test coverage
>
> Looks good.

@sashamatveev, please review again. This is the final iteration.

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

PR Comment: https://git.openjdk.org/jdk/pull/26707#issuecomment-3177335945

From almatvee at openjdk.org  Tue Aug 12 01:04:24 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 12 Aug 2025 01:04:24 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts [v3]
In-Reply-To: <TIq_tfAAqSVZsfNEGTTO6AnpmIVsSRI7m1b68xeCwG0=.e1e33826-dbec-4f54-a341-3b908768f073@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
 <TIq_tfAAqSVZsfNEGTTO6AnpmIVsSRI7m1b68xeCwG0=.e1e33826-dbec-4f54-a341-3b908768f073@github.com>
Message-ID: <_XJ5GXnoKzzOgIsZAz2Rppc8vYsvnVrVupMDriHr73I=.d980bb6a-e398-4cf8-8583-187f800e78db@github.com>

On Tue, 12 Aug 2025 00:46:44 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Support a new "app-dir" value of `win-shortcut`, `win-menu`, and `linux-shortcut` properties in additional launcher property files.
>> - Support an optional value of `--win-shortcut`, `--win-menu`, and `--linux-shortcut` CLI options. The valid value is "app-dir".
>> 
>> If a value of any property/CLI option from the above list is set to "app-dir", the startup directory of the corresponding shortcut will be set to the "app" subdirectory of the installation directory.
>> 
>> If a CLI option from the above list doesn't have a value, the startup directory of the corresponding shortcut for the main launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
>> 
>> If a value of a property from the above list evaluates to `true`, the startup directory of the corresponding shortcut for the additional launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
>> 
>> Added test cases to AddLShortcut test implicitly.
>> 
>> Reworked one of the additional launchers in AddLShortcut.test() to allow verification of the working directory when the launcher is invoked through the shortcut in manual tests.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Blessed modifiers order
>  - Rework AddLShortcutTest.test() to verify the working directory in which one of the additional launchers is started when invoked through a shortcut.

test/jdk/tools/jpackage/share/AddLShortcutTest.java line 95:

> 93: public class AddLShortcutTest {
> 94: 
> 95:     @Test(ifNotOS = OperatingSystem.MACOS)

Do we really need both `(ifNotOS = OperatingSystem.MACOS)` and `(os.family != "mac")`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26707#discussion_r2268328316

From jpai at openjdk.org  Tue Aug 12 01:50:21 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 01:50:21 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v19]
In-Reply-To: <obYr16Uyj6A8HHAuKSmdSJslAdhk4y1tzWD-DnWcDIg=.440726d7-7050-4a2a-9adb-aab9fe366f43@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <obYr16Uyj6A8HHAuKSmdSJslAdhk4y1tzWD-DnWcDIg=.440726d7-7050-4a2a-9adb-aab9fe366f43@github.com>
Message-ID: <BlqyLZXgatBs6j--Gc8uNUfyx52uCQzVJlR4-wTwd6c=.79f11d91-8269-47e9-a273-ad08a7072ae2@github.com>

On Mon, 11 Aug 2025 17:30:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small comment tweak.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-3108285563

From almatvee at openjdk.org  Tue Aug 12 02:18:14 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 12 Aug 2025 02:18:14 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts [v3]
In-Reply-To: <TIq_tfAAqSVZsfNEGTTO6AnpmIVsSRI7m1b68xeCwG0=.e1e33826-dbec-4f54-a341-3b908768f073@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
 <TIq_tfAAqSVZsfNEGTTO6AnpmIVsSRI7m1b68xeCwG0=.e1e33826-dbec-4f54-a341-3b908768f073@github.com>
Message-ID: <n6GALZw3e-D7oxDUaHJTgP3b-n84Dnd_YxnsbVj4uC4=.93d54692-4818-45f4-8936-c64ffae36044@github.com>

On Tue, 12 Aug 2025 00:46:44 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Support a new "app-dir" value of `win-shortcut`, `win-menu`, and `linux-shortcut` properties in additional launcher property files.
>> - Support an optional value of `--win-shortcut`, `--win-menu`, and `--linux-shortcut` CLI options. The valid value is "app-dir".
>> 
>> If a value of any property/CLI option from the above list is set to "app-dir", the startup directory of the corresponding shortcut will be set to the "app" subdirectory of the installation directory.
>> 
>> If a CLI option from the above list doesn't have a value, the startup directory of the corresponding shortcut for the main launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
>> 
>> If a value of a property from the above list evaluates to `true`, the startup directory of the corresponding shortcut for the additional launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
>> 
>> Added test cases to AddLShortcut test implicitly.
>> 
>> Reworked one of the additional launchers in AddLShortcut.test() to allow verification of the working directory when the launcher is invoked through the shortcut in manual tests.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Blessed modifiers order
>  - Rework AddLShortcutTest.test() to verify the working directory in which one of the additional launchers is started when invoked through a shortcut.

Latest changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26707#pullrequestreview-3108337385

From asemenyuk at openjdk.org  Tue Aug 12 02:18:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 12 Aug 2025 02:18:15 GMT
Subject: RFR: 8308349: missing working directory option for launcher when
 invoked from shortcuts [v3]
In-Reply-To: <_XJ5GXnoKzzOgIsZAz2Rppc8vYsvnVrVupMDriHr73I=.d980bb6a-e398-4cf8-8583-187f800e78db@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
 <TIq_tfAAqSVZsfNEGTTO6AnpmIVsSRI7m1b68xeCwG0=.e1e33826-dbec-4f54-a341-3b908768f073@github.com>
 <_XJ5GXnoKzzOgIsZAz2Rppc8vYsvnVrVupMDriHr73I=.d980bb6a-e398-4cf8-8583-187f800e78db@github.com>
Message-ID: <Imj6tfGmn5wTYb1VBc1TPggL0UbFvAuCd0dDmebXlts=.5f1a5d9a-307a-4024-85e2-0678ce01561e@github.com>

On Tue, 12 Aug 2025 01:01:08 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Blessed modifiers order
>>  - Rework AddLShortcutTest.test() to verify the working directory in which one of the additional launchers is started when invoked through a shortcut.
>
> test/jdk/tools/jpackage/share/AddLShortcutTest.java line 95:
> 
>> 93: public class AddLShortcutTest {
>> 94: 
>> 95:     @Test(ifNotOS = OperatingSystem.MACOS)
> 
> Do we really need both `(ifNotOS = OperatingSystem.MACOS)` and `(os.family != "mac")`?

The one is for jtreg, and the other is for the jpackage test runner. The latter makes sense when the test is executed outside of jtreg.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26707#discussion_r2268410054

From asemenyuk at openjdk.org  Tue Aug 12 03:19:17 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 12 Aug 2025 03:19:17 GMT
Subject: Integrated: 8308349: missing working directory option for launcher
 when invoked from shortcuts
In-Reply-To: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
References: <lXHjwasXgFeGUODy9LafWpg0xm0AdMn443HB-6urHfs=.c9a36184-6275-4592-9216-5fa56b5b5f8b@github.com>
Message-ID: <Fg_5G9SI50-ibmXvBtRPZbGQvaxYfIDHE0IkQbbNnYQ=.eac6f12d-bfe1-4f7d-ba04-3e8af7c0f88d@github.com>

On Fri, 8 Aug 2025 22:37:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Support a new "app-dir" value of `win-shortcut`, `win-menu`, and `linux-shortcut` properties in additional launcher property files.
> - Support an optional value of `--win-shortcut`, `--win-menu`, and `--linux-shortcut` CLI options. The valid value is "app-dir".
> 
> If a value of any property/CLI option from the above list is set to "app-dir", the startup directory of the corresponding shortcut will be set to the "app" subdirectory of the installation directory.
> 
> If a CLI option from the above list doesn't have a value, the startup directory of the corresponding shortcut for the main launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
> 
> If a value of a property from the above list evaluates to `true`, the startup directory of the corresponding shortcut for the additional launcher will be set to the installation directory on Windows and will not be set on Linux. This is the existing behavior; it has not changed.
> 
> Added test cases to AddLShortcut test implicitly.
> 
> Reworked one of the additional launchers in AddLShortcut.test() to allow verification of the working directory when the launcher is invoked through the shortcut in manual tests.

This pull request has now been integrated.

Changeset: 72d3a2a9
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72d3a2a9773b2a3fe0351e0acb7b10c0751d23d8
Stats:     372 lines in 16 files changed: 272 ins; 28 del; 72 mod

8308349: missing working directory option for launcher when invoked from shortcuts

Reviewed-by: almatvee

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

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

From sspitsyn at openjdk.org  Tue Aug 12 03:43:09 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Aug 2025 03:43:09 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <5-h_mFm-MT1hN0eyE3LIlssveIKitDmFBf0iDrke7Es=.6c480926-9735-4bbf-822b-d65f8f40d9d3@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26725#pullrequestreview-3108442923

From galder at openjdk.org  Tue Aug 12 04:31:14 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 12 Aug 2025 04:31:14 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <BJp73aGLKqCh1cR-XZHFIHCIaXuGzvtIjMhYgOol_fs=.40b4accf-53ae-47fd-8334-7a124aacaf74@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
 <phlaY7VkRoWWwDzsnKw3JxaaU-lZk3tXFo8KCEtbn3Q=.3ccdd4ac-d61c-4c4c-b679-7bab67072ee1@github.com>
 <t1HL1C_N0S0Z2EBVUqSrTs24kKDKM-Cng9EwnWTfBTQ=.2d2c1afb-699f-443e-a015-4b04ea3f96db@github.com>
 <BJp73aGLKqCh1cR-XZHFIHCIaXuGzvtIjMhYgOol_fs=.40b4accf-53ae-47fd-8334-7a124aacaf74@github.com>
Message-ID: <4mfHZiUcDJ3W0p2WCzgtUwp-FWSBX6eXOg1zLfcs_H0=.f0909507-d6fe-4d2a-a543-db6445e7f605@github.com>

On Mon, 11 Aug 2025 14:11:37 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Would you run specific tiers in those platforms? Just hotspot compiler? Or individual tests such as `ConvF2HFIdealizationTests` and `TestFloat16ScalarOperations`?
>
> Honestly, I don't know, I'd have to do the research myself. Probably focusing on the Float16 tests would be good enough. No other test would really use Float16, so running anything else would not be that useful probably.

I've done some testing on x86_64 and aarch64 and the tests pass.

I also made sure that the test output demonstrated execution of the expected IR rule as per the requirements of each platform.

## `c7gn.2xlarge` Graviton3


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
   jtreg:test/hotspot/jtreg/compiler/c2/irTests/ConvF2HFIdealizationTests.java
                                                         1     1     0     0     0
   jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
                                                         1     1     0     0     0
   jtreg:test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java
                                                         1     1     0     0     0
==============================
TEST SUCCESS

$ tail ConvF2HFIdealizationTests.jtr
Messages from Test VM
---------------------
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in test1: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true


----------System.err:(3/35)----------

JavaTest Message: Test complete.

result: Passed. Execution successful


test result: Passed. Execution successful

$ tail TestFloat16ScalarOperations.jtr
Messages from Test VM
---------------------
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testDivByPOT: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testMulByTWO: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testInexactFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testSNaNFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testQNaNFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testExactFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testRandomFP16ConstantPatternSet1: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testRandomFP16ConstantPatternSet2: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testRounding1: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testRounding2: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testMax: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testAddConstantFolding: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testDivConstantFolding: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testMin: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testMinConstantFolding: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testEliminateIntermediateHF2S: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testDivByOne: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testFMAConstantFolding: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testMaxConstantFolding: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testMul: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testconvF2HFAndS2HF: Feature constraint not met (applyIfCPUFeature): avx512_fp16, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testDiv: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testSqrtConstantFolding: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testSqrt: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testMulConstantFolding: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testFma: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testAdd1: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testAdd2: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testSubConstantFolding: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
[IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testSub: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true


----------System.err:(3/35)----------

JavaTest Message: Test complete.

result: Passed. Execution successful


test result: Passed. Execution successful


## `c7i.xlarge` Intel(R) Xeon(R) Platinum 8488C (saphire rapids):


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
   jtreg:test/hotspot/jtreg/compiler/c2/irTests/ConvF2HFIdealizationTests.java
                                                         1     1     0     0     0
   jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
                                                         1     1     0     0     0
   jtreg:test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java
                                                         1     1     0     0     0
==============================
TEST SUCCESS

$ tail ConvF2HFIdealizationTests.jtr
Messages from Test VM
---------------------
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in test1: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true


----------System.err:(3/35)----------

JavaTest Message: Test complete.

result: Passed. Execution successful


test result: Passed. Execution successful

$ tail TestFloat16ScalarOperations.jtr
Messages from Test VM
---------------------
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testDivByPOT: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testMulByTWO: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testInexactFP16ConstantPatterns: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testSNaNFP16ConstantPatterns: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testQNaNFP16ConstantPatterns: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testExactFP16ConstantPatterns: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testRandomFP16ConstantPatternSet1: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testRandomFP16ConstantPatternSet2: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testRounding1: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testRounding2: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testMax: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testAddConstantFolding: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testDivConstantFolding: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testMin: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testMinConstantFolding: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testEliminateIntermediateHF2S: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testDivByOne: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testFMAConstantFolding: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testMaxConstantFolding: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testMul: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testconvF2HFAndS2HF: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testDiv: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testSqrtConstantFolding: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testSqrt: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testMulConstantFolding: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testFma: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testAdd1: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testAdd2: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testSubConstantFolding: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true
[IREncodingPrinter] Disabling IR matching for rule 2 of 2 in testSub: Not all feature constraints are met (applyIfCPUFeatureAnd): fphp, true, asimdhp, true


----------System.err:(3/35)----------

JavaTest Message: Test complete.

result: Passed. Execution successful


test result: Passed. Execution successful

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2268546321

From galder at openjdk.org  Tue Aug 12 04:36:13 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 12 Aug 2025 04:36:13 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <4mfHZiUcDJ3W0p2WCzgtUwp-FWSBX6eXOg1zLfcs_H0=.f0909507-d6fe-4d2a-a543-db6445e7f605@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
 <phlaY7VkRoWWwDzsnKw3JxaaU-lZk3tXFo8KCEtbn3Q=.3ccdd4ac-d61c-4c4c-b679-7bab67072ee1@github.com>
 <t1HL1C_N0S0Z2EBVUqSrTs24kKDKM-Cng9EwnWTfBTQ=.2d2c1afb-699f-443e-a015-4b04ea3f96db@github.com>
 <BJp73aGLKqCh1cR-XZHFIHCIaXuGzvtIjMhYgOol_fs=.40b4accf-53ae-47fd-8334-7a124aacaf74@github.com>
 <4mfHZiUcDJ3W0p2WCzgtUwp-FWSBX6eXOg1zLfcs_H0=.f0909507-d6fe-4d2a-a543-db6445e7f605@github.com>
Message-ID: <Ls_YcAl09uT6mMR4tJxFJr9S1S_SRpS4roeLcc9UDok=.be1d4aa1-ade3-48dd-b34d-550c5ed7fd78@github.com>

On Tue, 12 Aug 2025 04:28:45 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> Honestly, I don't know, I'd have to do the research myself. Probably focusing on the Float16 tests would be good enough. No other test would really use Float16, so running anything else would not be that useful probably.
>
> I've done some testing on x86_64 and aarch64 and the tests pass.
> 
> I also made sure that the test output demonstrated execution of the expected IR rule as per the requirements of each platform.
> 
> ## `c7gn.2xlarge` Graviton3
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>    jtreg:test/hotspot/jtreg/compiler/c2/irTests/ConvF2HFIdealizationTests.java
>                                                          1     1     0     0     0
>    jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>                                                          1     1     0     0     0
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java
>                                                          1     1     0     0     0
> ==============================
> TEST SUCCESS
> 
> $ tail ConvF2HFIdealizationTests.jtr
> Messages from Test VM
> ---------------------
> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in test1: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
> 
> 
> ----------System.err:(3/35)----------
> 
> JavaTest Message: Test complete.
> 
> result: Passed. Execution successful
> 
> 
> test result: Passed. Execution successful
> 
> $ tail TestFloat16ScalarOperations.jtr
> Messages from Test VM
> ---------------------
> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testDivByPOT: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testMulByTWO: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testInexactFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testSNaNFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testQNaNFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testExactFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
> [IREncodingPrinter] Disabling IR matching for rule ...

Btw, I've noticed that `TestFloat16ScalarOperations` does not have `package` definition. Is that an oversight? It runs fine in spite of not having it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2268550794

From smarks at openjdk.org  Tue Aug 12 05:37:15 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 12 Aug 2025 05:37:15 GMT
Subject: RFR: 7191877: TEST_BUG:
 java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing
 intermittently
In-Reply-To: <6-Ej6gQDcrnV_LOQaLRCxO08mUVbbX_ZGPahC_ntK2k=.6e97cf50-3fec-4e0e-a4a9-8cc84ad4fc91@github.com>
References: <6-Ej6gQDcrnV_LOQaLRCxO08mUVbbX_ZGPahC_ntK2k=.6e97cf50-3fec-4e0e-a4a9-8cc84ad4fc91@github.com>
Message-ID: <LFAYdbJKPMLZq_pVI9Wtoy-kevL7VLhWKxl1lrvgSD4=.39b8734c-53fc-4749-9b67-1a083fc418f1@github.com>

On Wed, 6 Aug 2025 10:29:45 GMT, Johny Jose <duke at openjdk.org> wrote:

> The test was problem listed since jdk8 as intermittent failures were observed. For all the failed scenarios, number of objects left in leaseTable were less than or equal to 4. Though for most of the runs the number of objects left is less than 2, at times the tests are failing when the remaining objects are 3 or 4 (observed only on mac os). As per the code, the leak should be fixed if the number of objects left in the table is less than 11. I have updated the acceptable number of objects to 4 from 2, and is still at lower end compared to 11.

@johnyjose30 Please ping me again if you'd like me to look at the backports.

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

PR Comment: https://git.openjdk.org/jdk/pull/26657#issuecomment-3177769077

From jbhateja at openjdk.org  Tue Aug 12 06:01:29 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 12 Aug 2025 06:01:29 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v5]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <pJC4YdQW-lz-hNK8qgBxy6kEilmtdcfzwPYUiWBJNHY=.98f0a96f-999e-447b-bb3f-b419ad641743@github.com>

> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
> 
>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
> 
> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
> 
> Performance numbers:
> 
> 
> System : 13th Gen Intel(R) Core(TM) i3-1315U
> 
> Baseline:
> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Cleanups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24104/files
  - new: https://git.openjdk.org/jdk/pull/24104/files/405de56f..f36ae6dd

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

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

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

From jbhateja at openjdk.org  Tue Aug 12 06:01:29 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 12 Aug 2025 06:01:29 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
 <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com>
Message-ID: <k2V-EAfdcwZ0_CUfsFROCUJaX94roDzGktcQrvuVtXI=.d19af7dc-9a5a-489c-8af6-8f2cfd49dc1c@github.com>

On Mon, 11 Aug 2025 02:47:49 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes.
> 

Added comments.

> Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such a requirement. WDYT?

Currently, inline expander only supports constant origin. I have added a check to fail intrinsification and inline fallback using the hybrid call generator.

> Do we have specific value for `origin` like zero or vlen? If so, maybe simply Identity is better to be added as well.

Done, Thanks!, also added a new IR test to complement the code changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2268669566
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2268669731

From xgong at openjdk.org  Tue Aug 12 06:01:29 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 12 Aug 2025 06:01:29 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <k2V-EAfdcwZ0_CUfsFROCUJaX94roDzGktcQrvuVtXI=.d19af7dc-9a5a-489c-8af6-8f2cfd49dc1c@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
 <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com>
 <k2V-EAfdcwZ0_CUfsFROCUJaX94roDzGktcQrvuVtXI=.d19af7dc-9a5a-489c-8af6-8f2cfd49dc1c@github.com>
Message-ID: <PW0WqtvVzqu3qG_7xw_ineur2UE51rNDlKOuEOOkMYs=.0622e006-3614-4be5-b6db-7a0a770adb32@github.com>

On Tue, 12 Aug 2025 05:55:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 1714:
>> 
>>> 1712:   }
>>> 1713: 
>>> 1714:   Node* origin_node = gvn().intcon(origin->get_con() * type2aelembytes(elem_bt));
>> 
>> Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes.
>> 
>> Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such requirement. WDYT?
>
>> Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes.
>> 
> 
> Added comments.
> 
>> Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such a requirement. WDYT?
> 
> Currently, inline expander only supports constant origin. I have added a check to fail intrinsification and inline fallback using the hybrid call generator.

Thanks for your updating! So maybe the matcher function `supports_vector_slice_with_non_constant_index()` could also be removed totally?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2268675021

From jpai at openjdk.org  Tue Aug 12 07:12:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 07:12:19 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v19]
In-Reply-To: <obYr16Uyj6A8HHAuKSmdSJslAdhk4y1tzWD-DnWcDIg=.440726d7-7050-4a2a-9adb-aab9fe366f43@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <obYr16Uyj6A8HHAuKSmdSJslAdhk4y1tzWD-DnWcDIg=.440726d7-7050-4a2a-9adb-aab9fe366f43@github.com>
Message-ID: <jzMWr83_4bTgAiXXC9_F-DvwphE5SH1lc6GixZBbsEo=.63b57c67-f521-4820-9ab5-0b964371d198@github.com>

On Mon, 11 Aug 2025 17:30:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small comment tweak.

The PR was set to 2 reviewers when the (bigger) code changes were in progress. Alan approved the previous version of the PR yesterday and the only change you did after that was a one-liner code comment change which looks good to me. Plus the tier1, tier2 and tier3 tests you ran passed without any failures. I'll go ahead and set the reviewer count to 1 so that you can integrate this.

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

PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3177987702

From duke at openjdk.org  Tue Aug 12 07:15:24 2025
From: duke at openjdk.org (duke)
Date: Tue, 12 Aug 2025 07:15:24 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v19]
In-Reply-To: <obYr16Uyj6A8HHAuKSmdSJslAdhk4y1tzWD-DnWcDIg=.440726d7-7050-4a2a-9adb-aab9fe366f43@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <obYr16Uyj6A8HHAuKSmdSJslAdhk4y1tzWD-DnWcDIg=.440726d7-7050-4a2a-9adb-aab9fe366f43@github.com>
Message-ID: <fySbiOaMTRdfmtgZNcGIliWe2wvfrYfadosWiMdAu9Q=.da6d6c9b-957a-4151-805a-2a1bfd9598b6@github.com>

On Mon, 11 Aug 2025 17:30:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small comment tweak.

@david-beaumont 
Your change (at version ca26e00b99edf99ca7275dc813c5ef40df88de38) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3177997186

From mbaesken at openjdk.org  Tue Aug 12 07:20:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 07:20:17 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <afhwH3pzzKafxrmAwvVMjyXrbofPKc2M4NlBL9VMghI=.ee16b736-6164-4e8d-bb4f-a7143cb6b325@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26725#issuecomment-3178007009

From mbaesken at openjdk.org  Tue Aug 12 07:20:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 07:20:17 GMT
Subject: Integrated: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <AVTBCNs7xSKFFFJVQa31cO3Hr62OkNNGfd0k7Vx0hyk=.1031daa7-66af-4975-91d3-1f2c029ea537@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

This pull request has now been integrated.

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

8365240: [asan] exclude some tests when using asan enabled binaries

Reviewed-by: lmesnik, sspitsyn

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

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

From duke at openjdk.org  Tue Aug 12 07:32:15 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 12 Aug 2025 07:32:15 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v20]
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <V3Y1_upCMkxGMaJW0294C9Wns5Vs2IWw3hKc4V9Q_Aw=.cb9c0f2f-ed00-434e-bcdc-b5acd5378aa5@github.com>

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Small comment tweak.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/ca26e00b..2a2faa71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=18-19

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

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

From alanb at openjdk.org  Tue Aug 12 07:39:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Aug 2025 07:39:28 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v20]
In-Reply-To: <V3Y1_upCMkxGMaJW0294C9Wns5Vs2IWw3hKc4V9Q_Aw=.cb9c0f2f-ed00-434e-bcdc-b5acd5378aa5@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <V3Y1_upCMkxGMaJW0294C9Wns5Vs2IWw3hKc4V9Q_Aw=.cb9c0f2f-ed00-434e-bcdc-b5acd5378aa5@github.com>
Message-ID: <zfG3Vv1GQ6NaW_hlBr_-P8fPupHOXCx8yB6bKvgWC7c=.194a1bbc-1274-492e-b782-4fed0ba44bb7@github.com>

On Tue, 12 Aug 2025 07:32:15 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small comment tweak.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-3109020451

From duke at openjdk.org  Tue Aug 12 07:47:26 2025
From: duke at openjdk.org (duke)
Date: Tue, 12 Aug 2025 07:47:26 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v20]
In-Reply-To: <V3Y1_upCMkxGMaJW0294C9Wns5Vs2IWw3hKc4V9Q_Aw=.cb9c0f2f-ed00-434e-bcdc-b5acd5378aa5@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <V3Y1_upCMkxGMaJW0294C9Wns5Vs2IWw3hKc4V9Q_Aw=.cb9c0f2f-ed00-434e-bcdc-b5acd5378aa5@github.com>
Message-ID: <bIDMeuDlXdtlXfjv3cBl3Aty6lybKv2leZ4z7QYdIwU=.b6e46f81-a0c7-481e-b9e7-ce60670f98fa@github.com>

On Tue, 12 Aug 2025 07:32:15 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small comment tweak.

@david-beaumont 
Your change (at version 2a2faa715e9d3e66ef3f5e9192fe81aacfee1067) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3178129412

From alanb at openjdk.org  Tue Aug 12 07:53:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Aug 2025 07:53:17 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <0XRklHR3aLzgLwtfuw5JMMowA7dFsqU2z9-lvzXotNY=.12575164-9910-4a2e-95aa-19db014ac14a@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
 <tai9dYJU7s932a-n60B_cTr2kBuA7GEibvlojpdsnG0=.090a0c73-4d79-4437-bbec-ead83e5c7896@github.com>
 <0XRklHR3aLzgLwtfuw5JMMowA7dFsqU2z9-lvzXotNY=.12575164-9910-4a2e-95aa-19db014ac14a@github.com>
Message-ID: <Cuyax7zq9NCBoY1DDQNOwlqTVuBxDs0ScpvRG9N8w1I=.c9c21b51-2087-4c70-91cc-aebdbf1aa85e@github.com>

On Mon, 11 Aug 2025 16:43:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 324:
>> 
>>> 322:         } else {
>>> 323:             executor.execute(task);
>>> 324:         }
>> 
>> Is this worth special-casing?IIRC FJP::submit adapts the task if needed already.
>
> Ah, this is about getting a `AdaptedRunnableAction` rather than a `RunnableExecuteAction` (where the latter is an InterruptibleTask, and the former isn't). Sounds worth of a comment here?

Yes, it means we always adapt before calling submit, lazySubmit and externalSubmit rather than the mix of execute(Runnable) and xxxSubmit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2269004280

From aturbanov at openjdk.org  Tue Aug 12 08:16:21 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Aug 2025 08:16:21 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v2]
In-Reply-To: <KHzMuTmP9nQ47Myctv5PREoiPcgQNz7bb1PHzGZNZ9Q=.f1a2aa88-cf7a-4b1a-80bf-8a9f5c63391b@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <KHzMuTmP9nQ47Myctv5PREoiPcgQNz7bb1PHzGZNZ9Q=.f1a2aa88-cf7a-4b1a-80bf-8a9f5c63391b@github.com>
Message-ID: <2Wc7d4F68Rrvud7-DepUfKZojrVN9uHPBJttacxGuwU=.3b21a44f-3914-4cd3-bef1-9483ad2a2e97@github.com>

On Thu, 7 Aug 2025 22:05:55 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:
> 
>   Updates from review comments:
>    - Editorial improvements to javadoc
>    - Exceptions that occur closing streams are quietly logged
>      to the java.lang.Process system log as DEBUG
>    - The prototype code attempting to wait for process exit is removed,
>      it provided marginal benefit and raised complexity due to interrupt handling
>    - Test updates for racy test cases that are not errors

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

> 652:         // Close each stream
> 653:         quietClose(outputWriter != null ? outputWriter : getOutputStream());
> 654:         quietClose(inputReader != null ? inputReader  : getInputStream());

Suggestion:

        quietClose(inputReader != null ? inputReader : getInputStream());

test/jdk/java/lang/Process/ProcessCloseTest.java line 61:

> 59:             JAVA_HOME = System.getProperty("JAVA_HOME");
> 60:         String classPath = System.getProperty("test.class.path");
> 61:         return  List.of(JAVA_HOME + "/bin/java", "-cp", classPath, ProcessCloseTest.class.getName());

Suggestion:

        return List.of(JAVA_HOME + "/bin/java", "-cp", classPath, ProcessCloseTest.class.getName());

test/jdk/java/lang/Process/ProcessCloseTest.java line 172:

> 170:                 c.command.accept(p);
> 171:             });
> 172:         }  catch (IOException ioe) {

Suggestion:

        } catch (IOException ioe) {

test/jdk/java/lang/Process/ProcessCloseTest.java line 307:

> 305:         private static void stderrExpectPolo(Process p) {
> 306:             String line = readLine(p.getErrorStream());
> 307:             Assertions.assertEquals("Polo", line, "Stderr Expected Empty");        }

Suggestion:

            Assertions.assertEquals("Polo", line, "Stderr Expected Empty");
        }

test/jdk/java/lang/Process/ProcessCloseTest.java line 316:

> 314:         private static void stderrExpectEmpty(Process p) {
> 315:             String line = readLine(p.getErrorStream());
> 316:             Assertions.assertEquals("", line, "Stderr Expected Polo");        }

Suggestion:

            Assertions.assertEquals("", line, "Stderr Expected Polo");
        }

test/jdk/java/lang/Process/ProcessCloseTest.java line 470:

> 468:      * @param childCommands a sequence of ChildCommand names.
> 469:      */
> 470:     public static void main(String... childCommands)  {

Suggestion:

    public static void main(String... childCommands) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2269061968
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2269057839
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2269058295
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2269059672
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2269060271
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2269060904

From vyazici at openjdk.org  Tue Aug 12 08:17:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 08:17:59 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <MXCeeaIUUckQu-h3Q0vdW1LZg9LDaJGCxmREH-DLTnk=.bafc71a3-6bc4-4118-aa0c-0a0cda81881c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <MXCeeaIUUckQu-h3Q0vdW1LZg9LDaJGCxmREH-DLTnk=.bafc71a3-6bc4-4118-aa0c-0a0cda81881c@github.com>
Message-ID: <y1lv6fAu4p82DRRLDMWIx-3UonrTGtxOwgjAAMRMkDA=.3502014f-61eb-493c-858a-2ee2f4f0e7e7@github.com>

On Thu, 17 Jul 2025 13:58:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace casting with `as_Region()` in `generate_string_range_check`
>
> src/java.base/share/classes/java/lang/StringCoding.java line 130:
> 
>> 128:      * <p>
>> 129:      * This method assumes that {@code sa} is encoded in UTF-16, and hence,
>> 130:      * each {@code char} maps to 2 bytes.
> 
> Since `sa` is assumed to be encoded in UTF-16, what's the point of the previous paragraph?

@rgiulietti, gave it some more thought, and I think you're right, this is probably just noise. Removed in d5aabf0c62a.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2269064538

From vyazici at openjdk.org  Tue Aug 12 08:17:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 08:17:58 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Remove `@apiNote` in `encodeISOArray()` Javadoc
  
  Those who are touching to these methods should well be
  aware of the details elaborated in the `@apiNote`, no
  need to put it on a display.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/9b721bb9..d5aabf0c

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

  Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From mbaesken at openjdk.org  Tue Aug 12 08:24:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 08:24:55 GMT
Subject: RFR: 8365307: AIX make fails after JDK-8364611
Message-ID: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>

After recent change [JDK-8364611](https://bugs.openjdk.org/browse/JDK-8364611), the build fails on AIX with :


/priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c:75:41: error: format specifies type 'unsigned int' but the argument has type 'sigset_t' (aka 'struct sigset_t') [-Werror,-Wformat]
   75 | printf("%X %X\n", act.sa_flags, act.sa_mask);
      | ~~ ^~~~~~~~~~~


The printing of the mask is optional and not needed for a working test, so we can avoid it on AIX .

-------------

Commit messages:
 - JDK-8365307

Changes: https://git.openjdk.org/jdk/pull/26739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26739&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365307
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26739/head:pull/26739

PR: https://git.openjdk.org/jdk/pull/26739

From bkilambi at openjdk.org  Tue Aug 12 08:25:12 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 12 Aug 2025 08:25:12 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <Ls_YcAl09uT6mMR4tJxFJr9S1S_SRpS4roeLcc9UDok=.be1d4aa1-ade3-48dd-b34d-550c5ed7fd78@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
 <phlaY7VkRoWWwDzsnKw3JxaaU-lZk3tXFo8KCEtbn3Q=.3ccdd4ac-d61c-4c4c-b679-7bab67072ee1@github.com>
 <t1HL1C_N0S0Z2EBVUqSrTs24kKDKM-Cng9EwnWTfBTQ=.2d2c1afb-699f-443e-a015-4b04ea3f96db@github.com>
 <BJp73aGLKqCh1cR-XZHFIHCIaXuGzvtIjMhYgOol_fs=.40b4accf-53ae-47fd-8334-7a124aacaf74@github.com>
 <4mfHZiUcDJ3W0p2WCzgtUwp-FWSBX6eXOg1zLfcs_H0=.f0909507-d6fe-4d2a-a543-db6445e7f605@github.com>
 <Ls_YcAl09uT6mMR4tJxFJr9S1S_SRpS4roeLcc9UDok=.be1d4aa1-ade3-48dd-b34d-550c5ed7fd78@github.com>
Message-ID: <dCa3iODAOckBcn9AqNKBD9i71SQB0i6jBHSmmbjD18E=.77387cbd-dc49-4bdc-acab-6087daa8b1ef@github.com>

On Tue, 12 Aug 2025 04:33:04 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> I've done some testing on x86_64 and aarch64 and the tests pass.
>> 
>> I also made sure that the test output demonstrated execution of the expected IR rule as per the requirements of each platform.
>> 
>> ## `c7gn.2xlarge` Graviton3
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>    jtreg:test/hotspot/jtreg/compiler/c2/irTests/ConvF2HFIdealizationTests.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java
>>                                                          1     1     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> $ tail ConvF2HFIdealizationTests.jtr
>> Messages from Test VM
>> ---------------------
>> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in test1: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
>> 
>> 
>> ----------System.err:(3/35)----------
>> 
>> JavaTest Message: Test complete.
>> 
>> result: Passed. Execution successful
>> 
>> 
>> test result: Passed. Execution successful
>> 
>> $ tail TestFloat16ScalarOperations.jtr
>> Messages from Test VM
>> ---------------------
>> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testDivByPOT: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
>> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testMulByTWO: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
>> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testInexactFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
>> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testSNaNFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
>> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testQNaNFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeatureOr): avx512_fp16, true, zfh, true
>> [IREncodingPrinter] Disabling IR matching for rule 1 of 2 in testExactFP16ConstantPatterns: None of the feature constraints met (applyIfCPUFeat...
>
> Btw, I've noticed that `TestFloat16ScalarOperations` does not have `package` definition. Is that an oversight? It runs fine in spite of not having it

Hi, as you mostly touched the auto-vectorization part of c2, could you please run these float16 tests as well (most of these enable auto-vectorization for Float16) - 

`compiler/vectorization/TestFloat16VectorOperations.java`
`compiler/vectorization/TestFloatConversionsVectorNaN.java`
`compiler/vectorization/TestFloatConversionsVector.java`
`compiler/vectorization/TestFloat16ToFloatConv.java`
`compiler/vectorization/TestFloat16VectorConvChain.java`
`compiler/intrinsics/float16/*`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2269084605

From duke at openjdk.org  Tue Aug 12 08:29:17 2025
From: duke at openjdk.org (Johny Jose)
Date: Tue, 12 Aug 2025 08:29:17 GMT
Subject: Integrated: 7191877: TEST_BUG:
 java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing
 intermittently
In-Reply-To: <6-Ej6gQDcrnV_LOQaLRCxO08mUVbbX_ZGPahC_ntK2k=.6e97cf50-3fec-4e0e-a4a9-8cc84ad4fc91@github.com>
References: <6-Ej6gQDcrnV_LOQaLRCxO08mUVbbX_ZGPahC_ntK2k=.6e97cf50-3fec-4e0e-a4a9-8cc84ad4fc91@github.com>
Message-ID: <_m5EmBbquyGBs7AzYx6_zpzEj1t1YMjBSCOwRXETWYo=.841442a0-bb96-41bc-875b-961379960560@github.com>

On Wed, 6 Aug 2025 10:29:45 GMT, Johny Jose <duke at openjdk.org> wrote:

> The test was problem listed since jdk8 as intermittent failures were observed. For all the failed scenarios, number of objects left in leaseTable were less than or equal to 4. Though for most of the runs the number of objects left is less than 2, at times the tests are failing when the remaining objects are 3 or 4 (observed only on mac os). As per the code, the leak should be fixed if the number of objects left in the table is less than 11. I have updated the acceptable number of objects to 4 from 2, and is still at lower end compared to 11.

This pull request has now been integrated.

Changeset: 5a442197
Author:    Johny Jose <johny.jose at oracle.com>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a442197d21e1dfb89cdbf5f0ad5596869ab333a
Stats:     64 lines in 3 files changed: 3 ins; 18 del; 43 mod

7191877: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently

Reviewed-by: smarks, coffeys

-------------

PR: https://git.openjdk.org/jdk/pull/26657

From duke at openjdk.org  Tue Aug 12 08:38:28 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 12 Aug 2025 08:38:28 GMT
Subject: Integrated: 8360037: Refactor ImageReader in preparation for Valhalla
 support
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <8wbLqXImae7_EbBJhK6c6FaBEXt7sfOimsf1NwUQUuY=.ba560b8d-4785-4d49-928f-c8a39cd2082a@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> wrote:

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

This pull request has now been integrated.

Changeset: b81f4fae
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b81f4faed7180e51aa966a9bf2f84ba755c6736d
Stats:     1239 lines in 10 files changed: 623 ins; 369 del; 247 mod

8360037: Refactor ImageReader in preparation for Valhalla support

Reviewed-by: alanb, rriggs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/26054

From tschatzl at openjdk.org  Tue Aug 12 09:05:43 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 12 Aug 2025 09:05:43 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v47]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <8MXGEs7h-FkEkdBqBvzmyaV0yIQS-w2w3VV4nIrqtoI=.90d71538-ac03-479f-9772-d256703bb1a9@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * remove unused G1DetachedRefinementStats_lock
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - ... and 54 more: https://git.openjdk.org/jdk/compare/5a442197...7fe518ec

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=46
  Stats: 7108 lines in 112 files changed: 2582 ins; 3587 del; 939 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From vklang at openjdk.org  Tue Aug 12 09:12:21 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Aug 2025 09:12:21 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v4]
In-Reply-To: <GnqfVrsdRG-6p0dvT3Wn9Uhg_9R-ySPOb_-MFdECADg=.ff5fe2ae-3600-425e-bf65-54f74cf4f249@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
 <bHZwy3Z9m1Jb2ts2aT5CGgnSJNxaopPUx31hso5w--c=.67ee338b-d508-45d5-bbd3-e914551eea19@github.com>
 <GnqfVrsdRG-6p0dvT3Wn9Uhg_9R-ySPOb_-MFdECADg=.ff5fe2ae-3600-425e-bf65-54f74cf4f249@github.com>
Message-ID: <-hJgjZr0FJ_FWLrV9ZYnRXe1a9YwxGafbRIM_51wP-c=.b0004d78-4fe3-4878-91c4-94f6d3e230f2@github.com>

On Mon, 11 Aug 2025 18:08:40 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 174:
>> 
>>> 172:                     // Reduce the counter and if it reaches zero, clear the reference
>>> 173:                     // to the underlying holder.
>>> 174:                     underlyingHolder.countDown();
>> 
>> Doesn't the code here imply that if the underlying supplier/function etc throws an exception, the underlyingHolder won't get counted down, and will leak?
>
> No, because the?stable?value doesn?t?get?set in?that?case, so?the?supplier/function will?be?called?again.

@ExE-Boss That seems to presume that 1) it will be called again, and 2) it will eventually produce a non-exception

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2269207579

From pminborg at openjdk.org  Tue Aug 12 09:21:07 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Aug 2025 09:21:07 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v5]
In-Reply-To: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
Message-ID: <vL00V4ix1vi6qFWTe16o0B-NeFKGuIjUaD5_cicsQbM=.81d49e82-a7bd-40ac-b30a-e57e51cf6ce8@github.com>

> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
> 
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Add comment for outer.outer
 - Merge branch 'master' into sv-release-supplier2
 - Merge branch 'master' into sv-release-supplier2
 - Add a new method to StableValueImpl for improved speed
 - Merge branch 'master' into sv-release-supplier2
 - Fix performance regression
 - Clean up
 - Fix bug
 - Simplify
 - Revert to records
 - ... and 2 more: https://git.openjdk.org/jdk/compare/9b0a53dc...243479df

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25878/files
  - new: https://git.openjdk.org/jdk/pull/25878/files/f9fd6ebb..243479df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25878&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25878&range=03-04

  Stats: 89926 lines in 2356 files changed: 51300 ins; 25056 del; 13570 mod
  Patch: https://git.openjdk.org/jdk/pull/25878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25878/head:pull/25878

PR: https://git.openjdk.org/jdk/pull/25878

From dclarke at openjdk.org  Tue Aug 12 11:16:13 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 12 Aug 2025 11:16:13 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <goNlSp75pxPfwgD4zUK3kB9_3TKSm_O0z0G8I4zviGw=.fa378954-2a5f-46e0-93ee-ec91adb8082c@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <goNlSp75pxPfwgD4zUK3kB9_3TKSm_O0z0G8I4zviGw=.fa378954-2a5f-46e0-93ee-ec91adb8082c@github.com>
Message-ID: <_KCC0Md1R2Xpvl05BZ0dDYA39hwnoIrW3mzYf8qBvq4=.daef31b0-2157-4b6f-b827-fe333f1f0fc9@github.com>

On Sat, 26 Jul 2025 07:46:25 GMT, ExE Boss <duke at openjdk.org> wrote:

>> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
>> 
>> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
>> 
>> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.
>
> src/java.base/macosx/classes/sun/nio/ch/KQueuePoller.java line 44:
> 
>> 42: 
>> 43:     KQueuePoller(boolean subPoller, boolean read) throws IOException {
>> 44:         this.kqfd = kqueue_h.kqueue();
> 
> Note?that the?old?implementation of?`KQueue.create()` had?a?check for?negative `kqfd`: <https://github.com/openjdk/jdk/blob/d288ca28be7bfba3abe9f54cefbe53e73c25707e/src/java.base/macosx/native/libnio/ch/KQueue.c#L63-L71>

Sorry for the delay in getting back to this, thanks for the comment though! I'll update the PR to include that again

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2269512920

From dclarke at openjdk.org  Tue Aug 12 11:20:12 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 12 Aug 2025 11:20:12 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <g5myrFBNeMK9tEw7IwwXeC1Ut2UblEPY10I1jQgDCpE=.32a118f3-49d7-4793-a279-4981ce72bbf6@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <Ff05ao90-5o4GMTnLclSrFfBY8y3WTKWROAccW_Gw1s=.58507938-39d3-46e2-ae9f-e641c87acb57@github.com>
 <O_8NkCWn3ufZSs51ProN7S6rwiNBqKJ8bgK6gFy28Vo=.6faf6e80-3674-4095-a886-5a69a07aeda7@github.com>
 <g5myrFBNeMK9tEw7IwwXeC1Ut2UblEPY10I1jQgDCpE=.32a118f3-49d7-4793-a279-4981ce72bbf6@github.com>
Message-ID: <H47w7dVTp4vY5nHRPe2Kz1Mum-xrm4xkpqWcAiFzfWo=.b96a7172-6014-458b-b2b5-51ac13a404af@github.com>

On Thu, 31 Jul 2025 12:15:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> IMHO the more honest approach is to move these constants closer to the _h generated files that use them, as that's the way jextract intends them to be used.
>
> (Also, the latest version of jextract uses `Linker.canonicalLayouts` to derive these constants, which might be more robust longer term)

I can update FFMUtils so that all the different pointers user `Liner.canonicalLayouts`,

As for the other point, I think you're right that the shared FFMUtils won't work though I think it's a bit of a shame because of the number of similar duplicate lines. I can move it back to using different ones for each platform in the next commit

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2269522249

From pminborg at openjdk.org  Tue Aug 12 11:57:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Aug 2025 11:57:17 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v4]
In-Reply-To: <-hJgjZr0FJ_FWLrV9ZYnRXe1a9YwxGafbRIM_51wP-c=.b0004d78-4fe3-4878-91c4-94f6d3e230f2@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
 <bHZwy3Z9m1Jb2ts2aT5CGgnSJNxaopPUx31hso5w--c=.67ee338b-d508-45d5-bbd3-e914551eea19@github.com>
 <GnqfVrsdRG-6p0dvT3Wn9Uhg_9R-ySPOb_-MFdECADg=.ff5fe2ae-3600-425e-bf65-54f74cf4f249@github.com>
 <-hJgjZr0FJ_FWLrV9ZYnRXe1a9YwxGafbRIM_51wP-c=.b0004d78-4fe3-4878-91c4-94f6d3e230f2@github.com>
Message-ID: <9_-aWqAHHpyI0qLo2K1Ww6zvckkEOxo9MfL0T3aW8vU=.a2c626b4-5197-4858-872d-a07630364114@github.com>

On Tue, 12 Aug 2025 09:09:17 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> No, because the?stable?value doesn?t?get?set in?that?case, so?the?supplier/function will?be?called?again.
>
> @ExE-Boss That seems to presume that 1) it will be called again, and 2) it will eventually produce a non-exception

The underlying function will be retained until all values are computed (non exceptionally). It is as simple as that.

I was not able to come up with something better than that, but I am open to other suggestions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2269603690

From clanger at openjdk.org  Tue Aug 12 12:00:15 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 12 Aug 2025 12:00:15 GMT
Subject: RFR: 8365307: AIX make fails after JDK-8364611
In-Reply-To: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>
References: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>
Message-ID: <tLvI-BbftcDuUFTZcKb5KQtNV2pgYWIR159cwYyYw4Q=.7fb1a511-d47b-4193-b046-05a85a721808@github.com>

On Tue, 12 Aug 2025 08:18:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After recent change [JDK-8364611](https://bugs.openjdk.org/browse/JDK-8364611), the build fails on AIX with :
> 
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c:75:41: error: format specifies type 'unsigned int' but the argument has type 'sigset_t' (aka 'struct sigset_t') [-Werror,-Wformat]
>    75 | printf("%X %X\n", act.sa_flags, act.sa_mask);
>       | ~~ ^~~~~~~~~~~
> 
> 
> The printing of the mask is optional and not needed for a working test, so we can avoid it on AIX .

Thanks for fixing the build. Can't act.sa_mask be printed somehow on AIX, though?

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26739#pullrequestreview-3110135687

From vyazici at openjdk.org  Tue Aug 12 12:11:07 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 12:11:07 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v3]
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <ySC3_LxtRcFJjzSEWfWtabY2-IcRsNdq5AIrMzFtoJc=.6b85fcea-c613-4383-9786-c2e3fa5570cd@github.com>

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Simplify added null checks
 - Avoid code duplication by sprinkling some generics magic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26413/files
  - new: https://git.openjdk.org/jdk/pull/26413/files/1fb8582e..f536a341

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26413&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26413&range=01-02

  Stats: 325 lines in 1 file changed: 77 ins; 213 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/26413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26413/head:pull/26413

PR: https://git.openjdk.org/jdk/pull/26413

From vyazici at openjdk.org  Tue Aug 12 12:11:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 12:11:11 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v3]
In-Reply-To: <13urR68f8U8oqjrcaX1BtKI-EtD41ySuYt-oz333PdA=.c97d8293-2fbe-415d-983d-92b7e1c9d175@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <13urR68f8U8oqjrcaX1BtKI-EtD41ySuYt-oz333PdA=.c97d8293-2fbe-415d-983d-92b7e1c9d175@github.com>
Message-ID: <gmHr9frzazIJCYsvTbmxiDWkLHVHXePX8kt_qSAw0rM=.9d00f1eb-002e-4744-9eb6-4300976283a0@github.com>

On Mon, 28 Jul 2025 22:34:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Simplify added null checks
>>  - Avoid code duplication by sprinkling some generics magic
>
> src/java.base/share/classes/java/lang/String.java line 571:
> 
>> 569:     }
>> 570: 
>> 571:     private static String utf8ThrowingIae(byte[] bytes, int offset, int length) {
> 
> Iae should be all-caps. `IAE`

This change has disappeared ? the remark is not applicable anymore.

> src/java.base/share/classes/java/lang/String.java line 579:
> 
>> 577:     }
>> 578: 
>> 579:     private static IllegalArgumentException cce2iae(CharacterCodingException cce) {
> 
> More readable would be "cceToIAE"
> But this whole construct is suspect because of the contortions needed.

This change has disappeared ? the remark is not applicable anymore.

> src/java.base/share/classes/java/lang/String.java line 1289:
> 
>> 1287:     }
>> 1288: 
>> 1289:     private static void throwMalformed(byte[] val) throws MalformedInputException {
> 
> It is unnecessary to add add @throws of RuntimeExceptions, conventionally they are omitted as clutter and any RuntimeException can be thrown at any time.

`MalformedInputException` is a checked exception, I think there has been some sort of confusion here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2269623466
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2269623313
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2269621563

From vyazici at openjdk.org  Tue Aug 12 12:11:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 12:11:15 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v2]
In-Reply-To: <GYMlMXwoAVU4hBdebtau5SDWtPDT5MLeQ92r_2Qio8k=.e439853e-faa8-470a-afdc-0c8c5644d083@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <6LY-pGXEYGVLE2sAYTG8175PvnICXFoHw4velrtLk8E=.dc8a5a32-5c4f-44fa-a281-c5516a22b4bb@github.com>
 <GYMlMXwoAVU4hBdebtau5SDWtPDT5MLeQ92r_2Qio8k=.e439853e-faa8-470a-afdc-0c8c5644d083@github.com>
Message-ID: <bzw_vqzO39Ru2hB1_6R4ivmCKqFKypU0F-ggW5Np5Jw=.6488f81b-ef68-4dde-b1ee-c0fa28a02b84@github.com>

On Fri, 8 Aug 2025 17:29:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Volkan Yazici 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:
>> 
>>  - Group `String` methods by `doReplace` argument
>>  - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
>>  - Replace `requireNonNull` with implicit null checks
>>  - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
>>  - Improve docs of touched methods and add NPE checks
>>  - Convert IAE-throwing methods into CCE-throwing ones
>>  - Rename `JavaLangAccess::*NoRepl` methods
>
> src/java.base/share/classes/java/lang/String.java line 855:
> 
>> 853:         int len = val.length >> coder;  // assume LATIN1=0/UTF16=1;
>> 854:         int en = scale(len, ce.maxBytesPerChar());
>> 855:         // Fast-path with `ArrayEncoder` implies replacement.
> 
> I recommend documenting this on ArrayEncoder instead.

This already happens to be the case:

    /*
     * FastPath char[]/byte[] -> byte[] encoder, REPLACE on malformed input or
     * unmappable input.
     */

    public interface ArrayEncoder { ... }

> src/java.base/share/classes/java/lang/String.java line 949:
> 
>> 947:     static byte[] getBytesNoReplacement(String s, Charset cs) throws CharacterCodingException {
>> 948:         Objects.requireNonNull(s, "s");
>> 949:         Objects.requireNonNull(cs, "cs");
> 
> #26600 and subsequent PRs will add variable name reporting, so you can omit the string message to reduce bytecode size.

Great news! :star_struck: Simplified as requested in f536a341901.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2269618475
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2269613108

From vyazici at openjdk.org  Tue Aug 12 12:11:17 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 12:11:17 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v3]
In-Reply-To: <vpm4fE0UvlmqWd-E9O2vT_Me8_I6q0DRwGvFnEBO76E=.5a14fcac-a1c4-42be-8f83-a361ddd2e92f@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <UA0pGbsuzu3uVXQiMX6bXjQOdbpmnAhVOyR1tuk5mEo=.327cbc19-fd65-40af-89a0-fd19c65d4672@github.com>
 <vpm4fE0UvlmqWd-E9O2vT_Me8_I6q0DRwGvFnEBO76E=.5a14fcac-a1c4-42be-8f83-a361ddd2e92f@github.com>
Message-ID: <UvAR0OxGqdg_gYcw9i2C935F1j4amwTUUlsiPrWXNt0=.ba6d2c64-d1c9-4ea7-9296-412dda1d4ef2@github.com>

On Tue, 29 Jul 2025 14:22:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 1262:
>> 
>>> 1260:         MalformedInputException mie = new MalformedInputException(nb);
>>> 1261:         String msg = "malformed input off : " + off + ", length : " + nb;
>>> 1262:         mie.initCause(new IllegalArgumentException(msg));
>> 
>> Earlier `throw(Malformed|Unmappable)` methods were throwing `IAE` containing _extra diagnostics information_ and wrapping a `CCE` as a cause. After switching methods to throw `CCE`, which doesn't have a ctor accepting a `String` message, to retain this extra diagnostics information, I've added swapped their causal chain placement, and wrapped `IAE` with a `CCE` this time.
>> 
>> This played well with `CCE`-throwing methods, yet there are other `public` methods which did not have `throws CCE` in their footprint. For backward compatibility, in those spots, I've used `cce2iae` to obtain, again, a `IAE` wrapping the `CCE`, which matched the old behavior.
>
> Introducing CCE (an IOException) into more places in string handling is going in the wrong direction.
> As declared exceptions, they have to be caught and handled or re-thrown. That makes the source more complex and harder to maintain, as seen in the cce2iae mechanism.
> The prior use of IAE encapsulating a CCE as needed is simpler and more consistent with other Runtime exception handling in most of the String class.

Since the need for `cce2iae` is disapperaed, I'm resolving this conversation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2269607697

From vyazici at openjdk.org  Tue Aug 12 12:11:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 12:11:20 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v3]
In-Reply-To: <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>
Message-ID: <azRXxM2fdiBl97tQKxAJWrMFGMds08-a2OcDmp4GQ5A=.6e5e0dcc-2596-4d6a-b4f1-36605d813a42@github.com>

On Mon, 21 Jul 2025 13:00:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> The docs should mention these two details:
> 
> 1. This method does not replace upon malformed data but fails
> 2. This method does not copy the byte array for validation (can add to the warning)

@liach, I presume you want more than the following two (existing) comment blocks addressing these concerns:

     * <b>WARNING: The caller of this method shall relinquish and transfer the
     * ownership of the byte array to the callee</b>, since the latter will not
     * make a copy.
     ...
     * @throws CharacterCodingException for malformed or unmappable bytes

If so, mind elaborating on your suggested enhancements, please?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2269632642

From asteiner at openjdk.org  Tue Aug 12 12:13:10 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Tue, 12 Aug 2025 12:13:10 GMT
Subject: RFR: 8365307: AIX make fails after JDK-8364611
In-Reply-To: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>
References: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>
Message-ID: <8GN--Q-RbMpL66xO5HNVX4qkWiXZrLmMiKVd396vP4Q=.953da991-6e69-49ad-b04f-10d4fe2fecff@github.com>

On Tue, 12 Aug 2025 08:18:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After recent change [JDK-8364611](https://bugs.openjdk.org/browse/JDK-8364611), the build fails on AIX with :
> 
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c:75:41: error: format specifies type 'unsigned int' but the argument has type 'sigset_t' (aka 'struct sigset_t') [-Werror,-Wformat]
>    75 | printf("%X %X\n", act.sa_flags, act.sa_mask);
>       | ~~ ^~~~~~~~~~~
> 
> 
> The printing of the mask is optional and not needed for a working test, so we can avoid it on AIX .

LGTM

-------------

Marked as reviewed by asteiner (Author).

PR Review: https://git.openjdk.org/jdk/pull/26739#pullrequestreview-3110272208

From mbaesken at openjdk.org  Tue Aug 12 12:20:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 12:20:10 GMT
Subject: RFR: 8365307: AIX make fails after JDK-8364611
In-Reply-To: <tLvI-BbftcDuUFTZcKb5KQtNV2pgYWIR159cwYyYw4Q=.7fb1a511-d47b-4193-b046-05a85a721808@github.com>
References: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>
 <tLvI-BbftcDuUFTZcKb5KQtNV2pgYWIR159cwYyYw4Q=.7fb1a511-d47b-4193-b046-05a85a721808@github.com>
Message-ID: <kECmQNA13aqVFdDfOPhg6WcBHF-5uzkj9MIrJ0-foy8=.daa69d4b-0529-48da-adbb-494aa9ffc4aa@github.com>

On Tue, 12 Aug 2025 11:57:24 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Thanks for fixing the build. Can't act.sa_mask be printed somehow on AIX, though?

We have a member    `sigset_t sa_mask `  in the struct and most likely can evaluate this member, but it is only test coding so probably not worth much effort .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26739#issuecomment-3179076915

From mbaesken at openjdk.org  Tue Aug 12 12:20:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 12:20:12 GMT
Subject: RFR: 8365307: AIX make fails after JDK-8364611
In-Reply-To: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>
References: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>
Message-ID: <bczxpzSSqFEof9-dxC3oEZIVE8XP-BPz1vEqtPkQYjc=.fa509765-a3fb-4621-8a6b-664bb115f818@github.com>

On Tue, 12 Aug 2025 08:18:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After recent change [JDK-8364611](https://bugs.openjdk.org/browse/JDK-8364611), the build fails on AIX with :
> 
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c:75:41: error: format specifies type 'unsigned int' but the argument has type 'sigset_t' (aka 'struct sigset_t') [-Werror,-Wformat]
>    75 | printf("%X %X\n", act.sa_flags, act.sa_mask);
>       | ~~ ^~~~~~~~~~~
> 
> 
> The printing of the mask is optional and not needed for a working test, so we can avoid it on AIX .

Thanks for the reviews !   Integrating it already for fixing our builds.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26739#issuecomment-3179081631

From mbaesken at openjdk.org  Tue Aug 12 13:20:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 13:20:18 GMT
Subject: Integrated: 8365307: AIX make fails after JDK-8364611
In-Reply-To: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>
References: <Tc5muzlb9jIe0Yl50-yww6OCib6n44t077QM6qR6CZ4=.8a3c80b2-874b-4ee6-b1cc-9ebd3011e64a@github.com>
Message-ID: <PItuRhmIIc7BZs6OezryMz7t_rx8xCB8vRVeCtI-FCg=.6e2ddc59-2b36-4f95-913a-9fc424e02870@github.com>

On Tue, 12 Aug 2025 08:18:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After recent change [JDK-8364611](https://bugs.openjdk.org/browse/JDK-8364611), the build fails on AIX with :
> 
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c:75:41: error: format specifies type 'unsigned int' but the argument has type 'sigset_t' (aka 'struct sigset_t') [-Werror,-Wformat]
>    75 | printf("%X %X\n", act.sa_flags, act.sa_mask);
>       | ~~ ^~~~~~~~~~~
> 
> 
> The printing of the mask is optional and not needed for a working test, so we can avoid it on AIX .

This pull request has now been integrated.

Changeset: 391ea151
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/391ea151184c5621f263742605416c3ccd2c3d73
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8365307: AIX make fails after JDK-8364611

Reviewed-by: clanger, asteiner

-------------

PR: https://git.openjdk.org/jdk/pull/26739

From vklang at openjdk.org  Tue Aug 12 13:26:11 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Aug 2025 13:26:11 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v4]
In-Reply-To: <9_-aWqAHHpyI0qLo2K1Ww6zvckkEOxo9MfL0T3aW8vU=.a2c626b4-5197-4858-872d-a07630364114@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
 <bHZwy3Z9m1Jb2ts2aT5CGgnSJNxaopPUx31hso5w--c=.67ee338b-d508-45d5-bbd3-e914551eea19@github.com>
 <GnqfVrsdRG-6p0dvT3Wn9Uhg_9R-ySPOb_-MFdECADg=.ff5fe2ae-3600-425e-bf65-54f74cf4f249@github.com>
 <-hJgjZr0FJ_FWLrV9ZYnRXe1a9YwxGafbRIM_51wP-c=.b0004d78-4fe3-4878-91c4-94f6d3e230f2@github.com>
 <9_-aWqAHHpyI0qLo2K1Ww6zvckkEOxo9MfL0T3aW8vU=.a2c626b4-5197-4858-872d-a07630364114@github.com>
Message-ID: <r_f2Toqarvo1ArC5OZDM8M9vaA7SrqLA2S9OKPm6uuE=.08e9d0a5-27fe-42da-b389-0a23fb1c833e@github.com>

On Tue, 12 Aug 2025 11:54:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> @ExE-Boss That seems to presume that 1) it will be called again, and 2) it will eventually produce a non-exception
>
> The underlying function will be retained until all values are computed (non exceptionally). It is as simple as that.
> 
> I was not able to come up with something better than that, but I am open to other suggestions.

Would it make sense to record that it failed to initialize and then count down the holder, and then throw ExceptionInInitializerError (or something else?) upon subsequent access? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2269834372

From epeter at openjdk.org  Tue Aug 12 15:07:18 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 12 Aug 2025 15:07:18 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v6]
In-Reply-To: <CzTx08v5uJEFUXOihNMdC5nFMxYpX78s8MHMEE25m2s=.df97d05e-5467-4373-b030-9de3e61c9521@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <CzTx08v5uJEFUXOihNMdC5nFMxYpX78s8MHMEE25m2s=.df97d05e-5467-4373-b030-9de3e61c9521@github.com>
Message-ID: <Acjo9r9R-ccmmfnyXpUwSN_1qAabwUVTyv9VFH3b3Dc=.afe7d79f-3b0f-486b-a950-afd95a23ff60@github.com>

On Mon, 11 Aug 2025 16:31:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 274:

> 272:             // A long value that is less than zero has it's 63:th bit set and so,
> 273:             // we can just AND the expressions (and the sign bit 63)
> 274:             return (int) (((thisStart - thatEnd) & (thatStart - thisEnd)));  // overlap occurs -> negative value

Why not move the branch to here? Is there really a good reason why you move it to the call-site?
That way, you could save the comment:
`// Returns a negative value if the regions overlap, otherwise a non-negative value.`
Also: I see that your conditions at the call-site are not consistent with the current semantics. You have:
`if (overlaps(that) >= 0) {`
and
`src.overlaps(dst) == 0`
The second seems wrong to me - do you agree?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26672#discussion_r2270199905

From liach at openjdk.org  Tue Aug 12 16:03:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Aug 2025 16:03:17 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v3]
In-Reply-To: <ySC3_LxtRcFJjzSEWfWtabY2-IcRsNdq5AIrMzFtoJc=.6b85fcea-c613-4383-9786-c2e3fa5570cd@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <ySC3_LxtRcFJjzSEWfWtabY2-IcRsNdq5AIrMzFtoJc=.6b85fcea-c613-4383-9786-c2e3fa5570cd@github.com>
Message-ID: <mXoVv0Cv7aoxDpUKfV_13xbCvzOBt5xF96aMr_AhFhU=.bb32e5c4-4d08-4a39-81b2-4b196cef63a8@github.com>

On Tue, 12 Aug 2025 12:11:07 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify added null checks
>  - Avoid code duplication by sprinkling some generics magic

src/java.base/share/classes/java/lang/String.java line 851:

> 849:     }
> 850: 
> 851:     private static <E extends Exception> byte[] encodeWithEncoder(Charset cs, byte coder, byte[] val) {

Is the type parameter here redundant?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2270409766

From lkorinth at openjdk.org  Tue Aug 12 17:09:32 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 12 Aug 2025 17:09:32 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
Message-ID: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>

This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).

My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have ploughed through test cases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

After the review, I will update the copyrights.

I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

I got 4 timing related faults:
1) runtime/Thread/TestThreadDumpMonitorContention.java
   This is probably: https://bugs.openjdk.org/browse/JDK-8361370
2) sun/tools/jhsdb/BasicLauncherTest.java
   I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
3) gc/stress/TestReclaimStringsLeaksMemory.java
   I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
4) sun/security/ssl/X509KeyManager/CertChecking.java
   This is a new test that I got on last rebase. I have added a timeout of 480 to it.

In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.

>From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of default timeout factor", I have taken a few actions:
1) in testing(md|html): interpreted mode -> forced compilation mode
2) in MTTest.java: changed 1200 -> 400 (was 300 to begin with)

I am now re-running tier 1-8.

-------------

Commit messages:
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Changes: https://git.openjdk.org/jdk/pull/26749/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8260555
  Stats: 598 lines in 297 files changed: 49 ins; 91 del; 458 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

PR: https://git.openjdk.org/jdk/pull/26749

From cjplummer at openjdk.org  Tue Aug 12 17:54:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Aug 2025 17:54:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> sun/tools/jhsdb/BasicLauncherTest.java
> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.

@lkorinth Can you send me a link to the failure?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3180396310

From vyazici at openjdk.org  Tue Aug 12 19:29:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 19:29:28 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v4]
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <Q42gIyby5n9jbP7PjF7qicvmKbsgktXvI1LhKijZNMw=.a09cb9ae-3e7c-4ae7-acd5-a19f4eb89b64@github.com>

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant type parameters

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26413/files
  - new: https://git.openjdk.org/jdk/pull/26413/files/f536a341..c5ddfe62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26413&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26413&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26413/head:pull/26413

PR: https://git.openjdk.org/jdk/pull/26413

From vyazici at openjdk.org  Tue Aug 12 19:29:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 19:29:29 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v3]
In-Reply-To: <mXoVv0Cv7aoxDpUKfV_13xbCvzOBt5xF96aMr_AhFhU=.bb32e5c4-4d08-4a39-81b2-4b196cef63a8@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <ySC3_LxtRcFJjzSEWfWtabY2-IcRsNdq5AIrMzFtoJc=.6b85fcea-c613-4383-9786-c2e3fa5570cd@github.com>
 <mXoVv0Cv7aoxDpUKfV_13xbCvzOBt5xF96aMr_AhFhU=.bb32e5c4-4d08-4a39-81b2-4b196cef63a8@github.com>
Message-ID: <KbEu9htuAlNzlpcUueFbHg24U4tKFb2mmqvN4f9RAQ8=.a6d4c69f-3ebb-4212-a7d8-21d45001485f@github.com>

On Tue, 12 Aug 2025 15:58:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Simplify added null checks
>>  - Avoid code duplication by sprinkling some generics magic
>
> src/java.base/share/classes/java/lang/String.java line 851:
> 
>> 849:     }
>> 850: 
>> 851:     private static <E extends Exception> byte[] encodeWithEncoder(Charset cs, byte coder, byte[] val) {
> 
> Is the type parameter here redundant?

Yes, it is! Removed this one and other 3 in c5ddfe62eb8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2270957899

From syan at openjdk.org  Wed Aug 13 01:50:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:50:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Should we need to update the copyright year for the touch files

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271883564

From syan at openjdk.org  Wed Aug 13 01:54:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:54:16 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:

> 27:  * @requires vm.debug
> 28:  * @summary Test running with StressRecompilation enabled.
> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation

I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.


> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
55:elapsed time (seconds): 0.581
66:elapsed time (seconds): 0.575
116:elapsed time (seconds): 3.088
162:elapsed time (seconds): 0.001
173:elapsed time (seconds): 11.546

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271888024

From jbhateja at openjdk.org  Wed Aug 13 03:11:00 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 13 Aug 2025 03:11:00 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v6]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <-_yIOwHApwxDw0YIWJ7MnXqK2VknHMQYoGShNqaslRk=.26037fd7-5429-4f41-a829-14f485b0ff48@github.com>

> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
> 
>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
> 
> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
> 
> Performance numbers:
> 
> 
> System : 13th Gen Intel(R) Core(TM) i3-1315U
> 
> Baseline:
> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Cleanups, review resoultions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24104/files
  - new: https://git.openjdk.org/jdk/pull/24104/files/f36ae6dd..d55fa594

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=04-05

  Stats: 25 lines in 7 files changed: 0 ins; 24 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104

PR: https://git.openjdk.org/jdk/pull/24104

From jbhateja at openjdk.org  Wed Aug 13 03:11:00 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 13 Aug 2025 03:11:00 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <PW0WqtvVzqu3qG_7xw_ineur2UE51rNDlKOuEOOkMYs=.0622e006-3614-4be5-b6db-7a0a770adb32@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
 <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com>
 <k2V-EAfdcwZ0_CUfsFROCUJaX94roDzGktcQrvuVtXI=.d19af7dc-9a5a-489c-8af6-8f2cfd49dc1c@github.com>
 <PW0WqtvVzqu3qG_7xw_ineur2UE51rNDlKOuEOOkMYs=.0622e006-3614-4be5-b6db-7a0a770adb32@github.com>
Message-ID: <u7gj-zjbYH8GSVvJ3b49gxlx-SZQw1SR8RiwIUBm5T8=.d0402842-6784-4dbd-b556-7bd615bd22f1@github.com>

On Tue, 12 Aug 2025 05:58:47 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes.
>>> 
>> 
>> Added comments.
>> 
>>> Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such a requirement. WDYT?
>> 
>> Currently, inline expander only supports constant origin. I have added a check to fail intrinsification and inline fallback using the hybrid call generator.
>
> Thanks for your updating! So maybe the matcher function `supports_vector_slice_with_non_constant_index()` could also be removed totally?

Yes, idea here is just to intrinsify a perticular scenario where slice index is a constant value and not burden the inline expander with full-blown intrinsification of all possible control paths without impacting the performance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2271958737

From jbhateja at openjdk.org  Wed Aug 13 03:20:02 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 13 Aug 2025 03:20:02 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v7]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <JnP2NKR1BMSBMVOJXwTODwMgj_P20q8k2zw7HLy4ZdE=.c476fb6b-4ccd-430a-b198-a6cd3e48f901@github.com>

> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
> 
>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
> 
> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
> 
> Performance numbers:
> 
> 
> System : 13th Gen Intel(R) Core(TM) i3-1315U
> 
> Baseline:
> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Jatin Bhateja 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:

  Review comments resolution

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24104/files
  - new: https://git.openjdk.org/jdk/pull/24104/files/d55fa594..70c22932

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=05-06

  Stats: 6 lines in 6 files changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104

PR: https://git.openjdk.org/jdk/pull/24104

From xgong at openjdk.org  Wed Aug 13 07:08:13 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 13 Aug 2025 07:08:13 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <DDBBkWLVLL8XF1org8tsQicx3yiqlYwJFMVaSzsFl-I=.4fa53b0c-3966-4c24-a0ab-a10544fac619@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
 <cKfMB03HU_UVleFKpPzuot9c1S0uc7QBNxzImvIWEeM=.69cf2c37-b3cf-4e59-a4c5-b6b34d341444@github.com>
 <DDBBkWLVLL8XF1org8tsQicx3yiqlYwJFMVaSzsFl-I=.4fa53b0c-3966-4c24-a0ab-a10544fac619@github.com>
Message-ID: <uXffIM3qmaSHnGWOPSTHI0cWffqJi2uOUYYyEqhUrQI=.68e23a9a-3138-4267-b8ad-fc1b3a2a42ec@github.com>

On Wed, 13 Aug 2025 07:02:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/incubator/vector/VectorSliceBenchmark.java line 36:
>> 
>>> 34: @State(Scope.Thread)
>>> 35: @Fork(jvmArgs = {"--add-modules=jdk.incubator.vector"})
>>> 36: public class VectorSliceBenchmark {
>> 
>> I remember that it has the micro benchmarks for slice/unslice under `test/micro/org/openjdk/bench/jdk/incubator/vector/operation` on panama-vector. Can we reuse those JMHs to check the benchmark improvement?
>
>> I remember that it has the micro benchmarks for slice/unslice under `test/micro/org/openjdk/bench/jdk/incubator/vector/operation` on panama-vector. Can we reuse those JMHs to check the benchmark improvement?
> 
> All those are the ones with variable slice index , slice kernel performance of those benchmarks on AVX2 and AVX512 targets are at par with baseline, and deviations are statistically insignificant due to error margins. 
> 
> New benchmark complements the code.

OK. Make sense to me. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2272278442

From jbhateja at openjdk.org  Wed Aug 13 07:08:13 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 13 Aug 2025 07:08:13 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <cKfMB03HU_UVleFKpPzuot9c1S0uc7QBNxzImvIWEeM=.69cf2c37-b3cf-4e59-a4c5-b6b34d341444@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
 <cKfMB03HU_UVleFKpPzuot9c1S0uc7QBNxzImvIWEeM=.69cf2c37-b3cf-4e59-a4c5-b6b34d341444@github.com>
Message-ID: <DDBBkWLVLL8XF1org8tsQicx3yiqlYwJFMVaSzsFl-I=.4fa53b0c-3966-4c24-a0ab-a10544fac619@github.com>

On Mon, 11 Aug 2025 03:11:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> I remember that it has the micro benchmarks for slice/unslice under `test/micro/org/openjdk/bench/jdk/incubator/vector/operation` on panama-vector. Can we reuse those JMHs to check the benchmark improvement?

All those are the ones with variable slice index , slice kernel performance of those benchmarks on AVX2 and AVX512 targets are at par with baseline, and deviations are statistically insignificant due to error margins. 

New benchmark complements the code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2272272548

From sspitsyn at openjdk.org  Wed Aug 13 07:29:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 07:29:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

I've reviewed the Serviceability related tweaks and I'm okay with them in general.
But I'm curious if you do not see any timeouts with this anymore.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3114280042

From pminborg at openjdk.org  Wed Aug 13 09:00:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Aug 2025 09:00:15 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v4]
In-Reply-To: <r_f2Toqarvo1ArC5OZDM8M9vaA7SrqLA2S9OKPm6uuE=.08e9d0a5-27fe-42da-b389-0a23fb1c833e@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
 <bHZwy3Z9m1Jb2ts2aT5CGgnSJNxaopPUx31hso5w--c=.67ee338b-d508-45d5-bbd3-e914551eea19@github.com>
 <GnqfVrsdRG-6p0dvT3Wn9Uhg_9R-ySPOb_-MFdECADg=.ff5fe2ae-3600-425e-bf65-54f74cf4f249@github.com>
 <-hJgjZr0FJ_FWLrV9ZYnRXe1a9YwxGafbRIM_51wP-c=.b0004d78-4fe3-4878-91c4-94f6d3e230f2@github.com>
 <9_-aWqAHHpyI0qLo2K1Ww6zvckkEOxo9MfL0T3aW8vU=.a2c626b4-5197-4858-872d-a07630364114@github.com>
 <r_f2Toqarvo1ArC5OZDM8M9vaA7SrqLA2S9OKPm6uuE=.08e9d0a5-27fe-42da-b389-0a23fb1c833e@github.com>
Message-ID: <DmIYOvgz8r0MTyE8E0OA2iuQMdnFVolpNxbjkOORimU=.fc43a43e-9269-4456-8d2f-a96bc053945b@github.com>

On Tue, 12 Aug 2025 13:23:32 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> The underlying function will be retained until all values are computed (non exceptionally). It is as simple as that.
>> 
>> I was not able to come up with something better than that, but I am open to other suggestions.
>
> Would it make sense to record that it failed to initialize and then count down the holder, and then throw ExceptionInInitializerError (or something else?) upon subsequent access? ?

We thought about that in the past. There were several prototypes with a similar behavior. It is not an unreasonable alternative.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2272585714

From vklang at openjdk.org  Wed Aug 13 09:05:17 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Aug 2025 09:05:17 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
Message-ID: <pCRZ4IbujB-_Y8LYi27HPCzvt42ESr1gIQNI0jQmmHs=.764d2d96-e88a-46e4-a021-8d4d040683d1@github.com>

On Thu, 7 Aug 2025 14:03:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid underutilization on resize

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1299:

> 1297:                 if (pool != null &&
> 1298:                     (a == null ||                // always signal on resize
> 1299:                      U.getReferenceAcquire(a, slotOffset(m & (s - 1))) == null))

@DougLea Interesting. Is the reason that it is cheaper to check `a` for null here that it elides a nullcheck in the getReferenceAcquire? (even if it adds the cost of nulling out `a` after growArray())

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2272612154

From vklang at openjdk.org  Wed Aug 13 09:06:15 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Aug 2025 09:06:15 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v4]
In-Reply-To: <DmIYOvgz8r0MTyE8E0OA2iuQMdnFVolpNxbjkOORimU=.fc43a43e-9269-4456-8d2f-a96bc053945b@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>
 <bHZwy3Z9m1Jb2ts2aT5CGgnSJNxaopPUx31hso5w--c=.67ee338b-d508-45d5-bbd3-e914551eea19@github.com>
 <GnqfVrsdRG-6p0dvT3Wn9Uhg_9R-ySPOb_-MFdECADg=.ff5fe2ae-3600-425e-bf65-54f74cf4f249@github.com>
 <-hJgjZr0FJ_FWLrV9ZYnRXe1a9YwxGafbRIM_51wP-c=.b0004d78-4fe3-4878-91c4-94f6d3e230f2@github.com>
 <9_-aWqAHHpyI0qLo2K1Ww6zvckkEOxo9MfL0T3aW8vU=.a2c626b4-5197-4858-872d-a07630364114@github.com>
 <r_f2Toqarvo1ArC5OZDM8M9vaA7SrqLA2S9OKPm6uuE=.08e9d0a5-27fe-42da-b389-0a23fb1c833e@github.com>
 <DmIYOvgz8r0MTyE8E0OA2iuQMdnFVolpNxbjkOORimU=.fc43a43e-9269-4456-8d2f-a96bc053945b@github.com>
Message-ID: <reTCcl53X6kAQTIdEkhV623zXtAwPmhLtpeKEXXC2eA=.9f0b9b00-7550-4b5e-b9b7-97762df60df3@github.com>

On Wed, 13 Aug 2025 08:57:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Would it make sense to record that it failed to initialize and then count down the holder, and then throw ExceptionInInitializerError (or something else?) upon subsequent access? ?
>
> We thought about that in the past. There were several prototypes with a similar behavior. It is not an unreasonable alternative.

Ok, let's put a pin in this for now, and revisit later. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2272615326

From vklang at openjdk.org  Wed Aug 13 09:24:13 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Aug 2025 09:24:13 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
Message-ID: <MVjH0z_crBoLRnZSh6HMeRwnHZJz6N2-06kCwp5nUlw=.8ce504ea-176a-4f42-acd4-47956b5cd3ab@github.com>

On Thu, 7 Aug 2025 14:03:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid underutilization on resize

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1860:

> 1858:             phase != 0 && w != null && w.source != DROPPED) {
> 1859:             w.cancelTasks();               // clean queue
> 1860:             signalWork(null, 0);           // possibly replace

@DougLea Nice catch ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2272669251

From vklang at openjdk.org  Wed Aug 13 09:29:13 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Aug 2025 09:29:13 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
Message-ID: <eICY1Li3ffX7IWcRONzeBLb1YRZT1LnhLlhewrBW120=.e2feb334-025b-4782-a215-7ff985d8dc66@github.com>

On Thu, 7 Aug 2025 14:03:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid underutilization on resize

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1894:

> 1892:             if (a != null && k < a.length && k >= 0 && a[k] == null)
> 1893:                 break;
> 1894:             if (c == (c = ctl) && c == (c = compareAndExchangeCtl(c, nc))) {

CCAE to reduce cache traffic contention on `ctl` is good. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2272690784

From vklang at openjdk.org  Wed Aug 13 09:36:15 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Aug 2025 09:36:15 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
Message-ID: <Dt1XlLcV36oUN6d0Ckk2mLwNZnpKtCrjlukSPdqjwqY=.7b88c259-8d12-49e3-8356-9a71e7d11ecb@github.com>

On Thu, 7 Aug 2025 14:03:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid underutilization on resize

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2003:

> 2001:                                     continue rescan;
> 2002:                                 if (b == (b = q.base) && a[bk] == null) {
> 2003:                                     if (a[nk] == null && a[(b + 2) & m] == null) {

@DougLea Seems worth it to add a comment around why we're looking at b + 2 here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2272712916

From aturbanov at openjdk.org  Wed Aug 13 09:47:17 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Aug 2025 09:47:17 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/langtools/tools/lib/toolbox/ToolBox.java line 480:

> 478: 
> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;

Suggestion:

    private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2272745651

From pminborg at openjdk.org  Wed Aug 13 10:08:33 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Aug 2025 10:08:33 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v7]
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <6jw9dOmp-h0nETyFDk89SqIcp899DWUWdZYzrt11jys=.2edf6ed5-a635-47b1-af9f-4a928891d76c@github.com>

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
> 
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Revert comment
 - Revert change in AMSI
 - Back paddle on the branchless overlap method
 - Merge branch 'master' into copy-overlap
 - Fix comment
 - Simplify
 - Update copyright year
 - Add a branchless overlaps method
 - Optimize copy for certain lengths
 - Add methods to ScopedMemoryAccess
 - ... and 2 more: https://git.openjdk.org/jdk/compare/f8869b45...1a1606e2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26672/files
  - new: https://git.openjdk.org/jdk/pull/26672/files/9c52870b..1a1606e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26672&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26672&range=05-06

  Stats: 10902 lines in 287 files changed: 6168 ins; 3376 del; 1358 mod
  Patch: https://git.openjdk.org/jdk/pull/26672.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26672/head:pull/26672

PR: https://git.openjdk.org/jdk/pull/26672

From pminborg at openjdk.org  Wed Aug 13 10:11:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Aug 2025 10:11:13 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v6]
In-Reply-To: <CzTx08v5uJEFUXOihNMdC5nFMxYpX78s8MHMEE25m2s=.df97d05e-5467-4373-b030-9de3e61c9521@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <CzTx08v5uJEFUXOihNMdC5nFMxYpX78s8MHMEE25m2s=.df97d05e-5467-4373-b030-9de3e61c9521@github.com>
Message-ID: <qvLu6OPGXl6pjzp7hoqYep3VBpoZ2iaLJKTSMRyLzlo=.c0529a9a-304f-422c-aca0-aae0cc2ff216@github.com>

On Mon, 11 Aug 2025 16:31:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

I've decided to back paddle on the branchless overlap method. On some architectures, there was a performance penalty for doing this on top of the added complexity. All things considered, the advantages did not exceed the drawbacks. Nevertheless, this is still a significant performance contribution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3183122162

From pminborg at openjdk.org  Wed Aug 13 10:49:18 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Aug 2025 10:49:18 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v7]
In-Reply-To: <6jw9dOmp-h0nETyFDk89SqIcp899DWUWdZYzrt11jys=.2edf6ed5-a635-47b1-af9f-4a928891d76c@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <6jw9dOmp-h0nETyFDk89SqIcp899DWUWdZYzrt11jys=.2edf6ed5-a635-47b1-af9f-4a928891d76c@github.com>
Message-ID: <chcLGL6vXdQesC863MKBSNcTB4URixW1oXzsYq9gryU=.99077673-c548-412b-9777-fe076c240785@github.com>

On Wed, 13 Aug 2025 10:08:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Revert comment
>  - Revert change in AMSI
>  - Back paddle on the branchless overlap method
>  - Merge branch 'master' into copy-overlap
>  - Fix comment
>  - Simplify
>  - Update copyright year
>  - Add a branchless overlaps method
>  - Optimize copy for certain lengths
>  - Add methods to ScopedMemoryAccess
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/02caf89b...1a1606e2

Here are the latest performance figures (Mac M1):

Bytes | Base | Patch | Improvement
-- | -- | -- | --
2 | 3.184 | 2.832 | 11.06%
3 | 3.162 | 2.837 | 10.28%
4 | 3.344 | 2.835 | 15.22%
5 | 3.31 | 2.826 | 14.62%
6 | 3.328 | 2.848 | 14.42%
7 | 3.289 | 2.826 | 14.08%
8 | 4.139 | 2.747 | 33.63%
12 | 4.709 | 2.871 | 39.03%
16 | 4.173 | 3.782 | 9.37%
24 | 4.239 | 4.085 | 3.63%
64 | 4.86 | 4.815 | 0.93%

<img width="776" height="480" alt="image" src="https://github.com/user-attachments/assets/4870b554-7170-49b9-84aa-47540fd1efab" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3183267461

From vklang at openjdk.org  Wed Aug 13 11:39:16 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Aug 2025 11:39:16 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v5]
In-Reply-To: <vL00V4ix1vi6qFWTe16o0B-NeFKGuIjUaD5_cicsQbM=.81d49e82-a7bd-40ac-b30a-e57e51cf6ce8@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <vL00V4ix1vi6qFWTe16o0B-NeFKGuIjUaD5_cicsQbM=.81d49e82-a7bd-40ac-b30a-e57e51cf6ce8@github.com>
Message-ID: <qOgtxR4ZTqqSPj9S9CbdE52jlkWiWETqePalBMS-dT0=.520a9217-75ce-49b0-8bef-5f97782567f7@github.com>

On Tue, 12 Aug 2025 09:21:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
>> 
>> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Add comment for outer.outer
>  - Merge branch 'master' into sv-release-supplier2
>  - Merge branch 'master' into sv-release-supplier2
>  - Add a new method to StableValueImpl for improved speed
>  - Merge branch 'master' into sv-release-supplier2
>  - Fix performance regression
>  - Clean up
>  - Fix bug
>  - Simplify
>  - Revert to records
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b367a692...243479df

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 52:

> 50:  *                         of the valid inputs (as there might be "holes")
> 51:  * @param delegates        a delegate array of inputs to StableValue mappings
> 52:  * @param underlyingHolder of the original underlying Function

Suggestion:

 * @param underlyingHolder the holder of the original underlying Function

src/java.base/share/classes/jdk/internal/lang/stable/StableFunction.java line 45:

> 43:  *
> 44:  * @param values           a delegate map of inputs to StableValue mappings
> 45:  * @param underlyingHolder of the original underlying Function

Suggestion:

 * @param underlyingHolder the holder of the original underlying Function

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2273099020
PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2273102356

From vklang at openjdk.org  Wed Aug 13 11:45:13 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Aug 2025 11:45:13 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v5]
In-Reply-To: <vL00V4ix1vi6qFWTe16o0B-NeFKGuIjUaD5_cicsQbM=.81d49e82-a7bd-40ac-b30a-e57e51cf6ce8@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <vL00V4ix1vi6qFWTe16o0B-NeFKGuIjUaD5_cicsQbM=.81d49e82-a7bd-40ac-b30a-e57e51cf6ce8@github.com>
Message-ID: <GLetSVXAg8JsZ50BJ1V04j6KyNJo3B95EConJgvjgEQ=.280c78da-33da-4dee-a3f9-3b51bc592057@github.com>

On Tue, 12 Aug 2025 09:21:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
>> 
>> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Add comment for outer.outer
>  - Merge branch 'master' into sv-release-supplier2
>  - Merge branch 'master' into sv-release-supplier2
>  - Add a new method to StableValueImpl for improved speed
>  - Merge branch 'master' into sv-release-supplier2
>  - Fix performance regression
>  - Clean up
>  - Fix bug
>  - Simplify
>  - Revert to records
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/126c2618...243479df

src/java.base/share/classes/jdk/internal/lang/stable/StableFunction.java line 79:

> 77:     public static <T, R> StableFunction<T, R> of(Set<? extends T> inputs,
> 78:                                                  Function<? super T, ? extends R> underlying) {
> 79:         return new StableFunction<>(StableUtil.map(inputs), new UnderlyingHolder<>(underlying, inputs.size()));

Suggestion:

        var m = StableUtil.map(inputs);
        return new StableFunction<>(m, new UnderlyingHolder<>(underlying, m.size()));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2273121882

From pminborg at openjdk.org  Wed Aug 13 11:51:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Aug 2025 11:51:29 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v6]
In-Reply-To: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
Message-ID: <VlnSh-lsCWxczOTZN89mXVi6mrGxqiiT2rOqxoCF1qw=.28d9454a-2935-4ce8-85b8-d725a491ca7a@github.com>

> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
> 
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/lang/stable/StableFunction.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25878/files
  - new: https://git.openjdk.org/jdk/pull/25878/files/243479df..76fae6dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25878&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25878&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25878/head:pull/25878

PR: https://git.openjdk.org/jdk/pull/25878

From duke at openjdk.org  Wed Aug 13 12:26:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 13 Aug 2025 12:26:55 GMT
Subject: RFR: 8365467: Fix multiple issues in ExplodedImage
Message-ID: <xTJzG56QgMhHkqu2E6wFIICYkgbVTGLxOHCdhOFbKSQ=.a531e4ae-f4b5-41fc-8b55-6604a1dc26e3@github.com>

This PR addresses several issues found while adding unit tests for ExplodedImage.
I have added review comments for changes (some of which are a little preferential, but bring the code into line with things like ImageReader in terms of the name choices for variables).
Later it is likely that this code will be adapted for the up-coming preview mode support in Valhalla, so having it unit-testable is important.

-------------

Commit messages:
 - Provisional fixes for ExplodedImage issues.

Changes: https://git.openjdk.org/jdk/pull/26757/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26757&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365467
  Stats: 371 lines in 5 files changed: 291 ins; 27 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/26757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26757/head:pull/26757

PR: https://git.openjdk.org/jdk/pull/26757

From epeter at openjdk.org  Wed Aug 13 12:32:23 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 13 Aug 2025 12:32:23 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v7]
In-Reply-To: <6jw9dOmp-h0nETyFDk89SqIcp899DWUWdZYzrt11jys=.2edf6ed5-a635-47b1-af9f-4a928891d76c@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <6jw9dOmp-h0nETyFDk89SqIcp899DWUWdZYzrt11jys=.2edf6ed5-a635-47b1-af9f-4a928891d76c@github.com>
Message-ID: <9V5WzxZzQQAwJY-BAmGwmQVO72SCcnZYOZPkfRuZDFE=.352587c2-7270-40fb-9f8b-a54d1a8b783c@github.com>

On Wed, 13 Aug 2025 10:08:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Revert comment
>  - Revert change in AMSI
>  - Back paddle on the branchless overlap method
>  - Merge branch 'master' into copy-overlap
>  - Fix comment
>  - Simplify
>  - Update copyright year
>  - Add a branchless overlaps method
>  - Optimize copy for certain lengths
>  - Add methods to ScopedMemoryAccess
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b0f898b5...1a1606e2

If I see this right, it could be that we duplicate the copy on a byte. If we only copy 2 bytes, then the copy on the second byte is repeated:

src[0] -> dst[0]
src[1] -> dst[1]
src[1] -> dst[1]

But is that ok?

Assume we have threads 1 and 2, both access memory locations A and B:

// Initial state
A = x;
B = y;

// Concurrently:
1: B = A;
2: A = B + 1;

What states could be observed at the end? We could look at all permutations of the 4 operations from threads 1 and 2. Let's call the operations 1.1 (1 loads A), 1.2 (1 stores B), 2.1 (2 loads B), 2.2 (2 stores A).
These are the 4! / 4 = 6 possible permutations, together with the results for A and B:

1.1 1.2 2.1 2.2 -> A = x+1; B = x
1.1 2.1 1.2 2.2 -> A = y+1; B = x
1.1 2.1 2.2 1.2 -> A = y+1; B = x
2.1 1.1 1.2 2.2 -> A = y+1; B = x
2.1 1.1 2.2 1.2 -> A = y+1; B = x
2.1 2.2 1.1 1.2 -> A = y+1; B = y+1

Now assume we repeat the copy for thread 1. Thus, this could happen:

1: B = A;
2: A = B + 1;
1: B = A; // repeated copy

And if it happens in this sequence, we get result:
`A = x+1; B = x+1`
But this result was not observable before.

That makes me wonder if repeating the copy is really allowed in the Java memory model?

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 156:

> 154:         // `putByte()` below is enough as 3 is the maximum number of bytes covered
> 155:         final byte b = SCOPED_MEMORY_ACCESS.getByte(srcSession, src.unsafeGetBase(), src.unsafeGetOffset() + srcOffset + len - Byte.BYTES);
> 156:         SCOPED_MEMORY_ACCESS.putByte(dstSession, dst.unsafeGetBase(), dst.unsafeGetOffset() + dstOffset + len - Byte.BYTES, b);

Are these duplications of operations really ok? Do you have a good argument for that?

-------------

PR Review: https://git.openjdk.org/jdk/pull/26672#pullrequestreview-3115657763
PR Review Comment: https://git.openjdk.org/jdk/pull/26672#discussion_r2273228594

From vklang at openjdk.org  Wed Aug 13 12:34:14 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Aug 2025 12:34:14 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v6]
In-Reply-To: <VlnSh-lsCWxczOTZN89mXVi6mrGxqiiT2rOqxoCF1qw=.28d9454a-2935-4ce8-85b8-d725a491ca7a@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <VlnSh-lsCWxczOTZN89mXVi6mrGxqiiT2rOqxoCF1qw=.28d9454a-2935-4ce8-85b8-d725a491ca7a@github.com>
Message-ID: <D0dndl_50tAlFdEUcJy8eXhCf3Q78acVIacn8Co_GhY=.264cc2b6-d6d5-43a0-9106-3455ac3a619c@github.com>

On Wed, 13 Aug 2025 11:51:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
>> 
>> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/jdk/internal/lang/stable/StableFunction.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

src/java.base/share/classes/java/util/ImmutableCollections.java line 140:

> 138:                 public <E> List<E> stableList(int size, IntFunction<? extends E> mapper) {
> 139:                     // A stable list is not Serializable, so we cannot return `List.of()` if `size == 0`
> 140:                     return new StableList<>(size, new UnderlyingHolder<>(mapper, size));

I personally think it's better (if possible) that the constructor instantiates the UnderlyingHolder, it also makes it much more tractable to ensure that there's consistency between what's in the class and what goes into the UnderlyingHolder.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2273312209

From duke at openjdk.org  Wed Aug 13 12:40:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 13 Aug 2025 12:40:17 GMT
Subject: RFR: 8365467: Fix multiple issues in ExplodedImage
In-Reply-To: <xTJzG56QgMhHkqu2E6wFIICYkgbVTGLxOHCdhOFbKSQ=.a531e4ae-f4b5-41fc-8b55-6604a1dc26e3@github.com>
References: <xTJzG56QgMhHkqu2E6wFIICYkgbVTGLxOHCdhOFbKSQ=.a531e4ae-f4b5-41fc-8b55-6604a1dc26e3@github.com>
Message-ID: <QEESb2rzcVsVR2XWwSwYMKGC9q3tr36keq8h51LIgD0=.ecc0f769-738f-4cb3-b41e-5bb363f78fa3@github.com>

On Wed, 13 Aug 2025 12:20:23 GMT, David Beaumont <duke at openjdk.org> wrote:

> This PR addresses several issues found while adding unit tests for ExplodedImage.
> I have added review comments for changes (some of which are a little preferential, but bring the code into line with things like ImageReader in terms of the name choices for variables).
> Later it is likely that this code will be adapted for the up-coming preview mode support in Valhalla, so having it unit-testable is important.

Adding explanatory notes for the non-test changes/fixes.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 59:

> 57:     private static final String PACKAGES = "/packages/";
> 58: 
> 59:     private final Path modulesDir;

Needed to make this class actually testable and avoid just using the static field from SystemImage.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 65:

> 63: 
> 64:     ExplodedImage(Path modulesDir) throws IOException {
> 65:         this.modulesDir = modulesDir;

Avoid unnecessary assumptions about file systems.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 95:

> 93:         }
> 94: 
> 95:         @Override

Discovered this method was missing during testing. I *think* this logic is what's needed here, but I would like someone to just double check.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 132:

> 130:                 try (DirectoryStream<Path> stream = Files.newDirectoryStream(path)) {
> 131:                     for (Path p : stream) {
> 132:                         p = modulesDir.relativize(p);

Avoid using static field.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 158:

> 156: 
> 157:     @Override
> 158:     public synchronized void close() throws IOException {

The nodes map is always accessed synchronised except here, so by synchronizing this we can stop using ConcurrentHashMap.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 171:

> 169:             return node;
> 170:         }
> 171:         // lazily created for paths like /packages/<package>/<module>/xyz

This code is simply wrong. The lookup of 'packages/java.lang/java.base/java/lang' should fail, since there is no node for it. It's the wrapping file system's job to test for symbolic links in the path and resolve this sort of thing.
Only /packages, /packages/xxx and /packages/xxx/yyy nodes need to exist in SystemImage.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 216:

> 214:         } catch (IOException x) {
> 215:             // Since the path reference a file, any errors should not be ignored.
> 216:             throw new UncheckedIOException(x);

Silently ignoring IOException was both a risk, and a possible performance issue, since it was being used for normal code flow whenever a non-existent node was being asked for. Now, an exception here is unconditionally a problem, since the given path does exist.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 226:

> 224:      */
> 225:     Path underlyingModulesPath(String name) {
> 226:         if (name.startsWith(MODULES) && name.length() > MODULES.length()) {

The extra length test avoids issues when "/modules/" is given, since that *should* be invalid but otherwise gets turned into a path to the parent dir.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 258:

> 256:                     String moduleName = module.getFileName().toString();
> 257:                     // make sure "/modules/<moduleName>" is created
> 258:                     Objects.requireNonNull(createModulesNode(MODULES + moduleName, module));

This happens once per module, so it's where we create the root dirs (see below).

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 276:

> 274:         // create "/modules" directory
> 275:         // "nodes" map contains only /modules/<foo> nodes only so far and so add all as children of /modules
> 276:         PathNode modulesRootNode = new PathNode("/modules", new ArrayList<>(nodes.values()));

Renamed because there's already "modulesDir" elsewhere.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 286:

> 284:             List<Node> moduleLinkNodes = new ArrayList<>(moduleNameList.size());
> 285:             for (String moduleName : moduleNameList) {
> 286:                 Node moduleNode = Objects.requireNonNull(nodes.get(MODULES + moduleName));

There's no need to call code that "creates" the module directory node here, we did it above, and here we can just guarantee it's in the cache.

src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java line 81:

> 79:     }
> 80: 
> 81:     private static final String RUNTIME_HOME;

Hiding these prevents unwanted use by other classes (which would make them effectively untestable).

test/jdk/jdk/internal/jrtfs/whitebox/ExplodedImageTestDriver.java line 30:

> 28:  * @run junit/othervm java.base/jdk.internal.jrtfs.ExplodedImageTest
> 29:  */
> 30: public class ExplodedImageTestDriver {}

Not 100% sure if a class declaration is needed here. It seems to work fine, but I've seen a case where there wasn't one (but that felt odd). Happy to remove if not wanted.

test/jdk/jdk/internal/jrtfs/whitebox/TEST.properties line 1:

> 1: modules = \

Cargo-culted without a true understand of what's going on. This seems to be what's needed for module access.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26757#pullrequestreview-3115737360
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273278111
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273280133
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273285948
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273289787
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273293717
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273300351
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273308453
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273325040
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273310217
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273313715
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273312772
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273315520
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273317906
PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2273319482

From jpai at openjdk.org  Wed Aug 13 12:53:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 13 Aug 2025 12:53:22 GMT
Subject: RFR: 8360575: java.util.Properties.list() methods trim each value
 to 37 characters in the listed output [v4]
In-Reply-To: <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
References: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
 <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
Message-ID: <I8rOsQLH4bkXrJWV9QfTAhu9OfvchXTuJvPMOAhcFGc=.651c67f1-1196-46c4-9420-9a6aa11efe3c@github.com>

On Mon, 30 Jun 2025 06:01:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clarify the current implementation of the `java.util.Properties.list(...)` methods?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current implementation trims each value to a size of 37 when printing out the value. This behaviour isn't documented by these methods. The change in this PR adds an `@implNote` to make a mention of this current behaviour.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - no need to state the number of characters

I'll close this current PR. Based on the inputs I've received here and offline, the suggestion is to deprecate these methods (and the one in ThreadGroup). I'm working on those changes and will open a separate PR for that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26018#issuecomment-3183788840

From jpai at openjdk.org  Wed Aug 13 12:53:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 13 Aug 2025 12:53:23 GMT
Subject: Withdrawn: 8360575: java.util.Properties.list() methods trim each
 value to 37 characters in the listed output
In-Reply-To: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
References: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
Message-ID: <3gkeV79bDSceQ3i9ULUGxffS_vjgGOSC7z2aMcJGvyY=.5da71670-04a1-435f-9fcc-0db3062ef922@github.com>

On Fri, 27 Jun 2025 13:20:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to clarify the current implementation of the `java.util.Properties.list(...)` methods?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current implementation trims each value to a size of 37 when printing out the value. This behaviour isn't documented by these methods. The change in this PR adds an `@implNote` to make a mention of this current behaviour.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26018

From lkorinth at openjdk.org  Wed Aug 13 13:09:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:09:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
Message-ID: <RA6T2Udma4QM1EdTUlZ9Y4l6Wo1783yEKYgOPy8UOZY=.7938ce78-45a5-4607-9298-72cf19436662@github.com>

On Wed, 13 Aug 2025 01:47:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Should we need to update the copyright year for the touched files

`After the review, I will update the copyrights.`

It is IMO easier to review big changes without the noise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273410872

From lkorinth at openjdk.org  Wed Aug 13 13:21:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:21:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
Message-ID: <4q0047gChugbkkv-W0lis2E8nXVWh8YGVJiBehoojLY=.0b9055a2-f038-4247-82a9-7c60ee9f6637@github.com>

On Tue, 12 Aug 2025 17:52:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > sun/tools/jhsdb/BasicLauncherTest.java
> > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 
> @lkorinth Can you send me a link to the failure?

I sent it to you on email.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3183896453

From erikj at openjdk.org  Wed Aug 13 13:28:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Aug 2025 13:28:18 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

make/RunTests.gmk line 939:

> 937: 
> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.

I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273468852

From lkorinth at openjdk.org  Wed Aug 13 13:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
Message-ID: <jX2ocV7Rf3mYq7TYfPkxKQfgucnVdhEDYMB91LwhTtI=.8810fb03-295c-4be5-9771-d7e031390002@github.com>

On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:
> 
>> 27:  * @requires vm.debug
>> 28:  * @summary Test running with StressRecompilation enabled.
>> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation
> 
> I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.
> 
> 
>> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
> 55:elapsed time (seconds): 0.581
> 66:elapsed time (seconds): 0.575
> 116:elapsed time (seconds): 3.088
> 162:elapsed time (seconds): 0.001
> 173:elapsed time (seconds): 11.546

I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273488236

From pminborg at openjdk.org  Wed Aug 13 13:45:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Aug 2025 13:45:15 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v7]
In-Reply-To: <9V5WzxZzQQAwJY-BAmGwmQVO72SCcnZYOZPkfRuZDFE=.352587c2-7270-40fb-9f8b-a54d1a8b783c@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <6jw9dOmp-h0nETyFDk89SqIcp899DWUWdZYzrt11jys=.2edf6ed5-a635-47b1-af9f-4a928891d76c@github.com>
 <9V5WzxZzQQAwJY-BAmGwmQVO72SCcnZYOZPkfRuZDFE=.352587c2-7270-40fb-9f8b-a54d1a8b783c@github.com>
Message-ID: <e_sJc5mQvjC-dyW6lR3ax4BeJo5eNv_XQfsKfeux774=.abcc310e-cc91-4ff1-addf-4346e8c80549@github.com>

On Wed, 13 Aug 2025 12:29:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Revert comment
>>  - Revert change in AMSI
>>  - Back paddle on the branchless overlap method
>>  - Merge branch 'master' into copy-overlap
>>  - Fix comment
>>  - Simplify
>>  - Update copyright year
>>  - Add a branchless overlaps method
>>  - Optimize copy for certain lengths
>>  - Add methods to ScopedMemoryAccess
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/a863dcac...1a1606e2
>
> If I see this right, it could be that we duplicate the copy on a byte. If we only copy 2 bytes, then the copy on the second byte is repeated:
> 
> src[0] -> dst[0]
> src[1] -> dst[1]
> src[1] -> dst[1]
> 
> But is that ok?
> 
> Assume we have threads 1 and 2, both access memory locations A and B:
> 
> // Initial state
> A = x;
> B = y;
> 
> // Concurrently:
> 1: B = A;
> 2: A = B + 1;
> 
> What states could be observed at the end? We could look at all permutations of the 4 operations from threads 1 and 2. Let's call the operations 1.1 (1 loads A), 1.2 (1 stores B), 2.1 (2 loads B), 2.2 (2 stores A).
> These are the 4! / 4 = 6 possible permutations, together with the results for A and B:
> 
> 1.1 1.2 2.1 2.2 -> A = x+1; B = x
> 1.1 2.1 1.2 2.2 -> A = y+1; B = x
> 1.1 2.1 2.2 1.2 -> A = y+1; B = x
> 2.1 1.1 1.2 2.2 -> A = y+1; B = x
> 2.1 1.1 2.2 1.2 -> A = y+1; B = x
> 2.1 2.2 1.1 1.2 -> A = y+1; B = y+1
> 
> Now assume we repeat the copy for thread 1. Thus, this could happen:
> 
> 1: B = A;
> 2: A = B + 1;
> 1: B = A; // repeated copy
> 
> And if it happens in this sequence, we get result:
> `A = x+1; B = x+1`
> But this result was not observable before.
> 
> That makes me wonder if repeating the copy is really allowed in the Java memory model?

We have discussed the possibility of threads seeing different values, like in the above example by @eme64. We think this is ok because there are no guarantees of inter-thread visibility for memory segments. This has to be provided externally (e.g., using volatile/CAS operations). There are other cases where we are susceptible to similar problems (e.g, when doing unaligned long access). In short, segments do not fulfill all the aspects of the normal Java memory model (like for arrays).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3183988708

From lkorinth at openjdk.org  Wed Aug 13 13:53:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:53:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
Message-ID: <5nc1SBXnwAOJJvnrbMyPIsre61u--GxMHSffdDf8qUU=.77100025-4b9e-4e0a-b71d-df590df5f9ba@github.com>

On Wed, 13 Aug 2025 07:26:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore.

I only got the four timeouts described in the description, I got a few other failures as well that was not timeout related. I sent you a link to the test results in an email.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3184026177

From pminborg at openjdk.org  Wed Aug 13 14:14:30 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Aug 2025 14:14:30 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v8]
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <_Ompbh3_hc6yPqt7KvbiuZVMJ9m7NoYNKIR_szqG62A=.59147014-db31-4296-8469-f107b6e677a9@github.com>

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
> 
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Break out the default branch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26672/files
  - new: https://git.openjdk.org/jdk/pull/26672/files/1a1606e2..e05c8370

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26672&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26672&range=06-07

  Stats: 18 lines in 1 file changed: 8 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26672.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26672/head:pull/26672

PR: https://git.openjdk.org/jdk/pull/26672

From epeter at openjdk.org  Wed Aug 13 14:21:21 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 13 Aug 2025 14:21:21 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v7]
In-Reply-To: <9V5WzxZzQQAwJY-BAmGwmQVO72SCcnZYOZPkfRuZDFE=.352587c2-7270-40fb-9f8b-a54d1a8b783c@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <6jw9dOmp-h0nETyFDk89SqIcp899DWUWdZYzrt11jys=.2edf6ed5-a635-47b1-af9f-4a928891d76c@github.com>
 <9V5WzxZzQQAwJY-BAmGwmQVO72SCcnZYOZPkfRuZDFE=.352587c2-7270-40fb-9f8b-a54d1a8b783c@github.com>
Message-ID: <zyLlLnkmjBW3zpfxdAr-fTFRYZe3ovf66boXYXMqpS0=.90856711-fcf4-4c3b-8275-53b9845ca3ce@github.com>

On Wed, 13 Aug 2025 12:29:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Revert comment
>>  - Revert change in AMSI
>>  - Back paddle on the branchless overlap method
>>  - Merge branch 'master' into copy-overlap
>>  - Fix comment
>>  - Simplify
>>  - Update copyright year
>>  - Add a branchless overlaps method
>>  - Optimize copy for certain lengths
>>  - Add methods to ScopedMemoryAccess
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/6f6585fd...1a1606e2
>
> If I see this right, it could be that we duplicate the copy on a byte. If we only copy 2 bytes, then the copy on the second byte is repeated:
> 
> src[0] -> dst[0]
> src[1] -> dst[1]
> src[1] -> dst[1]
> 
> But is that ok?
> 
> Assume we have threads 1 and 2, both access memory locations A and B:
> 
> // Initial state
> A = x;
> B = y;
> 
> // Concurrently:
> 1: B = A;
> 2: A = B + 1;
> 
> What states could be observed at the end? We could look at all permutations of the 4 operations from threads 1 and 2. Let's call the operations 1.1 (1 loads A), 1.2 (1 stores B), 2.1 (2 loads B), 2.2 (2 stores A).
> These are the 4! / 4 = 6 possible permutations, together with the results for A and B:
> 
> 1.1 1.2 2.1 2.2 -> A = x+1; B = x
> 1.1 2.1 1.2 2.2 -> A = y+1; B = x
> 1.1 2.1 2.2 1.2 -> A = y+1; B = x
> 2.1 1.1 1.2 2.2 -> A = y+1; B = x
> 2.1 1.1 2.2 1.2 -> A = y+1; B = x
> 2.1 2.2 1.1 1.2 -> A = y+1; B = y+1
> 
> Now assume we repeat the copy for thread 1. Thus, this could happen:
> 
> 1: B = A;
> 2: A = B + 1;
> 1: B = A; // repeated copy
> 
> And if it happens in this sequence, we get result:
> `A = x+1; B = x+1`
> But this result was not observable before.
> 
> That makes me wonder if repeating the copy is really allowed in the Java memory model?

> We have discussed the possibility of threads seeing different values, like in the above example by @eme64. We think this is ok because there are no guarantees of inter-thread visibility for memory segments. This has to be provided externally (e.g., using volatile/CAS operations). There are other cases where we are susceptible to similar problems (e.g, when doing unaligned long access). In short, segments do not fulfill all the aspects of the normal Java memory model (like for arrays).

Hmm, I see. Is this documented in the `MemorySegment` API? What are all the bad things that can happen?
- Tearing of unaligned access - can it also tear if the user has ensured alignment?
- Repeated instructions (like the repeated copy I pointed out above).

It is of course a little surprising that you lose the Java memory model guarantees of instruction ordering if you wrap an array in a `MemorySegment`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3184127780

From pminborg at openjdk.org  Wed Aug 13 14:21:23 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Aug 2025 14:21:23 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v8]
In-Reply-To: <_Ompbh3_hc6yPqt7KvbiuZVMJ9m7NoYNKIR_szqG62A=.59147014-db31-4296-8469-f107b6e677a9@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <_Ompbh3_hc6yPqt7KvbiuZVMJ9m7NoYNKIR_szqG62A=.59147014-db31-4296-8469-f107b6e677a9@github.com>
Message-ID: <Mzckx02eGsILmMWvb90t76aU4uERpkhijUuQqH4gXW8=.f33b24fb-5ee8-46ff-a2c8-d3fe0da45e65@github.com>

On Wed, 13 Aug 2025 14:14:30 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Break out the default branch

Viktor Klang suggested breaking out the default switch case in a separate conditional branch. This turned out to give better performance for sizes 16 bytes and upwards:

Bytes | Base | Patch | Improvement
-- | -- | -- | --
2 | 3.184 | 2.818 | 11.49%
3 | 3.162 | 2.822 | 10.75%
4 | 3.344 | 2.83 | 15.37%
5 | 3.31 | 2.819 | 14.83%
6 | 3.328 | 2.813 | 15.47%
7 | 3.289 | 2.826 | 14.08%
8 | 4.139 | 2.842 | 31.34%
12 | 4.709 | 2.848 | 39.52%
16 | 4.173 | 3.788 | 9.23%
24 | 4.239 | 3.89 | 8.23%
64 | 4.86 | 4.513 | 7.14%

<img width="824" height="505" alt="image" src="https://github.com/user-attachments/assets/2e25ac20-effc-4a44-8561-4ece0d6c609b" />

With this, I think we are good to go in terms of performance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3184127843

From lkorinth at openjdk.org  Wed Aug 13 14:22:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:08 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  After suggestions from Erik and Andrey

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/ac47dbdc..dbe42964

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

PR: https://git.openjdk.org/jdk/pull/26749

From lkorinth at openjdk.org  Wed Aug 13 14:22:10 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:10 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
Message-ID: <imd2i-VIlFCbEytLUZDyy_1SEU8ebK39Eif8JbdQsTU=.fefa1e8d-027b-445d-be69-07f6c6a475fd@github.com>

On Wed, 13 Aug 2025 13:25:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> make/RunTests.gmk line 939:
> 
>> 937: 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.
> 
> I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

I updated it to "Please reach consensus before changing this. It was not easy changing it to a `1`. " I also did not break the comment as it was shorter than line 933 above it. Is it acceptable now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273621868

From lkorinth at openjdk.org  Wed Aug 13 14:22:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
Message-ID: <KRJUnB026z2YmEljJJCHz5JEklLTO2LJfpMvwvt6-5k=.8388ace4-c445-4fdc-a71d-dff5a53cbeb6@github.com>

On Wed, 13 Aug 2025 09:44:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 480:
> 
>> 478: 
>> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
>> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;
> 
> Suggestion:
> 
>     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

Fixed!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273614076

From redestad at openjdk.org  Wed Aug 13 14:23:22 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 13 Aug 2025 14:23:22 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
Message-ID: <b4bYIyfaNilRNu7b1CQlTCnzNcAnB359mg911TY5d24=.4560b893-e719-4ed9-bfa3-6408fd7ccbee@github.com>

On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `@apiNote` in `encodeISOArray()` Javadoc
>   
>   Those who are touching to these methods should well be
>   aware of the details elaborated in the `@apiNote`, no
>   need to put it on a display.

I've done some testing on linux-amd64 and verified that on microbenchmarks that exercise for example `StringCoding.hasNegatives` (a front door of one of the intrinsics this PR changes) the generated assembly is identical under ideal conditions. Spurious regressions seen in some setups could be inlining related: moving from a simple range check emitted by the intrinsic to a call to `Preconditions.checkFromIndexSize` may push us over some inlining threshold in some cases. I'll try to get my hands on a linux-aarch64 machine to do some diagnostic runs on.

An idea for future investigation could be to make `Preconditions.checkFromIndexSize` an intrinsic similar to `Preconditions.checkIndex` - to help the compiler do the right thing with more ease and perhaps slightly faster.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3116268132

From pminborg at openjdk.org  Wed Aug 13 14:27:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Aug 2025 14:27:13 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v7]
In-Reply-To: <zyLlLnkmjBW3zpfxdAr-fTFRYZe3ovf66boXYXMqpS0=.90856711-fcf4-4c3b-8275-53b9845ca3ce@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <6jw9dOmp-h0nETyFDk89SqIcp899DWUWdZYzrt11jys=.2edf6ed5-a635-47b1-af9f-4a928891d76c@github.com>
 <9V5WzxZzQQAwJY-BAmGwmQVO72SCcnZYOZPkfRuZDFE=.352587c2-7270-40fb-9f8b-a54d1a8b783c@github.com>
 <zyLlLnkmjBW3zpfxdAr-fTFRYZe3ovf66boXYXMqpS0=.90856711-fcf4-4c3b-8275-53b9845ca3ce@github.com>
Message-ID: <VFa2Thgg1UwWPhrcj9jX6QOczn6BV_CB_KiGWunhId8=.40142abc-6bab-45f8-9745-99d2482acacf@github.com>

On Wed, 13 Aug 2025 14:18:42 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> > We have discussed the possibility of threads seeing different values, like in the above example by @eme64. We think this is ok because there are no guarantees of inter-thread visibility for memory segments. This has to be provided externally (e.g., using volatile/CAS operations). There are other cases where we are susceptible to similar problems (e.g, when doing unaligned long access). In short, segments do not fulfill all the aspects of the normal Java memory model (like for arrays).
> 
> Hmm, I see. Is this documented in the `MemorySegment` API? What are all the bad things that can happen?
> 
> * Tearing of unaligned access - can it also tear if the user has ensured alignment?
> * Repeated instructions (like the repeated copy I pointed out above).
> 
> It is of course a little surprising that you lose the Java memory model guarantees of instruction ordering if you wrap an array in a `MemorySegment`.

This is unavoidable. Consider the case where we have a wrapped `long[]` in a segment, and then we get a new `var s2 = segment.asSlice(1)` on which we operate with long semantics...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3184150135

From epeter at openjdk.org  Wed Aug 13 14:37:12 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 13 Aug 2025 14:37:12 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v7]
In-Reply-To: <zyLlLnkmjBW3zpfxdAr-fTFRYZe3ovf66boXYXMqpS0=.90856711-fcf4-4c3b-8275-53b9845ca3ce@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <6jw9dOmp-h0nETyFDk89SqIcp899DWUWdZYzrt11jys=.2edf6ed5-a635-47b1-af9f-4a928891d76c@github.com>
 <9V5WzxZzQQAwJY-BAmGwmQVO72SCcnZYOZPkfRuZDFE=.352587c2-7270-40fb-9f8b-a54d1a8b783c@github.com>
 <zyLlLnkmjBW3zpfxdAr-fTFRYZe3ovf66boXYXMqpS0=.90856711-fcf4-4c3b-8275-53b9845ca3ce@github.com>
Message-ID: <-PQ09fPeUjwPk7YpNg45rtvc3MJugGwMBFhKlWXtPFI=.0fdf0182-09e9-4a33-a9da-109b7140d722@github.com>

On Wed, 13 Aug 2025 14:18:42 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> If I see this right, it could be that we duplicate the copy on a byte. If we only copy 2 bytes, then the copy on the second byte is repeated:
>> 
>> src[0] -> dst[0]
>> src[1] -> dst[1]
>> src[1] -> dst[1]
>> 
>> But is that ok?
>> 
>> Assume we have threads 1 and 2, both access memory locations A and B:
>> 
>> // Initial state
>> A = x;
>> B = y;
>> 
>> // Concurrently:
>> 1: B = A;
>> 2: A = B + 1;
>> 
>> What states could be observed at the end? We could look at all permutations of the 4 operations from threads 1 and 2. Let's call the operations 1.1 (1 loads A), 1.2 (1 stores B), 2.1 (2 loads B), 2.2 (2 stores A).
>> These are the 4! / 4 = 6 possible permutations, together with the results for A and B:
>> 
>> 1.1 1.2 2.1 2.2 -> A = x+1; B = x
>> 1.1 2.1 1.2 2.2 -> A = y+1; B = x
>> 1.1 2.1 2.2 1.2 -> A = y+1; B = x
>> 2.1 1.1 1.2 2.2 -> A = y+1; B = x
>> 2.1 1.1 2.2 1.2 -> A = y+1; B = x
>> 2.1 2.2 1.1 1.2 -> A = y+1; B = y+1
>> 
>> Now assume we repeat the copy for thread 1. Thus, this could happen:
>> 
>> 1: B = A;
>> 2: A = B + 1;
>> 1: B = A; // repeated copy
>> 
>> And if it happens in this sequence, we get result:
>> `A = x+1; B = x+1`
>> But this result was not observable before.
>> 
>> That makes me wonder if repeating the copy is really allowed in the Java memory model?
>
>> We have discussed the possibility of threads seeing different values, like in the above example by @eme64. We think this is ok because there are no guarantees of inter-thread visibility for memory segments. This has to be provided externally (e.g., using volatile/CAS operations). There are other cases where we are susceptible to similar problems (e.g, when doing unaligned long access). In short, segments do not fulfill all the aspects of the normal Java memory model (like for arrays).
> 
> Hmm, I see. Is this documented in the `MemorySegment` API? What are all the bad things that can happen?
> - Tearing of unaligned access - can it also tear if the user has ensured alignment?
> - Repeated instructions (like the repeated copy I pointed out above).
> 
> It is of course a little surprising that you lose the Java memory model guarantees of instruction ordering if you wrap an array in a `MemorySegment`.

> > > We have discussed the possibility of threads seeing different values, like in the above example by @eme64. We think this is ok because there are no guarantees of inter-thread visibility for memory segments. This has to be provided externally (e.g., using volatile/CAS operations). There are other cases where we are susceptible to similar problems (e.g, when doing unaligned long access). In short, segments do not fulfill all the aspects of the normal Java memory model (like for arrays).
> > 
> > 
> > Hmm, I see. Is this documented in the `MemorySegment` API? What are all the bad things that can happen?
> > 
> > * Tearing of unaligned access - can it also tear if the user has ensured alignment?
> > * Repeated instructions (like the repeated copy I pointed out above).
> > 
> > It is of course a little surprising that you lose the Java memory model guarantees of instruction ordering if you wrap an array in a `MemorySegment`.
> 
> This is unavoidable. Consider the case where we have a wrapped `long[]` in a segment, and then we get a new `var s2 = segment.asSlice(1)` on which we operate with long semantics...

Absolutely, we cannot avoid tearing. At least not for unaligned access. But one might hope that aligned accesses would not tear.

I don't know enough about the details here, but it seems to me that repeating instructions is a slightly different category. It does not seem unavoidable. But maybe we are willing to do it too, so we can get out some more performance.

I suppose in the end we can do whatever we want, as long as we ensure the user can understand what the guarantees are ;)

I quickly  scanned the `MemorySegment` documentation, and I could not see anything about memory model or visibility guarantees. As a user, I now would assume that this means that the Java memory model applies. At least as long as I stay away from unaligned accesses.

Well, there is a note for `JAVA_DOUBLE_UNALIGNED`, for example:
`Care should be taken when using unaligned value layouts as they may induce performance and portability issues.`
Why not just mention tearing directly?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3184191184

From prr at openjdk.org  Wed Aug 13 18:53:29 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 13 Aug 2025 18:53:29 GMT
Subject: RFR: 8365416: java.desktop no longer needs preview feature access
Message-ID: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>

Now that Scoped Values is no longer preview, the desktop module does not need the entry in the base module-info.java

-------------

Commit messages:
 - 8365416

Changes: https://git.openjdk.org/jdk/pull/26765/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26765&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365416
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26765.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26765/head:pull/26765

PR: https://git.openjdk.org/jdk/pull/26765

From jlu at openjdk.org  Wed Aug 13 20:47:21 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Aug 2025 20:47:21 GMT
Subject: RFR: 8364781: Re-examine DigitList digits resizing during parsing
 [v2]
In-Reply-To: <UBP3my1TDFYTza7tEbJYZIa_z0sAAPI_X7HLpQNEAmU=.1019b10f-3440-4781-8b33-f2aa7c2df942@github.com>
References: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
 <UBP3my1TDFYTza7tEbJYZIa_z0sAAPI_X7HLpQNEAmU=.1019b10f-3440-4781-8b33-f2aa7c2df942@github.com>
Message-ID: <9C8aDI-jY-4b2MFpIU9KDb7zJjczyrB0Hp8-QoVMhGk=.25310bca-5bc7-4ce6-9510-73f849e5876f@github.com>

On Fri, 8 Aug 2025 23:28:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR changes the DigitList resizing from adding increments of 100 to a doubling resizing approach. This helps with performance of larger String values during `DecimalFormat` parsing. See the comment on the associated JBS issue for further detail.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen review - replace with ArraysSupport

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26705#issuecomment-3185711520

From jlu at openjdk.org  Wed Aug 13 20:47:22 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Aug 2025 20:47:22 GMT
Subject: Integrated: 8364781: Re-examine DigitList digits resizing during
 parsing
In-Reply-To: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
References: <RdbK_G8qYvastg0THmbV8ytsUkQmLrPN7ACs8Gtd6Jw=.f38d724c-150b-4eff-aea7-8ae8d2847d3c@github.com>
Message-ID: <MHrdB0tNLxvYGUY-g1cpW4_iNMk8N14AY4bSkKlInJE=.d2296588-b4dd-4fee-8621-b06297a78a5f@github.com>

On Fri, 8 Aug 2025 20:46:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR changes the DigitList resizing from adding increments of 100 to a doubling resizing approach. This helps with performance of larger String values during `DecimalFormat` parsing. See the comment on the associated JBS issue for further detail.

This pull request has now been integrated.

Changeset: 96603200
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9660320041d0ba0f22ebe074a64472557b85a24c
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8364781: Re-examine DigitList digits resizing during parsing

Reviewed-by: liach, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/26705

From redestad at openjdk.org  Wed Aug 13 23:23:10 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 13 Aug 2025 23:23:10 GMT
Subject: RFR: 8364319: Move java.lang.constant.AsTypeMethodHandleDesc to
 jdk.internal
In-Reply-To: <mfrVbVcScpwmdWcGnFiabumfpIhI1wLse_FAHPJ7qRY=.2ed0cfcc-cd5a-4de0-b77b-f41a178912e5@github.com>
References: <mfrVbVcScpwmdWcGnFiabumfpIhI1wLse_FAHPJ7qRY=.2ed0cfcc-cd5a-4de0-b77b-f41a178912e5@github.com>
Message-ID: <VzGCzV9ThOgJ7AhkABrp210qfVPq6FRlG8C5DaFojA4=.1e26de3a-65c1-44cb-80a0-07ea15adb3e8@github.com>

On Tue, 29 Jul 2025 21:40:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> java.lang.constant.AsTypeMethodHandleDesc is an implementation class for the Constant API. It was omitted in the move probably because its name does not end with Impl. We should move it to the implementation package instead.

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26542#pullrequestreview-3117979936

From alanb at openjdk.org  Thu Aug 14 06:17:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Aug 2025 06:17:10 GMT
Subject: RFR: 8365416: java.desktop no longer needs preview feature access
In-Reply-To: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
References: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
Message-ID: <stwJjC3JCXrlRawcPWgha2Lpq64Hfv0wdOoe3_QY4p4=.21926bad-0f02-4de0-b638-0751d449c875@github.com>

On Wed, 13 Aug 2025 18:47:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Now that Scoped Values is no longer preview, the desktop module does not need the entry in the base module-info.java

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26765#pullrequestreview-3119157986

From jpai at openjdk.org  Thu Aug 14 08:00:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 08:00:13 GMT
Subject: RFR: 8365416: java.desktop no longer needs preview feature access
In-Reply-To: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
References: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
Message-ID: <ySVqQXNPc3Q15lGGqv_zec9pcF-c2ue1KlrMSF_4QPg=.ce72d2a7-7c6f-41d0-a449-de975543b1ed@github.com>

On Wed, 13 Aug 2025 18:47:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Now that Scoped Values is no longer preview, the desktop module does not need the entry in the base module-info.java

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26765#pullrequestreview-3119439209

From ghan at openjdk.org  Thu Aug 14 08:35:21 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 14 Aug 2025 08:35:21 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning after
 JDK-8364611
Message-ID: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>

This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
- bits/types/__sigset_t.h 
<img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />


- sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
<img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />


During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.

we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.

-------------

Commit messages:
 - 8365296: Build failure with Clang due to -Wformat warning after JDK-8364611

Changes: https://git.openjdk.org/jdk/pull/26771/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26771&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365296
  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26771/head:pull/26771

PR: https://git.openjdk.org/jdk/pull/26771

From ghan at openjdk.org  Thu Aug 14 09:01:54 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 14 Aug 2025 09:01:54 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v2]
In-Reply-To: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
Message-ID: <9WHpzNFxdghHLnEU2AAqLBzXrbHJzrdyOYwKVxTXh3k=.25b1b528-ee15-4566-ba69-4392daf67565@github.com>

> This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
> - bits/types/__sigset_t.h 
> <img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />
> 
> 
> - sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
> <img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />
> 
> 
> During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.
> 
> we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  Update exePrintSignalDisposition.c
  
  a small fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26771/files
  - new: https://git.openjdk.org/jdk/pull/26771/files/b6f672b5..207cc292

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26771&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26771&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26771/head:pull/26771

PR: https://git.openjdk.org/jdk/pull/26771

From duke at openjdk.org  Thu Aug 14 09:07:50 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 09:07:50 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not present
Message-ID: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>

Switched from TestSkippedException (not honoured by JUnit) to TestAbortedException (via Assumptions class) to avoid false negative test "failure". Note that now, the test is either shown as skipped, or passed, depending on which report is being looked at. Tweaked error message slightly since using an "exploded image" isn't the only cause.

-------------

Commit messages:
 - Remove unused imports.
 - Change how test is skipped to avoid false negative reporting.

Changes: https://git.openjdk.org/jdk/pull/26773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365436
  Stats: 14 lines in 1 file changed: 8 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26773/head:pull/26773

PR: https://git.openjdk.org/jdk/pull/26773

From alanb at openjdk.org  Thu Aug 14 09:24:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Aug 2025 09:24:13 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
References: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
Message-ID: <BlaLP1DQhf59cWGcy1onrexMPoilOtzuLkN10143p9k=.cb63c8e7-4a92-4025-b9a5-deef492a0069@github.com>

On Thu, 14 Aug 2025 09:00:24 GMT, David Beaumont <duke at openjdk.org> wrote:

> Switched from TestSkippedException (not honoured by JUnit) to TestAbortedException (via Assumptions class) to avoid false negative test "failure". Note that now, the test is either shown as skipped, or passed, depending on which report is being looked at. Tweaked error message slightly since using an "exploded image" isn't the only cause.

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 227:

> 225:         // This may be reporting as a skipped test, or a pass, depending
> 226:         // on how the test was run.
> 227:         Assumptions.assumeTrue(helper != null, "Cannot create test helper (no jimage file)");

There is a jimage file,  Helper.newHelper is returning null because there are no packaged modules in the runtime image (= no jmods directory).

In passing, tests.Helper is the supporting class for the jlink tests. We should rename it or creating a sub-directory in test/jdk/tools/lib/tests as the location/naming just won't work for this very specific class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26773#discussion_r2276063025

From duke at openjdk.org  Thu Aug 14 09:41:14 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 09:41:14 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not present
Message-ID: <Z0wp3YXswTbBWBV5NhqOC8G6QlVBPgClqCzTNXsHcVU=.1777816a-4066-4dab-a030-c0c8bf3c1097@github.com>

Changed test helper creation to know about linkable images, and changed how test skipping is reported (JUnit doesn't honor TestSkippedException, only TestAbortedException).

-------------

Commit messages:
 - Make test helper aware of linkable images, and fix how test skipping occurs.

Changes: https://git.openjdk.org/jdk/pull/26774/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365436
  Stats: 12 lines in 1 file changed: 6 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26774/head:pull/26774

PR: https://git.openjdk.org/jdk/pull/26774

From sgehwolf at openjdk.org  Thu Aug 14 09:54:13 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Aug 2025 09:54:13 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
References: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
Message-ID: <DE8DBu5jH0Gt3_dZM69mv88JD_V7CJkPXxbYIII3ChY=.4114e4d1-87c4-4f3e-8f38-627097ba96cd@github.com>

On Thu, 14 Aug 2025 09:00:24 GMT, David Beaumont <duke at openjdk.org> wrote:

> Switched from TestSkippedException (not honoured by JUnit) to TestAbortedException (via Assumptions class) to avoid false negative test "failure". Note that now, the test is either shown as skipped, or passed, depending on which report is being looked at. Tweaked error message slightly since using an "exploded image" isn't the only cause.

I'd suggest to make the test run on as many scenarios as possible. This patch seems to work for me on a JEP 493-enabled build:


diff --git a/test/jdk/jdk/internal/jimage/ImageReaderTest.java b/test/jdk/jdk/internal/jimage/ImageReaderTest.java
index 62281151126..14c5f8eac21 100644
--- a/test/jdk/jdk/internal/jimage/ImageReaderTest.java
+++ b/test/jdk/jdk/internal/jimage/ImageReaderTest.java
@@ -25,6 +25,7 @@
 import jdk.internal.jimage.ImageReader.Node;
 import jdk.test.lib.compiler.InMemoryJavaCompiler;
 import jdk.test.lib.util.JarBuilder;
+import jdk.tools.jlink.internal.LinkableRuntimeImage;
 import org.junit.jupiter.api.Assumptions;
 import org.junit.jupiter.api.Test;
 import org.junit.jupiter.api.TestInstance;
@@ -55,6 +56,7 @@
  * @summary Tests for ImageReader.
  * @modules java.base/jdk.internal.jimage
  *          jdk.jlink/jdk.tools.jimage
+ *          jdk.jlink/jdk.tools.jlink.internal
  * @library /test/jdk/tools/lib
  *          /test/lib
  * @build tests.*
@@ -216,7 +218,8 @@ public String toString() {
     private static Helper getHelper() {
         Helper helper;
         try {
-            helper = Helper.newHelper();
+            boolean isLinkableRuntime = LinkableRuntimeImage.isLinkableRuntime();
+            helper = Helper.newHelper(isLinkableRuntime);
         } catch (IOException e) {
             throw new RuntimeException(e);
         }


The comments seem wrong as Alan pointed out.

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 219:

> 217:         Helper helper;
> 218:         try {
> 219:             helper = Helper.newHelper();

Suggestion:

            boolean isLinkableRuntime = LinkableRuntimeImage.isLinkableRuntime();
            helper = Helper.newHelper(isLinkableRuntime);


This will make the test run (not abort) for JEP 493-enabled builds.

-------------

Changes requested by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26773#pullrequestreview-3119903344
PR Review Comment: https://git.openjdk.org/jdk/pull/26773#discussion_r2276140933

From ihse at openjdk.org  Thu Aug 14 09:57:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:57:14 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <VLEgFaeir6ZFohN9Htx5dB1GXkEQiavrlbmp-8y_4ow=.213bb36b-5a36-45fb-acb0-cb164d70eef1@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
 <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>
 <Tw5maFbJaPI5q0x-o44DqHICHN-dvxUQyUGaW4IbCLU=.abca2f27-d43f-48bd-9b92-c950002dbf0e@github.com>
 <A71apIJFIXpdfoYfRLzA4q3qLNvmvj0A8_sQHqTpCBU=.bfeb0c07-3ce7-45e7-9cbd-3a6abb767756@github.com>
 <J6-ABR3b34n5S3W1zHMSr_TxRNAnRioKaN6oIZljRuo=.4f116d02-f16e-4b43-9f07-63207cba38e0@github.com>
 <VLEgFaeir6ZFohN9Htx5dB1GXkEQiavrlbmp-8y_4ow=.213bb36b-5a36-45fb-acb0-cb164d70eef1@github.com>
Message-ID: <vDnzZGlusvloG4xLlr3ImY7SB2Tkt22rVaeHuthBtDk=.c2fa65b8-3078-493c-b6eb-b7c5e64baeb4@github.com>

On Mon, 11 Aug 2025 17:20:30 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This solution was modeled on how we create `module-included-libs.txt`. I agree that it is a bit hacky to inject this kind of stuff in ModuleWrapper, but I can't see how we can do it more cleanly. That's the only point at which we know the entire module for a phase. 
>> 
>> Maybe we can improve optics by doing a more official-looking "hook" for injecting functionality at pre-/post- whole-module processing? That would keep ModuleWrapper slimmer and without all the current specialized hooks, and make the name "wrapper" more relevant.
>> 
>> Or, we could rename the makefile to indicate better that it does a lot more than just wraps a file. (I have no good suggestions right now.)
>
> I'm not sure what you mean here. I described a solution that keeps it in LauncherCommon without creating races.

Aha, now I understand what you mean! My mind slipped -- I read `LauncherCommon.gmk` but thought `SetupBuildLauncher`. But you mean just store it in the top-level of the actual makefile that is included by all launchers. Yeah, that could definitely work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2276155249

From mcimadamore at openjdk.org  Thu Aug 14 09:58:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Aug 2025 09:58:15 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v8]
In-Reply-To: <_Ompbh3_hc6yPqt7KvbiuZVMJ9m7NoYNKIR_szqG62A=.59147014-db31-4296-8469-f107b6e677a9@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <_Ompbh3_hc6yPqt7KvbiuZVMJ9m7NoYNKIR_szqG62A=.59147014-db31-4296-8469-f107b6e677a9@github.com>
Message-ID: <PFA4Ggb2102xVsz5Zn5zCDmLK_4M-U8N_Cu4zRYdnK0=.db22b448-5376-4e10-9adb-5ceb8184e2de@github.com>

On Wed, 13 Aug 2025 14:14:30 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Break out the default branch

There's a couple of caveats when it comes to FFM and memory model. As observed, a memory segment can wrap a Java array. Now, if access to the memory segment uses a layout that matches the array element/alignment, all the standard JMM guarantees apply.

That said, once you have a segment wrapping, say a `long[]`, you can also do "partial reads/writes" -- e.g. you can only read parts of a `long` element. This is the "new" thing, and something for which we're considering adding some extra javadoc text:

https://bugs.openjdk.org/browse/JDK-8357630

(We have some candidate text discussed with John Rose).

The reverse can also happen -- e.g. if a segment wraps a `byte[]` it is possible to read multiple element at once, by e.g. reading an int layout. But this could already happen with the `ByteBuffer` API, so nothing new here.

Of course mis-aligned access can result in more partial read/writes -- e.g. an unaligned 8 byte access can be implemented as two 4-byte partial accesses, or a 4 byte partial access, followed by 2 byte partial access, followed by two 1-byte partial accesses (or any other combination). What you get here is unspecified.

All this said, I believe the question @eme64 is asking has more to do with `MemorySegment::copy` -- e.g. what kind of guarantees do we want to provide here? Should `copy` have the same semantics as a loop that moves bytes from one segment to another element-wise? If so, then we have a problem (as pointed out): the fact that the new implementation sometimes rewrites certain portions of the destination segments might create some semantics differences, esp. when it comes to visibility of updates in other threads. E.g. replacing a for loop with `MemorySegment::copy` might not always work as expected.

IMHO this is up to the javadoc for `MemorySegment::copy` (and other related bulk operations) to decide. E.g. while it would be nice if we could just say that updating a segment with a bulk operation has exactly the same semantics as updating the segment with a loop, we might need to relax things if we want to let free rein to the implementation to do more smarts.

And, in the specific context of this PR, we would have to weight as to whether adding the extra javadoc clarification (and subsequent additional user model complexity) is worth shaving half a nanosecond off the bulk copy. My general feeling is that the long term strategy here is to wait until we have better autovectorization support and/or vector API integrated, at which point we can replace all this with much more idiomatic code? (If so, then perhaps there isn't a lot of value in chasing smaller improvements in the interim?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3187850721

From mcimadamore at openjdk.org  Thu Aug 14 10:30:17 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Aug 2025 10:30:17 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v6]
In-Reply-To: <O9bCL7wLHTR3djQcZ3nVbo1abh4oBjbqFm5-9sY2jtk=.bcc93990-1400-460d-9377-65fd4435aed4@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
 <O9bCL7wLHTR3djQcZ3nVbo1abh4oBjbqFm5-9sY2jtk=.bcc93990-1400-460d-9377-65fd4435aed4@github.com>
Message-ID: <gZpglW4fGe9pflR2_WxltJX3kgvcNHJNGxHfzaZhnC4=.8cfcbc55-f68a-4d43-ae82-8ab10bba92f4@github.com>

On Tue, 5 Aug 2025 11:31:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Add a top-level section on string conversion
>  - Merge branch 'master' into ms-getstrings-boundary-doc
>  - Remove imp note
>  - Add text on N octets
>  - Improve wording
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update after comments
>  - Add info for multi-octet Charsets

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 410:

> 408:  * boolean isAligned = segment.maxByteAlignment() >= layout.byteAlignment();
> 409:  * }
> 410:  * <h2 id="string-conversion">String conversion</h2>

I'd experiment adding this at the end of the section "Accessing memory segments" -- since this is really about memory segment access.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1325:

> 1323:      * @param charset the charset used to {@linkplain Charset#newDecoder() decode} the
> 1324:      *                string bytes. The {@code charset} must be a
> 1325:      *                {@linkplain StandardCharsets standard charset} as described

I believe `allocateFrom` in SegmentAllocator can benefit from a similar treatment?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25715#discussion_r2276229622
PR Review Comment: https://git.openjdk.org/jdk/pull/25715#discussion_r2276230458

From jpai at openjdk.org  Thu Aug 14 10:42:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 10:42:26 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
Message-ID: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>

Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.

These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.

tier1, tier2 and tier3 testing of this change completed without any related failures.

-------------

Commit messages:
 - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

Changes: https://git.openjdk.org/jdk/pull/26776/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26776&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365533
  Stats: 27 lines in 7 files changed: 0 ins; 22 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26776/head:pull/26776

PR: https://git.openjdk.org/jdk/pull/26776

From duke at openjdk.org  Thu Aug 14 11:25:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 11:25:00 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
Message-ID: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>

Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
Tested locally in a worktree and normal repository. It produces:

 <component name="VcsDirectoryMappings">
    <mapping directory="$PROJECT_DIR$" vcs="Git" />
    <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
  </component>

in both cases, as expected.

-------------

Commit messages:
 - Simple fix (just checking file)

Changes: https://git.openjdk.org/jdk/pull/26777/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26777&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365048
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26777/head:pull/26777

PR: https://git.openjdk.org/jdk/pull/26777

From vklang at openjdk.org  Thu Aug 14 11:33:12 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 14 Aug 2025 11:33:12 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
Message-ID: <ySIGhdiBrALkO-l-XRHVVFR0WiQwlqbtjqzeemKrtwE=.a51312a7-afb1-4161-9b02-340daea2492e@github.com>

On Thu, 7 Aug 2025 14:03:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid underutilization on resize

src/java.base/share/classes/java/util/concurrent/Exchanger.java line 380:

> 378:                                   (!ForkJoinWorkerThread.hasKnownQueuedWork()))) {
> 379:                             for (int j = SPINS; p.match == null && j > 0; --j)
> 380:                                 Thread.onSpinWait();

It might not be worth it, but I wonder if something like this would make a positive impact:

Suggestion:

                        if (!(tryCancel = (deadline != 0L &&
                             (ns = deadline - System.nanoTime()) <= 0L) ||
                            Thread.currentThread().isInterrupted()))
                            && ncpu > 1 &&
                             (i != 0 || /* check for busy VTs */ (!ForkJoinWorkerThread.hasKnownQueuedWork()))) {
                            for (int j = SPINS; p.match == null && j > 0; --j)
                                Thread.onSpinWait();

src/java.base/share/classes/java/util/concurrent/Exchanger.java line 408:

> 406:                             if (Thread.interrupted())
> 407:                                 throw new InterruptedException();
> 408:                             if (deadline != 0L && ns <= 0L)

Is the reasoning here that `deadline` cannot be == 0L, or that it doesn't matter anymore if it is?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2276356973
PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2276362959

From vklang at openjdk.org  Thu Aug 14 11:37:13 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 14 Aug 2025 11:37:13 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
Message-ID: <kLQkjXp1Gx_CVTw_Ba5NlPpbcL8lIDiCDzYrxfRsQU0=.61d71450-2569-48e7-b6cb-1a35189b2bff@github.com>

On Thu, 7 Aug 2025 14:03:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid underutilization on resize

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1290:

> 1288:                     if (room == 0) {                        // resize
> 1289:                         growArray(a, cap, s);
> 1290:                         a = null;

Suggestion:

                        a = null;  // Indicate resize to trigger signalling

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2276372414

From vklang at openjdk.org  Thu Aug 14 11:44:13 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 14 Aug 2025 11:44:13 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v5]
In-Reply-To: <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
 <xANjsW2f2AVKPmiVv0sLdjhOGmZlvXFB75fPDHUNd5k=.b9cab189-6826-4d3f-8333-9e6504d22a13@github.com>
Message-ID: <Jth4ObCHaW6nh8I97IiuZVlS2RYNDdylk-t2w0JzCb0=.6757f349-5045-4043-b8f2-77d9e1191431@github.com>

On Thu, 7 Aug 2025 14:03:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid underutilization on resize

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2072:

> 2070:                     p = awaitWork(w, p);      // block, drop, or exit
> 2071:             }
> 2072:         }

@DougLea if `w != null` is always expected to be `true`, it might make sense to throw some form of exception in case it actually is. Possibly an assertion?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2276387045

From kfarrell at openjdk.org  Thu Aug 14 11:47:15 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 14 Aug 2025 11:47:15 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v13]
In-Reply-To: <ocW9CVM3lNYmfK2thvLhuUU3ln6skBZXHaNZ7SZ-RgU=.e425fe03-25cb-428b-ad06-b96afa3ae95b@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <ocW9CVM3lNYmfK2thvLhuUU3ln6skBZXHaNZ7SZ-RgU=.e425fe03-25cb-428b-ad06-b96afa3ae95b@github.com>
Message-ID: <Dt7XDkBYn0h3HGoGijt8k_MVenAaNsww6rWlxX1mzqU=.60d14d64-c15a-45ca-8ba3-32a23d41849e@github.com>

On Thu, 3 Jul 2025 08:47:20 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 <strong> note to @api note

Hi All, Would it be possible to progress review with this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3188158662

From jpai at openjdk.org  Thu Aug 14 11:52:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 11:52:15 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v13]
In-Reply-To: <ocW9CVM3lNYmfK2thvLhuUU3ln6skBZXHaNZ7SZ-RgU=.e425fe03-25cb-428b-ad06-b96afa3ae95b@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <ocW9CVM3lNYmfK2thvLhuUU3ln6skBZXHaNZ7SZ-RgU=.e425fe03-25cb-428b-ad06-b96afa3ae95b@github.com>
Message-ID: <Rpt33nSHWmHqEb9ZX2NOvZdr5ALlRk5qibW_RBd4Qpg=.80dc1e68-3c38-409c-ace6-f840554082a4@github.com>

On Thu, 3 Jul 2025 08:47:20 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 <strong> note to @api note

Hello Kieran,

> Hi All, Would it be possible to progress review with this?

I haven't been able to check and respond to your updates, sorry about that. I'll need at least a few more days to come back to this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3188171079

From vyazici at openjdk.org  Thu Aug 14 12:03:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 14 Aug 2025 12:03:12 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <KQrIZQoqb2FdLu7i6eUCI0fzR_cBDr_XQliY28KlVxE=.3be8aad2-e1c5-4056-8ccc-b3ea81e9fe29@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3120319106

From duke at openjdk.org  Thu Aug 14 12:04:14 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 14 Aug 2025 12:04:14 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <RwfKP5KO_jRS4HxRMRu_pfbiNJahmrRc9q8qMybEaiU=.8319ef07-772d-4817-8e5f-b88fd887afa1@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

See?also <https://github.com/openjdk/jdk/pull/26765> ([JDK?8365416])

[JDK?8365416]: https://bugs.openjdk.org/browse/JDK-8365416 "[JDK?8365416] java.desktop no?longer?needs preview?feature?access"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3188202824

From jpai at openjdk.org  Thu Aug 14 12:23:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 12:23:12 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <R-Hw3-g5SjEVgWmyAGyXJ2HrKh9MyDgcfuMvU9erYsk=.65b03c56-5e97-4de4-a3fc-639ffb8195e5@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

> See also #26765 ([JDK?8365416](https://bugs.openjdk.org/browse/JDK-8365416))

Right, that's what prompted me to start looking into this. The java.desktop change for which that other PR is open can go ahead independently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3188258941

From mbaesken at openjdk.org  Thu Aug 14 12:39:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Aug 2025 12:39:19 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v2]
In-Reply-To: <9WHpzNFxdghHLnEU2AAqLBzXrbHJzrdyOYwKVxTXh3k=.25b1b528-ee15-4566-ba69-4392daf67565@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <9WHpzNFxdghHLnEU2AAqLBzXrbHJzrdyOYwKVxTXh3k=.25b1b528-ee15-4566-ba69-4392daf67565@github.com>
Message-ID: <OoNIfVrcKWL2F4m8AacjIjZWBmKxkAJhV3GC1t3GVPw=.6c433837-29a0-459c-ba08-36377201c18f@github.com>

On Thu, 14 Aug 2025 09:01:54 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
>> - bits/types/__sigset_t.h 
>> <img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />
>> 
>> 
>> - sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
>> <img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />
>> 
>> 
>> During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.
>> 
>> we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update exePrintSignalDisposition.c
>   
>   a small fix

Seems there is also coding in os_posix.cpp ( describe_signal_set_short ) to print signal information , maybe 'borrow' from there?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26771#issuecomment-3188304551

From erikj at openjdk.org  Thu Aug 14 12:57:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Aug 2025 12:57:12 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <Tac0Dr70VGxF7RQrYpvPLs6_1CuhX7pnom8ygwZDIC4=.78e6ae25-dcf1-442a-a95a-7551eed0a0f8@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3120484397

From duke at openjdk.org  Thu Aug 14 13:04:20 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Thu, 14 Aug 2025 13:04:20 GMT
Subject: RFR: 8360575: java.util.Properties.list() methods trim each value
 to 37 characters in the listed output [v4]
In-Reply-To: <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
References: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
 <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
Message-ID: <tySxlCrQnvH18Oxo42GoJGiao4ameeWV7lJbF4TW_4I=.054d6840-d1c2-4f43-b94f-dcb0960c93e3@github.com>

On Mon, 30 Jun 2025 06:01:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clarify the current implementation of the `java.util.Properties.list(...)` methods?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current implementation trims each value to a size of 37 when printing out the value. This behaviour isn't documented by these methods. The change in this PR adds an `@implNote` to make a mention of this current behaviour.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - no need to state the number of characters

For completeness sake, here was the example I was thinking:

````props.stringPropertyNames().forEach(e-> out.println(e + '=' + props.getProperty(e)));````

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26018#issuecomment-3188369861

From duke at openjdk.org  Thu Aug 14 13:55:07 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 14 Aug 2025 13:55:07 GMT
Subject: RFR: 8077587: BigInteger Roots [v68]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <K3eOX6924Ti8cBqOHWOaRXIIY64ZVjU-4vj3g2mtbtk=.50c186c9-7258-4731-b41d-26e8016d4450@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  An optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/20f71485..d038106b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=67
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=66-67

  Stats: 12 lines in 1 file changed: 5 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From mcimadamore at openjdk.org  Thu Aug 14 14:09:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Aug 2025 14:09:15 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <GuDQS-KY1JxK-inCuq2nUpzwHmlv2enJECfNpvtFqG8=.575786b8-3aed-425c-88ab-14a89f18f1ff@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3120743925

From duke at openjdk.org  Thu Aug 14 14:11:20 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 14 Aug 2025 14:11:20 GMT
Subject: RFR: 8077587: BigInteger Roots [v69]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <DnRlvJltKuMjejW-qhzogTdOCZ2oC5u39v1a2-yfInU=.9679809c-05f7-4baf-b806-1487e0f78df6@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refine comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/d038106b..2af18f6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=68
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=67-68

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From asemenyuk at openjdk.org  Thu Aug 14 14:12:26 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 14 Aug 2025 14:12:26 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation
Message-ID: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>

- Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
 - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
 - Add tests for PackagingPipeline class.
 - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
 - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
 - Add tests for BuildEnv class.

-------------

Commit messages:
 - ResourceLocator: make ctor private. This class is not supposed to be instantiated. Improves the coverage.
 - Add a test case to JavaAppDescTest
 - MacDmgPackageBuilder: remove unused variable
 - Use MacBundle with AppImageSigner
 - BuildEnvFromParams: bugfix
 - Rename RuntimeBuilder.createRuntime() to RuntimeBuilder.create()
 - Test for PackagingPipeline
 - Get rid of AppImageDesc. It became redundant when AppImageLayout.rootDirectory() was added. Support using an external app image with a custom app image layout. Add ApplicationBuilder.overrideAppImageLayout(). Remove Package.packageLayout() and Package.asPackageApplicationLayout(). Create Linux and Mac packages with app image layout configured for packaging making PackagingPipeline.Builder.appImageLayoutForPackaging() redundant. Simplify PackagingPipeline. It always builds with application's app image layout. Don't wrap RuntimeException-s in PackagerException-s. Merge PackagingPipeline.appContextMapper and PackagingPipeline.pkgContextMapper into PackagingPipeline.contextMapper. Remove PackagingPipeline.Builder.appImageLayoutForPackaging(). Add MacPackage.guessRuntimeLayout()
 - Implementation Tweaks #1
 - Support custom runtime image layout in BuildEnvFromParams. Support custom runtime image layout for application in FromParams.createApplicationBuilder(). Set correct layout for predefined runtime image on macosx
 - ... and 6 more: https://git.openjdk.org/jdk/compare/8ad1fcc4...0d2b451e

Changes: https://git.openjdk.org/jdk/pull/26778/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26778&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365555
  Stats: 2353 lines in 55 files changed: 1914 ins; 229 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/26778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26778/head:pull/26778

PR: https://git.openjdk.org/jdk/pull/26778

From duke at openjdk.org  Thu Aug 14 14:13:47 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 14 Aug 2025 14:13:47 GMT
Subject: RFR: 8077587: BigInteger Roots [v70]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <M-dV4FvagLRUmaB6NshXc8TTlh_lvHmS0lh1GfrteSY=.f507a69d-9c40-40b1-befd-46096c992338@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refine comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/2af18f6c..2db18698

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=69
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=68-69

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From shade at openjdk.org  Thu Aug 14 14:57:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 14:57:14 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <jVfpvG27-Jqynp0FoWk-MJV6wtCj8dy8n5qkYy4KlPE=.d4306e1e-1f7e-4310-8db2-1d87c4c229b7@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

bin/idea.sh line 128:

> 126: fi
> 127: 
> 128: # Git workstrees use a '.git' file rather than directory, so test both.

Suggestion:

# Git worktrees use a '.git' file rather than directory, so test both.


Right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26777#discussion_r2276874741

From duke at openjdk.org  Thu Aug 14 15:05:05 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 14 Aug 2025 15:05:05 GMT
Subject: RFR: 8077587: BigInteger Roots [v71]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <J9j1wW2DZC9pOx9ecwuRLJmNvMcsEXwMT97lyxn2TVQ=.b974a6eb-f1c8-46c1-99d5-61330d0c8d40@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refine comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/2db18698..ec4f7c1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=70
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=69-70

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Thu Aug 14 15:10:46 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 14 Aug 2025 15:10:46 GMT
Subject: RFR: 8077587: BigInteger Roots [v72]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <woHoTcYEejSgYi4LIM3eNlvS_R8SIPK4GYrEeyCzHT0=.bba381df-7d24-424a-a0d8-6a75f4523733@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refine comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/ec4f7c1b..908b6915

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=71
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=70-71

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Thu Aug 14 15:12:53 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 15:12:53 GMT
Subject: RFR: 8365532: java/lang/module/ModuleReader/ModuleReaderTest.testImage
 fails
Message-ID: <WCIv2h-8dZtKz3FXHGxWZFufj__WYywc6tCmIyjsUwE=.e74cbaae-fbe5-45a5-bde0-d19f6aaba3cb@github.com>

This should fix this issue and locally fixes the test() method in:

test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java

which does:

--------
            // test nulls
            try {
                reader.find(null);
                assertTrue(false);
            } catch (NullPointerException expected) { }
--------

-------------

Commit messages:
 - Restore null pointer check

Changes: https://git.openjdk.org/jdk/pull/26780/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26780&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365532
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26780.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26780/head:pull/26780

PR: https://git.openjdk.org/jdk/pull/26780

From duke at openjdk.org  Thu Aug 14 15:15:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 15:15:17 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <jVfpvG27-Jqynp0FoWk-MJV6wtCj8dy8n5qkYy4KlPE=.d4306e1e-1f7e-4310-8db2-1d87c4c229b7@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
 <jVfpvG27-Jqynp0FoWk-MJV6wtCj8dy8n5qkYy4KlPE=.d4306e1e-1f7e-4310-8db2-1d87c4c229b7@github.com>
Message-ID: <zXySn_76sMfkGuhGCwbLv9OemiCpiS7hGcy1knVe3NY=.8d9fc163-f859-444d-838c-20e6b8daebc7@github.com>

On Thu, 14 Aug 2025 14:54:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
>> Tested locally in a worktree and normal repository. It produces:
>> 
>>  <component name="VcsDirectoryMappings">
>>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>>   </component>
>> 
>> in both cases, as expected.
>
> bin/idea.sh line 128:
> 
>> 126: fi
>> 127: 
>> 128: # Git workstrees use a '.git' file rather than directory, so test both.
> 
> Suggestion:
> 
> # Git worktrees use a '.git' file rather than directory, so test both.
> 
> 
> Right?

*doh* - thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26777#discussion_r2276919398

From ihse at openjdk.org  Thu Aug 14 15:15:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 15:15:15 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <HWbdhM5b-mqbKf5BeUHYSD8XyZksjZmcMnmlBabx518=.b610199e-6fea-4d35-bf54-0c872578bf23@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

LGTM, if you fix the typo in the comment.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3120977831

From duke at openjdk.org  Thu Aug 14 15:21:29 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 15:21:29 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees [v2]
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26777/files
  - new: https://git.openjdk.org/jdk/pull/26777/files/582a0143..307574fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26777&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26777&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26777/head:pull/26777

PR: https://git.openjdk.org/jdk/pull/26777

From prr at openjdk.org  Thu Aug 14 15:24:18 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Aug 2025 15:24:18 GMT
Subject: Integrated: 8365416: java.desktop no longer needs preview feature
 access
In-Reply-To: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
References: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
Message-ID: <K63_x5VIjPJHgWAEOSsrtznQ6z8Jeprm_RETLeNO8-c=.bd16c26f-d079-4bf6-9e4b-6c8e14cdbd85@github.com>

On Wed, 13 Aug 2025 18:47:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Now that Scoped Values is no longer preview, the desktop module does not need the entry in the base module-info.java

This pull request has now been integrated.

Changeset: b0f98df7
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0f98df75aee1e94a8c4b3eb8d0b1f4e715011ae
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8365416: java.desktop no longer needs preview feature access

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/26765

From duke at openjdk.org  Thu Aug 14 15:33:16 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 15:33:16 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <DE8DBu5jH0Gt3_dZM69mv88JD_V7CJkPXxbYIII3ChY=.4114e4d1-87c4-4f3e-8f38-627097ba96cd@github.com>
References: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
 <DE8DBu5jH0Gt3_dZM69mv88JD_V7CJkPXxbYIII3ChY=.4114e4d1-87c4-4f3e-8f38-627097ba96cd@github.com>
Message-ID: <ulSxglbto4gxQM-dHzbJG1bVVAkgf6YvWy48daBJu5Q=.5ee0094d-1ca2-48ef-af5f-6b20059fd8f4@github.com>

On Thu, 14 Aug 2025 09:49:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Switched from TestSkippedException (not honoured by JUnit) to TestAbortedException (via Assumptions class) to avoid false negative test "failure". Note that now, the test is either shown as skipped, or passed, depending on which report is being looked at. Tweaked error message slightly since using an "exploded image" isn't the only cause.
>
> test/jdk/jdk/internal/jimage/ImageReaderTest.java line 219:
> 
>> 217:         Helper helper;
>> 218:         try {
>> 219:             helper = Helper.newHelper();
> 
> Suggestion:
> 
>             boolean isLinkableRuntime = LinkableRuntimeImage.isLinkableRuntime();
>             helper = Helper.newHelper(isLinkableRuntime);
> 
> 
> This will make the test run (not abort) for JEP 493-enabled builds.

Yes, this was done for https://github.com/openjdk/jdk/pull/26774/files once I knew about it and could patch in the  extra modules line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26773#discussion_r2276973796

From duke at openjdk.org  Thu Aug 14 15:33:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 15:33:18 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <BlaLP1DQhf59cWGcy1onrexMPoilOtzuLkN10143p9k=.cb63c8e7-4a92-4025-b9a5-deef492a0069@github.com>
References: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
 <BlaLP1DQhf59cWGcy1onrexMPoilOtzuLkN10143p9k=.cb63c8e7-4a92-4025-b9a5-deef492a0069@github.com>
Message-ID: <BbMxprAX6qONv7BuPfbd_1DGqP4dXLkplQ8At-QxoiI=.2ab8b1a0-471c-47a7-81a7-fbd184752773@github.com>

On Thu, 14 Aug 2025 09:21:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Switched from TestSkippedException (not honoured by JUnit) to TestAbortedException (via Assumptions class) to avoid false negative test "failure". Note that now, the test is either shown as skipped, or passed, depending on which report is being looked at. Tweaked error message slightly since using an "exploded image" isn't the only cause.
>
> test/jdk/jdk/internal/jimage/ImageReaderTest.java line 227:
> 
>> 225:         // This may be reporting as a skipped test, or a pass, depending
>> 226:         // on how the test was run.
>> 227:         Assumptions.assumeTrue(helper != null, "Cannot create test helper (no jimage file)");
> 
> There is a jimage file,  Helper.newHelper is returning null because there are no packaged modules in the runtime image (= no jmods directory).
> 
> In passing, tests.Helper is the supporting class for the jlink tests. We should rename it or create a sub-directory in test/jdk/tools/lib/tests as the location/naming just won't work for this very specific class.

The other PR on the bug (https://github.com/openjdk/jdk/pull/26774/files) changes the comment.
Happy for a more specific wording though.
This PR is likely redundant now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26773#discussion_r2276971391

From shade at openjdk.org  Thu Aug 14 15:45:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 15:45:14 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees [v2]
In-Reply-To: <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
 <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>
Message-ID: <kbmyFXqCXWPWrLp2OpJIhLtq1lHPWz-bWPN_MbSzQGY=.f79d7433-64b6-4046-b9d5-577a1f720a86@github.com>

On Thu, 14 Aug 2025 15:21:29 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
>> Tested locally in a worktree and normal repository. It produces:
>> 
>>  <component name="VcsDirectoryMappings">
>>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>>   </component>
>> 
>> in both cases, as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3121091987

From sgehwolf at openjdk.org  Thu Aug 14 16:07:11 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Aug 2025 16:07:11 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
References: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
Message-ID: <BxDLWZXNQAopC6ENlUp0Qhpuis9MUZwgBncdu9E-NK4=.36b14909-acb4-46f8-8eba-5efe53ce5270@github.com>

On Thu, 14 Aug 2025 09:00:24 GMT, David Beaumont <duke at openjdk.org> wrote:

> Switched from TestSkippedException (not honoured by JUnit) to TestAbortedException (via Assumptions class) to avoid false negative test "failure". Note that now, the test is either shown as skipped, or passed, depending on which report is being looked at. Tweaked error message slightly since using an "exploded image" isn't the only cause.

I'm not sure why you've created another PR for the same issue, but I think this should get closed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26773#issuecomment-3189000932

From sgehwolf at openjdk.org  Thu Aug 14 16:06:11 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Aug 2025 16:06:11 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <Z0wp3YXswTbBWBV5NhqOC8G6QlVBPgClqCzTNXsHcVU=.1777816a-4066-4dab-a030-c0c8bf3c1097@github.com>
References: <Z0wp3YXswTbBWBV5NhqOC8G6QlVBPgClqCzTNXsHcVU=.1777816a-4066-4dab-a030-c0c8bf3c1097@github.com>
Message-ID: <2ECQRNdgyKt6Qhq5fkmLhRiJM7nQDRzhloZWKy4CcRI=.7e1f86c2-7a15-4f66-8e71-fbf7ab1aed37@github.com>

On Thu, 14 Aug 2025 09:34:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Changed test helper creation to know about linkable images, and changed how test skipping is reported (JUnit doesn't honor TestSkippedException, only TestAbortedException).

Looks good to me. This does the right thing for both builds. JEP 493-enabled and builds with `JMODs`. Thanks.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26774#pullrequestreview-3121170683

From ghan at openjdk.org  Thu Aug 14 16:05:13 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 14 Aug 2025 16:05:13 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v2]
In-Reply-To: <OoNIfVrcKWL2F4m8AacjIjZWBmKxkAJhV3GC1t3GVPw=.6c433837-29a0-459c-ba08-36377201c18f@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <9WHpzNFxdghHLnEU2AAqLBzXrbHJzrdyOYwKVxTXh3k=.25b1b528-ee15-4566-ba69-4392daf67565@github.com>
 <OoNIfVrcKWL2F4m8AacjIjZWBmKxkAJhV3GC1t3GVPw=.6c433837-29a0-459c-ba08-36377201c18f@github.com>
Message-ID: <1udeEVxR-4I1FFSOjAli2FSGg4xh0CBUkeaNKN7ZxQU=.a03972aa-7cbe-4d14-96f0-00993fce270b@github.com>

On Thu, 14 Aug 2025 12:36:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update exePrintSignalDisposition.c
>>   
>>   a small fix
>
> Seems there is also coding in os_posix.cpp ( describe_signal_set_short ) to print signal information , maybe 'borrow' from there?

Hi @MBaesken 
Thanks for the suggestion! I?ve updated the code as you requested. Please take a look when you have time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26771#issuecomment-3188992836

From ghan at openjdk.org  Thu Aug 14 16:02:54 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 14 Aug 2025 16:02:54 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v3]
In-Reply-To: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
Message-ID: <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>

> This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
> - bits/types/__sigset_t.h 
> <img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />
> 
> 
> - sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
> <img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />
> 
> 
> During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.
> 
> we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.

Guanqiang Han has updated the pull request incrementally with two additional commits since the last revision:

 - Update exePrintSignalDisposition.c
   
   a small fix
 - Update exePrintSignalDisposition.c
   
   Refactor act.sa_mask output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26771/files
  - new: https://git.openjdk.org/jdk/pull/26771/files/207cc292..6077719c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26771&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26771&range=01-02

  Stats: 15 lines in 1 file changed: 7 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26771/head:pull/26771

PR: https://git.openjdk.org/jdk/pull/26771

From asemenyuk at openjdk.org  Thu Aug 14 16:18:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 14 Aug 2025 16:18:12 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation
In-Reply-To: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
Message-ID: <2bgHby1Ki4MCj1zz5npU4W4ye7K9cRbw29GOeeazzhY=.3d92a498-db54-4911-ba88-d2f06dac3e43@github.com>

On Thu, 14 Aug 2025 13:35:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
>  - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
>  - Add tests for PackagingPipeline class.
>  - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
>  - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
>  - Add tests for BuildEnv class.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26778#issuecomment-3189038277

From alanb at openjdk.org  Thu Aug 14 16:04:22 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Aug 2025 16:04:22 GMT
Subject: RFR: 8365532:
 java/lang/module/ModuleReader/ModuleReaderTest.testImage fails
In-Reply-To: <WCIv2h-8dZtKz3FXHGxWZFufj__WYywc6tCmIyjsUwE=.e74cbaae-fbe5-45a5-bde0-d19f6aaba3cb@github.com>
References: <WCIv2h-8dZtKz3FXHGxWZFufj__WYywc6tCmIyjsUwE=.e74cbaae-fbe5-45a5-bde0-d19f6aaba3cb@github.com>
Message-ID: <Bb3ecJFsfyk73XnWwIcB1CAacQv9iGtV476BGZ68Y2w=.a5cb7207-2198-429d-9970-336bb9b93192@github.com>

On Thu, 14 Aug 2025 15:06:40 GMT, David Beaumont <duke at openjdk.org> wrote:

> This should fix this issue and locally fixes the test() method in:
> 
> test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java
> 
> which does:
> 
> --------
>             // test nulls
>             try {
>                 reader.find(null);
>                 assertTrue(false);
>             } catch (NullPointerException expected) { }
> --------

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26780#pullrequestreview-3121160433

From duke at openjdk.org  Thu Aug 14 16:53:21 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 16:53:21 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
References: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
Message-ID: <mdtxcrDA_2t1MSY0rbwst_q3yLUGZBjK6Lk9ebgnEaw=.5b09ad7d-e15c-466d-845a-5ed84d9eceda@github.com>

On Thu, 14 Aug 2025 09:00:24 GMT, David Beaumont <duke at openjdk.org> wrote:

> Switched from TestSkippedException (not honoured by JUnit) to TestAbortedException (via Assumptions class) to avoid false negative test "failure". Note that now, the test is either shown as skipped, or passed, depending on which report is being looked at. Tweaked error message slightly since using an "exploded image" isn't the only cause.

I'm closing this alternate PR, please review https://github.com/openjdk/jdk/pull/26774 instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26773#issuecomment-3189166720

From duke at openjdk.org  Thu Aug 14 16:53:21 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 16:53:21 GMT
Subject: Withdrawn: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
References: <H792BjjQ6Qv1YDwXWLhrwEt1D-jGDHzzHFmva1uJiXM=.05768978-842b-4c08-95af-097b4686dba7@github.com>
Message-ID: <mZYSgWVv_6BZuC1ICYjZxvwOxJWsC5IsGphwbu0kwUA=.d850c123-818d-49a4-8a1f-8065c007fe99@github.com>

On Thu, 14 Aug 2025 09:00:24 GMT, David Beaumont <duke at openjdk.org> wrote:

> Switched from TestSkippedException (not honoured by JUnit) to TestAbortedException (via Assumptions class) to avoid false negative test "failure". Note that now, the test is either shown as skipped, or passed, depending on which report is being looked at. Tweaked error message slightly since using an "exploded image" isn't the only cause.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26773

From duke at openjdk.org  Thu Aug 14 16:54:17 2025
From: duke at openjdk.org (duke)
Date: Thu, 14 Aug 2025 16:54:17 GMT
Subject: RFR: 8365532:
 java/lang/module/ModuleReader/ModuleReaderTest.testImage fails
In-Reply-To: <WCIv2h-8dZtKz3FXHGxWZFufj__WYywc6tCmIyjsUwE=.e74cbaae-fbe5-45a5-bde0-d19f6aaba3cb@github.com>
References: <WCIv2h-8dZtKz3FXHGxWZFufj__WYywc6tCmIyjsUwE=.e74cbaae-fbe5-45a5-bde0-d19f6aaba3cb@github.com>
Message-ID: <_cQwOhlsWxc-rCjiutIOrPt-K874RlzTKlXOEphrsgQ=.8e35d884-00a7-4514-8f30-7b238d5c90ac@github.com>

On Thu, 14 Aug 2025 15:06:40 GMT, David Beaumont <duke at openjdk.org> wrote:

> This should fix this issue and locally fixes the test() method in:
> 
> test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java
> 
> which does:
> 
> --------
>             // test nulls
>             try {
>                 reader.find(null);
>                 assertTrue(false);
>             } catch (NullPointerException expected) { }
> --------

@david-beaumont 
Your change (at version ac4d9a5914649e9d520f4f6d418f7498642992ed) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26780#issuecomment-3189168788

From duke at openjdk.org  Thu Aug 14 16:56:19 2025
From: duke at openjdk.org (duke)
Date: Thu, 14 Aug 2025 16:56:19 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees [v2]
In-Reply-To: <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
 <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>
Message-ID: <POJ80NJokh7WpThYZr7VToQeK1vRj7edNGVdQdgUa4Q=.f8f99f10-e00e-4502-b2bb-a40c35fdc5a7@github.com>

On Thu, 14 Aug 2025 15:21:29 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
>> Tested locally in a worktree and normal repository. It produces:
>> 
>>  <component name="VcsDirectoryMappings">
>>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>>   </component>
>> 
>> in both cases, as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

@david-beaumont 
Your change (at version 307574fa815477b3efe05c231956f516b80d53b9) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26777#issuecomment-3189176682

From duke at openjdk.org  Thu Aug 14 17:05:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 17:05:19 GMT
Subject: Integrated: 8365048: idea.sh script does not correctly detect/handle
 git worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <D4aPGmEAcbSm5u004g_6yDHdAZ_NQfCHAfLfN07NuW8=.5f9a68b3-5519-4476-8919-da9c2b47f05d@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

This pull request has now been integrated.

Changeset: ba231052
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba231052319676ece5105253b58efa4e906feab4
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8365048: idea.sh script does not correctly detect/handle git worktrees

Reviewed-by: shade, vyazici, erikj, mcimadamore, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/26777

From dnsimon at openjdk.org  Thu Aug 14 19:33:15 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Aug 2025 19:33:15 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
Message-ID: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>

On Wed, 13 Aug 2025 14:22:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   After suggestions from Erik and Andrey

> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

Would you mind also running tier9 to avoid surprises there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3189640422

From almatvee at openjdk.org  Thu Aug 14 20:03:14 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 14 Aug 2025 20:03:14 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation
In-Reply-To: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
Message-ID: <3Ngi7yVC2RnIGTGU96vMt0_1mRC5GM0HP-qhx8L2mlg=.97969f2d-5e61-4b23-929c-3a79cce5dbc3@github.com>

On Thu, 14 Aug 2025 13:35:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
>  - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
>  - Add tests for PackagingPipeline class.
>  - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
>  - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
>  - Add tests for BuildEnv class.

Can you put less generic title?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26778#issuecomment-3189717464

From liach at openjdk.org  Thu Aug 14 20:27:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Aug 2025 20:27:11 GMT
Subject: RFR: 8361730: The
 CodeBuilder.trying(BlockCodeBuilder,CatchBuilder) method generates corrupted
 bytecode in certain cases
In-Reply-To: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
References: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
Message-ID: <dP7zowKHl1le3a9yRzMdljhBYOnCK3Y0FNvJWfqfVbE=.ae5781a3-4bb9-406c-a9a8-cf52a74e9fe5@github.com>

On Fri, 1 Aug 2025 18:05:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> Explicitly document that BlockCodeBuilder expects control flow to continue after it merges back to the parent block, so failure to do that by the users can lead to malformed code. This is better than introducing complex and costly analysis.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26602#issuecomment-3189777745

From liach at openjdk.org  Thu Aug 14 20:30:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Aug 2025 20:30:15 GMT
Subject: Integrated: 8361730: The
 CodeBuilder.trying(BlockCodeBuilder,CatchBuilder) method generates corrupted
 bytecode in certain cases
In-Reply-To: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
References: <C8iiP5_y-4ti9Oo4LnbZ-nfpXbhsThAA_a-ddcl5bf4=.e97bc7a7-3b35-42f2-b07c-96e04ca4bb38@github.com>
Message-ID: <-wbHSWsIwKm4a4NB8plMSl9et9Nwjh2HiS2oHUVYm74=.cd2a99c7-72e1-4bda-8509-3fd11a044b7a@github.com>

On Fri, 1 Aug 2025 18:05:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> Explicitly document that BlockCodeBuilder expects control flow to continue after it merges back to the parent block, so failure to do that by the users can lead to malformed code. This is better than introducing complex and costly analysis.

This pull request has now been integrated.

Changeset: c5cbcac8
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5cbcac828e1c7aa845cf16e68f6306ae49e050c
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8361730: The CodeBuilder.trying(BlockCodeBuilder,CatchBuilder) method generates corrupted bytecode in certain cases

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/26602

From jrose at openjdk.org  Thu Aug 14 20:33:14 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 14 Aug 2025 20:33:14 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <b4bYIyfaNilRNu7b1CQlTCnzNcAnB359mg911TY5d24=.4560b893-e719-4ed9-bfa3-6408fd7ccbee@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
 <b4bYIyfaNilRNu7b1CQlTCnzNcAnB359mg911TY5d24=.4560b893-e719-4ed9-bfa3-6408fd7ccbee@github.com>
Message-ID: <lew3mRNm3V0fB7QQa28K1nHoosIiB5EUvD3YArkef9E=.b2b3a9c1-4e97-4054-b53e-0637fee0f939@github.com>

On Wed, 13 Aug 2025 14:20:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> ? to help the compiler do the right thing with more ease and perhaps slightly faster

If the Java code is good enough, then the precondition method can simply be marked `@ForceInline`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3189790415

From jrose at openjdk.org  Thu Aug 14 20:38:14 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 14 Aug 2025 20:38:14 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
Message-ID: <wONWlQ2iXz95r_tmfpX0a4gkkPuTX8SzICQmvCO6MOw=.539e708d-6b69-44a8-b03d-7aaa602bca91@github.com>

On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `@apiNote` in `encodeISOArray()` Javadoc
>   
>   Those who are touching to these methods should well be
>   aware of the details elaborated in the `@apiNote`, no
>   need to put it on a display.

Some more parts to the precondition intrinsic story, FTR:

Apart from inlining, one of the goals of the intrinsic preconditions is to allow them to more reliably interact with elimination of range checks.  The JVM knows its own intrinsic checks in the `aaload` bytecode (and its brothers), and it also knows its own intrinsic precondition method.  Both kinds of checks are fodder for RCE (range check elimination) and specifically the iteration range splitting performed when a loop is factored into pre/main/post loops.  The main part is statically proven to traverse an index range which is incapable of failing any of the checks (within the loop body).  This RCE in turn unlocks power moves like vectorization.

If the precondition check in question works OK for these use cases, it can be marked force-inline, but if there is also evidence that it would unlock more loop optimizations, then it should be made an intrinsic (or else built on top of another intrinsics, with force-inline).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3189804162

From ayang at openjdk.org  Thu Aug 14 20:42:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 14 Aug 2025 20:42:14 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v3]
In-Reply-To: <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>
Message-ID: <OM5loFNgbyfzu38jmygcOPeTGX6PKv2yEjmXrTpoBXw=.968abbb3-de7f-432e-b17a-a5d8b855a1ee@github.com>

On Thu, 14 Aug 2025 16:02:54 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
>> - bits/types/__sigset_t.h 
>> <img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />
>> 
>> 
>> - sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
>> <img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />
>> 
>> 
>> During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.
>> 
>> we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.
>
> Guanqiang Han has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update exePrintSignalDisposition.c
>    
>    a small fix
>  - Update exePrintSignalDisposition.c
>    
>    Refactor act.sa_mask output

The fix looks reasonable. However, the discrepancy btw and AIX and others seems unnecessary complexity. I'd prefer having `ifdef` removed also.

Looking at how these prints are used/tested, I believe `sa_mask` is not really needed and it doesn't seem very useful also. Therefore, I'd suggest removing it, just like what's done for AIX. My 2c.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26771#pullrequestreview-3122060281

From asemenyuk at openjdk.org  Thu Aug 14 21:00:11 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 14 Aug 2025 21:00:11 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation
In-Reply-To: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
Message-ID: <WbZSVHSjaPGymBoTXpBumLj-FIaDFG0lZnYaUHWYRg0=.e270b75f-bd66-41bf-85b1-60f59bdddf7d@github.com>

On Thu, 14 Aug 2025 13:35:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
>  - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
>  - Add tests for PackagingPipeline class.
>  - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
>  - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
>  - Add tests for BuildEnv class.

I'd appreciate a better alternative for the title.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26778#issuecomment-3189854226

From jrose at openjdk.org  Thu Aug 14 21:25:15 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 14 Aug 2025 21:25:15 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
Message-ID: <WZiUMVR-MjZaxVpbNhfLk6hfjoFyXI1Xj8W4ukODKsY=.823179fb-9ee3-48d1-a227-9e0927e8c687@github.com>

On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `@apiNote` in `encodeISOArray()` Javadoc
>   
>   Those who are touching to these methods should well be
>   aware of the details elaborated in the `@apiNote`, no
>   need to put it on a display.

Another comment on the precondition in question:  It does not appear to be inside a loop, but rather a precursor to a bulk operation (which searches the sign bits of a byte array slice).  It's hard to imagine the JIT doing a better job with that as an intrinsic, since it probably won't be RCE-ed within an enclosing hot loop.  So, yes, force-inline it.

Volkan found a pre-existing RFE about that precondition check, and I added a lengthy comment to it, FTR:

https://bugs.openjdk.org/browse/JDK-8361837#comment-14809088

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3189908913

From jrose at openjdk.org  Thu Aug 14 21:37:16 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 14 Aug 2025 21:37:16 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
Message-ID: <htMG8pwYVAd_9Weh9XGWyMF8uVa2WXC3kIeFnYHmqeI=.3be621b3-4996-45e5-a88d-459862cf5790@github.com>

On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `@apiNote` in `encodeISOArray()` Javadoc
>   
>   Those who are touching to these methods should well be
>   aware of the details elaborated in the `@apiNote`, no
>   need to put it on a display.

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 159:

> 157:         private static int encodeISOArray(char[] sa, int sp,
> 158:                                           byte[] da, int dp, int len) {
> 159:             if ((sp | dp | len) < 0 ||

I think this change is OK; I understand it removes uncertainty about inlining of the checking helper method.

In general, though, I think we should be using the Preconditions methods, instead of hand-rolling checks from random-looking Java operators.  (Sorry, but they will look random to the person reading this years later!)

(I think Objects::rNN is overkill; I do believe that the implicit null checks are easy to reason about.  I guess tastes vary here.  O::rNN is marked force-inline, so that should not be a problem to throw it into the checking logic, as an explicit null check.)

Anyway, I would like to a see a comment here, in the code, saying why the Preconditions methods are not used at this point.  If there was an inlining problem, let's acknowledge it.  It's OK to make String code be a special case (with hand-rolled checks, carefully tuned).  Let's document how we did that.

One point:  I don't think we expect these bulk string operations to occur in a containing hot loop, so the intrinsic value of Precondition methods (to contribute to RCE optimizations) is not required.  Still, on the whole, it is usually better to use a named method than a tricky Java operator expression ? much as we all love those!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2277764353

From liach at openjdk.org  Thu Aug 14 21:44:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Aug 2025 21:44:21 GMT
Subject: RFR: 8364319: Move java.lang.constant.AsTypeMethodHandleDesc to
 jdk.internal
In-Reply-To: <mfrVbVcScpwmdWcGnFiabumfpIhI1wLse_FAHPJ7qRY=.2ed0cfcc-cd5a-4de0-b77b-f41a178912e5@github.com>
References: <mfrVbVcScpwmdWcGnFiabumfpIhI1wLse_FAHPJ7qRY=.2ed0cfcc-cd5a-4de0-b77b-f41a178912e5@github.com>
Message-ID: <2uCWy8rdRvyEK7UMAeWhASN65LDEgkLajfZ5_Mdh7Lw=.72006271-4bd7-472e-9a00-745ea22771f7@github.com>

On Tue, 29 Jul 2025 21:40:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> java.lang.constant.AsTypeMethodHandleDesc is an implementation class for the Constant API. It was omitted in the move probably because its name does not end with Impl. We should move it to the implementation package instead.

Committed on mainline and tier 1 and 2 passed. Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26542#issuecomment-3189942032

From liach at openjdk.org  Thu Aug 14 21:44:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Aug 2025 21:44:22 GMT
Subject: Integrated: 8364319: Move java.lang.constant.AsTypeMethodHandleDesc to
 jdk.internal
In-Reply-To: <mfrVbVcScpwmdWcGnFiabumfpIhI1wLse_FAHPJ7qRY=.2ed0cfcc-cd5a-4de0-b77b-f41a178912e5@github.com>
References: <mfrVbVcScpwmdWcGnFiabumfpIhI1wLse_FAHPJ7qRY=.2ed0cfcc-cd5a-4de0-b77b-f41a178912e5@github.com>
Message-ID: <gepOhphfBu9H5xEnzLZfQi6vbt8TldLeB0EVwGKiNRA=.1b81f02a-709c-4eb2-aac7-39de80d99789@github.com>

On Tue, 29 Jul 2025 21:40:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> java.lang.constant.AsTypeMethodHandleDesc is an implementation class for the Constant API. It was omitted in the move probably because its name does not end with Impl. We should move it to the implementation package instead.

This pull request has now been integrated.

Changeset: 8c363b3e
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c363b3e3e5c1273a5e9b3393ed09a31b0647a21
Stats:     155 lines in 4 files changed: 80 ins; 74 del; 1 mod

8364319: Move java.lang.constant.AsTypeMethodHandleDesc to jdk.internal

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/26542

From jrose at openjdk.org  Thu Aug 14 21:46:16 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 14 Aug 2025 21:46:16 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
Message-ID: <zf3LD_dDYhkFONhcALEQloQFPeYJhI5HC3UlQpxRvTw=.98599fcb-145c-4e33-bc77-09463901f638@github.com>

On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `@apiNote` in `encodeISOArray()` Javadoc
>   
>   Those who are touching to these methods should well be
>   aware of the details elaborated in the `@apiNote`, no
>   need to put it on a display.

test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java line 56:

> 54:  * @summary Verify `StringCoding::countPositives` intrinsic Java wrapper checks
> 55:  *          by enabling the ones in the compiler intrinsic using
> 56:  *          `-XX:+VerifyIntrinsicChecks`

Is this only a negative test for the optional extra range checks?

That is to say, do we win if there are no additional throws, when all index inputs are valid (in range)?

Or is there some corner of these tests (there are three files here) which intentionally instigates out-of-range errors, by passing out-of-range index inputs, and then makes sure that the expected exceptions occur?

It would be good to put in a brief comment saying, "This test does not trigger out-of-range errors.  The +VerifyIntrinsicChecks version of this test simply ensures that the assembly code will produce no spurious errors."

But it would be nice, someday, to test lots of edge conditions which ARE out-of-range, and make sure (again) that the behavior is the same with and without the +VerifyIntrinsicChecks mode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2277777054

From jrose at openjdk.org  Thu Aug 14 21:49:17 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 14 Aug 2025 21:49:17 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
Message-ID: <sImS4M6MqrUSEaVX7wve7iMp6NyYinP_mpBauBSbEcY=.b5d41299-3c49-47c4-b537-72a2fd3763af@github.com>

On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `@apiNote` in `encodeISOArray()` Javadoc
>   
>   Those who are touching to these methods should well be
>   aware of the details elaborated in the `@apiNote`, no
>   need to put it on a display.

test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 90:

> 88:     }
> 89: 
> 90:     private static void violateIntrinsicMethodContract() {

Ah, here is the positive test for the extra range checking in mode +VerifyIntrinsicChecks.
In the other place where I put a comment, maybe point at this test (in the comment)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2277781995

From jrose at openjdk.org  Thu Aug 14 22:00:17 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 14 Aug 2025 22:00:17 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
Message-ID: <zKHfqXgqcT9tzvbzGp5YkKm-Z8l27X8p-Ahwq6DibH8=.4bc79267-fe27-4317-8524-3b4433d3bd81@github.com>

On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `@apiNote` in `encodeISOArray()` Javadoc
>   
>   Those who are touching to these methods should well be
>   aware of the details elaborated in the `@apiNote`, no
>   need to put it on a display.

This is lovely work.  I've left a few suggestions which you may wish to take action on.

src/hotspot/share/opto/library_call.cpp line 946:

> 944:                                                  Node* count,
> 945:                                                  bool char_count,
> 946:                                                  bool halt_on_oob) {

Adding halt_on_oob is a pro move.  It makes it very clear that something very bad is afoot.

Now I see why A/B testing was harder to do in the jtreg tests, especially for the "throwing" case.

Just a note for the future (no change requested):  The InternalError exception is sometimes used for these kinds of "crash and burn" conditiosn.   (See the code in java.lang.invoke.)  Users can try to catch IE, but they are advised not to, and it will therefore crash the thread (at least), as an unhandled throw.  The advantage of using IE is that a jtreg harness can catch it much more easily (as opposed to a hard VM halt).

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3122211152
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2277794171

From darcy at openjdk.org  Thu Aug 14 23:10:12 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 14 Aug 2025 23:10:12 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features
In-Reply-To: <057oW0YhZwRqcTgDFLOom2eOAiT8RS1tFFWt4Gr2nYU=.2b7de5b0-2a16-4a7e-a0d6-b319bac34a3f@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <057oW0YhZwRqcTgDFLOom2eOAiT8RS1tFFWt4Gr2nYU=.2b7de5b0-2a16-4a7e-a0d6-b319bac34a3f@github.com>
Message-ID: <-1C1hR0E_DhhQnrWGu7s9F0wYz9UxLaehQTJf59hc4Y=.1ad06e9e-3a2b-4344-ae8c-a872a7005e0a@github.com>

On Sat, 3 May 2025 00:56:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.
>
> Tested tier 1-2, no failure, so this isn't creating breakage. Marking this RFR.

Repeating some feedback from a separate discussion, @liach please separate out javadoc tag refactorings/corrections into a separate PR to ease the review here. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25017#issuecomment-3190130594

From naoto at openjdk.org  Thu Aug 14 23:28:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Aug 2025 23:28:26 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v2]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <OU40d8bs-zjJAWpFLKa4VjqmzU5-_0Mdh0Sxnl6NlUY=.e4238b1c-8879-4219-a600-819478143d2a@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  allow hour-only offsets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/7fc267a3..5658f255

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=00-01

  Stats: 43 lines in 3 files changed: 36 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From naoto at openjdk.org  Thu Aug 14 23:37:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Aug 2025 23:37:53 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v3]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <jKqMDS6cJwTbsYUJb9Espr37TAVd6axWXzMAbyhAeXo=.1fc66658-4c77-49da-ace0-bd2e5d96c4d1@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  allow all ISO 8601 offsets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/5658f255..048f5eab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=01-02

  Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From naoto at openjdk.org  Thu Aug 14 23:49:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Aug 2025 23:49:25 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v4]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  test cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/048f5eab..fa198b88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=02-03

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From naoto at openjdk.org  Thu Aug 14 23:53:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Aug 2025 23:53:16 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v4]
In-Reply-To: <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
Message-ID: <S7qhOknwX7bKJWtUs66Jim_nB4MdyU_aecjkkc2rypw=.6d77f8d3-2223-4ae9-8206-1beefebb3a80@github.com>

On Thu, 14 Aug 2025 23:49:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cases

Changed the proposed fix to leniently allow all ISO 8601 offsets by using "+HH" as the pattern.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3190223880

From iklam at openjdk.org  Fri Aug 15 00:20:30 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 15 Aug 2025 00:20:30 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
Message-ID: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>

This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 

- We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
- `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
- In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.

-------------

Commit messages:
 - tightened SystemDictionary::preload_class()
 - Fixed bugs found in JCK
 - added entry in ProblemList-AotJdk.txt due to 8323727
 - more clean up
 - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap
 - Fixed arm build
 - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap
 - clean up
 - java.net.URL class needs runtimeSetup
 - fixed build
 - ... and 5 more: https://git.openjdk.org/jdk/compare/25480f00...15746239

Changes: https://git.openjdk.org/jdk/pull/26375/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350550
  Stats: 553 lines in 39 files changed: 441 ins; 13 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/26375.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375

PR: https://git.openjdk.org/jdk/pull/26375

From ghan at openjdk.org  Fri Aug 15 00:34:15 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Fri, 15 Aug 2025 00:34:15 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v3]
In-Reply-To: <OM5loFNgbyfzu38jmygcOPeTGX6PKv2yEjmXrTpoBXw=.968abbb3-de7f-432e-b17a-a5d8b855a1ee@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>
 <OM5loFNgbyfzu38jmygcOPeTGX6PKv2yEjmXrTpoBXw=.968abbb3-de7f-432e-b17a-a5d8b855a1ee@github.com>
Message-ID: <FwH1sAAuIjAymRPwbDxQvk4ATA-2bqseaKIMcSkArdQ=.c6bc5490-0e9f-45f8-ae23-bae89e2bf16d@github.com>

On Thu, 14 Aug 2025 20:39:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update exePrintSignalDisposition.c
>>    
>>    a small fix
>>  - Update exePrintSignalDisposition.c
>>    
>>    Refactor act.sa_mask output
>
> The fix looks reasonable. However, the discrepancy btw and AIX and others seems unnecessary complexity. I'd prefer having `ifdef` removed also.
> 
> Looking at how these prints are used/tested, I believe `sa_mask` is not really needed and it doesn't seem very useful also. Therefore, I'd suggest removing it, just like what's done for AIX. My 2c.

hi @albertnetymk , thanks for the feedback! I agree that removing it would be the simplest solution.
Let?s get @MBaesken input as well, and if we reach an agreement, I?m happy to proceed with the simplest approach.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26771#issuecomment-3190282210

From almatvee at openjdk.org  Fri Aug 15 00:48:20 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 15 Aug 2025 00:48:20 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation
In-Reply-To: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
Message-ID: <safILUlxOR5nO6sCr8UvgTOEX21EOl2WQ0SoMvOFwUs=.359137dd-c0a1-41b1-9bb0-f33bc176d2eb@github.com>

On Thu, 14 Aug 2025 13:35:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
>  - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
>  - Add tests for PackagingPipeline class.
>  - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
>  - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
>  - Add tests for BuildEnv class.

Looks good. I do not have better alternatives for title. Lets keep it as is. Also, make sure to run macOS signing tests. I left minor comment.

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/PackagingPipelineTest.java line 189:

> 187: 
> 188:         assertEquals(expected, actual);
> 189:         System.out.println(String.format("testCreatePackage:\n---\n%s\n---", actual));

Looks like debug `println`.

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/PackagingPipelineTest.java line 365:

> 363:         final var actual = Files.readString(outputDir.resolve(pkg.packageFileNameWithSuffix()));
> 364:         assertEquals(expected, actual);
> 365:         System.out.println(String.format("%s:\n---\n%s\n---",

Same as above.

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/PackagingPipelineTest.java line 588:

> 586: 
> 587:         assertEquals(expected, actual);
> 588:         System.out.println(String.format("%s:\n---\n%s\n---", logMsgHeader, actual));

Same as above.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26778#pullrequestreview-3122496975
PR Review Comment: https://git.openjdk.org/jdk/pull/26778#discussion_r2277992965
PR Review Comment: https://git.openjdk.org/jdk/pull/26778#discussion_r2277999124
PR Review Comment: https://git.openjdk.org/jdk/pull/26778#discussion_r2278004848

From haosun at openjdk.org  Fri Aug 15 01:31:19 2025
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 15 Aug 2025 01:31:19 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v3]
In-Reply-To: <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>
Message-ID: <Ypmja5R9deZ6_UjSPWHAPKJNvh8ENyq6dzjtS8ynOrw=.443aff38-e165-4c33-bc95-2e306f9f440f@github.com>

On Thu, 14 Aug 2025 16:02:54 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
>> - bits/types/__sigset_t.h 
>> <img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />
>> 
>> 
>> - sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
>> <img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />
>> 
>> 
>> During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.
>> 
>> we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.
>
> Guanqiang Han has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update exePrintSignalDisposition.c
>    
>    a small fix
>  - Update exePrintSignalDisposition.c
>    
>    Refactor act.sa_mask output

test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

nit: `XX, YY,` means that this file was created in `XX` year and the latest update is done in `YY` year. If `XX == YY`, then use `XX,`.

Suggestion:

 * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26771#discussion_r2278049700

From shaojin.wensj at alibaba-inc.com  Fri Aug 15 01:51:54 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Fri, 15 Aug 2025 09:51:54 +0800
Subject: =?UTF-8?B?VXNpbmcgZW5oYW5jZWQgc3dpdGNoIGluIE1ldGhvZEhhbmRsZURlc2M=?=
Message-ID: <51905a58-e7c0-405d-8963-9586bb074085.shaojin.wensj@alibaba-inc.com>

In MethodHandleDesc, the ofField method uses enhanced switch, while the of and ofMethod methods use traditional switch. The same class should have a unified style.
https://github.com/openjdk/jdk/pull/26769 <https://github.com/openjdk/jdk/pull/26769 >
I have submitted a draft Pull Request and would appreciate some feedback.
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250815/f8d80c96/attachment-0001.htm>

From ghan at openjdk.org  Fri Aug 15 02:24:11 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Fri, 15 Aug 2025 02:24:11 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v3]
In-Reply-To: <Ypmja5R9deZ6_UjSPWHAPKJNvh8ENyq6dzjtS8ynOrw=.443aff38-e165-4c33-bc95-2e306f9f440f@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>
 <Ypmja5R9deZ6_UjSPWHAPKJNvh8ENyq6dzjtS8ynOrw=.443aff38-e165-4c33-bc95-2e306f9f440f@github.com>
Message-ID: <gLuJxZ068FedOh7A-N2HSzLpjl6ImU4oJ4OKfo7_utI=.1ff0903b-86be-47e9-9ba9-2b5e55c27e10@github.com>

On Fri, 15 Aug 2025 01:28:39 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update exePrintSignalDisposition.c
>>    
>>    a small fix
>>  - Update exePrintSignalDisposition.c
>>    
>>    Refactor act.sa_mask output
>
> test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> nit: `XX, YY,` means that this file was created in `XX` year and the latest update is done in `YY` year. If `XX == YY`, then use `XX,`.
> 
> Suggestion:
> 
>  * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.

Hi @shqking , thanks for the suggestion! I checked the file history, and it was actually created in 2025. Therefore, I updated the copyright to Copyright (c) 2025 to reflect the correct creation year. If the file gets updated in the future, we can follow the ?XX, YY? format.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26771#discussion_r2278090946

From syan at openjdk.org  Fri Aug 15 02:57:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 15 Aug 2025 02:57:15 GMT
Subject: RFR: 8365532:
 java/lang/module/ModuleReader/ModuleReaderTest.testImage fails
In-Reply-To: <WCIv2h-8dZtKz3FXHGxWZFufj__WYywc6tCmIyjsUwE=.e74cbaae-fbe5-45a5-bde0-d19f6aaba3cb@github.com>
References: <WCIv2h-8dZtKz3FXHGxWZFufj__WYywc6tCmIyjsUwE=.e74cbaae-fbe5-45a5-bde0-d19f6aaba3cb@github.com>
Message-ID: <vkGxrs6fLfccF8bYSlM7M8O43sC-ZnThSpBVeL6dja0=.340e4dd2-17ca-4292-bbd2-263d525b7d9c@github.com>

On Thu, 14 Aug 2025 15:06:40 GMT, David Beaumont <duke at openjdk.org> wrote:

> This should fix this issue and locally fixes the test() method in:
> 
> test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java
> 
> which does:
> 
> --------
>             // test nulls
>             try {
>                 reader.find(null);
>                 assertTrue(false);
>             } catch (NullPointerException expected) { }
> --------

I think we should integrate this PR right now to avoid the test noisy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26780#issuecomment-3190461374

From duke at openjdk.org  Fri Aug 15 02:57:15 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 15 Aug 2025 02:57:15 GMT
Subject: Integrated: 8365532:
 java/lang/module/ModuleReader/ModuleReaderTest.testImage fails
In-Reply-To: <WCIv2h-8dZtKz3FXHGxWZFufj__WYywc6tCmIyjsUwE=.e74cbaae-fbe5-45a5-bde0-d19f6aaba3cb@github.com>
References: <WCIv2h-8dZtKz3FXHGxWZFufj__WYywc6tCmIyjsUwE=.e74cbaae-fbe5-45a5-bde0-d19f6aaba3cb@github.com>
Message-ID: <u2OltNuHbhkMppzLMx63ujAHk1qUiB0uhWovdGDI1uA=.91aa700f-4500-456a-b1c2-8899ea5355d8@github.com>

On Thu, 14 Aug 2025 15:06:40 GMT, David Beaumont <duke at openjdk.org> wrote:

> This should fix this issue and locally fixes the test() method in:
> 
> test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java
> 
> which does:
> 
> --------
>             // test nulls
>             try {
>                 reader.find(null);
>                 assertTrue(false);
>             } catch (NullPointerException expected) { }
> --------

This pull request has now been integrated.

Changeset: 44b19c01
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44b19c01acdfff07a4f017466be3f03fae6013c6
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8365532: java/lang/module/ModuleReader/ModuleReaderTest.testImage fails

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/26780

From liangchenblue at gmail.com  Fri Aug 15 03:13:13 2025
From: liangchenblue at gmail.com (Chen Liang)
Date: Thu, 14 Aug 2025 22:13:13 -0500
Subject: Using enhanced switch in MethodHandleDesc
In-Reply-To: <CABe8uE1wnv7w-i7f_Q7Quzt45fHLW1CzSuaoKWQ+3kMP7AT3Jg@mail.gmail.com>
References: <51905a58-e7c0-405d-8963-9586bb074085.shaojin.wensj@alibaba-inc.com>
 <CABe8uE1wnv7w-i7f_Q7Quzt45fHLW1CzSuaoKWQ+3kMP7AT3Jg@mail.gmail.com>
Message-ID: <CABe8uE1gBKJ75nQxceh608kw8ZQwy0wHjHMePQF5kStq5HonUQ@mail.gmail.com>

Forwarding to the main list, forgot to reply all.

On Thu, Aug 14, 2025 at 10:12?PM Chen Liang <liangchenblue at gmail.com> wrote:

> Hello wenshao, I think this is a reasonable enhancement.
>
> In addition, you can review the switch in jdk.internal.constant as well. I
> find there is a traditional switch in ConstantUtils.skipOverFieldSignature
> that can be updated too.
>
> Since enhanced switch statements and expressions can handle
> exhaustive switch over enum without default branches, you can consider
> remove default branches so we will get compile errors reminding us to
> update when we add new method handle kinds.
>
> Regards,
> Chen
>
> On Thu, Aug 14, 2025 at 9:49?PM wenshao <shaojin.wensj at alibaba-inc.com>
> wrote:
>
>> In MethodHandleDesc, the ofField method uses enhanced switch, while the
>> of and ofMethod methods use traditional switch. The same class should have
>> a unified style.
>>
>> https://github.com/openjdk/jdk/pull/26769
>>
>> I have submitted a draft Pull Request and would appreciate some feedback.
>>
>> -
>> Shaojin Wen
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250814/6a86e1ed/attachment-0001.htm>

From liach at openjdk.org  Fri Aug 15 04:28:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Aug 2025 04:28:17 GMT
Subject: RFR: 8361638: java.lang.classfile.CodeBuilder.CatchBuilder should
 not throw IllegalArgumentException for representable exception
 handlers [v3]
In-Reply-To: <xYg9aPaPJ8m-VVywcsyvq5Yj6lzPFbyE6NnvArsAPk4=.47e19c03-ee26-45eb-b090-275a3a200248@github.com>
References: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
 <xYg9aPaPJ8m-VVywcsyvq5Yj6lzPFbyE6NnvArsAPk4=.47e19c03-ee26-45eb-b090-275a3a200248@github.com>
Message-ID: <dY7frE7TsMJ_gcx9I1N1vgaplp6aEjfi8xNLQN6dMrY=.ed14610c-f001-442f-821e-8826a18d4f30@github.com>

On Tue, 29 Jul 2025 17:06:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> CatchBuilder has a simple check for duplicate catch types. However, this check is never comprehensive as it still allows subtypes covered by supertypes, and covering that would be too costly; in addition, the "illegal" duplicate catch types are still valid `class` files. We should remove this duplicate catch type check, and compensate with documentation on the effects of duplicate types.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrong ref

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26372#issuecomment-3190563654

From liach at openjdk.org  Fri Aug 15 04:28:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Aug 2025 04:28:18 GMT
Subject: Integrated: 8361638: java.lang.classfile.CodeBuilder.CatchBuilder
 should not throw IllegalArgumentException for representable exception handlers
In-Reply-To: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
References: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
Message-ID: <PeBJe88KiqhHkBLUsoiucW8gLHCKY3GoOG0nd01CaXo=.6c94f899-eb6f-49a6-b351-94f6271b3088@github.com>

On Thu, 17 Jul 2025 16:50:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> CatchBuilder has a simple check for duplicate catch types. However, this check is never comprehensive as it still allows subtypes covered by supertypes, and covering that would be too costly; in addition, the "illegal" duplicate catch types are still valid `class` files. We should remove this duplicate catch type check, and compensate with documentation on the effects of duplicate types.

This pull request has now been integrated.

Changeset: 6fb6f3d3
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6fb6f3d39b321e2a1c1fa2cef2c19222a6dcf7b9
Stats:     85 lines in 4 files changed: 53 ins; 14 del; 18 mod

8361638: java.lang.classfile.CodeBuilder.CatchBuilder should not throw IllegalArgumentException for representable exception handlers

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/26372

From liach at openjdk.org  Fri Aug 15 04:29:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Aug 2025 04:29:15 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <kmngnozEmlS3-dfo_xmzpW84PLGX-yrXavmBAGO_7Ys=.4600fb69-1c42-4132-9cce-1077fbdc7ae4@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

Looks right to me. However since your changed lines is directly by the java.desktop changed line, there's a conflict and you must resolve it.

In addition, `PreviewFeature.Feature` enum has a few obsolete entries - they should be kept until the preview feature is not in the minimum boot JDK. Now the boot JDK is min 24, and a few of the features are already permanent in 24.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26776#pullrequestreview-3122788756
PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3190566237

From asemenyuk at openjdk.org  Fri Aug 15 05:13:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Aug 2025 05:13:10 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation
In-Reply-To: <safILUlxOR5nO6sCr8UvgTOEX21EOl2WQ0SoMvOFwUs=.359137dd-c0a1-41b1-9bb0-f33bc176d2eb@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
 <safILUlxOR5nO6sCr8UvgTOEX21EOl2WQ0SoMvOFwUs=.359137dd-c0a1-41b1-9bb0-f33bc176d2eb@github.com>
Message-ID: <z0-YcZQ_jt4JdGacR4YRYJwLuJ0oFtaNkmkPW11Cdz0=.eed3a079-4769-4cf8-b8ff-2ed6f7dc2867@github.com>

On Fri, 15 Aug 2025 00:21:49 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
>>  - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
>>  - Add tests for PackagingPipeline class.
>>  - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
>>  - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
>>  - Add tests for BuildEnv class.
>
> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/PackagingPipelineTest.java line 189:
> 
>> 187: 
>> 188:         assertEquals(expected, actual);
>> 189:         System.out.println(String.format("testCreatePackage:\n---\n%s\n---", actual));
> 
> Looks like debug `println`.

It is on purpose to get an idea of what the test with the given parameter value is doing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26778#discussion_r2278257978

From alanb at openjdk.org  Fri Aug 15 05:49:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Aug 2025 05:49:10 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <Z0wp3YXswTbBWBV5NhqOC8G6QlVBPgClqCzTNXsHcVU=.1777816a-4066-4dab-a030-c0c8bf3c1097@github.com>
References: <Z0wp3YXswTbBWBV5NhqOC8G6QlVBPgClqCzTNXsHcVU=.1777816a-4066-4dab-a030-c0c8bf3c1097@github.com>
Message-ID: <9cvY8wlXYuwDSLw5Qr0TB7hwjNj0fZvw0Mc8TXM41ks=.67a94787-1815-482d-a6ef-17df6ea517df@github.com>

On Thu, 14 Aug 2025 09:34:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Changed test helper creation to know about linkable images, and changed how test skipping is reported (JUnit doesn't honor TestSkippedException, only TestAbortedException).

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26774#pullrequestreview-3122960546

From mbaesken at openjdk.org  Fri Aug 15 06:52:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Aug 2025 06:52:13 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v3]
In-Reply-To: <OM5loFNgbyfzu38jmygcOPeTGX6PKv2yEjmXrTpoBXw=.968abbb3-de7f-432e-b17a-a5d8b855a1ee@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>
 <OM5loFNgbyfzu38jmygcOPeTGX6PKv2yEjmXrTpoBXw=.968abbb3-de7f-432e-b17a-a5d8b855a1ee@github.com>
Message-ID: <WHQWj6qzRUCevgy_oNywAk2d01xwTZy3LQiTcdBrtU0=.a531c82d-66e3-4d0f-b13a-56e26b3d2cc3@github.com>

On Thu, 14 Aug 2025 20:39:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The fix looks reasonable. However, the discrepancy btw and AIX and others seems unnecessary complexity. I'd prefer having `ifdef` removed also.
> 
> Looking at how these prints are used/tested, I believe `sa_mask` is not really needed and it doesn't seem very useful also. Therefore, I'd suggest removing it, just like what's done for AIX. My 2c.

That's fine .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26771#issuecomment-3190785447

From ghan at openjdk.org  Fri Aug 15 07:07:57 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Fri, 15 Aug 2025 07:07:57 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v4]
In-Reply-To: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
Message-ID: <QFTLzaYC5XkmSdXaDY1clHeHg7Skh5nUAFhIai2Q_VI=.9a63a7f5-1ea1-416e-b7b2-b9db69c67e2e@github.com>

> This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
> - bits/types/__sigset_t.h 
> <img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />
> 
> 
> - sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
> <img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />
> 
> 
> During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.
> 
> we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  Update exePrintSignalDisposition.c
  
  Remove unnecessary sa_mask printing based on reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26771/files
  - new: https://git.openjdk.org/jdk/pull/26771/files/6077719c..30961273

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26771&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26771&range=02-03

  Stats: 18 lines in 1 file changed: 0 ins; 18 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26771/head:pull/26771

PR: https://git.openjdk.org/jdk/pull/26771

From ghan at openjdk.org  Fri Aug 15 07:12:11 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Fri, 15 Aug 2025 07:12:11 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v3]
In-Reply-To: <WHQWj6qzRUCevgy_oNywAk2d01xwTZy3LQiTcdBrtU0=.a531c82d-66e3-4d0f-b13a-56e26b3d2cc3@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>
 <OM5loFNgbyfzu38jmygcOPeTGX6PKv2yEjmXrTpoBXw=.968abbb3-de7f-432e-b17a-a5d8b855a1ee@github.com>
 <WHQWj6qzRUCevgy_oNywAk2d01xwTZy3LQiTcdBrtU0=.a531c82d-66e3-4d0f-b13a-56e26b3d2cc3@github.com>
Message-ID: <HYn5JfixoEz_-rtT6deW1VqTfWvFwSqP2yheyrLNGuE=.a2d82a29-cdaa-43d1-8860-487f339ce2ea@github.com>

On Fri, 15 Aug 2025 06:49:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The fix looks reasonable. However, the discrepancy btw and AIX and others seems unnecessary complexity. I'd prefer having `ifdef` removed also.
>> 
>> Looking at how these prints are used/tested, I believe `sa_mask` is not really needed and it doesn't seem very useful also. Therefore, I'd suggest removing it, just like what's done for AIX. My 2c.
>
>> The fix looks reasonable. However, the discrepancy btw and AIX and others seems unnecessary complexity. I'd prefer having `ifdef` removed also.
>> 
>> Looking at how these prints are used/tested, I believe `sa_mask` is not really needed and it doesn't seem very useful also. Therefore, I'd suggest removing it, just like what's done for AIX. My 2c.
> 
> That's fine .

@MBaesken @albertnetymk 
Thanks for the feedback. I?ve removed the sa_mask printing as suggested. Please take another look when you have time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26771#issuecomment-3190812148

From ayang at openjdk.org  Fri Aug 15 07:31:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 15 Aug 2025 07:31:10 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v4]
In-Reply-To: <QFTLzaYC5XkmSdXaDY1clHeHg7Skh5nUAFhIai2Q_VI=.9a63a7f5-1ea1-416e-b7b2-b9db69c67e2e@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <QFTLzaYC5XkmSdXaDY1clHeHg7Skh5nUAFhIai2Q_VI=.9a63a7f5-1ea1-416e-b7b2-b9db69c67e2e@github.com>
Message-ID: <MPUD4nHEOfBYyqE-SVNtXncsIJjx8Ju-lARwM2XNVIc=.4a96fe75-6012-48a7-b5f1-5ab6c6152631@github.com>

On Fri, 15 Aug 2025 07:07:57 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
>> - bits/types/__sigset_t.h 
>> <img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />
>> 
>> 
>> - sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
>> <img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />
>> 
>> 
>> During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.
>> 
>> we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update exePrintSignalDisposition.c
>   
>   Remove unnecessary sa_mask printing based on reviewer feedback

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26771#pullrequestreview-3123152952

From mbaesken at openjdk.org  Fri Aug 15 07:35:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Aug 2025 07:35:13 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v4]
In-Reply-To: <QFTLzaYC5XkmSdXaDY1clHeHg7Skh5nUAFhIai2Q_VI=.9a63a7f5-1ea1-416e-b7b2-b9db69c67e2e@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <QFTLzaYC5XkmSdXaDY1clHeHg7Skh5nUAFhIai2Q_VI=.9a63a7f5-1ea1-416e-b7b2-b9db69c67e2e@github.com>
Message-ID: <IoFQIaeW-4LOVckpEcSBv-d8l-FJWxk0MYtggSlwCeQ=.fbdc786c-ef01-4964-a80f-ac0979d53b5c@github.com>

On Fri, 15 Aug 2025 07:07:57 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
>> - bits/types/__sigset_t.h 
>> <img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />
>> 
>> 
>> - sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
>> <img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />
>> 
>> 
>> During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.
>> 
>> we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update exePrintSignalDisposition.c
>   
>   Remove unnecessary sa_mask printing based on reviewer feedback

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26771#pullrequestreview-3123157628

From vyazici at openjdk.org  Fri Aug 15 08:39:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 15 Aug 2025 08:39:20 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v16]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Document tests using `-XX:+VerifyIntrinsicChecks` don't check out-of-range conditions
 - Document why `Preconditions` is not used

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/d5aabf0c..2ba4ba6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=14-15

  Stats: 19 lines in 5 files changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From vyazici at openjdk.org  Fri Aug 15 08:39:24 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 15 Aug 2025 08:39:24 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v15]
In-Reply-To: <zKHfqXgqcT9tzvbzGp5YkKm-Z8l27X8p-Ahwq6DibH8=.4bc79267-fe27-4317-8524-3b4433d3bd81@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <sy-MuD8D8GXEj0F3jVNjmy6lDsID_qmqsaUN1Uoi1jw=.194218d8-222a-4497-9ea0-5ce92ac8d970@github.com>
 <zKHfqXgqcT9tzvbzGp5YkKm-Z8l27X8p-Ahwq6DibH8=.4bc79267-fe27-4317-8524-3b4433d3bd81@github.com>
Message-ID: <sbIrhiBH4cKqQ4-3K4AYcQVGyvo7XXr8ktctGC0JAFE=.6144e88b-7fe3-48c8-8a98-9dfb2e68239b@github.com>

On Thu, 14 Aug 2025 21:55:48 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove `@apiNote` in `encodeISOArray()` Javadoc
>>   
>>   Those who are touching to these methods should well be
>>   aware of the details elaborated in the `@apiNote`, no
>>   need to put it on a display.
>
> src/hotspot/share/opto/library_call.cpp line 946:
> 
>> 944:                                                  Node* count,
>> 945:                                                  bool char_count,
>> 946:                                                  bool halt_on_oob) {
> 
> Adding halt_on_oob is a pro move.  It makes it very clear that something very bad is afoot.
> 
> Now I see why A/B testing was harder to do in the jtreg tests, especially for the "throwing" case.
> 
> Just a note for the future (no change requested):  The InternalError exception is sometimes used for these kinds of "crash and burn" conditiosn.   (See the code in java.lang.invoke.)  Users can try to catch IE, but they are advised not to, and it will therefore crash the thread (at least), as an unhandled throw.  The advantage of using IE is that a jtreg harness can catch it much more easily (as opposed to a hard VM halt).

Thanks for the remark. I will share this with @dafedafe and @TobiHartmann.

> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 159:
> 
>> 157:         private static int encodeISOArray(char[] sa, int sp,
>> 158:                                           byte[] da, int dp, int len) {
>> 159:             if ((sp | dp | len) < 0 ||
> 
> I think this change is OK; I understand it removes uncertainty about inlining of the checking helper method.
> 
> In general, though, I think we should be using the Preconditions methods, instead of hand-rolling checks from random-looking Java operators.  (Sorry, but they will look random to the person reading this years later!)
> 
> (I think Objects::rNN is overkill; I do believe that the implicit null checks are easy to reason about.  I guess tastes vary here.  O::rNN is marked force-inline, so that should not be a problem to throw it into the checking logic, as an explicit null check.)
> 
> Anyway, I would like to a see a comment here, in the code, saying why the Preconditions methods are not used at this point.  If there was an inlining problem, let's acknowledge it.  It's OK to make String code be a special case (with hand-rolled checks, carefully tuned).  Let's document how we did that.
> 
> One point:  I don't think we expect these bulk string operations to occur in a containing hot loop, so the intrinsic value of Precondition methods (to contribute to RCE optimizations) is not required.  Still, on the whole, it is usually better to use a named method than a tricky Java operator expression ? much as we all love those!
> 
> P.S. For regular code (not the very hottest hand-optimized string methods) I do prefer to put the checking logic in a separate method.  This is (again) a matter of taste.  The point is to make the method that does the work be as compact as possible, preferably below about 35 bytecodes (which, sadly, is favored by our inlining policy ATM).  If the method which does the work is 10% work-doing bytecodes and 90% condition-checking and exception-formatting and exception-throwing code, then the JIT will get a bad view of it, and will not inline as generously.  In fact, I often prefer to make the checks method small also, and save all the exception reporting junk for a THIRD method, which is never called, and does not need to be inlined at all.  So, for me, the sweet spot is one small method to do the work, another small method to do the checks (perhaps force-inline, if it is medium sized), and a third method to throw the exception, which is as horrible as it needs to be.

Very valid point. In 62350347, documented why `Preconditions` is not used.

> test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 90:
> 
>> 88:     }
>> 89: 
>> 90:     private static void violateIntrinsicMethodContract() {
> 
> Ah, here is the positive test for the extra range checking in mode +VerifyIntrinsicChecks.
> In the other place where I put a comment, maybe point at this test (in the comment)?

Yes, and no. Yes, this test verifies mode `+VerifyIntrinsicChecks` employed by _a_ VM intrinsic that triggers a VM halt on constraint violation ? but only that. No, it doesn't _exhaustively_ verify extra range checks of `StringCoding::encodeAsciiArray` in mode `+VerifyIntrinsicChecks`.

Since `SC:eAA` is just used as a vehicle to reach to a VM halt triggered by `halt_on_oob = true`, I prefer to _not_ refer to this test as the positive test for the extra range checking in mode `+VerifyIntrinsicChecks` of `TestEncodeIntrinsics`, which tests `StringCoding::encodeAsciiArray`.

> test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java line 56:
> 
>> 54:  * @summary Verify `StringCoding::countPositives` intrinsic Java wrapper checks
>> 55:  *          by enabling the ones in the compiler intrinsic using
>> 56:  *          `-XX:+VerifyIntrinsicChecks`
> 
> Is this only a negative test for the optional extra range checks?
> 
> That is to say, do we win if there are no additional throws, when all index inputs are valid (in range)?
> 
> Or is there some corner of these tests (there are three files here) which intentionally instigates out-of-range errors, by passing out-of-range index inputs, and then makes sure that the expected exceptions occur?
> 
> It would be good to put in a brief comment saying, "This test does not trigger out-of-range errors.  The +VerifyIntrinsicChecks version of this test simply ensures that the assembly code will produce no spurious errors."
> 
> But it would be nice, someday, to test lots of edge conditions which ARE out-of-range, and make sure (again) that the behavior is the same with and without the +VerifyIntrinsicChecks mode.

Your assessment is correct. In 2ba4ba6f, I've added `@comment` blocks as requested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2278536177
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2278534999
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2278535750
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2278535192

From vyazici at openjdk.org  Fri Aug 15 09:12:13 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 15 Aug 2025 09:12:13 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v4]
In-Reply-To: <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
Message-ID: <SA4mEI5wxD2hBNl-gUQJJM_cqpd7LJes27I3hRsKcVU=.93131aea-6d17-4892-8c3c-eda41b47124f@github.com>

On Thu, 14 Aug 2025 23:49:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cases

Thanks for adding the tests. In its current state, it LGTM based on my limited understanding. I'll leave the final approval to those more knowledgeable in this area.

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 1:

> 1: /*

Doesn't copyright year need a bump?

test/jdk/java/time/test/java/time/TestInstant.java line 179:

> 177:             {"2017-01-01T00:00:00.000+0"},
> 178:             {"2017-01-01T00:00:00.000+0:"},
> 179:             {"2017-01-01T00:00:00.000+02:"},

It is nice that leniency allows `0200` (i.e., missing white space), but not `02:` or `02:00:` (i.e., trailing separators).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26708#pullrequestreview-3123312615
PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2278580535
PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2278597174

From ghan at openjdk.org  Fri Aug 15 09:42:17 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Fri, 15 Aug 2025 09:42:17 GMT
Subject: RFR: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611 [v3]
In-Reply-To: <WHQWj6qzRUCevgy_oNywAk2d01xwTZy3LQiTcdBrtU0=.a531c82d-66e3-4d0f-b13a-56e26b3d2cc3@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
 <tyVlY1oDC_2S_wWiCSixlJVTipcisQdU5H9HkCWaNvA=.4ab6b1fc-6424-4cd1-87f8-61695e3b5ef3@github.com>
 <OM5loFNgbyfzu38jmygcOPeTGX6PKv2yEjmXrTpoBXw=.968abbb3-de7f-432e-b17a-a5d8b855a1ee@github.com>
 <WHQWj6qzRUCevgy_oNywAk2d01xwTZy3LQiTcdBrtU0=.a531c82d-66e3-4d0f-b13a-56e26b3d2cc3@github.com>
Message-ID: <DFUUyjoeqk5APLfiPBjWkAPUvnJbo50YviYdGwbsgSc=.46d6284d-3238-47f3-aa6e-143bd1110f42@github.com>

On Fri, 15 Aug 2025 06:49:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The fix looks reasonable. However, the discrepancy btw and AIX and others seems unnecessary complexity. I'd prefer having `ifdef` removed also.
>> 
>> Looking at how these prints are used/tested, I believe `sa_mask` is not really needed and it doesn't seem very useful also. Therefore, I'd suggest removing it, just like what's done for AIX. My 2c.
>
>> The fix looks reasonable. However, the discrepancy btw and AIX and others seems unnecessary complexity. I'd prefer having `ifdef` removed also.
>> 
>> Looking at how these prints are used/tested, I believe `sa_mask` is not really needed and it doesn't seem very useful also. Therefore, I'd suggest removing it, just like what's done for AIX. My 2c.
> 
> That's fine .

Many thanks to both of you @MBaesken @albertnetymk for your review and approval. I?ve integrated the changes.
Please sponsor it ? appreciate it!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26771#issuecomment-3191107779

From ghan at openjdk.org  Fri Aug 15 09:45:17 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Fri, 15 Aug 2025 09:45:17 GMT
Subject: Integrated: 8365296: Build failure with Clang due to -Wformat warning
 after JDK-8364611
In-Reply-To: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
References: <lEf_L8cYWclXVvCHrJl3wBw8CqB8WismWRtUnA0ZmyQ=.c216cdb8-67ee-4677-9865-0a2e129bbdfd@github.com>
Message-ID: <zgzoKoPqyoni2h8ndj9RqVzGdxZP3kAX9PF1AXriLYg=.17ccbe24-f68b-49eb-83ff-990c1b3053bb@github.com>

On Thu, 14 Aug 2025 08:29:11 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> This issue is related to the definition of __sigset_t (__sigset_t  act.sa_mask).   In the glibc source, __sigset_t is defined in multiple places:  
> - bits/types/__sigset_t.h 
> <img width="1071" height="415" alt="image02" src="https://github.com/user-attachments/assets/4dff7546-f0b3-448c-832f-54f7b9ffc476" />
> 
> 
> - sysdeps/unix/sysv/linux/bits/types/__sigset_t.h (introduced after glibc 2.25)   
> <img width="1059" height="487" alt="image01" src="https://github.com/user-attachments/assets/54101f9b-3b1a-4943-83ee-6f6471c060a6" />
> 
> 
> During compilation with Clang, the latter definition appears to be used, where __sigset_t is a struct, causing the printf("%X", act.sa_mask) to fail.
> 
> we can detect whether _SIGSET_NWORDS is defined and handle the printing differently based on that, ensuring correct handling of the struct type.

This pull request has now been integrated.

Changeset: b6d5f49b
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6d5f49b8dc2cb7c8e93d7885c2432a28d04e57e
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8365296: Build failure with Clang due to -Wformat warning after JDK-8364611

Reviewed-by: ayang, mbaesken

-------------

PR: https://git.openjdk.org/jdk/pull/26771

From duke at openjdk.org  Fri Aug 15 09:48:13 2025
From: duke at openjdk.org (erifan)
Date: Fri, 15 Aug 2025 09:48:13 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v7]
In-Reply-To: <JnP2NKR1BMSBMVOJXwTODwMgj_P20q8k2zw7HLy4ZdE=.c476fb6b-4ccd-430a-b198-a6cd3e48f901@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <JnP2NKR1BMSBMVOJXwTODwMgj_P20q8k2zw7HLy4ZdE=.c476fb6b-4ccd-430a-b198-a6cd3e48f901@github.com>
Message-ID: <_mLYFBM0CoUb9fZDL1bPJKArnOWmf_XVz-oN9prPjTQ=.4e8a9f02-205a-4f5f-ab60-920f10452585@github.com>

On Wed, 13 Aug 2025 03:20:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
>> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
>> 
>>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
>> 
>> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
>> 
>> Performance numbers:
>> 
>> 
>> System : 13th Gen Intel(R) Core(TM) i3-1315U
>> 
>> Baseline:
>> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
>> VectorSliceB...
>
> Jatin Bhateja 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:
> 
>   Review comments resolution

src/hotspot/share/opto/callGenerator.hpp line 1:

> 1: /*

2024 -> 2025

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2278705851

From scolebourne at openjdk.org  Fri Aug 15 10:34:15 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Fri, 15 Aug 2025 10:34:15 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v4]
In-Reply-To: <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
Message-ID: <aElY2nzXve1s-OajB_H8StlgnZehnkkHMCB5GJbgH6U=.21f9b2e4-a469-47df-aee1-122fa7088fa2@github.com>

On Thu, 14 Aug 2025 23:49:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cases

Looks like a good solution to the problem, thanks.

-------------

Marked as reviewed by scolebourne (Author).

PR Review: https://git.openjdk.org/jdk/pull/26708#pullrequestreview-3123565912

From duke at openjdk.org  Fri Aug 15 11:19:10 2025
From: duke at openjdk.org (duke)
Date: Fri, 15 Aug 2025 11:19:10 GMT
Subject: RFR: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <Z0wp3YXswTbBWBV5NhqOC8G6QlVBPgClqCzTNXsHcVU=.1777816a-4066-4dab-a030-c0c8bf3c1097@github.com>
References: <Z0wp3YXswTbBWBV5NhqOC8G6QlVBPgClqCzTNXsHcVU=.1777816a-4066-4dab-a030-c0c8bf3c1097@github.com>
Message-ID: <b60IC6akkpopSUAanvIXvXmdewb9c9YnhQzhoHjJPLs=.28cc752c-7523-4fe1-bf9d-f04a00da634a@github.com>

On Thu, 14 Aug 2025 09:34:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Changed test helper creation to know about linkable images, and changed how test skipping is reported (JUnit doesn't honor TestSkippedException, only TestAbortedException).

@david-beaumont 
Your change (at version 0eac6a0ae97b33af29bc20c174a4b57a5c8c20be) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26774#issuecomment-3191280621

From lkorinth at openjdk.org  Fri Aug 15 11:43:33 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:43:33 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/dbe42964..8fa40e7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

PR: https://git.openjdk.org/jdk/pull/26749

From lkorinth at openjdk.org  Fri Aug 15 11:59:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:59:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <iWlp9Azqc_MsGBnk-PK8OYZqpcnhSASRJmnz8IgzTQI=.965cedce-3e5a-40e5-9e86-9b1f5c2d2021@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Added three new `/timeout=480` after the last run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3191343090

From syan at openjdk.org  Fri Aug 15 14:08:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 15 Aug 2025 14:08:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

make/RunTests.gmk line 940:

> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1

Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2279056261

From asemenyuk at openjdk.org  Fri Aug 15 14:48:13 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Aug 2025 14:48:13 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation [v2]
In-Reply-To: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
Message-ID: <ZUmbW9xId4M6XxEqnGDoMIjPLeak4NPPnsyXTr_PQ4I=.6f1ee591-75c4-4387-879c-a70424a2935f@github.com>

> - Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
>  - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
>  - Add tests for PackagingPipeline class.
>  - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
>  - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
>  - Add tests for BuildEnv class.

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - ResourceLocator: make ctor private. This class is not supposed to be instantiated. Improves the coverage.
 - Add a test case to JavaAppDescTest
 - MacDmgPackageBuilder: remove unused variable
 - Use MacBundle with AppImageSigner
 - BuildEnvFromParams: bugfix
 - Rename RuntimeBuilder.createRuntime() to RuntimeBuilder.create()
 - Test for PackagingPipeline
 - Get rid of AppImageDesc. It became redundant when AppImageLayout.rootDirectory() was added. Support using an external app image with a custom app image layout. Add ApplicationBuilder.overrideAppImageLayout(). Remove Package.packageLayout() and Package.asPackageApplicationLayout(). Create Linux and Mac packages with app image layout configured for packaging making PackagingPipeline.Builder.appImageLayoutForPackaging() redundant. Simplify PackagingPipeline. It always builds with application's app image layout. Don't wrap RuntimeException-s in PackagerException-s. Merge PackagingPipeline.appContextMapper and PackagingPipeline.pkgContextMapper into PackagingPipeline.contextMapper. Remove PackagingPipeline.Builder.appImageLayoutForPackaging(). Add MacPackage.guessRuntimeLayout()
 - Implementation Tweaks #1
 - Support custom runtime image layout in BuildEnvFromParams. Support custom runtime image layout for application in FromParams.createApplicationBuilder(). Set correct layout for predefined runtime image on macosx
 - ... and 6 more: https://git.openjdk.org/jdk/compare/2a0a46d5...9f33d8e2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26778/files
  - new: https://git.openjdk.org/jdk/pull/26778/files/0d2b451e..9f33d8e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26778&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26778&range=00-01

  Stats: 10205 lines in 296 files changed: 4593 ins; 4395 del; 1217 mod
  Patch: https://git.openjdk.org/jdk/pull/26778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26778/head:pull/26778

PR: https://git.openjdk.org/jdk/pull/26778

From asemenyuk at openjdk.org  Fri Aug 15 15:11:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Aug 2025 15:11:09 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation [v3]
In-Reply-To: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
Message-ID: <rZrzJF5tycfdF161v6FZtuGBP7jNk9loSvqdUTpcVXw=.884c31c3-b02f-4e06-bcc9-5d8ce922e2ff@github.com>

> - Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
>  - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
>  - Add tests for PackagingPipeline class.
>  - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
>  - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
>  - Add tests for BuildEnv class.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Fix issues uncovered when running signing tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26778/files
  - new: https://git.openjdk.org/jdk/pull/26778/files/9f33d8e2..099da666

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26778&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26778&range=01-02

  Stats: 17 lines in 3 files changed: 8 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26778/head:pull/26778

PR: https://git.openjdk.org/jdk/pull/26778

From asemenyuk at openjdk.org  Fri Aug 15 15:27:11 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Aug 2025 15:27:11 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation [v3]
In-Reply-To: <safILUlxOR5nO6sCr8UvgTOEX21EOl2WQ0SoMvOFwUs=.359137dd-c0a1-41b1-9bb0-f33bc176d2eb@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
 <safILUlxOR5nO6sCr8UvgTOEX21EOl2WQ0SoMvOFwUs=.359137dd-c0a1-41b1-9bb0-f33bc176d2eb@github.com>
Message-ID: <wa8QQnJWxoWuS78zR2jOQo6pzulMt8VpsuTQJjzlWGg=.1512ea3f-3f38-4215-b74e-757fd56043e4@github.com>

On Fri, 15 Aug 2025 00:45:24 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> make sure to run macOS signing tests

Good point! I caught a couple of bugs when running them. See the https://github.com/openjdk/jdk/pull/26778/commits/099da666b5eb15e5aa061ad8964879d54ec8238d commit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26778#issuecomment-3191794989

From ghan at openjdk.org  Fri Aug 15 15:27:54 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Fri, 15 Aug 2025 15:27:54 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name length
 early
Message-ID: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>

Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.

-------------

Commit messages:
 - 8328874: Class::forName0 should validate the class name length early

Changes: https://git.openjdk.org/jdk/pull/26802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328874
  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26802/head:pull/26802

PR: https://git.openjdk.org/jdk/pull/26802

From alanb at openjdk.org  Fri Aug 15 15:38:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Aug 2025 15:38:09 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early
In-Reply-To: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
Message-ID: <QI7YmnwAK37IeoLzqWiuGi7p4wL247I1z_pk4SlqxhY=.f8c425ac-cea9-46cc-93d8-547d902daae5@github.com>

On Fri, 15 Aug 2025 15:19:35 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.

src/java.base/share/native/libjava/Class.c line 119:

> 117:         JNU_ThrowClassNotFoundException(env, msg);
> 118:         return 0;
> 119:     }

I wonder if it's time to hoist these checks so that the checking is in a more discoverable place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2279296271

From liach at openjdk.org  Fri Aug 15 15:47:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Aug 2025 15:47:09 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early
In-Reply-To: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
Message-ID: <sR_jgJCle6sa9o1lyyjhdr6GqqEGjE8OKbigfgKww7Y=.be93d9f1-2932-4864-8204-3e21343f9d35@github.com>

On Fri, 15 Aug 2025 15:19:35 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.

We currently have a trend of moving argument validations and checks to pure Java code, to minimize downcall into the VM (whose code cannot be optimized by compilers). Even if we keep checks in the VM, I guess jvm.cpp might be a better place than Class.c.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3191926599

From naoto at openjdk.org  Fri Aug 15 16:52:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Aug 2025 16:52:01 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v5]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  copyright year update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/fa198b88..7523e344

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From swen at openjdk.org  Fri Aug 15 20:08:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 15 Aug 2025 20:08:46 GMT
Subject: RFR: 8365620: Using enhanced switch in MethodHandleDesc
Message-ID: <T0XtV9qhLIv7m9KzwPU4v0_T0b7WdCagiSu7wxlkP4M=.2fe32d54-adba-4a1f-a738-9a5c76b76d2c@github.com>

In MethodHandleDesc, the `ofField` method uses enhanced switch, while the `of` and `ofMethod` methods use traditional switch. The same class should have a unified style.

-------------

Commit messages:
 - from @liach
 - enhanced switch

Changes: https://git.openjdk.org/jdk/pull/26769/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26769&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365620
  Stats: 26 lines in 1 file changed: 0 ins; 14 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/26769.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26769/head:pull/26769

PR: https://git.openjdk.org/jdk/pull/26769

From liach at openjdk.org  Fri Aug 15 20:08:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Aug 2025 20:08:46 GMT
Subject: RFR: 8365620: Using enhanced switch in MethodHandleDesc
In-Reply-To: <T0XtV9qhLIv7m9KzwPU4v0_T0b7WdCagiSu7wxlkP4M=.2fe32d54-adba-4a1f-a738-9a5c76b76d2c@github.com>
References: <T0XtV9qhLIv7m9KzwPU4v0_T0b7WdCagiSu7wxlkP4M=.2fe32d54-adba-4a1f-a738-9a5c76b76d2c@github.com>
Message-ID: <Y1SKAqXc0SJR1jyhR9OG294XmnbdYsE3mGwNAb2rsew=.1ae65875-889e-4cc7-bb39-3981f5c261c3@github.com>

On Thu, 14 Aug 2025 04:49:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In MethodHandleDesc, the `ofField` method uses enhanced switch, while the `of` and `ofMethod` methods use traditional switch. The same class should have a unified style.

src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java line 123:

> 121:             case VIRTUAL, SPECIAL, INTERFACE_VIRTUAL, INTERFACE_SPECIAL, INTERFACE_STATIC, STATIC, CONSTRUCTOR
> 122:                     -> new DirectMethodHandleDescImpl(kind, owner, name, lookupMethodType);
> 123:             default -> throw new IllegalArgumentException(kind.toString());

I recommend using `case GETTER, SETTER, STATIC_GETTER, STATIC_SETTER` explicitly in case we have more kinds in the future, this will become a compile error and remind us to update. And we can remove the default branch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26769#discussion_r2278135364

From swen at openjdk.org  Fri Aug 15 20:08:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 15 Aug 2025 20:08:46 GMT
Subject: RFR: 8365620: Using enhanced switch in MethodHandleDesc
In-Reply-To: <Y1SKAqXc0SJR1jyhR9OG294XmnbdYsE3mGwNAb2rsew=.1ae65875-889e-4cc7-bb39-3981f5c261c3@github.com>
References: <T0XtV9qhLIv7m9KzwPU4v0_T0b7WdCagiSu7wxlkP4M=.2fe32d54-adba-4a1f-a738-9a5c76b76d2c@github.com>
 <Y1SKAqXc0SJR1jyhR9OG294XmnbdYsE3mGwNAb2rsew=.1ae65875-889e-4cc7-bb39-3981f5c261c3@github.com>
Message-ID: <I6rv7hw4hXDrd1vVV5KRebfK-Xh-mgc4GdYBe2YWrkc=.63ca8d3d-ab79-486f-9f78-f67c7e5eaece@github.com>

On Fri, 15 Aug 2025 03:08:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In MethodHandleDesc, the `ofField` method uses enhanced switch, while the `of` and `ofMethod` methods use traditional switch. The same class should have a unified style.
>
> src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java line 123:
> 
>> 121:             case VIRTUAL, SPECIAL, INTERFACE_VIRTUAL, INTERFACE_SPECIAL, INTERFACE_STATIC, STATIC, CONSTRUCTOR
>> 122:                     -> new DirectMethodHandleDescImpl(kind, owner, name, lookupMethodType);
>> 123:             default -> throw new IllegalArgumentException(kind.toString());
> 
> I recommend using `case GETTER, SETTER, STATIC_GETTER, STATIC_SETTER` explicitly in case we have more kinds in the future, this will become a compile error and remind us to update. And we can remove the default branch.

If we remove the default case, unexpected behavior may occur when DirectMethodHandleDesc.Kind adds new enum values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26769#discussion_r2278420230

From duke at openjdk.org  Fri Aug 15 20:08:46 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 15 Aug 2025 20:08:46 GMT
Subject: RFR: 8365620: Using enhanced switch in MethodHandleDesc
In-Reply-To: <I6rv7hw4hXDrd1vVV5KRebfK-Xh-mgc4GdYBe2YWrkc=.63ca8d3d-ab79-486f-9f78-f67c7e5eaece@github.com>
References: <T0XtV9qhLIv7m9KzwPU4v0_T0b7WdCagiSu7wxlkP4M=.2fe32d54-adba-4a1f-a738-9a5c76b76d2c@github.com>
 <Y1SKAqXc0SJR1jyhR9OG294XmnbdYsE3mGwNAb2rsew=.1ae65875-889e-4cc7-bb39-3981f5c261c3@github.com>
 <I6rv7hw4hXDrd1vVV5KRebfK-Xh-mgc4GdYBe2YWrkc=.63ca8d3d-ab79-486f-9f78-f67c7e5eaece@github.com>
Message-ID: <roSVwPdS_oXkFwVfIliHbuMZtU0wUX0rMhwjSzfvcoY=.2fc5cfac-106e-4dc2-91a4-3863e564beec@github.com>

On Fri, 15 Aug 2025 06:57:14 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java line 123:
>> 
>>> 121:             case VIRTUAL, SPECIAL, INTERFACE_VIRTUAL, INTERFACE_SPECIAL, INTERFACE_STATIC, STATIC, CONSTRUCTOR
>>> 122:                     -> new DirectMethodHandleDescImpl(kind, owner, name, lookupMethodType);
>>> 123:             default -> throw new IllegalArgumentException(kind.toString());
>> 
>> I recommend using `case GETTER, SETTER, STATIC_GETTER, STATIC_SETTER` explicitly in case we have more kinds in the future, this will become a compile error and remind us to update. And we can remove the default branch.
>
> If we remove the default case, unexpected behavior may occur when DirectMethodHandleDesc.Kind adds new enum values.

That?won?t?happen as?this is?an?enhanced switch?expression, which?must be?exhaustive at?compile?time (and?gets?an?implicit `throw?new?MatchException(?)` default?clause for?exhaustiveness checking?at?runtime).

Suggestion:

            case GETTER, SETTER, STATIC_GETTER, STATIC_SETTER
                -> throw new IllegalArgumentException(kind.toString());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26769#discussion_r2278557045

From almatvee at openjdk.org  Fri Aug 15 21:11:13 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 15 Aug 2025 21:11:13 GMT
Subject: RFR: 8365555: Cleanup redundancies in jpackage implementation [v3]
In-Reply-To: <rZrzJF5tycfdF161v6FZtuGBP7jNk9loSvqdUTpcVXw=.884c31c3-b02f-4e06-bcc9-5d8ce922e2ff@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
 <rZrzJF5tycfdF161v6FZtuGBP7jNk9loSvqdUTpcVXw=.884c31c3-b02f-4e06-bcc9-5d8ce922e2ff@github.com>
Message-ID: <yL6tFpUuXCgcYG_nk1TSfgMeHGNzPzEC5eVz18WJgss=.4998b0f0-2dc2-427a-baf3-1a380fbe6412@github.com>

On Fri, 15 Aug 2025 15:11:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
>>  - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
>>  - Add tests for PackagingPipeline class.
>>  - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
>>  - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
>>  - Add tests for BuildEnv class.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issues uncovered when running signing tests

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26778#pullrequestreview-3125174254

From asemenyuk at openjdk.org  Sat Aug 16 04:44:29 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 16 Aug 2025 04:44:29 GMT
Subject: Integrated: 8365555: Cleanup redundancies in jpackage implementation
In-Reply-To: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
References: <dvSDvVqlV8vsKBopsPoyzf9Ca6aQQjwAG9AlQniMDtM=.17cbb157-c1c4-4910-acf2-735654023df4@github.com>
Message-ID: <SPOqktofn77eYHCsrtvRAGNGoYz9Gcx8xSYlQsTUf4E=.280d78e3-7f05-40d9-8473-f28f43cf1aa6@github.com>

On Thu, 14 Aug 2025 13:35:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Remove AppImageDesc class. It was supposed to bind an AppImageLayout instance with a root directory, but since AppImageLayout has `rootDirectory()` method it is redundant.
>  - Remove redundant `Package.packageLayout()` and `Package.asPackageApplicationLayout()` methods from the model, 
>  - Add tests for PackagingPipeline class.
>  - Move JUnitAdapter.java from "/test/jdk/tools/jpackage/helpers-test" to "/test/jdk/tools/jpackage/junit/tools" directory, support running platform-specific JUnit tests.
>  - Enhance AppImageLayout class, add unit tests for derived MacApplicationLayout and LinuxApplicationLayout classes.
>  - Add tests for BuildEnv class.

This pull request has now been integrated.

Changeset: 57210af9
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57210af9bceb582be112564465ab66cebd43a4c0
Stats:     2365 lines in 56 files changed: 1921 ins; 229 del; 215 mod

8365555: Cleanup redundancies in jpackage implementation

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/26778

From duke at openjdk.org  Sat Aug 16 15:09:18 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 16 Aug 2025 15:09:18 GMT
Subject: RFR: 8077587: BigInteger Roots [v73]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <DfOgINtE8hQLdFnOpbrLzmteptSvP7B2nUcc0xZf7hQ=.a43264a3-51e2-409d-af66-8b6b8108361b@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Ensure root's overestimate in for loop

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/908b6915..4ff90bbf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=72
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=71-72

  Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From perini.davide at dpsoftware.org  Sun Aug 17 11:08:18 2025
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Sun, 17 Aug 2025 13:08:18 +0200
Subject: jpackage, wix and custom action
Message-ID: <c296ee48-5230-421c-b38f-94047d2170e6@dpsoftware.org>

Hi there.

Is it possible to create a custom action with jpackage+wix to launch the 
application as soon as the installation is finished?

I find nothing on the internet on this but it should be so simple to do it.

Is there someone who can guide us on how to do it please?

Thanks
Davide

From jpai at openjdk.org  Mon Aug 18 04:49:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 04:49:28 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - merge latest from master branch
 - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

-------------

Changes: https://git.openjdk.org/jdk/pull/26776/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26776&range=01
  Stats: 27 lines in 7 files changed: 0 ins; 22 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26776/head:pull/26776

PR: https://git.openjdk.org/jdk/pull/26776

From alanb at openjdk.org  Mon Aug 18 06:04:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Aug 2025 06:04:14 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
 <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
Message-ID: <H_tMMP8u5UzbkC9lwzvo4NTkFdDGg0x_baZZ07tg5Ig=.12c19630-073e-46aa-bf94-cb26b566f87a@github.com>

On Mon, 18 Aug 2025 04:49:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
>> 
>> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
>> 
>> tier1, tier2 and tier3 testing of this change completed without any related failures.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge latest from master branch
>  - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26776#pullrequestreview-3126883742

From jpai at openjdk.org  Mon Aug 18 06:48:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 06:48:19 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
 <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
Message-ID: <s6oGXOyF-XsFhvS6dqVXvNZ0OScyeuTwolxjCYzYvr0=.89d24294-775a-4d26-ac51-c09c5d29b955@github.com>

On Mon, 18 Aug 2025 04:49:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
>> 
>> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
>> 
>> tier1, tier2 and tier3 testing of this change completed without any related failures.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge latest from master branch
>  - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

Thank you Alan and Chen for the reviews.

tier1, tier2 and tier3 testing with this change completed without any related issues.

> In addition, `PreviewFeature.Feature` enum has a few obsolete entries ... Now the boot JDK is min 24, and a few of the features are already permanent in 24.

I'll file a separate issue to clean those up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3195338107

From duke at openjdk.org  Mon Aug 18 07:11:25 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 18 Aug 2025 07:11:25 GMT
Subject: Integrated: 8365436: ImageReaderTest fails when jmods directory not
 present
In-Reply-To: <Z0wp3YXswTbBWBV5NhqOC8G6QlVBPgClqCzTNXsHcVU=.1777816a-4066-4dab-a030-c0c8bf3c1097@github.com>
References: <Z0wp3YXswTbBWBV5NhqOC8G6QlVBPgClqCzTNXsHcVU=.1777816a-4066-4dab-a030-c0c8bf3c1097@github.com>
Message-ID: <S-bigXjrDgjJSWRlZ5660oEJmMR0Oza5Hij20CTtCmQ=.cf8a1b78-5161-4741-bbfc-79b1d09f877d@github.com>

On Thu, 14 Aug 2025 09:34:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Changed test helper creation to know about linkable images, and changed how test skipping is reported (JUnit doesn't honor TestSkippedException, only TestAbortedException).

This pull request has now been integrated.

Changeset: e7ca8c7d
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7ca8c7d55fa959cb43d49d63128420b05b7cc92
Stats:     12 lines in 1 file changed: 6 ins; 4 del; 2 mod

8365436: ImageReaderTest fails when jmods directory not present

Reviewed-by: sgehwolf, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/26774

From duke at openjdk.org  Mon Aug 18 08:11:01 2025
From: duke at openjdk.org (Johny Jose)
Date: Mon, 18 Aug 2025 08:11:01 GMT
Subject: RFR: 8365398: TEST_BUG:
 java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing
 intermittently
Message-ID: <ARjI44UG551o1xr4FOT8ezBDuSnuH0svvgwNOVMuvZs=.050eb1e6-f771-4c23-8d37-84506bf889cf@github.com>

Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6

-------------

Commit messages:
 - 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently

Changes: https://git.openjdk.org/jdk/pull/26815/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26815&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365398
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26815.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26815/head:pull/26815

PR: https://git.openjdk.org/jdk/pull/26815

From vyazici at openjdk.org  Mon Aug 18 08:24:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 18 Aug 2025 08:24:20 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v16]
In-Reply-To: <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com>
Message-ID: <vEyqS52q-BxZOH7WjgfZOP5TndVQAzhiKvM98eFyvB4=.488027ce-a77e-4a5f-a2cd-7c2251666807@github.com>

On Fri, 15 Aug 2025 08:39:20 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Document tests using `-XX:+VerifyIntrinsicChecks` don't check out-of-range conditions
>  - Document why `Preconditions` is not used

[JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842), addressed by this PR, is the first step in a series of similar improvements under the [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) umbrella issue. I wanted to get this one in perfect shape to serve as a guide for the subsequent PRs, hence the meticulous effort. Thanks so much to everyone helped with reviewing this work. ? ?

I've verified that `tier1,tier2,tier3,tier4,tier5,hs-comp-stress,hs-precheckin-comp` passes for 2ba4ba6f455 on several platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3195628634

From lkorinth at openjdk.org  Mon Aug 18 09:10:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:10:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
Message-ID: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>

On Fri, 15 Aug 2025 14:05:49 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD
>
> make/RunTests.gmk line 940:
> 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
>> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1
> 
> Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2281781536

From lkorinth at openjdk.org  Mon Aug 18 09:18:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:18:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
Message-ID: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>

On Mon, 18 Aug 2025 09:07:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> make/RunTests.gmk line 940:
>> 
>>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>>> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
>>> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1
>> 
>> Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()
>
> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

It is also something that can be changed later, in a follow up fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2281802454

From vyazici at openjdk.org  Mon Aug 18 09:21:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 18 Aug 2025 09:21:12 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v5]
In-Reply-To: <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
Message-ID: <3v62VnuJiyQ7CWHZt2fcDULp6ToDtFLr1G8IXqAFkx0=.875ef0ae-c69d-4993-a758-621dab89d123@github.com>

On Fri, 15 Aug 2025 16:52:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year update

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26708#pullrequestreview-3127527503

From lkorinth at openjdk.org  Mon Aug 18 09:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
 <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
Message-ID: <3l5I9q7S4O_0gH6mvxy3P21f1JxqcQKNsnBTN7rWhmc=.ddcf4337-dc6e-493d-ae07-5bd4affb9321@github.com>

On Thu, 14 Aug 2025 19:30:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> Would you mind also running tier9 to avoid surprises there.

I had problems doing this, and I just want to say that I have not run tier9 (I have talked to Douglas off-list).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195900610

From lkorinth at openjdk.org  Mon Aug 18 09:43:14 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:43:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <9GMJWT-CNwqDVALuPdRR9EDs5G1c2jUr3y887qw2_EU=.1a7347a2-d1e5-427d-aeda-6924e2db39ba@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

If there are no mayor objections, I will update the copyrights before I leave work today.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195923727

From dfuchs at openjdk.org  Mon Aug 18 11:38:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 11:38:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:


	java/net/httpclient/CancelledResponse.java
	java/net/httpclient/whitebox/FlowTestDriver.java


The	first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196281299

From rgiulietti at openjdk.org  Mon Aug 18 13:08:11 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Aug 2025 13:08:11 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <SgyqhFlGbzacV_bV9cWNYUiwfVeIwt9PaQnbFSzyc3c=.52676b13-0e61-49d4-bfbf-528c3fd67934@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
 <o9PEv-AjuFI373A-GJqunNxwL_xxxm4erHyqFn2uEVs=.404dd4e1-cd90-4db5-bc27-254d1c740fb0@github.com>
 <SgyqhFlGbzacV_bV9cWNYUiwfVeIwt9PaQnbFSzyc3c=.52676b13-0e61-49d4-bfbf-528c3fd67934@github.com>
Message-ID: <zzQJxUf8uS-jS6-_Oi34rVO952yeaB7cQnwkv86BAyU=.d8646525-32aa-4984-bebb-e61d69d85f7d@github.com>

On Thu, 17 Jul 2025 19:37:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Good to see this enhancement, Raffaello. Are you planning to provide some test cases for the change, confirming the implementation switches between old/new depending on the system property?
>
>> @naotoj Do you mean adding a test with values known to have slightly different outcomes? Sure, will do.
> 
> Yes, as in the JBS issue

@naotoj I'm requesting a review because of a merge with conflict resolved by hand. Tier1-3 pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26364#issuecomment-3196750262

From rriggs at openjdk.org  Mon Aug 18 13:15:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 13:15:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings.  The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196793327

From rgiulietti at openjdk.org  Mon Aug 18 13:26:12 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Aug 2025 13:26:12 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v8]
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <hsOgY6PV7oL6hnf9Hei5fouDy80tDnVMox4Wm7cpInE=.35f5aec4-fe97-46b5-9dad-bdeee878c1a9@github.com>

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into 8362448
 - Merge branch 'master' into 8362448
 - Merge master.
 - Refactoring to paramaterized tests.
 - Removed temporary comment from tests.
 - Added tests.
 - Added comment to COMPAT static field.
 - Merge branch 'master' into 8362448
 - 8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
 - Remove some unused methods from FloatingDecimal.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/c1198bba...52bff4c1

-------------

Changes: https://git.openjdk.org/jdk/pull/26364/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26364&range=07
  Stats: 190 lines in 7 files changed: 140 ins; 7 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/26364.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26364/head:pull/26364

PR: https://git.openjdk.org/jdk/pull/26364

From jpai at openjdk.org  Mon Aug 18 13:43:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 13:43:23 GMT
Subject: Integrated: 8365533: Remove outdated jdk.internal.javac package export
 to several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <rGcu60RTmmtT0IhftuIgwKa33UyYiopBA9D4Oal7op0=.b4692860-d62b-426b-a248-63030d11fa6f@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

This pull request has now been integrated.

Changeset: 81c6ed38
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81c6ed38828940d51c872c354c29dc13ed62a5ac
Stats:     27 lines in 7 files changed: 0 ins; 22 del; 5 mod

8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

Reviewed-by: alanb, liach

-------------

PR: https://git.openjdk.org/jdk/pull/26776

From jpai at openjdk.org  Mon Aug 18 14:23:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 14:23:16 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <s6oGXOyF-XsFhvS6dqVXvNZ0OScyeuTwolxjCYzYvr0=.89d24294-775a-4d26-ac51-c09c5d29b955@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
 <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
 <s6oGXOyF-XsFhvS6dqVXvNZ0OScyeuTwolxjCYzYvr0=.89d24294-775a-4d26-ac51-c09c5d29b955@github.com>
Message-ID: <GyH3rTfRAPhV2t0UQNd3v5tucgnj1GlhkNTLz30emJ4=.075a85a3-06ad-40ef-8cfc-94be7c608801@github.com>

On Mon, 18 Aug 2025 06:45:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > In addition, `PreviewFeature.Feature` enum has a few obsolete entries ... Now the boot JDK is min 24, and a few of the features are already permanent in 24.
> 
> I'll file a separate issue to clean those up.

I've now filed https://bugs.openjdk.org/browse/JDK-8365699 to track this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3197140201

From lkorinth at openjdk.org  Mon Aug 18 14:34:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 14:34:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
Message-ID: <lSUzoh2lhdmeEPYY2eAAGIycS8QSm5_9BLFy7FgOfFw=.f7a8acc4-ead5-4625-9d3c-83a345212193@github.com>

On Mon, 18 Aug 2025 13:12:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings. The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

Noted. I did it so reviewers could se the change "as a whole". Feel free to review a part of the change!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197186029

From lmesnik at openjdk.org  Mon Aug 18 15:01:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 18 Aug 2025 15:01:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <O_WRSR2Q7KM1CWMYPxfXyFQI3lU9AjTOklWNVYAxvUk=.387e933f-0eed-43d8-a2eb-dbe2dd98cc75@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Thank you for fixing this! I think the changes are good.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3128749995

From alexey.semenyuk at oracle.com  Mon Aug 18 15:12:09 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 18 Aug 2025 11:12:09 -0400
Subject: jpackage, wix and custom action
In-Reply-To: <c296ee48-5230-421c-b38f-94047d2170e6@dpsoftware.org>
References: <c296ee48-5230-421c-b38f-94047d2170e6@dpsoftware.org>
Message-ID: <ac8776b2-37d7-4f93-adc1-b968c4ffc942@oracle.com>

Hi Davide,

I've answered this question on another mail list already, see [1].

[1] 
https://mail.openjdk.org/pipermail/client-libs-dev/2025-April/027426.html

- Alexey

On 8/17/2025 7:08 AM, Davide Perini wrote:
> Hi there.
>
> Is it possible to create a custom action with jpackage+wix to launch 
> the application as soon as the installation is finished?
>
> I find nothing on the internet on this but it should be so simple to 
> do it.
>
> Is there someone who can guide us on how to do it please?
>
> Thanks
> Davide


From liach at openjdk.org  Mon Aug 18 15:49:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 15:49:18 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v16]
In-Reply-To: <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com>
Message-ID: <0IvasB1atRajkt5C286w66VPeNSPBvh1LNzZMIeKv0s=.a6e6f723-27fa-458d-94ae-58b20b57fee2@github.com>

On Fri, 15 Aug 2025 08:39:20 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Document tests using `-XX:+VerifyIntrinsicChecks` don't check out-of-range conditions
>  - Document why `Preconditions` is not used

Looks good in principle; didn't check in the details for compiler code, which I don't necessarily understand.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3128936303

From naoto at openjdk.org  Mon Aug 18 16:02:13 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 16:02:13 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v8]
In-Reply-To: <hsOgY6PV7oL6hnf9Hei5fouDy80tDnVMox4Wm7cpInE=.35f5aec4-fe97-46b5-9dad-bdeee878c1a9@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <hsOgY6PV7oL6hnf9Hei5fouDy80tDnVMox4Wm7cpInE=.35f5aec4-fe97-46b5-9dad-bdeee878c1a9@github.com>
Message-ID: <Aysngd8BySGcY89JAJXQc3aO8ez9579YttgivCwx96Q=.3667deb4-481c-4fbd-b1bd-5461c3e510c5@github.com>

On Mon, 18 Aug 2025 13:26:12 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into 8362448
>  - Merge branch 'master' into 8362448
>  - Merge master.
>  - Refactoring to paramaterized tests.
>  - Removed temporary comment from tests.
>  - Added tests.
>  - Added comment to COMPAT static field.
>  - Merge branch 'master' into 8362448
>  - 8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
>  - Remove some unused methods from FloatingDecimal.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/c1198bba...52bff4c1

LGTM as before

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26364#pullrequestreview-3128984140

From rgiulietti at openjdk.org  Mon Aug 18 16:15:25 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Aug 2025 16:15:25 GMT
Subject: Integrated: 8362448: Make use of the Double.toString(double) algorithm
 in java.text.DecimalFormat
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <TT6983mEefZmoqXlgcmHwY6OHgrPFxSlH-0eOSRu3rU=.235c7ca5-947b-4231-bedf-9baf093645ed@github.com>

On Thu, 17 Jul 2025 10:04:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

This pull request has now been integrated.

Changeset: 285adff2
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/285adff24e869b62397d4d1c14e6e969f3285836
Stats:     190 lines in 7 files changed: 140 ins; 7 del; 43 mod

8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat

Reviewed-by: naoto, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/26364

From stevenschlansker at gmail.com  Mon Aug 18 16:18:39 2025
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Mon, 18 Aug 2025 09:18:39 -0700
Subject: Generic type signatures in MethodRepository have many copies of
 simple class names
In-Reply-To: <14C49006-FC38-4610-8D77-F0D7A3D1429C@gmail.com>
References: <FC1D50CF-6C71-4250-937F-CB4821E1303B@gmail.com>
 <a64d370b-6a16-49c4-83c3-8af76d7bafcc@civilian-framework.org>
 <14C49006-FC38-4610-8D77-F0D7A3D1429C@gmail.com>
Message-ID: <56BBAC56-CCD2-449F-8D2F-820F63F17C6C@gmail.com>


> On Aug 11, 2025, at 9:44?AM, Steven Schlansker <stevenschlansker at gmail.com> wrote:
> 
>> 
>> On Aug 10, 2025, at 2:29?PM, Johannes D?bler <jd at civilian-framework.org> wrote:
>> 
>> Hi Steven,
>> 
>> I think you are onto something. Given this example
>> 
>>> public class TypeParamsDemo {
>>>    public static void main(String[] args) throws Exception {
>>>        Method method = TypeParamsDemo.class.getMethod("getList", Set.class);
>>>        TypeVariable<Method>[] tp = method.getTypeParameters();
>>>    }
>>> 
>>>    public <T extends Number> List<T> getList(Set<T> set) {
>>>        return new ArrayList<>(set);
>>>    }
>>> }
>> 
>> Then:
>> tp[0].bounds[0].path[0].name is "java.lang.Number" and  is a newly created String parsed from the type signature "<T:Ljava/lang/Number;>(Ljava/util/Set<TT;>;)Ljava/util/List<TT;>;".
>> The result of method.getTypeParameters() is cached in Method.genericInfo, so once initialized by a caller (e.g. by Jackson/REST easy) it won't go away.
>> Imho interning the class name should be fine since it refers to an existing class.
>> 
>> Best
>> Johannes
>> 
> 
> Thank you for your analysis Johannes.
> I've opened https://github.com/openjdk/jdk/pull/26730 with my proposed change.
> 

It seems that I need a bug issue open in order to proceed any further.
Is anyone able to create a bug report and potentially sponsor this change? Thank you!

Steven


>> 
>> On 09/08/2025 01:10, Steven Schlansker wrote:
>>> Hello core-libs-dev, happy Friday!
>>> 
>>> While diagnosing an out of memory situation in our application, I noticed a surprising source of memory usage.
>>> While this is not so severe to actually cause our OOM, it seems wasteful and I thought to bring it to your attention.
>>> 
>>> We use reflection-based technologies like Jackson JSON and RESTEasy that retrieve generic type information from many of our classes.
>>> Our profiler provides diagnostics of wasted space due to duplicate objects, particularly Strings.
>>> 
>>> The analysis highlights many thousands of copies of String instances holding the full name of a class, e.g. "java.util.Optional"
>>> or "com.mycompany.Id". The path to GC route looks like:
>>> 
>>> String <- sun.reflect.generics.tree.SimpleClassTypeSignature <- Object[] <- ArrayList <- ClassTypeSignature <- MethodTypeSignature <- MethodRepository <- Method
>>> 
>>> Seeing how these SimpleClassTypeSignature instances are created, it looks like they come from the sun.reflect.generics.parser.SignatureParser which calls
>>> `input.substring(mark, index)`, possibly with a call to `replace('/', '.')` to munge the package name. In all but the simplest of cases, this will return a new String
>>> for every call.
>>> 
>>> Since this String is representing a Class name, the cardinality should by its nature be very low. For each unique type, there will be many methods referring to it.
>>> Additionally, this generic information is lazy-loaded at most once per Method object.
>>> 
>>> Therefore, SimpleClassTypeSignature.n seems like a natural place to apply String.intern(), for example changing:
>>> 
>>> public static SimpleClassTypeSignature make(String n,
>>>    boolean dollar,
>>>    TypeArgument[] tas){
>>>        return new SimpleClassTypeSignature(n, dollar, tas);
>>> }
>>> 
>>> to intern the name:
>>> 
>>> public static SimpleClassTypeSignature make(String n,
>>>    boolean dollar,
>>>    TypeArgument[] tas){
>>>        return new SimpleClassTypeSignature(n.intern(), dollar, tas);
>>> }
>>> 
>>> With any luck, maybe this can even share the same string instance as the class itself uses.
>>> Am I correct in thinking this would be a moderately nice improvement, for a relatively cheap cost?
>>> Or perhaps there's some reason this isn't a good idea?
>>> 
>>> Thank you for your thoughts on the subject,
>>> Steven



From rriggs at openjdk.org  Mon Aug 18 16:19:18 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 16:19:18 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives [v2]
In-Reply-To: <RAEVEwPQn9HITx6gFkIQ-J0jRPhaju86-SmeTFuIxUA=.613dbc86-fdae-4e18-af47-658aba03b557@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
 <RAEVEwPQn9HITx6gFkIQ-J0jRPhaju86-SmeTFuIxUA=.613dbc86-fdae-4e18-af47-658aba03b557@github.com>
Message-ID: <cKknZmzvSGiE7d86dKXGGa1i2rsRnLE8DK-T2POkn6s=.7347ecd1-405b-44d1-9bdd-26e32303bb46@github.com>

On Fri, 1 Aug 2025 13:15:29 GMT, Brett Okken <duke at openjdk.org> wrote:

>> As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coding conventions

looks good.

Its fine to integrate the performance improvement as-is, if improvements are warranted, they can be applied more broadly in a later PR.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26597#pullrequestreview-3129049010
PR Comment: https://git.openjdk.org/jdk/pull/26597#issuecomment-3197573017

From lkorinth at openjdk.org  Mon Aug 18 16:34:21 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:21 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  after suggestion from Daniel

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/8fa40e7d..286a2cc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=02-03

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

PR: https://git.openjdk.org/jdk/pull/26749

From lkorinth at openjdk.org  Mon Aug 18 16:34:22 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:22 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
Message-ID: <KNNxBq11P7lT_D16Mzwx-_VHkNITiw5wQbuYCf58yQI=.cdcf7871-b20c-4e44-b10e-c6108e647afb@github.com>

On Mon, 18 Aug 2025 11:34:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:
> 
> ```
> 	java/net/httpclient/CancelledResponse.java
> 	java/net/httpclient/whitebox/FlowTestDriver.java
> ```
> 
> The first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

Fixed! Thanks for helping!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197614389

From rriggs at openjdk.org  Mon Aug 18 16:38:19 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 16:38:19 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v16]
In-Reply-To: <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com>
Message-ID: <RbqiZSS3znFG-sLrsACuXDDAHCvKhSjQI7jrWBGWa7Q=.29093649-0dc2-41f9-b8d7-ba4b624de293@github.com>

On Fri, 15 Aug 2025 08:39:20 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Document tests using `-XX:+VerifyIntrinsicChecks` don't check out-of-range conditions
>  - Document why `Preconditions` is not used

looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3129121186

From dfuchs at openjdk.org  Mon Aug 18 16:46:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 16:46:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <a3CwlSQwHYj_F3fC30zoiDhXf9G-cn5xK8ZwVFmxBd0=.afdaf352-e494-4bc6-adf2-dc5afa0dd4b9@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

Thanks! Changes to JNDI / net / httpclient LGTM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197675337

From rriggs at openjdk.org  Mon Aug 18 18:16:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 18:16:17 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v5]
In-Reply-To: <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
Message-ID: <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>

On Fri, 15 Aug 2025 16:52:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year update

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 1205:

> 1203:      * {@link DateTimeFormatterBuilder#appendOffset(String, String)
> 1204:      * appendOffset("+HH", "Z")} in lenient mode will be used to parse the offset,
> 1205:      * converting the instant to UTC as necessary.

Suggestion:

     * When parsing, the lenient mode behavior of
     * {@link DateTimeFormatterBuilder#appendOffset(String, String)
     * appendOffset("+HH", "Z")} will be used to parse the offset,
     * converting the instant to UTC as necessary.

The phrase "in lenient mode" after the mention of appendOffset made me think the caller had to set lenient mode.
Here and below in DateTimeFormatterBiulder.java.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3893:

> 3891:                     .appendFraction(NANO_OF_SECOND, minDigits, maxDigits, true)
> 3892:                     .parseLenient()
> 3893:                     .appendOffset("+HH", "Z")

The "+HH" pattern is supposed to be ignoring minutes and seconds but it does not appear to.  In jshell, I see:

jshell> Instant.parse("2017-01-01T00:00:00.000-02:10:12")
$8 ==> 2017-01-01T02:10:12Z

It would be more consistent with the original pattern to use `"+HH:mm:ss"`

test/jdk/java/time/test/java/time/TestInstant.java line 170:

> 168:     @Test(dataProvider = "valid_instants")
> 169:     public void test_parse_valid(String instant) {
> 170:         Instant.parse(instant);

The test should verify the correct time is parsed.
And include cases where the minute and second are non-zero.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283043042
PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283113795
PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283096548

From naoto at openjdk.org  Mon Aug 18 19:14:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 19:14:08 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v6]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <1IFvzeiRjMlxZsy5dKIb-owi972J3jgN-K9Vry3E78g=.1afc0e1e-70ff-4712-a1ae-44f4b5039ffa@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/time/format/DateTimeFormatter.java
  
  Right. Changing to your suggested wording
  
  Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/7523e344..8bc222af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From naoto at openjdk.org  Mon Aug 18 19:19:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 19:19:08 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v7]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <7C6nMpOBczEFuUsCqtJjz1V_5ylyvL9-3PLcXjolg0g=.26469091-6b8a-43b1-a81a-b525691c1d55@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

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 nine additional commits since the last revision:

 - DateTimeFormatterBuilder wording
 - Added non-zero offset test cases
 - Merge branch 'master' into JDK-8364752-Instant-ISO8601
 - Update src/java.base/share/classes/java/time/format/DateTimeFormatter.java
   
   Right. Changing to your suggested wording
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - copyright year update
 - test cases
 - allow all ISO 8601 offsets
 - allow hour-only offsets
 - initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/8bc222af..0d78a520

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=05-06

  Stats: 16207 lines in 511 files changed: 8985 ins; 5233 del; 1989 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From naoto at openjdk.org  Mon Aug 18 19:19:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 19:19:17 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v5]
In-Reply-To: <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
 <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>
Message-ID: <OiWEUvmIMQdPXE9gPc004jGGJqmlj5-WVlTioYxFOBw=.27ffcbcd-54b5-4fb4-a80c-a73911a28b4c@github.com>

On Mon, 18 Aug 2025 18:12:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright year update
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3893:
> 
>> 3891:                     .appendFraction(NANO_OF_SECOND, minDigits, maxDigits, true)
>> 3892:                     .parseLenient()
>> 3893:                     .appendOffset("+HH", "Z")
> 
> The "+HH" pattern is supposed to be ignoring minutes and seconds but it does not appear to.  In jshell, I see:
> 
> jshell> Instant.parse("2017-01-01T00:00:00.000-02:10:12")
> $8 ==> 2017-01-01T02:10:12Z
> 
> It would be more consistent with the original pattern to use `"+HH:mm:ss"`

IIUC, "ignoring minutes and seconds" refers to formatting, i.e, "-02:10:12" only prints "-02" Parsing offsets in lenient mode always parses minute/seconds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283235663

From duke at openjdk.org  Mon Aug 18 20:15:43 2025
From: duke at openjdk.org (duke)
Date: Mon, 18 Aug 2025 20:15:43 GMT
Subject: RFR: 8364320: String encodeUTF8 latin1 with negatives [v2]
In-Reply-To: <RAEVEwPQn9HITx6gFkIQ-J0jRPhaju86-SmeTFuIxUA=.613dbc86-fdae-4e18-af47-658aba03b557@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
 <RAEVEwPQn9HITx6gFkIQ-J0jRPhaju86-SmeTFuIxUA=.613dbc86-fdae-4e18-af47-658aba03b557@github.com>
Message-ID: <fDs0lhJS_YeUD30Ge0ocvfyKy3XvPExgDxJHMkAB2f0=.3aa1b93d-beb2-411b-a9df-d1856b7f4db3@github.com>

On Fri, 1 Aug 2025 13:15:29 GMT, Brett Okken <duke at openjdk.org> wrote:

>> As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coding conventions

@bokken 
Your change (at version 26bd9d94c0e93e3b9872dc61c1c88eb2fd709434) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26597#issuecomment-3198282360

From rriggs at openjdk.org  Mon Aug 18 20:25:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 20:25:44 GMT
Subject: RFR: 8364751: ConstantBootstraps.explicitCast contradictory
 specification for null-to-primitive
In-Reply-To: <3FkADEF7XBhLXhzquFIsu2nVkpkGg6b8XBKp-X-Gk70=.d63a9bbf-095b-4947-a541-fbdcee3a1484@github.com>
References: <3FkADEF7XBhLXhzquFIsu2nVkpkGg6b8XBKp-X-Gk70=.d63a9bbf-095b-4947-a541-fbdcee3a1484@github.com>
Message-ID: <Sk7Ye37sQPoANpSzIMSDiKOJKb1CGGDYQ4H8IcIsGLE=.74f87f63-d4f8-4c73-9f3d-e6d3f9b51584@github.com>

On Sun, 10 Aug 2025 01:11:43 GMT, Chen Liang <liach at openjdk.org> wrote:

> ConstantBootstraps.explicitCast behaves like a snippet of code in its specification. However, in the rest of the nominal spec, it incorrectly assumes a null `value` and a primitive `dstType` results in a ClassCastException instead of the zero value of that primitive type. This is inconsistent with that snippet and the actual code behavior.
> 
> The specification is fixed, the test for `explicitCast` is merged into the main `ConstantBootstraps` test, and a new unit test case for `value = null` and `dstType = char.class` is added, verifying the outcome is `'u0000'`.

Looks ok; but another reviewer more familiar with the domain may be good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26714#pullrequestreview-3129796141

From liach at openjdk.org  Mon Aug 18 20:47:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 20:47:38 GMT
Subject: RFR: 8364751: ConstantBootstraps.explicitCast contradictory
 specification for null-to-primitive
In-Reply-To: <3FkADEF7XBhLXhzquFIsu2nVkpkGg6b8XBKp-X-Gk70=.d63a9bbf-095b-4947-a541-fbdcee3a1484@github.com>
References: <3FkADEF7XBhLXhzquFIsu2nVkpkGg6b8XBKp-X-Gk70=.d63a9bbf-095b-4947-a541-fbdcee3a1484@github.com>
Message-ID: <qgtmR8uScunGp3ODDkvSITGMf_vQlmq-0JcN8dM_vZw=.2ee88c18-e511-4395-8802-3e25a1c79d62@github.com>

On Sun, 10 Aug 2025 01:11:43 GMT, Chen Liang <liach at openjdk.org> wrote:

> ConstantBootstraps.explicitCast behaves like a snippet of code in its specification. However, in the rest of the nominal spec, it incorrectly assumes a null `value` and a primitive `dstType` results in a ClassCastException instead of the zero value of that primitive type. This is inconsistent with that snippet and the actual code behavior.
> 
> The specification is fixed, the test for `explicitCast` is merged into the main `ConstantBootstraps` test, and a new unit test case for `value = null` and `dstType = char.class` is added, verifying the outcome is `'u0000'`.

Yep, @JornVernee is on vacation; I expect Jorn's review later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26714#issuecomment-3198363192

From perini.davide at dpsoftware.org  Mon Aug 18 21:36:25 2025
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Mon, 18 Aug 2025 23:36:25 +0200
Subject: jpackage, wix and custom action
In-Reply-To: <ac8776b2-37d7-4f93-adc1-b968c4ffc942@oracle.com>
References: <c296ee48-5230-421c-b38f-94047d2170e6@dpsoftware.org>
 <ac8776b2-37d7-4f93-adc1-b968c4ffc942@oracle.com>
Message-ID: <4522c449-3404-416b-b785-4597ef8df15c@dpsoftware.org>

Hi Alexey,
I haven?t seen your reply on the other mailing list, sorry.

Your answer was the definitive solution to my problem.

I?ll leave my complete main.wxs here for future reference:
https://github.com/sblantipodi/build_tools/blob/master/wix/main.wxs

Thanks!
Davide


Il 18/08/2025 17:12, Alexey Semenyuk ha scritto:
> Hi Davide,
>
> I've answered this question on another mail list already, see [1].
>
> [1] 
> https://mail.openjdk.org/pipermail/client-libs-dev/2025-April/027426.html
>
> - Alexey
>
> On 8/17/2025 7:08 AM, Davide Perini wrote:
>> Hi there.
>>
>> Is it possible to create a custom action with jpackage+wix to launch 
>> the application as soon as the installation is finished?
>>
>> I find nothing on the internet on this but it should be so simple to 
>> do it.
>>
>> Is there someone who can guide us on how to do it please?
>>
>> Thanks
>> Davide
>


From rriggs at openjdk.org  Mon Aug 18 21:44:24 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 21:44:24 GMT
Subject: RFR: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
Message-ID: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>

Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
There is no decoding needed, and no exceptions expected or thrown when creating the string from the supplied latin1 bytes. 
If COMPACT_STRINGS is false, the bytes are inflated to UTF16.

-------------

Commit messages:
 - 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl

Changes: https://git.openjdk.org/jdk/pull/26831/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26831&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365719
  Stats: 81 lines in 7 files changed: 32 ins; 40 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26831/head:pull/26831

PR: https://git.openjdk.org/jdk/pull/26831

From alexey.semenyuk at oracle.com  Mon Aug 18 21:44:42 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 18 Aug 2025 17:44:42 -0400
Subject: [External] : Re: jpackage, wix and custom action
In-Reply-To: <4522c449-3404-416b-b785-4597ef8df15c@dpsoftware.org>
References: <c296ee48-5230-421c-b38f-94047d2170e6@dpsoftware.org>
 <ac8776b2-37d7-4f93-adc1-b968c4ffc942@oracle.com>
 <4522c449-3404-416b-b785-4597ef8df15c@dpsoftware.org>
Message-ID: <d3096b7a-6875-4ee2-88f0-f2ae57227a81@oracle.com>

Hi Davide,

It's good to know you found the solution. Thank you for sharing your 
code! It could be handy if we decide to make this a standard feature of 
jpackage.

- Alexey

On 8/18/2025 5:36 PM, Davide Perini wrote:
> Hi Alexey,
> I haven?t seen your reply on the other mailing list, sorry.
>
> Your answer was the definitive solution to my problem.
>
> I?ll leave my complete main.wxs here for future reference:
> https://urldefense.com/v3/__https://github.com/sblantipodi/build_tools/blob/master/wix/main.wxs__;!!ACWV5N9M2RV99hQ!PiWbO4ldDxIRYL2bctIcO9Bqdjq21wZkR-aRSsDzvyj3lZUYo-MKMH2ehZOXZDzyytOow_coUQDD1mvUU1kvXhpIy3X6KgpyFw$ 
>
> Thanks!
> Davide
>
>
> Il 18/08/2025 17:12, Alexey Semenyuk ha scritto:
>> Hi Davide,
>>
>> I've answered this question on another mail list already, see [1].
>>
>> [1] 
>> https://mail.openjdk.org/pipermail/client-libs-dev/2025-April/027426.html 
>>
>> - Alexey
>>
>> On 8/17/2025 7:08 AM, Davide Perini wrote:
>>> Hi there.
>>>
>>> Is it possible to create a custom action with jpackage+wix to launch 
>>> the application as soon as the installation is finished?
>>>
>>> I find nothing on the internet on this but it should be so simple to 
>>> do it.
>>>
>>> Is there someone who can guide us on how to do it please?
>>>
>>> Thanks
>>> Davide
>>
>


From jlu at openjdk.org  Mon Aug 18 22:13:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Aug 2025 22:13:53 GMT
Subject: Integrated: 8364780: Unicode extension clarifications for
 NumberFormat/DecimalFormatSymbols
In-Reply-To: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
Message-ID: <2lsuTxa7zfKW1N3K8UzlF2Mcz1InCvkgN60Kb3t7gLE=.cfb04e36-33b2-4547-a897-ba2703780684@github.com>

On Thu, 7 Aug 2025 21:47:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.
> 
> Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.

This pull request has now been integrated.

Changeset: a0053012
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0053012a4423725eac2411239bd28642ff3b321
Stats:     16 lines in 2 files changed: 6 ins; 0 del; 10 mod

8364780: Unicode extension clarifications for NumberFormat/DecimalFormatSymbols

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/26683

From rriggs at openjdk.org  Mon Aug 18 22:31:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 22:31:50 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v5]
In-Reply-To: <OiWEUvmIMQdPXE9gPc004jGGJqmlj5-WVlTioYxFOBw=.27ffcbcd-54b5-4fb4-a80c-a73911a28b4c@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
 <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>
 <OiWEUvmIMQdPXE9gPc004jGGJqmlj5-WVlTioYxFOBw=.27ffcbcd-54b5-4fb4-a80c-a73911a28b4c@github.com>
Message-ID: <wtUNw3nQaxX4ibMQy9JVjm6M0e2uszjLON6Xkl6C6nE=.ccd1d557-915e-4a9c-ae1b-868b04b5e604@github.com>

On Mon, 18 Aug 2025 19:17:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3893:
>> 
>>> 3891:                     .appendFraction(NANO_OF_SECOND, minDigits, maxDigits, true)
>>> 3892:                     .parseLenient()
>>> 3893:                     .appendOffset("+HH", "Z")
>> 
>> The "+HH" pattern is supposed to be ignoring minutes and seconds but it does not appear to.  In jshell, I see:
>> 
>> jshell> Instant.parse("2017-01-01T00:00:00.000-02:10:12")
>> $8 ==> 2017-01-01T02:10:12Z
>> 
>> It would be more consistent with the original pattern to use `"+HH:mm:ss"`
>
> IIUC, "ignoring minutes and seconds" refers to formatting, i.e, "-02:10:12" only prints "-02" Parsing offsets in lenient mode always parses minute/seconds.

True, but you have to read further into the `appendOffset` prose to know that the minutes and sections can be present. Using the full pattern would convey more quickly the full syntax being parsed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283632033

From liach at openjdk.org  Mon Aug 18 22:35:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 22:35:41 GMT
Subject: RFR: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
In-Reply-To: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
References: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
Message-ID: <wROdwFsz80VCWXIIR0w5pHTxMi1BgYQHF-ID7D0V03U=.b0228570-dd26-4f3e-9be0-81b7885b89e1@github.com>

On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when creating the string from the supplied latin1 bytes. 
> If COMPACT_STRINGS is false, the bytes are inflated to UTF16.

A necessary simplification. Reviewed the copyright years too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26831#pullrequestreview-3130153832

From naoto at openjdk.org  Mon Aug 18 22:43:39 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 22:43:39 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v5]
In-Reply-To: <wtUNw3nQaxX4ibMQy9JVjm6M0e2uszjLON6Xkl6C6nE=.ccd1d557-915e-4a9c-ae1b-868b04b5e604@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
 <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>
 <OiWEUvmIMQdPXE9gPc004jGGJqmlj5-WVlTioYxFOBw=.27ffcbcd-54b5-4fb4-a80c-a73911a28b4c@github.com>
 <wtUNw3nQaxX4ibMQy9JVjm6M0e2uszjLON6Xkl6C6nE=.ccd1d557-915e-4a9c-ae1b-868b04b5e604@github.com>
Message-ID: <vfKT5-XqbFNY0MuGSm4fjDwW0-RudyXXRf9RrswQ2as=.c40382dc-308c-4269-af32-558fef419164@github.com>

On Mon, 18 Aug 2025 22:28:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> IIUC, "ignoring minutes and seconds" refers to formatting, i.e, "-02:10:12" only prints "-02" Parsing offsets in lenient mode always parses minute/seconds.
>
> True, but you have to read further into the `appendOffset` prose to know that the minutes and sections can be present. Using the full pattern would convey more quickly the full syntax being parsed.

Using the full pattern means the colons may not be optional. The `appendOffset` spec reads:

If the specified pattern is "+HH", the presence of colons is determined by whether the character after the hour digits is a colon or not.

Among the supported patterns, only "+HH" (and I believe "+H" too) take the colons optional in lenient mode, i.e, both "+02:00" and "+0200" are allowed, which suits the ISO 8601 offset format.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283644271

From syan at openjdk.org  Tue Aug 19 03:34:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 03:34:47 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
Message-ID: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>

On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.
>
> It is also something that can be changed later, in a follow up fix.

Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds too long and it's unacceptable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2283972732

From vyazici at openjdk.org  Tue Aug 19 05:09:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 05:09:52 GMT
Subject: Integrated: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <1re-TiUs1k4Z0hUrkWLaVZhmvPDKGtLwP0O8kuxNw8w=.5c557f62-fc34-4e06-b520-6d8aa55e6aa2@github.com>

On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

This pull request has now been integrated.

Changeset: 655dc516
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/655dc516c22ac84fccee6b1fdc607c492465be6b
Stats:     434 lines in 23 files changed: 326 ins; 20 del; 88 mod

8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics

Reviewed-by: rriggs, liach, dfenacci, thartmann, redestad, jrose

-------------

PR: https://git.openjdk.org/jdk/pull/25998

From dholmes at openjdk.org  Tue Aug 19 05:25:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:25:40 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
Message-ID: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>

On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> It is also something that can be changed later, in a follow up fix.
>
> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.

> It is unclear to me if the author meant this to be 2.5 more than normal or 10 more than JTREG default, or a multiplier that seems to work. 

What matters is that the actual timeout, in seconds, remains unchanged, so please address this. Timeouts that are excessively long waste machine resources.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284090715

From dholmes at openjdk.org  Tue Aug 19 05:49:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:49:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199288818

From syan at openjdk.org  Tue Aug 19 05:52:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 05:52:37 GMT
Subject: RFR: 8365398: TEST_BUG:
 java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing
 intermittently
In-Reply-To: <ARjI44UG551o1xr4FOT8ezBDuSnuH0svvgwNOVMuvZs=.050eb1e6-f771-4c23-8d37-84506bf889cf@github.com>
References: <ARjI44UG551o1xr4FOT8ezBDuSnuH0svvgwNOVMuvZs=.050eb1e6-f771-4c23-8d37-84506bf889cf@github.com>
Message-ID: <uR1z5-EB8UN2KrLriqVUQRKu2cPorplHGGMycV6uyk8=.05770200-c77a-4755-927a-c43b318908aa@github.com>

On Mon, 18 Aug 2025 08:01:58 GMT, Johny Jose <duke at openjdk.org> wrote:

> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6

test/jdk/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java line 128:

> 126:         }
> 127: 
> 128:         /* numLeft should be 6 - if 11 there is a problem. */

Below maybe more exactly

/* numLeft should be less than 6 - if 11 there is a problem. */

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26815#discussion_r2284138429

From syan at openjdk.org  Tue Aug 19 05:55:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 05:55:40 GMT
Subject: RFR: 8365398: TEST_BUG:
 java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing
 intermittently
In-Reply-To: <ARjI44UG551o1xr4FOT8ezBDuSnuH0svvgwNOVMuvZs=.050eb1e6-f771-4c23-8d37-84506bf889cf@github.com>
References: <ARjI44UG551o1xr4FOT8ezBDuSnuH0svvgwNOVMuvZs=.050eb1e6-f771-4c23-8d37-84506bf889cf@github.com>
Message-ID: <yt6Bv6tiWTmvujOtGP8t3tVNWBe4nQPkqPQbunHKkY4=.ac1e63c5-4491-411a-bc55-6ddc234d8f55@github.com>

On Mon, 18 Aug 2025 08:01:58 GMT, Johny Jose <duke at openjdk.org> wrote:

> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6

Does do the fullgc before `getDGCLeaseTableSize()` can fix this imtermittent failure

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26815#issuecomment-3199300269

From vyazici at openjdk.org  Tue Aug 19 06:02:39 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 06:02:39 GMT
Subject: RFR: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
In-Reply-To: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
References: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
Message-ID: <oSLUyHqms_lZ-RYpyaeJIADkIf2Xo4kPYVdJ7vdUhPA=.b3f8716d-359f-4bbf-b28e-a439e2cecaa4@github.com>

On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when creating the string from the supplied latin1 bytes. 
> If COMPACT_STRINGS is false, the bytes are inflated to UTF16.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 330:

> 328:      * @return the newly created string
> 329:      */
> 330:     String uncheckedNewStringWithLatin1Bytes(byte[] bytes);

@RogerRiggs, we introduce a new `JLA::uncheckedNewStringNoRepl` specialization that
 doesn't throw `CCE` and fix the charset to Latin-1. _"The only reason"_ we do this is to save the call-site from catching `CCE`, am I right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26831#discussion_r2284154346

From dholmes at openjdk.org  Tue Aug 19 06:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 06:07:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
Message-ID: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>

On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
>> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.
>
> DELETED - I confused the timeout with the timeout-factor. New comment below.

No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 

However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284161138

From dholmes at openjdk.org  Tue Aug 19 06:18:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 06:18:36 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early
In-Reply-To: <sR_jgJCle6sa9o1lyyjhdr6GqqEGjE8OKbigfgKww7Y=.be93d9f1-2932-4864-8204-3e21343f9d35@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <sR_jgJCle6sa9o1lyyjhdr6GqqEGjE8OKbigfgKww7Y=.be93d9f1-2932-4864-8204-3e21343f9d35@github.com>
Message-ID: <KsICIX0TxtmPoGC8FqglEXWW6iwAYfWnJFCg8lLSNM0=.1d5c6ec8-9cad-41be-98a9-f6d4b7c884b2@github.com>

On Fri, 15 Aug 2025 15:44:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> We currently have a trend of moving argument validations and checks to pure Java code, to minimize downcall into the VM (whose code cannot be optimized by compilers). Even if we keep checks in the VM, I guess jvm.cpp might be a better place than Class.c.

No, that would defeat the purpose of creating this request in the first place. It was the calls within Class.c that originally choked on the excessive length. We want to avoid operating on these excessively large strings, and so need to bail out early on the Java/libjava side.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3199349458

From syan at openjdk.org  Tue Aug 19 06:40:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 06:40:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
Message-ID: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>

On Tue, 19 Aug 2025 06:04:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DELETED - I confused the timeout with the timeout-factor. New comment below.
>
> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
> 
> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.

The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284273170

From mbaesken at openjdk.org  Tue Aug 19 07:59:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 19 Aug 2025 07:59:16 GMT
Subject: RFR: 8365700: jar --validate without any --file option leaves around a
 temporary file /tmp/tmpJar<number>.jar
Message-ID: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>

The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
This has been observed at least on Linux and AIX .

-------------

Commit messages:
 - JDK-8365700

Changes: https://git.openjdk.org/jdk/pull/26837/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26837&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365700
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26837/head:pull/26837

PR: https://git.openjdk.org/jdk/pull/26837

From epeter at openjdk.org  Tue Aug 19 08:14:46 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 19 Aug 2025 08:14:46 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3]
In-Reply-To: <WUdDHLOp97AX6ZT5-0hJ9E65hVbhKAkDZezvFy1j8Vs=.df1bc921-830f-4a11-a864-6ea1f4f3aaeb@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
 <vyVkMQdZMj0GkWf5ARt2UnltthyPCwTXvffpGfDPpms=.374f29f8-eb73-4e39-a240-ee71302c97af@github.com>
 <WUdDHLOp97AX6ZT5-0hJ9E65hVbhKAkDZezvFy1j8Vs=.df1bc921-830f-4a11-a864-6ea1f4f3aaeb@github.com>
Message-ID: <4yjOry6dcewq69ugsBK19mG7ss77qZq6JQtuoiR3XYM=.4dd258c9-67a0-4183-bbc6-cbd3c4addd84@github.com>

On Mon, 4 Aug 2025 19:47:32 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> This seems to be failing in the CI on the build of: linux-x64-debug-nopch
>> 
>> [2025-08-04T19:02:29,373Z] /......../workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp:293:27: error: 'stub_id' was not declared in this scope; did you mean 'StubId'?
>> [2025-08-04T19:02:29,373Z]   293 |   StubCodeMark mark(this, stub_id);
>> [2025-08-04T19:02:29,373Z]       |                           ^~~~~~~
>> [2025-08-04T19:02:29,373Z]       |                           StubId
>> [2025-08-04T19:02:29,373Z]
>
>> This seems to be failing in the CI on the build of: linux-x64-debug-nopch
>> 
>> ```
>> [2025-08-04T19:02:29,373Z] /......../workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp:293:27: error: 'stub_id' was not declared in this scope; did you mean 'StubId'?
>> [2025-08-04T19:02:29,373Z]   293 |   StubCodeMark mark(this, stub_id);
>> [2025-08-04T19:02:29,373Z]       |                           ^~~~~~~
>> [2025-08-04T19:02:29,373Z]       |                           StubId
>> [2025-08-04T19:02:29,373Z] 
>> ```
> 
> Thanks for notification. It looks like an incorrect type declaration. I'll submit a fix.

@missa-prime I was on vacation for a few weeks. Feel free to ping others when I don't respond ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3199712429

From lkorinth at openjdk.org  Tue Aug 19 09:02:36 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:02:36 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
Message-ID: <uOH12UfZUHixcxSAx8lP66zvzxKr50yUj8x4_x22Su0=.31769f01-81c4-48b0-9050-f642c562deb5@github.com>

On Tue, 19 Aug 2025 05:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

Thanks David! And as you said, a few more adjustments will probably be needed when we have run this for a while.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199869795

From jpai at openjdk.org  Tue Aug 19 09:14:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Aug 2025 09:14:37 GMT
Subject: RFR: 8365700: jar --validate without any --file option leaves
 around a temporary file /tmp/tmpJar<number>.jar
In-Reply-To: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
References: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
Message-ID: <tuvDk9cVhKei8XR0Os70JKiB3nTTqrrul0YiPrfsfYE=.c868b140-ae1a-4f50-93a7-629b99201e16@github.com>

On Tue, 19 Aug 2025 07:51:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
> This has been observed at least on Linux and AIX .

Thank you Matthias for this fix. Although it was the `JarNoFileArgOperations` test which showed up this issue, the actual bug resides in the `jar` tool which is where your fix resides. This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26837#pullrequestreview-3131432807

From lkorinth at openjdk.org  Tue Aug 19 09:19:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:19:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <BM1P_203-vMLbBYxbzigREy0NuHWoZqfgQvmGV0SH7I=.bf66ee89-19a9-4212-b800-08e7c835f4de@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

I do not think 4x longer timeouts for `-Xcomp` is unreasonable. I also do not want to make this huge change even bigger. If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284650722

From djelinski at openjdk.org  Tue Aug 19 10:00:04 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:00:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <_z_WkScJqZa0sGl-fiivLYz2RjMtrKRpszMfD5KoVV8=.7a6e7075-2c6c-4a97-bdf1-333dcb35fc5c@github.com>

On Thu, 24 Jul 2025 16:59:12 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/ThrowingConsumer.java line 26:
> 
>> 24: 
>> 25: @FunctionalInterface
>> 26: public interface ThrowingConsumer<T, X extends Throwable> {
> 
> This interface is only implemented by Http2Handler. We should remove it.

Removed in f31d9235e852395182034e5c3a826a9112e51b8c

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284751142

From djelinski at openjdk.org  Tue Aug 19 10:09:58 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:09:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <BfmSxWK_QlU_xRgeDJ42C6CBn0PAgzINJ57MQG8JMPE=.6ccb4260-d3a5-4295-a09c-efb1f2add293@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <BfmSxWK_QlU_xRgeDJ42C6CBn0PAgzINJ57MQG8JMPE=.6ccb4260-d3a5-4295-a09c-efb1f2add293@github.com>
Message-ID: <6tYLAgdx9Uwc1i6d_SLprx-ieRWn1qYjDFdDyyujxbQ=.b078fd44-7975-4b5f-9f74-1160c7c42b3e@github.com>

On Wed, 16 Jul 2025 11:19:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> src/java.net.http/share/classes/jdk/internal/net/http/AltSvcProcessor.java line 164:
> 
>> 162:             // serialized form of an origin (defined in section 6.2 of RFC-6454)
>> 163:             try {
>> 164:                 origin = Origin.fromASCIISerializedForm(frame.getOrigin());
> 
> Do we check if the origin is authoritative before processing the alt service? I don't see that here

Addressed in 2d6d1da0249ce133608624fd83c8c6573d56506a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284763893

From djelinski at openjdk.org  Tue Aug 19 10:10:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:10:01 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <2uIlI67ZuXY_FGElLjUN1wcwoPSdVrQACgyVF7AEbfk=.624e0472-4a35-4c9a-aec8-cc02e28d5632@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <2uIlI67ZuXY_FGElLjUN1wcwoPSdVrQACgyVF7AEbfk=.624e0472-4a35-4c9a-aec8-cc02e28d5632@github.com>
Message-ID: <JRMgb9xlQML3FKbcex2XylamJinAc6aSHnuLu-ayBIs=.3908e778-a98f-49c5-891b-84fcf6714abb@github.com>

On Tue, 1 Jul 2025 11:13:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/http3/frames/FramesDecoder.java line 143:
> 
>> 141:      * This method doesn't try to do any decoding.
>> 142:      */
>> 143:     public Http3Frame peek() {
> 
> This method is unused. I'll remove it.

Addressed in fe4073ca4939e9870924cfc54f1d6e6091642af3

> src/java.net.http/share/classes/jdk/internal/net/http/http3/streams/UniStreamPair.java line 87:
> 
>> 85:     private final CompletableFuture<QuicStreamWriter> streamWriterCF;
>> 86:     // a queue of ByteBuffers submitted for writing.
>> 87:     // might be null if not used. Only used in QueuingStreamPair.
> 
> It seems to be true. I'll see if I can move it to QueuingStreamPair.

Moved in c2a351ed5cdcaa5c0bdf7e28140a1dfb4e751d56 + 91fb530b350f733789c4deae53c83855d00365b6

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284775186
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284771544

From djelinski at openjdk.org  Tue Aug 19 10:31:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:31:01 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <_KViTKZGBXQP1jf-JCdme4Wwzhc1VxUbIgeIaqCuA3E=.b36c2681-216d-4377-9492-9164eef40b51@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <gJjX2SWnVaY5_Iu8xzVmwlIdgYS8PgPYVHEvOaz00KY=.53ed95dc-6560-48da-8db2-49823788a63c@github.com>
 <_KViTKZGBXQP1jf-JCdme4Wwzhc1VxUbIgeIaqCuA3E=.b36c2681-216d-4377-9492-9164eef40b51@github.com>
Message-ID: <mdU0Lw6Eds9_6ewGzEDUnP9a-j4oAmoDlofBw-v2v8I=.7053de75-94c8-4022-b4bc-592e06935b3e@github.com>

On Mon, 30 Jun 2025 09:45:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 124:
>> 
>>> 122:     // exchange so that it can be aborted/timed out mid setup.
>>> 123:     final class ConnectionAborter {
>>> 124:         // In case of HTTP/3 direct connection we may have
>> 
>> "direct" is usually used to refer to connections that don't use a proxy; since H3 connections never use a proxy, can we drop the "direct" here?
>
> Good point. I will rephrase. We should be speaking of HTTP/3 requests (and not connection) here anyway.

done in ee6a0c4ff95d0fd9924f58d163b7653b7b314bc9

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284825038

From djelinski at openjdk.org  Tue Aug 19 10:37:07 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:37:07 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kTIIcfqilyJuMUP65znNS6M7QoUQGpws8bXRmcbC0hQ=.a7fa725f-be22-41c1-b2b3-378ad0695ea9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <kTIIcfqilyJuMUP65znNS6M7QoUQGpws8bXRmcbC0hQ=.a7fa725f-be22-41c1-b2b3-378ad0695ea9@github.com>
Message-ID: <bhw7qD8rn9iN1GnIWbkTCNLSxF9jBysNDNc0vt_i-x4=.3fe07ad0-ac25-44de-be39-896993ddb8a3@github.com>

On Fri, 27 Jun 2025 15:27:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 85:
> 
>> 83: 
>> 84:     // This will be set to true only when it is guaranteed that the server hasn't processed
>> 85:     // the request. Typically this happens when the server explicitly states (through a GOAWAY frame
> 
> Suggestion:
> 
>     // the request. Typically, this happens when the server explicitly states (through a GOAWAY frame

addressed in ee6a0c4ff95d0fd9924f58d163b7653b7b314bc9

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284839382

From djelinski at openjdk.org  Tue Aug 19 10:37:07 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:37:07 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <0uFs6gr4vZ3wgNvAsWhQfjl1_Wq9njUMcHHO-atXhJ0=.60d8e149-5ca9-4b8f-8268-76ca4b03e31a@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <sZqtNoTLqHcpgpaIQ3htp1aSzrAgGkUyLx7mxR9P8jg=.5bf2e89f-2776-4a82-8eff-83ac07995836@github.com>
 <0uFs6gr4vZ3wgNvAsWhQfjl1_Wq9njUMcHHO-atXhJ0=.60d8e149-5ca9-4b8f-8268-76ca4b03e31a@github.com>
Message-ID: <5D1KMUpI79Z4iv8ogIxo_x2w2YZKkfrpRrvlFpS_mYk=.c611224a-f26f-41fb-98e5-52bcf7f29247@github.com>

On Fri, 27 Jun 2025 12:47:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 121:
>> 
>>> 119:     }
>>> 120: 
>>> 121:     // Keeps track of the underlying connection when establishing an HTTP/2
>> 
>> since this is now used with HTTP/3, should we update this comment?
>
> I have verified the other comments in this class and updated to mention or HTTP/3 in a few places in this class, in my local repo. Will appear the next time I sync this PR.

addressed in a245450023ad189a54dfcb66a4303182fe81c972

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284836370

From ghan at openjdk.org  Tue Aug 19 12:54:22 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 19 Aug 2025 12:54:22 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v2]
In-Reply-To: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
Message-ID: <wUH-A0caZXnrVJ9oIoufuQXfTqQLrEZrafh3ZR_5u2M=.5ad9cf31-6b99-4069-9710-a4d5935ac0e7@github.com>

> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.

Guanqiang Han 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:

 - move check into java side
 - Merge remote-tracking branch 'upstream/master' into 8328874
 - 8328874: Class::forName0 should validate the class name length early
   
   Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26802/files
  - new: https://git.openjdk.org/jdk/pull/26802/files/95db25db..79fe33eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=00-01

  Stats: 5617 lines in 166 files changed: 4373 ins; 620 del; 624 mod
  Patch: https://git.openjdk.org/jdk/pull/26802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26802/head:pull/26802

PR: https://git.openjdk.org/jdk/pull/26802

From duke at openjdk.org  Tue Aug 19 13:13:37 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 19 Aug 2025 13:13:37 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v2]
In-Reply-To: <wUH-A0caZXnrVJ9oIoufuQXfTqQLrEZrafh3ZR_5u2M=.5ad9cf31-6b99-4069-9710-a4d5935ac0e7@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <wUH-A0caZXnrVJ9oIoufuQXfTqQLrEZrafh3ZR_5u2M=.5ad9cf31-6b99-4069-9710-a4d5935ac0e7@github.com>
Message-ID: <SHvgMkw3WKB_Kq_GYB4LWtffwlazxx4txK-OtwVyQCQ=.a98a719c-434b-4a15-b89f-219f7a6319c0@github.com>

On Tue, 19 Aug 2025 12:54:22 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.
>
> Guanqiang Han 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:
> 
>  - move check into java side
>  - Merge remote-tracking branch 'upstream/master' into 8328874
>  - 8328874: Class::forName0 should validate the class name length early
>    
>    Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.

src/java.base/share/classes/java/lang/Class.java line 4160:

> 4158:     private static boolean classNameLengthIsValid(String name) {
> 4159: 	    Objects.requireNonNull(name);
> 4160: 	    return name.length() <= JAVA_CLASSNAME_MAX_LEN;

This?check is?incorrect, as?the?`JAVA_CLASSNAME_MAX_LEN` applies?to the?Modified?UTF?8 length, rather?than the?UTF?16?length.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2285226775

From dclarke at openjdk.org  Tue Aug 19 13:18:49 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 19 Aug 2025 13:18:49 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs [v2]
In-Reply-To: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <L-GZflmckhvHik1Yh2AKIkglbcJQaXJyvTsYc8Donug=.c093953c-06b6-479b-82f6-f3824f78a52b@github.com>

> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
> 
> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
> 
> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.

Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:

  implementing feedback, adding missing errno checks, cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25546/files
  - new: https://git.openjdk.org/jdk/pull/25546/files/4878d558..e2207883

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25546&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25546&range=00-01

  Stats: 322 lines in 8 files changed: 168 ins; 135 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25546.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25546/head:pull/25546

PR: https://git.openjdk.org/jdk/pull/25546

From dclarke at openjdk.org  Tue Aug 19 13:22:40 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 19 Aug 2025 13:22:40 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs [v2]
In-Reply-To: <L-GZflmckhvHik1Yh2AKIkglbcJQaXJyvTsYc8Donug=.c093953c-06b6-479b-82f6-f3824f78a52b@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <L-GZflmckhvHik1Yh2AKIkglbcJQaXJyvTsYc8Donug=.c093953c-06b6-479b-82f6-f3824f78a52b@github.com>
Message-ID: <tSmF3uk6sLmjU1PzQe004i6Y4h0iX3fkObey-vv7dPk=.16e22e7a-a1c1-4f87-917a-020835228dac@github.com>

On Tue, 19 Aug 2025 13:18:49 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
>> 
>> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
>> 
>> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implementing feedback, adding missing errno checks, cleanup

I made a few changes mostly based on comments but I'll give a little patch notes:

- I'd missed some errno checks for kqueue
- Moved the FFMUtils class from shared to just be in `maxosx`, I also changed how this gets the valueLayouts for C values to match how newer versions of jextract generate this
- I changed how the util method that converts errno codes to their respective error strings


I ran this against the selector tests on all OSs and everything seems green after repeated tests

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3200745633

From dfuchs at openjdk.org  Tue Aug 19 13:31:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 13:31:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <rjOdFLUipPEg5WANViULncjttCDE1vafjjR0wzhi4HE=.55628aae-59c2-4d50-848a-771154bcd45c@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <rjOdFLUipPEg5WANViULncjttCDE1vafjjR0wzhi4HE=.55628aae-59c2-4d50-848a-771154bcd45c@github.com>
Message-ID: <pa5NKYPprdVCPOfR-MZmJGi_jjZjBa90wdOuopGcGL4=.8899187b-806f-4b32-830d-cd6eaa55fa5a@github.com>

On Thu, 24 Jul 2025 15:20:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/http3/H3SimpleTest.java line 47:
> 
>> 45: /*
>> 46:  * @test
>> 47:  * @summary Basic test to verify HTTP3 requests from HttpClient with security manager enabled
> 
> nothing in this test references the security manager.

Will be updated in the next iteration

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285279024

From dfuchs at openjdk.org  Tue Aug 19 13:57:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 13:57:13 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <MEsc5nZ6yFa1haC_LsDWdL4M-zKKvDb-TGIQBB88LZo=.67f38e94-b307-4a02-90e0-26e89097f801@github.com>

On Thu, 24 Jul 2025 15:31:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/http3/H3UnsupportedSSLParametersTest.java line 42:
> 
>> 40:  * @run junit H3UnsupportedSSLParametersTest
>> 41:  */
>> 42: public class H3UnsupportedSSLParametersTest {
> 
> This test overlaps with H3QuicTLSConnection. Any reason we shouldn't merge them?

I logged https://bugs.openjdk.org/browse/JDK-8365793

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285352186

From asteiner at openjdk.org  Tue Aug 19 14:01:39 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Tue, 19 Aug 2025 14:01:39 GMT
Subject: RFR: 8365700: Jar --validate without any --file option leaves
 around a temporary file /tmp/tmpJar<number>.jar
In-Reply-To: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
References: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
Message-ID: <CQhQs0m1sya-KqImvL-qmKI6kup71_98ISrKP-BaqkQ=.9a38b4ce-7fd4-4c13-ba9a-6cc68edd9b43@github.com>

On Tue, 19 Aug 2025 07:51:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
> This has been observed at least on Linux and AIX .

LGTM

-------------

Marked as reviewed by asteiner (Author).

PR Review: https://git.openjdk.org/jdk/pull/26837#pullrequestreview-3132480856

From dfuchs at openjdk.org  Tue Aug 19 14:04:08 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 14:04:08 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <GFPn5-6oANk9F3Z1PXf4GQyQTgR_c8ef1NiVK0ywISU=.56380351-7f84-4685-b379-d69fd719c00b@github.com>

On Thu, 24 Jul 2025 16:02:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/http3/H3StreamLimitReachedTest.java line 94:
> 
>> 92: import static org.testng.Assert.assertFalse;
>> 93: 
>> 94: public class H3StreamLimitReachedTest implements HttpServerAdapters {
> 
> This test seems to duplicate the checks in `StreamLimitTest`.

Actually it doesn't. Though they might overlap to some extent. The StreamLimitTest test tests the vanilla retry of requests when stream limit is reached. The H3StreamLimitReachedTest tests more complex scenarios for connection reuse (or not reuse) by issuing different requests with different discovery modes, and mixing that with retries caused by stream limit reached. Maybe the issue here is finding a better name (or better summary) for these tests. I logged https://bugs.openjdk.org/browse/JDK-8365794

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285373543

From rriggs at openjdk.org  Tue Aug 19 14:14:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 14:14:43 GMT
Subject: RFR: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
In-Reply-To: <oSLUyHqms_lZ-RYpyaeJIADkIf2Xo4kPYVdJ7vdUhPA=.b3f8716d-359f-4bbf-b28e-a439e2cecaa4@github.com>
References: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
 <oSLUyHqms_lZ-RYpyaeJIADkIf2Xo4kPYVdJ7vdUhPA=.b3f8716d-359f-4bbf-b28e-a439e2cecaa4@github.com>
Message-ID: <4JFBgSjdzq7YcC-zfZ_We2MfMlhkl7qVSEOTypQSFDc=.b94d781e-3d4c-4f8b-a23f-a594aec5034e@github.com>

On Tue, 19 Aug 2025 06:00:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
>> There is no decoding needed, and no exceptions expected or thrown when creating the string from the supplied latin1 bytes. 
>> If COMPACT_STRINGS is false, the bytes are inflated to UTF16.
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 330:
> 
>> 328:      * @return the newly created string
>> 329:      */
>> 330:     String uncheckedNewStringWithLatin1Bytes(byte[] bytes);
> 
> @RogerRiggs, we introduce a new `JLA::uncheckedNewStringNoRepl` specialization that
>  doesn't throw `CCE` and fix the charset to Latin-1. _"The only reason"_ we do this is to save the call-site from catching `CCE`, am I right?

The common case is that the caller already has created a latin1 string, and it avoids the overhead of re-dispatching on the Charset and adding decoding overhead. 
The rationale for adding the package busting access is to improve performance, both in avoiding an unnecessary allocation and compute cycles.  The callers in each of these cases have been tuned for high performance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26831#discussion_r2285407351

From dfuchs at openjdk.org  Tue Aug 19 14:25:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 14:25:03 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <659XlzlcGDRFIXAZ9NIu6ZIStogxpE7ZU3M-uKIIV9Q=.6a607db8-b932-479a-995d-8fa53c52f984@github.com>

On Thu, 24 Jul 2025 17:04:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2RedirectHandler.java line 61:
> 
>> 59:     }
>> 60: 
>> 61:     protected byte[] getResponseBytes() {
> 
> this method doesn't appear to be overridden anywhere. Should we revert these changes?

I have logged a task to revisit http2/RedirectTest to use HttpServerAdapters, like http3/H3RedirectTest does. Once this is done we should be able to delete this class - it has an almost duplicate in HttpServerAdapters.
https://bugs.openjdk.org/browse/JDK-8365795

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285442041

From dfuchs at openjdk.org  Tue Aug 19 14:32:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 14:32:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <x4aGnRdJT6-mjJFEebSgMAeJPH90562GHLrYVwB4e08=.a226424e-b4a6-4d1b-a580-04c0688bc54e@github.com>

On Thu, 24 Jul 2025 19:28:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/jdk/internal/net/http/quic/packets/QuicPacketNumbersTest.java line 33:
> 
>> 31:  * @modules java.net.http/jdk.internal.net.http.quic.packets
>> 32:  */
>> 33: public class QuicPacketNumbersTest {
> 
> This test covers the same functions as `quic/PacketNumbersTest.java`; can we remove one?

I logged https://bugs.openjdk.org/browse/JDK-8365796

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285466697

From aturbanov at openjdk.org  Tue Aug 19 14:40:45 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 19 Aug 2025 14:40:45 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v8]
In-Reply-To: <_Ompbh3_hc6yPqt7KvbiuZVMJ9m7NoYNKIR_szqG62A=.59147014-db31-4296-8469-f107b6e677a9@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <_Ompbh3_hc6yPqt7KvbiuZVMJ9m7NoYNKIR_szqG62A=.59147014-db31-4296-8469-f107b6e677a9@github.com>
Message-ID: <QXh9cHU6ND0dQEgLatf0Loezv0txPUPOlKxFbPiq-Ss=.96561b84-15e2-4189-b3d8-57a6fd04955f@github.com>

On Wed, 13 Aug 2025 14:14:30 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Break out the default branch

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 126:

> 124: 
> 125: 
> 126:             if( len > 15) {

Suggestion:

            if (len > 15) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26672#discussion_r2285488529

From ghan at openjdk.org  Tue Aug 19 14:42:58 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 19 Aug 2025 14:42:58 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v3]
In-Reply-To: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
Message-ID: <RV88piqOvjX3cWg-QET_Awo3kxst0x9l506ll7mEJcU=.583e5dd5-fe2f-4f1f-af2d-22c8b9ceca8e@github.com>

> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  Update Class.java
  
  fix whitespace errors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26802/files
  - new: https://git.openjdk.org/jdk/pull/26802/files/79fe33eb..b3237eb1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26802/head:pull/26802

PR: https://git.openjdk.org/jdk/pull/26802

From dfuchs at openjdk.org  Tue Aug 19 14:48:09 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 14:48:09 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <4kAWa2wgbihXfl3lGOhZJ3sNAFh3RwlPMRT9ZeQpYiY=.68e72d2f-3477-4f01-a4da-4e88ecedd3ed@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <4kAWa2wgbihXfl3lGOhZJ3sNAFh3RwlPMRT9ZeQpYiY=.68e72d2f-3477-4f01-a4da-4e88ecedd3ed@github.com>
Message-ID: <8UesLa3azo0QuwwzT7-y1c5ByUBzkYMxe3cTfaGM2Dw=.46c6655e-3f4f-4b32-9a9a-7d20bc8356b6@github.com>

On Thu, 24 Jul 2025 12:21:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/http3/BadCipherSuiteErrorTest.java line 59:
> 
>> 57:  * causing hang problems
>> 58:  */
>> 59: public class BadCipherSuiteErrorTest implements HttpServerAdapters {
> 
> This test overlaps with H3QuicTLSConnection test. Any reason to keep them separate?

http3/BadCipherSuiteErrorTest is a clone of http2/ErrorTest - adapted to replace HTTP/2 specifics with HTTP/3.
The original ErrorTest test had been introduced as a non regression test for JDK-8157105.
I guess we could consider merging BadCipherSuiteErrorTest with H3QuicTLSConnection if we are sure that path is covered. I have logged https://bugs.openjdk.org/browse/JDK-8365800

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285508994

From rriggs at openjdk.org  Tue Aug 19 15:01:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 15:01:40 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v4]
In-Reply-To: <Q42gIyby5n9jbP7PjF7qicvmKbsgktXvI1LhKijZNMw=.a09cb9ae-3e7c-4ae7-acd5-a19f4eb89b64@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <Q42gIyby5n9jbP7PjF7qicvmKbsgktXvI1LhKijZNMw=.a09cb9ae-3e7c-4ae7-acd5-a19f4eb89b64@github.com>
Message-ID: <46MfOJA8bICEbZ7EpwzTealkJKqvsxREIKZhsyA-LRE=.295d951f-1eb7-4ad7-9e6a-3f2810c581ce@github.com>

On Tue, 12 Aug 2025 19:29:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant type parameters

It seems that the API is overloaded trying to satisfy too many requirements, replace/noreplace, throw/nothrow and supporting arbitrary Charsets.  There are multiple callers that only need to create a string from byte array holding latin1.
They are burdened with catching and ignoring exceptions that do not occur.

I'm suggesting breaking out that use case in PR#https://github.com/openjdk/jdk/pull/26831.
That leaves `Files.readString` that needs the full CharSet/noReplace/throw behavior.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3201113471

From dfuchs at openjdk.org  Tue Aug 19 15:08:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 15:08:15 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <vr9dbhdfhe_CZkHcwTIY8AaPWVzOmKsthRIuvnvdUFU=.b8c6b4bd-1c52-4371-838a-d9d0d271c8f2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <vr9dbhdfhe_CZkHcwTIY8AaPWVzOmKsthRIuvnvdUFU=.b8c6b4bd-1c52-4371-838a-d9d0d271c8f2@github.com>
Message-ID: <6nBDnOO0K3TPubH3Vmr0zZhOV4xWdanspQgz4R4cOtk=.c084b221-a808-4dfd-aa1e-3fd085d4ac33@github.com>

On Wed, 23 Jul 2025 11:00:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/AsFileDownloadTest.java line 453:
> 
>> 451: 
>> 452:         @Override
>> 453:         public void handle(HttpTestExchange t) throws IOException {
> 
> this is almost an exact copy of the method above.

Right. Thanks for spotting that. The right thing to do here would be to refactor the HTTP/2 part of the test to stop using Http2TestServer but use HttpTestServer instead, like the new HTTP/3 part. That would get rid of the almost duplicate. I have logged https://bugs.openjdk.org/browse/JDK-8365802

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285564303

From rriggs at openjdk.org  Tue Aug 19 15:09:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 15:09:50 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl
Message-ID: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>

Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

-------------

Commit messages:
 - 8365703: Refactor ZipCoder to use common JLA.uncheckedNewStringNoRepl

Changes: https://git.openjdk.org/jdk/pull/26822/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26822&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365703
  Stats: 36 lines in 4 files changed: 12 ins; 17 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26822.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26822/head:pull/26822

PR: https://git.openjdk.org/jdk/pull/26822

From vyazici at openjdk.org  Tue Aug 19 15:09:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 15:09:53 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl
In-Reply-To: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
Message-ID: <-0fR1GN06Wdba7TKwbKidSU_pEA5MOurcK7fVeaY2r8=.eaafc81d-f50b-4024-a59f-d2d004849f4e@github.com>

On Mon, 18 Aug 2025 15:31:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

src/java.base/share/classes/java/util/zip/ZipCoder.java line 283:

> 281:                 // We use the JLA.newStringUTF8NoRepl variant to throw
> 282:                 // exceptions eagerly when opening ZipFiles
> 283:                 return hash(toString(a, off, len));

Earlier, `byte[]` was shared by the `String` instantiated, now it needs to be cloned. That is, I presume this to have a performance implication. Was this considered?

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 361:

> 359:      * @throws IllegalArgumentException for malformed or unmappable bytes.
> 360:      */
> 361:     String newStringUTF8NoRepl(byte[] bytes, int off, int len);

One less hole in the JLA, nice! ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26822#discussion_r2284136776
PR Review Comment: https://git.openjdk.org/jdk/pull/26822#discussion_r2284141237

From rriggs at openjdk.org  Tue Aug 19 15:09:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 15:09:53 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl
In-Reply-To: <-0fR1GN06Wdba7TKwbKidSU_pEA5MOurcK7fVeaY2r8=.eaafc81d-f50b-4024-a59f-d2d004849f4e@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
 <-0fR1GN06Wdba7TKwbKidSU_pEA5MOurcK7fVeaY2r8=.eaafc81d-f50b-4024-a59f-d2d004849f4e@github.com>
Message-ID: <YAIF2AahIjujeO3vEdJm7v-XYtrctrMN2DK2O5GUyRU=.4b82c596-cadb-44d4-bebb-c194d84cfd26@github.com>

On Tue, 19 Aug 2025 05:48:36 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 283:
> 
>> 281:                 // We use the JLA.newStringUTF8NoRepl variant to throw
>> 282:                 // exceptions eagerly when opening ZipFiles
>> 283:                 return hash(toString(a, off, len));
> 
> Earlier, `byte[]` was shared by the `String` instantiated, now it needs to be cloned. That is, I presume this to have a performance implication. Was this considered?

It always makes a copy, previously and as refactored.
The trampoline in System.java called into String with noShare = true.

public String newStringUTF8NoRepl(byte[] bytes, int off, int len) {
    return String.newStringUTF8NoRepl(bytes, off, len, true);
}

Now the copy is explicitly done by the caller and the contract is clear that the buffer is always not shared but transferred. (and one less argument and conditional)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26822#discussion_r2285476791

From ghan at openjdk.org  Tue Aug 19 15:20:52 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 19 Aug 2025 15:20:52 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v4]
In-Reply-To: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
Message-ID: <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>

> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  Update Class.java
  
  correct length of class name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26802/files
  - new: https://git.openjdk.org/jdk/pull/26802/files/b3237eb1..8eb1d4c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=02-03

  Stats: 16 lines in 1 file changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26802/head:pull/26802

PR: https://git.openjdk.org/jdk/pull/26802

From ghan at openjdk.org  Tue Aug 19 15:24:40 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 19 Aug 2025 15:24:40 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v2]
In-Reply-To: <SHvgMkw3WKB_Kq_GYB4LWtffwlazxx4txK-OtwVyQCQ=.a98a719c-434b-4a15-b89f-219f7a6319c0@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <wUH-A0caZXnrVJ9oIoufuQXfTqQLrEZrafh3ZR_5u2M=.5ad9cf31-6b99-4069-9710-a4d5935ac0e7@github.com>
 <SHvgMkw3WKB_Kq_GYB4LWtffwlazxx4txK-OtwVyQCQ=.a98a719c-434b-4a15-b89f-219f7a6319c0@github.com>
Message-ID: <QzOEZEU5HMulQNsQb-qqcn5xfOVAgolIM7EUm-lfjmY=.fa2e8893-f7e1-4e4b-843b-5e38bcfc4aa6@github.com>

On Tue, 19 Aug 2025 13:10:31 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Guanqiang Han 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:
>> 
>>  - move check into java side
>>  - Merge remote-tracking branch 'upstream/master' into 8328874
>>  - 8328874: Class::forName0 should validate the class name length early
>>    
>>    Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.
>
> src/java.base/share/classes/java/lang/Class.java line 4160:
> 
>> 4158:     private static boolean classNameLengthIsValid(String name) {
>> 4159: 	    Objects.requireNonNull(name);
>> 4160: 	    return name.length() <= JAVA_CLASSNAME_MAX_LEN;
> 
> This?check is?incorrect, as?the?`JAVA_CLASSNAME_MAX_LEN` applies?to the?Modified?UTF?8 length, rather?than the?UTF?16?length.

@ExE-Boss Good catch ? you?re right, this should check the Modified UTF-8 length rather than the UTF-16 length. I have updated the implementation accordingly?please take another look.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2285607194

From liach at openjdk.org  Tue Aug 19 15:26:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Aug 2025 15:26:38 GMT
Subject: RFR: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
In-Reply-To: <4JFBgSjdzq7YcC-zfZ_We2MfMlhkl7qVSEOTypQSFDc=.b94d781e-3d4c-4f8b-a23f-a594aec5034e@github.com>
References: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
 <oSLUyHqms_lZ-RYpyaeJIADkIf2Xo4kPYVdJ7vdUhPA=.b3f8716d-359f-4bbf-b28e-a439e2cecaa4@github.com>
 <4JFBgSjdzq7YcC-zfZ_We2MfMlhkl7qVSEOTypQSFDc=.b94d781e-3d4c-4f8b-a23f-a594aec5034e@github.com>
Message-ID: <ugZF91KzHLY7yDKyavPPxiY_w-g-WjsWRo8Vg-gUq9k=.33d73246-b142-4f17-ad0d-ddc8545ff3e7@github.com>

On Tue, 19 Aug 2025 14:11:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 330:
>> 
>>> 328:      * @return the newly created string
>>> 329:      */
>>> 330:     String uncheckedNewStringWithLatin1Bytes(byte[] bytes);
>> 
>> @RogerRiggs, we introduce a new `JLA::uncheckedNewStringNoRepl` specialization that
>>  doesn't throw `CCE` and fix the charset to Latin-1. _"The only reason"_ we do this is to save the call-site from catching `CCE`, am I right?
>
> The common case is that the caller already has created a latin1 string, and it avoids the overhead of re-dispatching on the Charset and adding decoding overhead. 
> The rationale for adding the package busting access is to improve performance, both in avoiding an unnecessary allocation and compute cycles.  The callers in each of these cases have been tuned for high performance.

Using `uncheckedNewStringNoRepl` for the performance side effect is confusing, especially with the meaningless try-catch and the constant encoding. A dedicated API allows us to track this particular usage better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26831#discussion_r2285613575

From ghan at openjdk.org  Tue Aug 19 15:28:39 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 19 Aug 2025 15:28:39 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early
In-Reply-To: <sR_jgJCle6sa9o1lyyjhdr6GqqEGjE8OKbigfgKww7Y=.be93d9f1-2932-4864-8204-3e21343f9d35@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <sR_jgJCle6sa9o1lyyjhdr6GqqEGjE8OKbigfgKww7Y=.be93d9f1-2932-4864-8204-3e21343f9d35@github.com>
Message-ID: <fVcg4jcUhazoEUnx-KdYS3VLdP1NgMA9xUSLyG36gyY=.60a8b6de-96dd-43c6-b12b-91cc96694b3c@github.com>

On Fri, 15 Aug 2025 15:44:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.
>
> We currently have a trend of moving argument validations and checks to pure Java code, to minimize downcall into the VM (whose code cannot be optimized by compilers). Even if we keep checks in the VM, I guess jvm.cpp might be a better place than Class.c.

@liach @dholmes-ora Thank you both for the detailed feedback and explanation.
I've moved the check to the Java side. Please have a look when you get a chance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3201215930

From ghan at openjdk.org  Tue Aug 19 15:28:43 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 19 Aug 2025 15:28:43 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v4]
In-Reply-To: <QI7YmnwAK37IeoLzqWiuGi7p4wL247I1z_pk4SlqxhY=.f8c425ac-cea9-46cc-93d8-547d902daae5@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <QI7YmnwAK37IeoLzqWiuGi7p4wL247I1z_pk4SlqxhY=.f8c425ac-cea9-46cc-93d8-547d902daae5@github.com>
Message-ID: <10refGlFP9-Ty0WewdDkgPVG3FNapKuwql7FTmVcUbo=.46532d39-de4e-490a-9f75-d141ea785e47@github.com>

On Fri, 15 Aug 2025 15:35:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Class.java
>>   
>>   correct length of class name
>
> src/java.base/share/native/libjava/Class.c line 119:
> 
>> 117:         JNU_ThrowClassNotFoundException(env, msg);
>> 118:         return 0;
>> 119:     }
> 
> I wonder if it's time to hoist these checks so that the checking is in a more discoverable place.

@AlanBateman Thank you for the comments . I've moved the check to the Java side. Please have a look when you have time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2285619954

From lancea at openjdk.org  Tue Aug 19 16:04:39 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 19 Aug 2025 16:04:39 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl
In-Reply-To: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
Message-ID: <2a9-BzyKouoEZJvy6xS_ci9A5HPynB0N7aSnb_jVc98=.bdebbd07-2696-49bc-8d8b-2b701cd67067@github.com>

On Mon, 18 Aug 2025 15:31:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

I think the changes look good as ZipFile.Source::checkAndAddEntry should still throw a ZipException with this change

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26822#pullrequestreview-3132960064

From liach at openjdk.org  Tue Aug 19 16:08:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Aug 2025 16:08:37 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v4]
In-Reply-To: <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>
Message-ID: <2vdariBU5CUr1jfa_KcEMmPrCtm2vTfdluBdQjt8OEs=.433e38c1-9467-420c-adf1-742a85206948@github.com>

On Tue, 19 Aug 2025 15:20:52 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Class.java
>   
>   correct length of class name

There is a `jdk.internal.util.ModifiedUtf::utfLen` that you can use instead of writing your own function.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3201350265

From jrose at openjdk.org  Tue Aug 19 16:24:37 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 19 Aug 2025 16:24:37 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v4]
In-Reply-To: <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>
Message-ID: <INpNz-JbOQJQQqqfSVT9uMrP1tcWz0WcrPLLGE9lETk=.9b809889-d709-4e07-bbf9-8e3fa3503a95@github.com>

On Tue, 19 Aug 2025 15:20:52 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Class.java
>   
>   correct length of class name

Surely that loop already exists, and even if it not, it should live in a place where it is more widely useful and easier to optimize.

(Widely useful?  Yes, because asking the length of a string in modified-utf8, and checking whether it fits inside the constant pool limit, is not just for `Class::forName`.)

(Easier to optimize?  If we have the loop in a common place, maintainers will probably ensure that it has the right performance characteristics.  A one-off loop is less likely to attract improvements in the future.)

A quick search reveals a new friend, `jdk.internal.util.ModifiedUtf::utfLen`.  It seems to me you should use that rather than writing your own loop.  Look at other code (under `java.*` packages) that uses it for a model.  You can pass zero for the funny extra parameter.

Perhaps not for this PR, we might add a method somewhere (requires discussion) that calls `jdk.internal.util.ModifiedUtf::utfLen` and also the prefix-searcher (non-zero-ascii only?).  But if we just have a hand-rolled one-off loop, it is much harder to make such improvements.  If we use API points instead of manual loops, its much easier for maintainers to make improvements.

Also, speaking of improvements, if such a method is framed as a constant pool validity check (`isValidConstantPoolString`) then an O(1) check is possible:  Just ask if the string's body is less than (1<<16)/2 for ASCII-only strings, and less than (1<<16)/3 for other strings, and there's no need to search the string body.  But this only works for an API point that "knows" what the maximum size is ahead of time.  The classfile spinner logic could use this, not just for class names, but for all `CONSTANT_Utf8` entries in the CP.  That work would NOT be for this PR, but rather for the authors of the classfile API to think about.

(Chen beat me to the discovery!)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3201402304
PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3201404019

From rriggs at openjdk.org  Tue Aug 19 16:48:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 16:48:43 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v4]
In-Reply-To: <Q42gIyby5n9jbP7PjF7qicvmKbsgktXvI1LhKijZNMw=.a09cb9ae-3e7c-4ae7-acd5-a19f4eb89b64@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <Q42gIyby5n9jbP7PjF7qicvmKbsgktXvI1LhKijZNMw=.a09cb9ae-3e7c-4ae7-acd5-a19f4eb89b64@github.com>
Message-ID: <e8eK-fHYgpW3DQyjph1P0oiPS586hsZzyN4FumiBKHE=.52c4e8e9-45a4-4c9e-a2a5-14faf63d9252@github.com>

On Tue, 12 Aug 2025 19:29:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant type parameters

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 361:

> 359:      * @throws CharacterCodingException For malformed input or unmappable characters
> 360:      */
> 361:     String newStringUTF8NoReplacement(byte[] bytes, int offset, int length) throws CharacterCodingException;

This method is only used by ZipCoder and could be refactored to use `uncheckedNewStringNoReplacement` as in PR#https://github.com/openjdk/jdk/pull/26822.
It is a refactoring cleanup not directly related to renaming the NoRepl methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2285806922

From vyazici at openjdk.org  Tue Aug 19 17:07:36 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 17:07:36 GMT
Subject: RFR: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
In-Reply-To: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
References: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
Message-ID: <koQwgvJLPX2SL2Mzx15n4a1zKbHoJx8MXhc9EObQkKI=.e6cd119f-903f-4458-b08e-45e2c32eacbd@github.com>

On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when creating the string from the supplied latin1 bytes. 
> If COMPACT_STRINGS is false, the bytes are inflated to UTF16.

Verified

* All `uncheckedNewStringNoRepl` call-sites
* All `uncheckedNewStringWithLatin1Bytes` call-sites provide valid Latin-1 `byte[]`
* New `newStringWithLatin1Bytes` is a verbatim copy of the relevant sections from `newStringNoRepl1`, which provides `newStringNoRepl`
* Copyright year bumps

-------------

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26831#pullrequestreview-3133151566

From duke at openjdk.org  Tue Aug 19 17:25:44 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 19 Aug 2025 17:25:44 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs [v2]
In-Reply-To: <L-GZflmckhvHik1Yh2AKIkglbcJQaXJyvTsYc8Donug=.c093953c-06b6-479b-82f6-f3824f78a52b@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <L-GZflmckhvHik1Yh2AKIkglbcJQaXJyvTsYc8Donug=.c093953c-06b6-479b-82f6-f3824f78a52b@github.com>
Message-ID: <LQqA9Mu-vchWtNP4kTqbZKWZYnShz5rBrXTd-piViFU=.29d6db47-195d-43c2-90d0-c50063b11522@github.com>

On Tue, 19 Aug 2025 13:18:49 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
>> 
>> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
>> 
>> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implementing feedback, adding missing errno checks, cleanup

src/java.base/macosx/classes/sun/nio/ch/KQueuePoller.java line 50:

> 48:                     "kqueue failed");
> 49:         }
> 50:         this.kqfd = res;

Maybe?this duplicated?check should?probably be?moved?into a?common?method in?`KQueue`, like?the?old `KQueue.create()`?method, but?implemented in?**Java**:

static int create() throws IOException {
	int res = kqueue_h.kqueue();
	if (res < 0) {
		throw ErrnoUtils.IOExceptionWithErrnoString(-res, "kqueue failed");
	}
	return res;
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2285879853

From vyazici at openjdk.org  Tue Aug 19 17:53:39 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 17:53:39 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl
In-Reply-To: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
Message-ID: <kDPcnqOeTPDvl2yCpbVoba1_KDrp0EZTMuoVqrbdUOA=.17a280a1-d77f-4a44-a0a6-80c1e153bf24@github.com>

On Mon, 18 Aug 2025 15:31:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

Marked as reviewed by vyazici (Committer).

src/java.base/share/classes/java/lang/String.java line 763:

> 761:      * The byte array can be exclusively used to construct
> 762:      * the string and is not modified or used for any other purpose.
> 763:      */

I see you opted for adhering to the method commenting style that is already present in the file. While I can see the rationale and advantages for such an approach, we might also consider incorporating a complete Javadoc block, e.g.,

Suggestion:

    /**
     * {@return a new {@code String} created using the given byte array that is
     * encoded in specified charset}
     * <p>
     * <b>WARNING: The caller of this method is assumed to have relinquished
     * and transferred the ownership of the byte array</b>. It can thus be
     * exclusively used to construct the {@code String}.
     *
     * @param src byte array containing encoded characters
     * @param cs charset the byte array encoded in
     *
     * @throws CharacterCodingException for malformed input or unmappable characters
     */


I trust your judgement on the matter. Feel free the discard the above remark.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26822#pullrequestreview-3133259512
PR Review Comment: https://git.openjdk.org/jdk/pull/26822#discussion_r2285931273

From vyazici at openjdk.org  Tue Aug 19 17:53:40 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 17:53:40 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl
In-Reply-To: <YAIF2AahIjujeO3vEdJm7v-XYtrctrMN2DK2O5GUyRU=.4b82c596-cadb-44d4-bebb-c194d84cfd26@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
 <-0fR1GN06Wdba7TKwbKidSU_pEA5MOurcK7fVeaY2r8=.eaafc81d-f50b-4024-a59f-d2d004849f4e@github.com>
 <YAIF2AahIjujeO3vEdJm7v-XYtrctrMN2DK2O5GUyRU=.4b82c596-cadb-44d4-bebb-c194d84cfd26@github.com>
Message-ID: <D-qh-cplZTgVnSZL7mcbwpsyi5BIsILyUxGRy9ijOlQ=.a2075aee-f64f-4d83-8ca6-3111f4a034ed@github.com>

On Tue, 19 Aug 2025 14:33:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipCoder.java line 283:
>> 
>>> 281:                 // We use the JLA.newStringUTF8NoRepl variant to throw
>>> 282:                 // exceptions eagerly when opening ZipFiles
>>> 283:                 return hash(toString(a, off, len));
>> 
>> Earlier, `byte[]` was shared by the `String` instantiated, now it needs to be cloned. That is, I presume this to have a performance implication. Was this considered?
>
> It always makes a copy, previously and as refactored.
> The trampoline in System.java called into String with noShare = true.
> 
> public String newStringUTF8NoRepl(byte[] bytes, int off, int len) {
>     return String.newStringUTF8NoRepl(bytes, off, len, true);
> }
> 
> Now the copy is explicitly done by the caller and the contract is clear that the buffer is always not shared but transferred. (and one less argument and conditional)

Right. Apparently I was completely lost while trying to follow that double-negation (i.e., `noShare = true`) logic. Thanks so much for the elaborate explanation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26822#discussion_r2285924877

From rriggs at openjdk.org  Tue Aug 19 17:57:20 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 17:57:20 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl [v2]
In-Reply-To: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
Message-ID: <iE3cFXyPtwl3u62BMOrLPVr9dIZ4oIAYNxHA1oJrJII=.4b4ef487-3b34-476f-9fad-30ab7d39db71@github.com>

> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Flesh out javadoc in src/java.base/share/classes/java/lang/String.java
  
  Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26822/files
  - new: https://git.openjdk.org/jdk/pull/26822/files/3ec3f69d..ef153862

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26822&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26822&range=00-01

  Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26822.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26822/head:pull/26822

PR: https://git.openjdk.org/jdk/pull/26822

From rriggs at openjdk.org  Tue Aug 19 18:00:36 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 18:00:36 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl [v2]
In-Reply-To: <kDPcnqOeTPDvl2yCpbVoba1_KDrp0EZTMuoVqrbdUOA=.17a280a1-d77f-4a44-a0a6-80c1e153bf24@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
 <kDPcnqOeTPDvl2yCpbVoba1_KDrp0EZTMuoVqrbdUOA=.17a280a1-d77f-4a44-a0a6-80c1e153bf24@github.com>
Message-ID: <Z_WzkqFec2qTtKnaB3ijB6prVXkUdltKdUWgtKXew2I=.6160f842-1a98-4dba-a2d2-202074eef173@github.com>

On Tue, 19 Aug 2025 17:50:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Flesh out javadoc in src/java.base/share/classes/java/lang/String.java
>>   
>>   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>
> Marked as reviewed by vyazici (Committer).

@vy Thanks for the more complete javadoc. Please re-review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26822#issuecomment-3201676492

From rriggs at openjdk.org  Tue Aug 19 18:24:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 18:24:39 GMT
Subject: RFR: 8364752: Class java.time.Instant cannot parse all ISO 8601
 date formats [v7]
In-Reply-To: <7C6nMpOBczEFuUsCqtJjz1V_5ylyvL9-3PLcXjolg0g=.26469091-6b8a-43b1-a81a-b525691c1d55@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <7C6nMpOBczEFuUsCqtJjz1V_5ylyvL9-3PLcXjolg0g=.26469091-6b8a-43b1-a81a-b525691c1d55@github.com>
Message-ID: <s6qohQ84R83TldxAsQgwbuw7c_kd3zgicMU3eLRs8Sc=.d40bb109-9d53-46af-bae9-cbe5d2ecb72c@github.com>

On Mon, 18 Aug 2025 19:19:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.
>
> 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 nine additional commits since the last revision:
> 
>  - DateTimeFormatterBuilder wording
>  - Added non-zero offset test cases
>  - Merge branch 'master' into JDK-8364752-Instant-ISO8601
>  - Update src/java.base/share/classes/java/time/format/DateTimeFormatter.java
>    
>    Right. Changing to your suggested wording
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - copyright year update
>  - test cases
>  - allow all ISO 8601 offsets
>  - allow hour-only offsets
>  - initial commit

Looks good, thanks for the explanation of the parsing format.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26708#pullrequestreview-3133368081

From lancea at openjdk.org  Tue Aug 19 18:28:38 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 19 Aug 2025 18:28:38 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl [v2]
In-Reply-To: <iE3cFXyPtwl3u62BMOrLPVr9dIZ4oIAYNxHA1oJrJII=.4b4ef487-3b34-476f-9fad-30ab7d39db71@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
 <iE3cFXyPtwl3u62BMOrLPVr9dIZ4oIAYNxHA1oJrJII=.4b4ef487-3b34-476f-9fad-30ab7d39db71@github.com>
Message-ID: <ZlpoT4fMBsWlEUxCLQ_-M4Pbc_8VHlmcG69hqww48d8=.be89e497-31ad-4948-8c1e-35d6a9121547@github.com>

On Tue, 19 Aug 2025 17:57:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Flesh out javadoc in src/java.base/share/classes/java/lang/String.java
>   
>   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26822#pullrequestreview-3133382802

From duke at openjdk.org  Tue Aug 19 18:37:38 2025
From: duke at openjdk.org (simon)
Date: Tue, 19 Aug 2025 18:37:38 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <lrGc0T402-YGh15BhxlTRnuWqjNYYWBPYd9G-oxHZfU=.e46b94a0-0807-4882-8aea-6464d3e47e07@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <1SnIOzJsyWrBHdfrsQh7mT6_ImIeGx1QoifHfHwqo_w=.977f95f8-3a62-4643-8b70-e6f6a1e2934e@github.com>
 <lrGc0T402-YGh15BhxlTRnuWqjNYYWBPYd9G-oxHZfU=.e46b94a0-0807-4882-8aea-6464d3e47e07@github.com>
Message-ID: <fPa-j7hxQXpAmmXgNmKdx_OXN6vIVoVjVuv6YvHKI2o=.0bdf34e7-89af-4040-ad24-1323ecbc9733@github.com>

On Sun, 20 Jul 2025 23:36:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @liach I know that I'm commenting on a weekend but it's to you see tomorrow. 
>> 
>> I'm commiting a 1.0 version for this implementation - to get your feedback about
>> 
>> I think we should create some unit tests for this API and classes involved. Where do you think that is the most appropriate location in the project to do it?
>
>> I think we should create some unit tests for this API and classes involved. Where do you think that is the most appropriate location in the project to do it?
> 
> Unit tests for `java.lang.classfile` reside in `test/jdk/jdk/classfile`. They can be run with `make test TEST=jdk/jdk/classfile`.

@liach I'm busy on my regular work, but I'll work on it in a few days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26406#issuecomment-3201783832

From duke at openjdk.org  Tue Aug 19 18:51:37 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 19 Aug 2025 18:51:37 GMT
Subject: RFR: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
In-Reply-To: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
References: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
Message-ID: <IAPavzCcJKBaT-W6uzo5Kk67ii6X3S_1zPow6cmieiA=.2adc443f-102f-4096-8979-2a7091ed6c96@github.com>

On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when creating the string from the supplied latin1 bytes. 
> If COMPACT_STRINGS is false, the bytes are inflated to UTF16.

src/java.base/share/classes/java/lang/String.java line 773:

> 771: 
> 772:         if (COMPACT_STRINGS)
> 773:             return new String(src, LATIN1);

small suggestion: add braces around the return statement

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26831#discussion_r2286047919

From duke at openjdk.org  Tue Aug 19 19:09:43 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 19 Aug 2025 19:09:43 GMT
Subject: RFR: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
In-Reply-To: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
References: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
Message-ID: <GrsBKUg_YSTNPsYC822Wpolu7AfS1ki7DA9EroV2REc=.e2edd2f4-6b9d-4c12-9a97-b7618f2e2f37@github.com>

On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when creating the string from the supplied latin1 bytes. 
> If COMPACT_STRINGS is false, the bytes are inflated to UTF16.

src/java.base/share/classes/java/lang/String.java line 766:

> 764:      * @param src a byte array with the bytes for a latin1 string
> 765:      */
> 766:     static String newStringWithLatin1Bytes(byte[] src) {

You could call this new method from `newStringNoRepl1(byte[] src, Charset cs)` for the ISO_8859_1 case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26831#discussion_r2286100360

From rriggs at openjdk.org  Tue Aug 19 19:09:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 19:09:44 GMT
Subject: RFR: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
In-Reply-To: <IAPavzCcJKBaT-W6uzo5Kk67ii6X3S_1zPow6cmieiA=.2adc443f-102f-4096-8979-2a7091ed6c96@github.com>
References: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
 <IAPavzCcJKBaT-W6uzo5Kk67ii6X3S_1zPow6cmieiA=.2adc443f-102f-4096-8979-2a7091ed6c96@github.com>
Message-ID: <tVxZFTvuB14MT2wv9NyDzj67JyZ2qXVqi41R-OhAihY=.c1b96b60-60ca-4875-8112-9057ca44d85f@github.com>

On Tue, 19 Aug 2025 18:42:58 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
>> There is no decoding needed, and no exceptions expected or thrown when creating the string from the supplied latin1 bytes. 
>> If COMPACT_STRINGS is false, the bytes are inflated to UTF16.
>
> src/java.base/share/classes/java/lang/String.java line 773:
> 
>> 771: 
>> 772:         if (COMPACT_STRINGS)
>> 773:             return new String(src, LATIN1);
> 
> small suggestion: add braces around the return statement

Will fix in a future update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26831#discussion_r2286096499

From rriggs at openjdk.org  Tue Aug 19 19:09:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 19:09:45 GMT
Subject: Integrated: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
In-Reply-To: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
References: <KRzN1O80AAvaZgDC44yi8MQh1Lm5QWnsg6BkrD6ljR0=.9cf194d8-0f5b-4f0e-9e01-b3bd6bd36074@github.com>
Message-ID: <zAb1YCeooT0NW-3Hv1QH0cNju_momj3A-2RCcuxJtO4=.0f80a141-9594-4b6c-b1f8-ffb310e280d5@github.com>

On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when creating the string from the supplied latin1 bytes. 
> If COMPACT_STRINGS is false, the bytes are inflated to UTF16.

This pull request has now been integrated.

Changeset: 884076f6
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/884076f6e249c336b088642e483adc0896df7a6e
Stats:     80 lines in 7 files changed: 32 ins; 39 del; 9 mod

8365719: Refactor uses of JLA.uncheckedNewStringNoRepl

Reviewed-by: liach, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/26831

From rriggs at openjdk.org  Tue Aug 19 19:24:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 19:24:51 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl [v3]
In-Reply-To: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
Message-ID: <cSXcP4M_VYnsvyKeR0k_O1dAgMDalCicvAU2DxbIeXw=.81c56551-827a-4b24-a3f6-1f46f10a5074@github.com>

> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge
 - Flesh out javadoc in src/java.base/share/classes/java/lang/String.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - 8365703: Refactor ZipCoder to use common JLA.uncheckedNewStringNoRepl
   
   Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs)
   instead of the JLA.newStringUTF8NoRepl.
   A copy of the bytes is made so it can be exclusively used to create the string.
   The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

-------------

Changes: https://git.openjdk.org/jdk/pull/26822/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26822&range=02
  Stats: 44 lines in 4 files changed: 20 ins; 17 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26822.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26822/head:pull/26822

PR: https://git.openjdk.org/jdk/pull/26822

From liach at openjdk.org  Tue Aug 19 19:28:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Aug 2025 19:28:38 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
 [v2]
In-Reply-To: <d4eKNq628qw6wxeZxmhH8zeOb78fV0Y4C3U6eLyOFF0=.80069f4b-5d44-493b-99c7-b3e5170a788e@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <d4eKNq628qw6wxeZxmhH8zeOb78fV0Y4C3U6eLyOFF0=.80069f4b-5d44-493b-99c7-b3e5170a788e@github.com>
Message-ID: <8SATUrpYYdU3aqlNNHpKWrlL5AvNJfrI3oW0shsGYI0=.9516b28f-3c70-422d-a88e-5aa92c4070b0@github.com>

On Mon, 21 Jul 2025 20:57:03 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>
>
> simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8355652: update copyright year to 2025 in ClassFileVersionImpl.java
>  - 8355652: update copyright year to 2025 in ClassFileVersionImpl.java

No worries, you can also use `/open` command to reopen a bot-closed PR if the bot closes for inactivity.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26406#issuecomment-3201955675

From vyazici at openjdk.org  Tue Aug 19 19:52:39 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 19:52:39 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl [v3]
In-Reply-To: <cSXcP4M_VYnsvyKeR0k_O1dAgMDalCicvAU2DxbIeXw=.81c56551-827a-4b24-a3f6-1f46f10a5074@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
 <cSXcP4M_VYnsvyKeR0k_O1dAgMDalCicvAU2DxbIeXw=.81c56551-827a-4b24-a3f6-1f46f10a5074@github.com>
Message-ID: <rt9Fr73RxD7qOHAiaPj5s3eaBzNJNJUk1VFs2GDsN9w=.ace7533b-370d-4b30-9a1d-b263989a39bf@github.com>

On Tue, 19 Aug 2025 19:24:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - Flesh out javadoc in src/java.base/share/classes/java/lang/String.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - 8365703: Refactor ZipCoder to use common JLA.uncheckedNewStringNoRepl
>    
>    Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs)
>    instead of the JLA.newStringUTF8NoRepl.
>    A copy of the bytes is made so it can be exclusively used to create the string.
>    The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

Marked as reviewed by vyazici (Committer).

src/java.base/share/classes/java/lang/String.java line 696:

> 694:      * the string and is not modified or used for any other purpose.
> 695:      */
> 696:     static String newStringUTF8NoRepl(byte[] bytes, int offset, int length) {

@RogerRiggs, `/integrate` has failed due to merge conflict. While you're at it, you might consider making this method `private`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26822#pullrequestreview-3133624472
PR Review Comment: https://git.openjdk.org/jdk/pull/26822#discussion_r2286184625

From almatvee at openjdk.org  Tue Aug 19 20:13:10 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 19 Aug 2025 20:13:10 GMT
Subject: RFR: 8356218: [macos] Document --app-content
Message-ID: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>

- Added following note for `--app-content` on macOS to help and man page: `The value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the application bundle). Otherwise, jpackage may produce invalid application bundle which may fail code signing and/or notarization.`
- Added warning if `--app-content` if it points to non-standard subdirectory in "Contents" directory.
- Added test to cover warning message.

-------------

Commit messages:
 - 8356218: [macos] Document --app-content

Changes: https://git.openjdk.org/jdk/pull/26848/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26848&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356218
  Stats: 55 lines in 6 files changed: 49 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26848/head:pull/26848

PR: https://git.openjdk.org/jdk/pull/26848

From rriggs at openjdk.org  Tue Aug 19 20:32:23 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 20:32:23 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl [v4]
In-Reply-To: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
Message-ID: <8_5H_-8mi85LsHFczMNRtfgUR3rawFtOiBLtMOt2sOY=.ab085541-38a0-4754-bcb9-e2daa2ebd6cc@github.com>

> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Declare newStringUTF8NoRepl `private`, it no longer needs to be package private

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26822/files
  - new: https://git.openjdk.org/jdk/pull/26822/files/aa245f84..f47c0c70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26822&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26822&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26822.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26822/head:pull/26822

PR: https://git.openjdk.org/jdk/pull/26822

From lancea at openjdk.org  Tue Aug 19 20:35:37 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 19 Aug 2025 20:35:37 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl [v4]
In-Reply-To: <8_5H_-8mi85LsHFczMNRtfgUR3rawFtOiBLtMOt2sOY=.ab085541-38a0-4754-bcb9-e2daa2ebd6cc@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
 <8_5H_-8mi85LsHFczMNRtfgUR3rawFtOiBLtMOt2sOY=.ab085541-38a0-4754-bcb9-e2daa2ebd6cc@github.com>
Message-ID: <ZmB0cefLZiUX73zC7V7FwcfQ9aRGMh2N-4qo1cyP0S4=.28a2502d-3538-487f-989b-15ae6773a554@github.com>

On Tue, 19 Aug 2025 20:32:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declare newStringUTF8NoRepl `private`, it no longer needs to be package private

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26822#pullrequestreview-3133743530

From duke at openjdk.org  Tue Aug 19 20:36:46 2025
From: duke at openjdk.org (Brett Okken)
Date: Tue, 19 Aug 2025 20:36:46 GMT
Subject: Integrated: 8364320: String encodeUTF8 latin1 with negatives
In-Reply-To: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
References: <IeW9GHNHe4VFjSQHwU6n2IGKRCVm7RqSTF3c7SvTm1s=.a511c276-3e2b-4976-ba0b-0d12688a4756@github.com>
Message-ID: <hdeyYoybvLwMQPuxUz0_EmhawnAL3_RcuhFOVUJp5TA=.c677cd93-0b91-4b7f-9dbc-5c967c919d69@github.com>

On Fri, 1 Aug 2025 12:34:15 GMT, Brett Okken <duke at openjdk.org> wrote:

> As suggested on mailing list, when encoding latin1 bytes to utf-8, we can count the leading positive bytes and in the case where there is a negative, we can copy all the positive values to the target byte[] prior to processing the remaining data 1 byte at a time.
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149417.html

This pull request has now been integrated.

Changeset: 3bbaa772
Author:    Brett Okken <brett.okken at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bbaa772b0bb94694940156ec0ce421f87f02be7
Stats:     9 lines in 1 file changed: 6 ins; 1 del; 2 mod

8364320: String encodeUTF8 latin1 with negatives

Reviewed-by: liach, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/26597

From asemenyuk at openjdk.org  Tue Aug 19 21:08:37 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Aug 2025 21:08:37 GMT
Subject: RFR: 8356218: [macos] Document --app-content
In-Reply-To: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
Message-ID: <NZD7RZu6MkHNhntZE4xEMU5CK5zx5n4BmDrcItKpLiY=.b5a10621-d774-4126-8827-c4aef6801720@github.com>

On Tue, 19 Aug 2025 20:07:10 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added following note for `--app-content` on macOS to help and man page: `The value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the application bundle). Otherwise, jpackage may produce invalid application bundle which may fail code signing and/or notarization.`
> - Added warning if `--app-content` if it points to non-standard subdirectory in "Contents" directory.
> - Added test to cover warning message.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 134:

> 132:                     .anyMatch(subDir -> contentDir.getFileName().toString()
> 133:                                                   .equalsIgnoreCase(subDir))) {
> 134:                 Log.info(MessageFormat.format(I18N.getString(

Can be simplified down to:

Log.info(I18N.format("warning.non.standard.contents.sub.dir", contentDir));

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 88:

> 86: warning.unsigned.app.image=Warning: Using unsigned app-image to build signed {0}.
> 87: warning.per.user.app.image.signed=Warning: Support for per-user configuration of the installed application will not be supported due to missing "{0}" in predefined signed application image.
> 88: warning.non.standard.contents.sub.dir=Warning: --app-content value "{0}" points to the non-standard subdirectory in the "Contents" directory of the application bundle.

This warning is not particularly helpful. It doesn't provide details.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2286330418
PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2286334217

From asemenyuk at openjdk.org  Tue Aug 19 21:20:37 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Aug 2025 21:20:37 GMT
Subject: RFR: 8356218: [macos] Document --app-content
In-Reply-To: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
Message-ID: <hPoArdDy7V-wHgHj2Tg6wZDdBZ4ebX8GWlxOVHQ5kWg=.67b9c10a-954e-424c-aefd-8bb083869f42@github.com>

On Tue, 19 Aug 2025 20:07:10 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added following note for `--app-content` on macOS to help and man page: `The value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the application bundle). Otherwise, jpackage may produce invalid application bundle which may fail code signing and/or notarization.`
> - Added warning if `--app-content` if it points to non-standard subdirectory in "Contents" directory.
> - Added test to cover warning message.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 133:

> 131:             if (!CONTENTS_SUB_DIRS.stream()
> 132:                     .anyMatch(subDir -> contentDir.getFileName().toString()
> 133:                                                   .equalsIgnoreCase(subDir))) {

Why case-insensitive path name comparison on Unix?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2286356298

From almatvee at openjdk.org  Tue Aug 19 21:29:37 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 19 Aug 2025 21:29:37 GMT
Subject: RFR: 8356218: [macos] Document --app-content
In-Reply-To: <hPoArdDy7V-wHgHj2Tg6wZDdBZ4ebX8GWlxOVHQ5kWg=.67b9c10a-954e-424c-aefd-8bb083869f42@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
 <hPoArdDy7V-wHgHj2Tg6wZDdBZ4ebX8GWlxOVHQ5kWg=.67b9c10a-954e-424c-aefd-8bb083869f42@github.com>
Message-ID: <O2VQ03JH-_y4lAVHHgEN30-CLFr-QQIDOyo9LcKoXTg=.4d9f494c-bfac-4496-9eb9-48ef9ebf5623@github.com>

On Tue, 19 Aug 2025 21:17:37 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Added following note for `--app-content` on macOS to help and man page: `The value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the application bundle). Otherwise, jpackage may produce invalid application bundle which may fail code signing and/or notarization.`
>> - Added warning if `--app-content` if it points to non-standard subdirectory in "Contents" directory.
>> - Added test to cover warning message.
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 133:
> 
>> 131:             if (!CONTENTS_SUB_DIRS.stream()
>> 132:                     .anyMatch(subDir -> contentDir.getFileName().toString()
>> 133:                                                   .equalsIgnoreCase(subDir))) {
> 
> Why case-insensitive path name comparison on Unix?

By default macOS is case-insensitive. If I rename `MacOS` to `macos` in application bundle, such bundle will still works. I assumed that `Resources` and `resources` are same thing. After thinking more about it I think it should be case sensitive comparison. Will change it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2286373060

From rriggs at openjdk.org  Tue Aug 19 21:43:41 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 21:43:41 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v3]
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: <wqSm8F00PIjp2Rx4eBicHlrhywbR5arhTmj4DEGuW_w=.14241807-5eae-4ec9-9ffb-6422c6aadd89@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 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 8364361-process-autocloseable
 - Throw IOExceptions on close instead of logging.
 - The close method is idempotent, it will only close the streams and
   destroy the process on the first call to close.
 - Updates from review comments:
    - Editorial improvements to javadoc
    - Exceptions that occur closing streams are quietly logged
      to the java.lang.Process system log as DEBUG
    - The prototype code attempting to wait for process exit is removed,
      it provided marginal benefit and raised complexity due to interrupt handling
    - Test updates for racy test cases that are not errors
 - 8364361: [process] java.lang.Process should implement close and be AutoCloseable
   Specify and implement AutoCloseable for Process.
   Add tests and example code as a snippet.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/c04ee6e2..06af45c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=01-02

  Stats: 23164 lines in 697 files changed: 14071 ins; 6269 del; 2824 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 rriggs at openjdk.org  Tue Aug 19 21:50:33 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 21:50:33 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v4]
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: <BwaqlzimwTEQlIaW0oZ4-lQ6Z-22PQVeuxTA4RboP24=.861e2a28-26ff-435b-8e6f-70ffbb4ed965@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:

  Revisited handling of IOExceptions to throw instead of completely ignoring or logging.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/06af45c0..6f393df1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=02-03

  Stats: 74 lines in 4 files changed: 16 ins; 47 del; 11 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 acobbs at openjdk.org  Tue Aug 19 21:54:37 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 19 Aug 2025 21:54:37 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v4]
In-Reply-To: <BwaqlzimwTEQlIaW0oZ4-lQ6Z-22PQVeuxTA4RboP24=.861e2a28-26ff-435b-8e6f-70ffbb4ed965@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <BwaqlzimwTEQlIaW0oZ4-lQ6Z-22PQVeuxTA4RboP24=.861e2a28-26ff-435b-8e6f-70ffbb4ed965@github.com>
Message-ID: <vU6LdPF1aj7fNJkXSc4CcFSG4XRLwV7SsWlRNqa1100=.02f63842-5de1-43b6-ad42-25fa2ace1c98@github.com>

On Tue, 19 Aug 2025 21:50:33 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:
> 
>   Revisited handling of IOExceptions to throw instead of completely ignoring or logging.

src/java.base/share/classes/java/lang/Process.java line 652:

> 650:      */
> 651:     public void close() throws IOException {
> 652:         synchronized(this) {

Might be safer to create a dedicated, private object to use for locking here instead of `this`. Otherwise there's a possibility of deadlock (or indefinite delay), for example, if a subclass happens to have a `synchronized` method that could block while trying to communicate with the process, etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2286415567

From almatvee at openjdk.org  Tue Aug 19 22:10:53 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 19 Aug 2025 22:10:53 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v2]
In-Reply-To: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
Message-ID: <L7Qf1r3tu4ByoBrNC7m49Gd7MLCALQvq1JB8-dWZesI=.2015e27d-5196-453c-b2e5-77e9ae5e3ec5@github.com>

> - Added following note for `--app-content` on macOS to help and man page: `The value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the application bundle). Otherwise, jpackage may produce invalid application bundle which may fail code signing and/or notarization.`
> - Added warning if `--app-content` if it points to non-standard subdirectory in "Contents" directory.
> - Added test to cover warning message.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8356218: [macos] Document --app-content [v2]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26848/files
  - new: https://git.openjdk.org/jdk/pull/26848/files/803787f2..18d37f69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26848&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26848&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26848/head:pull/26848

PR: https://git.openjdk.org/jdk/pull/26848

From almatvee at openjdk.org  Tue Aug 19 22:10:53 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 19 Aug 2025 22:10:53 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v2]
In-Reply-To: <O2VQ03JH-_y4lAVHHgEN30-CLFr-QQIDOyo9LcKoXTg=.4d9f494c-bfac-4496-9eb9-48ef9ebf5623@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
 <hPoArdDy7V-wHgHj2Tg6wZDdBZ4ebX8GWlxOVHQ5kWg=.67b9c10a-954e-424c-aefd-8bb083869f42@github.com>
 <O2VQ03JH-_y4lAVHHgEN30-CLFr-QQIDOyo9LcKoXTg=.4d9f494c-bfac-4496-9eb9-48ef9ebf5623@github.com>
Message-ID: <KZHTtZLtwI3kVkxlAtrf5uwI4MpnyvStcN6lOmMVsh8=.a0ee92a6-166a-4a82-8dfd-d72c98c7019c@github.com>

On Tue, 19 Aug 2025 21:26:41 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 133:
>> 
>>> 131:             if (!CONTENTS_SUB_DIRS.stream()
>>> 132:                     .anyMatch(subDir -> contentDir.getFileName().toString()
>>> 133:                                                   .equalsIgnoreCase(subDir))) {
>> 
>> Why case-insensitive path name comparison on Unix?
>
> By default macOS is case-insensitive. If I rename `MacOS` to `macos` in application bundle, such bundle will still works. I assumed that `Resources` and `resources` are same thing. After thinking more about it I think it should be case sensitive comparison. Will change it.

Changed to case sensitive comparison.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2286440419

From almatvee at openjdk.org  Tue Aug 19 22:10:53 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 19 Aug 2025 22:10:53 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v2]
In-Reply-To: <NZD7RZu6MkHNhntZE4xEMU5CK5zx5n4BmDrcItKpLiY=.b5a10621-d774-4126-8827-c4aef6801720@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
 <NZD7RZu6MkHNhntZE4xEMU5CK5zx5n4BmDrcItKpLiY=.b5a10621-d774-4126-8827-c4aef6801720@github.com>
Message-ID: <cEiZaMfYfUkbYaVeqSJnzx2y5JiB5uRb_8XgT4J-2uk=.8eed0cb2-3aff-4156-8a3e-0ab3243935e6@github.com>

On Tue, 19 Aug 2025 21:03:37 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356218: [macos] Document --app-content [v2]
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 134:
> 
>> 132:                     .anyMatch(subDir -> contentDir.getFileName().toString()
>> 133:                                                   .equalsIgnoreCase(subDir))) {
>> 134:                 Log.info(MessageFormat.format(I18N.getString(
> 
> Can be simplified down to:
> 
> Log.info(I18N.format("warning.non.standard.contents.sub.dir", contentDir));

Fixed. I copy-paste this code. We have many places with `MessageFormat.format(I18N.getString())`. Should I file follow up bug to clean-up it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2286439169

From asemenyuk at openjdk.org  Tue Aug 19 22:18:36 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Aug 2025 22:18:36 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v2]
In-Reply-To: <cEiZaMfYfUkbYaVeqSJnzx2y5JiB5uRb_8XgT4J-2uk=.8eed0cb2-3aff-4156-8a3e-0ab3243935e6@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
 <NZD7RZu6MkHNhntZE4xEMU5CK5zx5n4BmDrcItKpLiY=.b5a10621-d774-4126-8827-c4aef6801720@github.com>
 <cEiZaMfYfUkbYaVeqSJnzx2y5JiB5uRb_8XgT4J-2uk=.8eed0cb2-3aff-4156-8a3e-0ab3243935e6@github.com>
Message-ID: <SlpHeUMijwVfrN9tiULH1tl6gKEevDfSeSD7QXs_agY=.269fb84e-bf98-4253-a7d5-68bd05972194@github.com>

On Tue, 19 Aug 2025 22:06:56 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 134:
>> 
>>> 132:                     .anyMatch(subDir -> contentDir.getFileName().toString()
>>> 133:                                                   .equalsIgnoreCase(subDir))) {
>>> 134:                 Log.info(MessageFormat.format(I18N.getString(
>> 
>> Can be simplified down to:
>> 
>> Log.info(I18N.format("warning.non.standard.contents.sub.dir", contentDir));
>
> Fixed. I copy-paste this code. We have many places with `MessageFormat.format(I18N.getString())`. Should I file follow up bug to clean-up it?

Up to you. I think it is sufficient merely not add new `MessageFormat.format()` calls and use `I18N.format()` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2286451957

From dholmes at openjdk.org  Tue Aug 19 22:53:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 22:53:36 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v4]
In-Reply-To: <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>
Message-ID: <xCXSrsVfXdz9RTC5-g5Q74DGzFn4FZL4vdaB4hCqv5g=.fb615567-bcb7-4cc4-a3cd-94c19637954c@github.com>

On Tue, 19 Aug 2025 15:20:52 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Class.java
>   
>   correct length of class name

It is up to core-libs folk but to me that seems far too heavyweight to have on the Java side, and we are then going to repeat some of it in the C code.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26802#pullrequestreview-3134128473

From rriggs at openjdk.org  Tue Aug 19 23:36:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 23:36:42 GMT
Subject: RFR: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl [v4]
In-Reply-To: <8_5H_-8mi85LsHFczMNRtfgUR3rawFtOiBLtMOt2sOY=.ab085541-38a0-4754-bcb9-e2daa2ebd6cc@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
 <8_5H_-8mi85LsHFczMNRtfgUR3rawFtOiBLtMOt2sOY=.ab085541-38a0-4754-bcb9-e2daa2ebd6cc@github.com>
Message-ID: <yqoX-ITyEbpQA6pqFkvfYLs44Wlr1VqWZA7j-S4a4Io=.0f742bbe-21ed-4dc5-94fc-889f34d5600f@github.com>

On Tue, 19 Aug 2025 20:32:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declare newStringUTF8NoRepl `private`, it no longer needs to be package private

Thanks for the reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26822#issuecomment-3202937104

From rriggs at openjdk.org  Tue Aug 19 23:36:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 23:36:43 GMT
Subject: Integrated: 8365703: Refactor ZipCoder to use common
 JLA.uncheckedNewStringNoRepl
In-Reply-To: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
References: <BR4II1R4R69xY0Ty6U4Zs0g5PhxdrUkZs1erorX8fg0=.f9041e29-40b7-4b11-bacd-08560998bc46@github.com>
Message-ID: <YD9jxGyz1r-TYOIbLomKez9EWHdWCry6cmhJSW4LVBE=.dbf60852-2b3e-413e-bbbe-0e08caf4747c@github.com>

On Mon, 18 Aug 2025 15:31:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[] bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.

This pull request has now been integrated.

Changeset: 55e7494d
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55e7494deebfdacbb94d470995f770caa732877b
Stats:     44 lines in 4 files changed: 20 ins; 17 del; 7 mod

8365703: Refactor ZipCoder to use common JLA.uncheckedNewStringNoRepl

Reviewed-by: lancea, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/26822

From rriggs at openjdk.org  Tue Aug 19 23:40:37 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 23:40:37 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v4]
In-Reply-To: <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>
Message-ID: <Wx8DFMIxoP10sQ0ttDQMy3ZPuYCM4DlwUfL0rQaGY9E=.fcccf4ec-e011-46d7-ac6a-1de2a0c47c6e@github.com>

On Tue, 19 Aug 2025 15:20:52 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Class.java
>   
>   correct length of class name

src/java.base/share/classes/java/lang/Class.java line 4160:

> 4158:     private static boolean classNameLengthIsValid(String name) {
> 4159:         Objects.requireNonNull(name);
> 4160:         return getUtf8Length(name) <= JAVA_CLASSNAME_MAX_LEN;

An exact UTF-8 length is not needed to know that the length is valid.
The worst case expansion is *4 for an encoding of a pair of surrogate chars.
A quick approximation would be: `name.length() <= JAVA_CLASSNAME_MAX_LEN / 4`.
Most class names are much shorter and almost never need to compute the exact UTF-8 length.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2286624874

From duke at openjdk.org  Wed Aug 20 01:21:43 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 20 Aug 2025 01:21:43 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v2]
In-Reply-To: <L7Qf1r3tu4ByoBrNC7m49Gd7MLCALQvq1JB8-dWZesI=.2015e27d-5196-453c-b2e5-77e9ae5e3ec5@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
 <L7Qf1r3tu4ByoBrNC7m49Gd7MLCALQvq1JB8-dWZesI=.2015e27d-5196-453c-b2e5-77e9ae5e3ec5@github.com>
Message-ID: <1Tocftaax86p3LY8y0m-1zJktjWBUEYn96oAPXm9QcI=.b784748b-c9bf-427c-9694-dbf73a3b534e@github.com>

On Tue, 19 Aug 2025 22:10:53 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added following note for `--app-content` on macOS to help and man page: `The value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the application bundle). Otherwise, jpackage may produce invalid application bundle which may fail code signing and/or notarization.`
>> - Added warning if `--app-content` if it points to non-standard subdirectory in "Contents" directory.
>> - Added test to cover warning message.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356218: [macos] Document --app-content [v2]

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 130:

> 128:     private static void validateAppContentDirs(Application app) {
> 129:         for (var contentDir : app.contentDirs()) {
> 130:             if (!CONTENTS_SUB_DIRS.stream()

You could replace `CONTENTS_SUB_DIRS` with a `Set<String>`, and the inspection with `CONTENTS_SUB_DIRS.contains(contentDir.getFileName().toString())`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2286752531

From ghan at openjdk.org  Wed Aug 20 01:30:27 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Wed, 20 Aug 2025 01:30:27 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v5]
In-Reply-To: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
Message-ID: <mmb5HxGx_id_9uuM_BhrcITS8_fDIPyof-kI_lj5khU=.2148ac1f-e853-4d5e-aafb-f708aa6da00f@github.com>

> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  Update Class.java
  
  updates the class name length validation logic on the Java side

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26802/files
  - new: https://git.openjdk.org/jdk/pull/26802/files/8eb1d4c7..27971bf3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=03-04

  Stats: 22 lines in 1 file changed: 7 ins; 14 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26802/head:pull/26802

PR: https://git.openjdk.org/jdk/pull/26802

From ghan at openjdk.org  Wed Aug 20 05:10:39 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Wed, 20 Aug 2025 05:10:39 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v4]
In-Reply-To: <2vdariBU5CUr1jfa_KcEMmPrCtm2vTfdluBdQjt8OEs=.433e38c1-9467-420c-adf1-742a85206948@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <o23KlcqA0KABMEIgJa3Ox_v59i7Nd1J2qT1KMvL87qM=.df8766b3-708d-41de-827a-f322b230a625@github.com>
 <2vdariBU5CUr1jfa_KcEMmPrCtm2vTfdluBdQjt8OEs=.433e38c1-9467-420c-adf1-742a85206948@github.com>
Message-ID: <BaN56wBXLF5os39tWTkUJoNqElnjT6mp_ZTSlSq6N8s=.8b251885-aea3-49db-a509-50ecb6dd3a6d@github.com>

On Tue, 19 Aug 2025 16:05:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Class.java
>>   
>>   correct length of class name
>
> There is a `jdk.internal.util.ModifiedUtf::utfLen` that you can use instead of writing your own function.

@liach @dholmes-ora @rose00 @RogerRiggs Thanks for all the valuable feedback! I?ve updated the changes accordingly?please take another look when you have time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3204209083

From mbaesken at openjdk.org  Wed Aug 20 06:50:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Aug 2025 06:50:42 GMT
Subject: RFR: 8365700: Jar --validate without any --file option leaves
 around a temporary file /tmp/tmpJar<number>.jar
In-Reply-To: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
References: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
Message-ID: <j2HEUTaMvz79n0ADjD0U9mtugwSlJhyZlrS-erxIGio=.7af09a9e-01fb-475e-9704-335bb74dd3c3@github.com>

On Tue, 19 Aug 2025 07:51:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
> This has been observed at least on Linux and AIX .

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26837#issuecomment-3204413561

From mbaesken at openjdk.org  Wed Aug 20 06:50:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Aug 2025 06:50:43 GMT
Subject: Integrated: 8365700: Jar --validate without any --file option leaves
 around a temporary file /tmp/tmpJar<number>.jar
In-Reply-To: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
References: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
Message-ID: <fEzhZLegB_ayNUXsTPRhpRkDWBNVs4sMXzoYE9sKkXs=.ca6a4b1d-ffd8-4625-84b4-d7e270caa888@github.com>

On Tue, 19 Aug 2025 07:51:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
> This has been observed at least on Linux and AIX .

This pull request has now been integrated.

Changeset: 320235cc
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/320235ccb88b4b554cd5756b7e6a34ce97aabd53
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8365700: Jar --validate without any --file option leaves around a temporary file /tmp/tmpJar<number>.jar

Reviewed-by: jpai, asteiner

-------------

PR: https://git.openjdk.org/jdk/pull/26837

From epeter at openjdk.org  Wed Aug 20 06:55:44 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 20 Aug 2025 06:55:44 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
Message-ID: <59dW-P8qExfEfXqud1rOPax4qGcubqi9RQxM4tJLQoQ=.dd1a3fb3-8ded-4e2d-bc25-49456e7ab46f@github.com>

On Tue, 5 Aug 2025 11:39:43 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
>> 
>> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
>> 
>> 
>> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
>> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
>> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
>> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
>> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
>> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
>> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
>> 
>> 
>> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
>> 
>> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.
>
> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check at the very least that auto vectorization is supported

Had a quick look again and found a few more suggestions in the tests/benchmarks.
But I think the VM changes are solid :)

test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java line 407:

> 405: 
> 406:     @Test
> 407:     @IR(counts = {IRNode.STORE_VECTOR, "> 0"},

Since you are already fixing up some things here, and we want to be really sure that the vectorization generates correct results, can you please do the following:
- Create IR rule counts for not just the store, but also load and the MoveX2Y. For negative rules it is ok to only check for store, but for positive rules we should try to list all vectors we expect.
- Replace the `Random` usage with `Generators`. This ensures we cover NaN's and other special values more often.

test/micro/org/openjdk/bench/vm/compiler/VectorBitConversion.java line 90:

> 88: 
> 89:     @Benchmark
> 90:     public long[] doubleToLongBits() {

I wonder if we should not just extend this benchmark, that has `convertI2F` etc:
`test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java`

Just a suggestion, we can also keep them separately. Maybe one day we should clean up the benchmarks, and put them all in some `autovectorization` subdirectory, and organize the files and benchmarks a little better.

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26457#pullrequestreview-3135001659
PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2287146098
PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2287159346

From duke at openjdk.org  Wed Aug 20 07:40:23 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 20 Aug 2025 07:40:23 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
Message-ID: <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>

On Sat, 25 Jan 2025 13:04:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. This refactoring is to remove the unused code and reuse DecimalDigits to reduce duplication of code.

@wenshao How about extracting a new PR from this that only deals with removing the unused code?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-2847787894

From swen at openjdk.org  Wed Aug 20 07:40:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 07:40:23 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
Message-ID: <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>

On Fri, 2 May 2025 17:56:49 GMT, Johannes Graham <duke at openjdk.org> wrote:

> @wenshao How about extracting a new PR from this that only deals with removing the unused code?

Yes, but I will wait until after June 5th so that it does not affect the release of JDK 25.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-2856834563

From swen at openjdk.org  Wed Aug 20 07:40:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 07:40:23 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
Message-ID: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>

Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. This refactoring is to remove the unused code and reuse DecimalDigits to reduce duplication of code.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into floating_dec_202501
 - remove unused code
 - char[] -> byte[]

Changes: https://git.openjdk.org/jdk/pull/23311/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365832
  Stats: 202 lines in 2 files changed: 10 ins; 130 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/23311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23311/head:pull/23311

PR: https://git.openjdk.org/jdk/pull/23311

From rgiulietti at openjdk.org  Wed Aug 20 07:40:23 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Aug 2025 07:40:23 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
 <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
Message-ID: <Vyg8xcRO4yNnzRznlIgTtXWEyJE8MeInvp5rx3oMGT8=.f04f007c-9ef8-4822-ad47-c05ea8296074@github.com>

On Wed, 7 May 2025 02:25:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> @wenshao How about extracting a new PR from this that only deals with removing the unused code?
>
>> @wenshao How about extracting a new PR from this that only deals with removing the unused code?
> 
> Yes, but I will wait until after June 5th so that it does not affect the release of JDK 25.

@wenshao I'm working on a general overhaul of FloatingDecimal and related classes in some current and future PRs.

If you could restrict your changes to just DigitList, that would be less interference with my work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-2948860797

From swen at openjdk.org  Wed Aug 20 07:40:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 07:40:23 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
 <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
Message-ID: <vRv1b-U1eL3AG-kdC-8hbij2MW1LDCGbmyLkCOw8uIo=.df37437c-28d4-4bbc-89b9-c38614d56c40@github.com>

On Wed, 7 May 2025 02:25:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> @wenshao How about extracting a new PR from this that only deals with removing the unused code?
>
>> @wenshao How about extracting a new PR from this that only deals with removing the unused code?
> 
> Yes, but I will wait until after June 5th so that it does not affect the release of JDK 25.

> @wenshao I'm working on a general overhaul of FloatingDecimal and related classes in some current and future PRs.
> 
> If you could restrict your changes to just DigitList, that would be less interference with my work.

@rgiulietti  Sorry, I was traveling last week and I just saw your comment now. This is a draft pull request, you can move on with your plans and ignore it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-2968469161

From rgiulietti at openjdk.org  Wed Aug 20 07:40:23 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Aug 2025 07:40:23 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <vRv1b-U1eL3AG-kdC-8hbij2MW1LDCGbmyLkCOw8uIo=.df37437c-28d4-4bbc-89b9-c38614d56c40@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
 <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
 <vRv1b-U1eL3AG-kdC-8hbij2MW1LDCGbmyLkCOw8uIo=.df37437c-28d4-4bbc-89b9-c38614d56c40@github.com>
Message-ID: <h2Zq7_DFVEKkc5HE97E2f7ZaUr2c2BjaGMVb1vh0mXA=.c591cc84-e752-4845-8377-0df98b42ee83@github.com>

On Thu, 12 Jun 2025 23:54:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>>> @wenshao How about extracting a new PR from this that only deals with removing the unused code?
>> 
>> Yes, but I will wait until after June 5th so that it does not affect the release of JDK 25.
>
>> @wenshao I'm working on a general overhaul of FloatingDecimal and related classes in some current and future PRs.
>> 
>> If you could restrict your changes to just DigitList, that would be less interference with my work.
> 
> @rgiulietti  Sorry, I was traveling last week and I just saw your comment now. This is a draft pull request, you can move on with your plans and ignore it.

@wenshao Curiously, there are now some people (you, @j3graham and myself) which are working on FloatingDecimal and related classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-2970354634

From swen at openjdk.org  Wed Aug 20 07:40:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 07:40:23 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <vRv1b-U1eL3AG-kdC-8hbij2MW1LDCGbmyLkCOw8uIo=.df37437c-28d4-4bbc-89b9-c38614d56c40@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
 <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
 <vRv1b-U1eL3AG-kdC-8hbij2MW1LDCGbmyLkCOw8uIo=.df37437c-28d4-4bbc-89b9-c38614d56c40@github.com>
Message-ID: <zv01R276aJiQXC7jVvO9d8ALKpZUxvOimIYtA4wrH_I=.fe5ddca6-f5e6-42b2-a6b2-8b85383cc769@github.com>

On Thu, 12 Jun 2025 23:54:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>>> @wenshao How about extracting a new PR from this that only deals with removing the unused code?
>> 
>> Yes, but I will wait until after June 5th so that it does not affect the release of JDK 25.
>
>> @wenshao I'm working on a general overhaul of FloatingDecimal and related classes in some current and future PRs.
>> 
>> If you could restrict your changes to just DigitList, that would be less interference with my work.
> 
> @rgiulietti  Sorry, I was traveling last week and I just saw your comment now. This is a draft pull request, you can move on with your plans and ignore it.

> @wenshao Curiously, there are now some people (you, @j3graham and myself) which are working on FloatingDecimal and related classes.

In PR #23310, @j3graham 's comment on January 25 mentioned FloatingDecimal, so I paid attention to this class

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-2972264952

From rgiulietti at openjdk.org  Wed Aug 20 07:40:23 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Aug 2025 07:40:23 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <zv01R276aJiQXC7jVvO9d8ALKpZUxvOimIYtA4wrH_I=.fe5ddca6-f5e6-42b2-a6b2-8b85383cc769@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
 <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
 <vRv1b-U1eL3AG-kdC-8hbij2MW1LDCGbmyLkCOw8uIo=.df37437c-28d4-4bbc-89b9-c38614d56c40@github.com>
 <zv01R276aJiQXC7jVvO9d8ALKpZUxvOimIYtA4wrH_I=.fe5ddca6-f5e6-42b2-a6b2-8b85383cc769@github.com>
Message-ID: <9hDgCmZL6ehkYci0KtA63K9h9WpSpVI3q_ilQgpOZdo=.6906868b-cd1d-49e4-a07d-2f0cf3ad841d@github.com>

On Sat, 14 Jun 2025 04:58:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>>> @wenshao I'm working on a general overhaul of FloatingDecimal and related classes in some current and future PRs.
>>> 
>>> If you could restrict your changes to just DigitList, that would be less interference with my work.
>> 
>> @rgiulietti  Sorry, I was traveling last week and I just saw your comment now. This is a draft pull request, you can move on with your plans and ignore it.
>
>> @wenshao Curiously, there are now some people (you, @j3graham and myself) which are working on FloatingDecimal and related classes.
> 
> In PR #23310, @j3graham 's comment on January 25 mentioned FloatingDecimal, so I paid attention to this class

@wenshao While I didn't check all the details, I think these changes look OK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-3200026842

From liach at openjdk.org  Wed Aug 20 07:40:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Aug 2025 07:40:24 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
Message-ID: <PQHF9TnO_rfY28Vt98kX0S5-m_YPLUNhCrFs5G7WZSo=.12888e7b-ed64-4298-b81f-f506bf2ba1f0@github.com>

On Sat, 25 Jan 2025 13:04:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. This refactoring is to remove the unused code and reuse DecimalDigits to reduce duplication of code.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 988:

> 986:         return threadLocalBinaryToASCIIBuffer.get();
> 987:     }
> 988: 

Why was this thread local buffer removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23311#discussion_r1929831900

From swen at openjdk.org  Wed Aug 20 07:40:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 07:40:24 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <PQHF9TnO_rfY28Vt98kX0S5-m_YPLUNhCrFs5G7WZSo=.12888e7b-ed64-4298-b81f-f506bf2ba1f0@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <PQHF9TnO_rfY28Vt98kX0S5-m_YPLUNhCrFs5G7WZSo=.12888e7b-ed64-4298-b81f-f506bf2ba1f0@github.com>
Message-ID: <AocCAZat9KGWThT4qlYLNUzchtL_94vdtO6BXYscNPo=.9e197f63-1a11-482e-87c3-8646471dfc6a@github.com>

On Sun, 26 Jan 2025 17:48:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. This refactoring is to remove the unused code and reuse DecimalDigits to reduce duplication of code.
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 988:
> 
>> 986:         return threadLocalBinaryToASCIIBuffer.get();
>> 987:     }
>> 988: 
> 
> Why was this thread local buffer removed?

Creating a BinaryToASCIIConverter is not expensive and does not require the use of cache, but this should be proven by performance testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23311#discussion_r1929895384

From liach at openjdk.org  Wed Aug 20 07:40:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Aug 2025 07:40:24 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <AocCAZat9KGWThT4qlYLNUzchtL_94vdtO6BXYscNPo=.9e197f63-1a11-482e-87c3-8646471dfc6a@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <PQHF9TnO_rfY28Vt98kX0S5-m_YPLUNhCrFs5G7WZSo=.12888e7b-ed64-4298-b81f-f506bf2ba1f0@github.com>
 <AocCAZat9KGWThT4qlYLNUzchtL_94vdtO6BXYscNPo=.9e197f63-1a11-482e-87c3-8646471dfc6a@github.com>
Message-ID: <Mjgt92iylr0WsYUaFklkATIGFf3nFcSXj3KrOwdnLhE=.87d73cee-87d5-426b-a591-175be0f177e5@github.com>

On Sun, 26 Jan 2025 23:42:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 988:
>> 
>>> 986:         return threadLocalBinaryToASCIIBuffer.get();
>>> 987:     }
>>> 988: 
>> 
>> Why was this thread local buffer removed?
>
> Creating a BinaryToASCIIConverter is not expensive and does not require the use of cache, but this should be proven by performance testing.

Each `BinaryToASCIIBuffer` allocates an array for digits. That might be why the buffer was added. @rgiulietti might decide if this removal is fine or if we should keep it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23311#discussion_r1929902085

From duke at openjdk.org  Wed Aug 20 07:40:24 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 20 Aug 2025 07:40:24 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <Mjgt92iylr0WsYUaFklkATIGFf3nFcSXj3KrOwdnLhE=.87d73cee-87d5-426b-a591-175be0f177e5@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <PQHF9TnO_rfY28Vt98kX0S5-m_YPLUNhCrFs5G7WZSo=.12888e7b-ed64-4298-b81f-f506bf2ba1f0@github.com>
 <AocCAZat9KGWThT4qlYLNUzchtL_94vdtO6BXYscNPo=.9e197f63-1a11-482e-87c3-8646471dfc6a@github.com>
 <Mjgt92iylr0WsYUaFklkATIGFf3nFcSXj3KrOwdnLhE=.87d73cee-87d5-426b-a591-175be0f177e5@github.com>
Message-ID: <NS6FN1gVkB6kj6JFFJ2-7G80W3D2bWNu8uUHlKGBYF8=.2fc01bd3-3907-415c-a663-37fd43c6f1db@github.com>

On Mon, 27 Jan 2025 00:22:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Creating a BinaryToASCIIConverter is not expensive and does not require the use of cache, but this should be proven by performance testing.
>
> Each `BinaryToASCIIBuffer` allocates an array for digits. That might be why the buffer was added. @rgiulietti might decide if this removal is fine or if we should keep it.

It is interesting to note that that DigitList, which I think is the only remaining consumer of BinaryToAsciiBuffer reparses the string to separate the exponent and the mantissa. The converter has those separately and getChars does work to stick them together into a string. If the removal of the thread local has a noticeable performance impact, there is an opportunity to eliminate some allocations by having DigitList access the exponent and mantissa directly from the converter without needing toJavaFormatString

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23311#discussion_r1931546904

From vyazici at openjdk.org  Wed Aug 20 08:01:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 20 Aug 2025 08:01:46 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v4]
In-Reply-To: <BwaqlzimwTEQlIaW0oZ4-lQ6Z-22PQVeuxTA4RboP24=.861e2a28-26ff-435b-8e6f-70ffbb4ed965@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <BwaqlzimwTEQlIaW0oZ4-lQ6Z-22PQVeuxTA4RboP24=.861e2a28-26ff-435b-8e6f-70ffbb4ed965@github.com>
Message-ID: <rOFHF9qL-0PUH-pcmgMoknctertvQAfWTiy_2g9NJoY=.b47fe7a5-d1f1-4a87-9a4e-b2bc79ec0672@github.com>

On Tue, 19 Aug 2025 21:50:33 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:
> 
>   Revisited handling of IOExceptions to throw instead of completely ignoring or logging.

src/java.base/share/classes/java/lang/Process.java line 146:

> 144:  * @since   1.0
> 145:  */
> 146: public abstract class Process implements AutoCloseable {

Since we added `throws IOException` to `close()`, have we considered implementing `Closeable` instead?

src/java.base/share/classes/java/lang/Process.java line 651:

> 649:      * @since 26
> 650:      */
> 651:     public void close() throws IOException {

Suggestion:

    @Override
    public void close() throws IOException {

test/jdk/java/lang/Process/ProcessCloseTest.java line 386:

> 384:                     break;
> 385:                 } catch (InterruptedException ie) {
> 386:                     // retry above

Are we sure about completely discarding the interrupt?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2287302548
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2287295760
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2287315234

From duke at openjdk.org  Wed Aug 20 08:06:41 2025
From: duke at openjdk.org (Thomas Zimmermann)
Date: Wed, 20 Aug 2025 08:06:41 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal
In-Reply-To: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
Message-ID: <ou7FnJpDsbPHDQARyBDycUqCEqnzGNuuD7xQ_hehmOQ=.4bfd5bec-0462-4daa-bcdc-a9f1fae772a5@github.com>

On Sat, 25 Jan 2025 13:04:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. This refactoring is to remove the unused code and reuse DecimalDigits to reduce duplication of code.

src/java.base/share/classes/java/text/DigitList.java line 325:

> 323: 
> 324:         byte[] chars = getDataChars(20);
> 325:         int len = fdConverter.getChars(chars);;

Suggestion:

        int len = fdConverter.getChars(chars);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23311#discussion_r2287339395

From swen at openjdk.org  Wed Aug 20 08:44:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 08:44:24 GMT
Subject: RFR: 8365832: Refactor FloatingDecimal [v2]
In-Reply-To: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
Message-ID: <qdgHiMuSwAytDxYmnzz8YoV1Csx4Qb-R5gqWszaf3Do=.ed69c4cf-5c91-4cd1-bc5d-252056431c6b@github.com>

> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. This refactoring is to remove the unused code and reuse DecimalDigits to reduce duplication of code.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/text/DigitList.java
  
  Co-authored-by: Thomas Zimmermann <zimmi at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23311/files
  - new: https://git.openjdk.org/jdk/pull/23311/files/df2d9e47..823ecb13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23311/head:pull/23311

PR: https://git.openjdk.org/jdk/pull/23311

From pminborg at openjdk.org  Wed Aug 20 08:51:24 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 20 Aug 2025 08:51:24 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v9]
In-Reply-To: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
Message-ID: <iWp0eekrd2VD1ef23JT_rfDSIYNHm9XD09dG8tcavu4=.71100a11-e73a-4739-bcc3-396177d82f96@github.com>

> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
> 
> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Do not use overlapping copy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26672/files
  - new: https://git.openjdk.org/jdk/pull/26672/files/e05c8370..25947da8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26672&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26672&range=07-08

  Stats: 88 lines in 1 file changed: 37 ins; 42 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26672.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26672/head:pull/26672

PR: https://git.openjdk.org/jdk/pull/26672

From pminborg at openjdk.org  Wed Aug 20 08:54:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 20 Aug 2025 08:54:50 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved using overlaps [v9]
In-Reply-To: <iWp0eekrd2VD1ef23JT_rfDSIYNHm9XD09dG8tcavu4=.71100a11-e73a-4739-bcc3-396177d82f96@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <iWp0eekrd2VD1ef23JT_rfDSIYNHm9XD09dG8tcavu4=.71100a11-e73a-4739-bcc3-396177d82f96@github.com>
Message-ID: <gBCFcB6sTDpLbLgwxr04RNwS__e3sl3LLwgrVDXcZGo=.eb8fa47d-e185-4ca9-8183-0edbe9c38c66@github.com>

On Wed, 20 Aug 2025 08:51:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not use overlapping copy

I've removed overlapping copy, which impacts performance a bit:

Bytes | Base | Patch | Improvement
-- | -- | -- | --
2 | 3.184 | 2.97 | 6.72%
3 | 3.162 | 3.011 | 4.78%
4 | 3.344 | 3.117 | 6.79%
5 | 3.31 | 3.15 | 4.83%
6 | 3.328 | 3.382 | -1.62%
7 | 3.289 | 3.441 | -4.62%
8 | 4.139 | 3.147 | 23.97%
12 | 4.709 | 4.694 | 0.32%
16 | 4.173 | 3.792 | 9.13%
24 | 4.239 | 3.903 | 7.93%
64 | 4.86 | 4.736 | 2.55%


<img width="806" height="496" alt="image" src="https://github.com/user-attachments/assets/3aaa4cec-dfe5-4235-b9dd-33c017dd7970" />

The patch still gives significant performance improvements for likely copy sizes like 8 and 16 bytes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3204893330

From jbhateja at openjdk.org  Wed Aug 20 10:11:47 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 20 Aug 2025 10:11:47 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v8]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <ledEIa5Cj9jGqJfRfGBCIF6_nvGBw5lG8j2ksYwePs8=.6dd826a7-c935-40be-afea-bd8ed146560f@github.com>

> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
> 
>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
> 
> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
> 
> Performance numbers:
> 
> 
> System : 13th Gen Intel(R) Core(TM) i3-1315U
> 
> Baseline:
> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Update callGenerator.hpp copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24104/files
  - new: https://git.openjdk.org/jdk/pull/24104/files/70c22932..340f1849

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104

PR: https://git.openjdk.org/jdk/pull/24104

From rgiulietti at openjdk.org  Wed Aug 20 11:06:40 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Aug 2025 11:06:40 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup
In-Reply-To: <zv01R276aJiQXC7jVvO9d8ALKpZUxvOimIYtA4wrH_I=.fe5ddca6-f5e6-42b2-a6b2-8b85383cc769@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
 <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
 <vRv1b-U1eL3AG-kdC-8hbij2MW1LDCGbmyLkCOw8uIo=.df37437c-28d4-4bbc-89b9-c38614d56c40@github.com>
 <zv01R276aJiQXC7jVvO9d8ALKpZUxvOimIYtA4wrH_I=.fe5ddca6-f5e6-42b2-a6b2-8b85383cc769@github.com>
Message-ID: <Wv33p997XgoVtquhCOOeUVRaMQSULJlz26E6vMmiT5s=.e16586c5-619c-4cb9-b053-f51cda1993a7@github.com>

On Sat, 14 Jun 2025 04:58:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>>> @wenshao I'm working on a general overhaul of FloatingDecimal and related classes in some current and future PRs.
>>> 
>>> If you could restrict your changes to just DigitList, that would be less interference with my work.
>> 
>> @rgiulietti  Sorry, I was traveling last week and I just saw your comment now. This is a draft pull request, you can move on with your plans and ignore it.
>
>> @wenshao Curiously, there are now some people (you, @j3graham and myself) which are working on FloatingDecimal and related classes.
> 
> In PR #23310, @j3graham 's comment on January 25 mentioned FloatingDecimal, so I paid attention to this class

@wenshao In the initial description, there's a mention to reuse `DecimalDigits` to reduce code.
Is that still relevant? I'm asking because I don't see any usage of `DecimalDigits`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-3205662781

From swen at openjdk.org  Wed Aug 20 11:22:40 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 11:22:40 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup
In-Reply-To: <zv01R276aJiQXC7jVvO9d8ALKpZUxvOimIYtA4wrH_I=.fe5ddca6-f5e6-42b2-a6b2-8b85383cc769@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
 <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
 <vRv1b-U1eL3AG-kdC-8hbij2MW1LDCGbmyLkCOw8uIo=.df37437c-28d4-4bbc-89b9-c38614d56c40@github.com>
 <zv01R276aJiQXC7jVvO9d8ALKpZUxvOimIYtA4wrH_I=.fe5ddca6-f5e6-42b2-a6b2-8b85383cc769@github.com>
Message-ID: <dlnM_QhNZ4RXjWigYOx7z81r65a5a5L4-3MMzuEOtwg=.72d5f066-92b0-4ca1-ac48-24292ee6655e@github.com>

On Sat, 14 Jun 2025 04:58:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>>> @wenshao I'm working on a general overhaul of FloatingDecimal and related classes in some current and future PRs.
>>> 
>>> If you could restrict your changes to just DigitList, that would be less interference with my work.
>> 
>> @rgiulietti  Sorry, I was traveling last week and I just saw your comment now. This is a draft pull request, you can move on with your plans and ignore it.
>
>> @wenshao Curiously, there are now some people (you, @j3graham and myself) which are working on FloatingDecimal and related classes.
> 
> In PR #23310, @j3graham 's comment on January 25 mentioned FloatingDecimal, so I paid attention to this class

> @wenshao In the initial description, there's a mention to reuse `DecimalDigits` to reduce code. Is that still relevant? I'm asking because I don't see any usage of `DecimalDigits`.

Thanks @rgiulietti  for the reminder, the original description is outdated and has been updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-3205739968

From galder at openjdk.org  Wed Aug 20 12:01:38 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 20 Aug 2025 12:01:38 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <dCa3iODAOckBcn9AqNKBD9i71SQB0i6jBHSmmbjD18E=.77387cbd-dc49-4bdc-acab-6087daa8b1ef@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
 <phlaY7VkRoWWwDzsnKw3JxaaU-lZk3tXFo8KCEtbn3Q=.3ccdd4ac-d61c-4c4c-b679-7bab67072ee1@github.com>
 <t1HL1C_N0S0Z2EBVUqSrTs24kKDKM-Cng9EwnWTfBTQ=.2d2c1afb-699f-443e-a015-4b04ea3f96db@github.com>
 <BJp73aGLKqCh1cR-XZHFIHCIaXuGzvtIjMhYgOol_fs=.40b4accf-53ae-47fd-8334-7a124aacaf74@github.com>
 <4mfHZiUcDJ3W0p2WCzgtUwp-FWSBX6eXOg1zLfcs_H0=.f0909507-d6fe-4d2a-a543-db6445e7f605@github.com>
 <Ls_YcAl09uT6mMR4tJxFJr9S1S_SRpS4roeLcc9UDok=.be1d4aa1-ade3-48dd-b34d-550c5ed7fd78@github.com>
 <dCa3iODAOckBcn9AqNKBD9i71SQB0i6jBHSmmbjD18E=.77387cbd-dc49-4bdc-acab-6087daa8b1ef@github.com>
Message-ID: <ChLzYXErOx0QjWlidMUV5PdpGYNFVX80IQQvi8kafE0=.20e45810-ed07-45ea-9170-7b4569676eae@github.com>

On Tue, 12 Aug 2025 08:22:11 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Btw, I've noticed that `TestFloat16ScalarOperations` does not have `package` definition. Is that an oversight? It runs fine in spite of not having it
>
> Hi, as you mostly touched the auto-vectorization part of c2, could you please run these float16 tests as well (most of these enable auto-vectorization for Float16) - 
> 
> `compiler/vectorization/TestFloat16VectorOperations.java`
> `compiler/vectorization/TestFloatConversionsVectorNaN.java`
> `compiler/vectorization/TestFloatConversionsVector.java`
> `compiler/vectorization/TestFloat16ToFloatConv.java`
> `compiler/vectorization/TestFloat16VectorConvChain.java`
> `compiler/intrinsics/float16/*`

@Bhavana-Kilambi I've run these tests:


  "test/hotspot/jtreg/compiler/c2/irTests/ConvF2HFIdealizationTests.java"
  "test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java"
  "test/hotspot/jtreg/compiler/intrinsics/float16/*"
  "test/hotspot/jtreg/compiler/vectorization/TestFloat16ToFloatConv.java"
  "test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java"
  "test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java"
  "test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVector.java"
  "test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java"


On x86:

Test results: passed: 11; did not meet platform requirements: 1
(TestFloatConversionsVectorNaN is for riscv)


On graviton 3 aarch64:

Test results: passed: 10; failed: 1; did not meet platform requirements: 1


The failure on aarch64 is already existing issue [JDK-8361582](https://bugs.openjdk.org/browse/JDK-8361582)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2287939342

From epeter at openjdk.org  Wed Aug 20 12:12:39 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 20 Aug 2025 12:12:39 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <ChLzYXErOx0QjWlidMUV5PdpGYNFVX80IQQvi8kafE0=.20e45810-ed07-45ea-9170-7b4569676eae@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
 <phlaY7VkRoWWwDzsnKw3JxaaU-lZk3tXFo8KCEtbn3Q=.3ccdd4ac-d61c-4c4c-b679-7bab67072ee1@github.com>
 <t1HL1C_N0S0Z2EBVUqSrTs24kKDKM-Cng9EwnWTfBTQ=.2d2c1afb-699f-443e-a015-4b04ea3f96db@github.com>
 <BJp73aGLKqCh1cR-XZHFIHCIaXuGzvtIjMhYgOol_fs=.40b4accf-53ae-47fd-8334-7a124aacaf74@github.com>
 <4mfHZiUcDJ3W0p2WCzgtUwp-FWSBX6eXOg1zLfcs_H0=.f0909507-d6fe-4d2a-a543-db6445e7f605@github.com>
 <Ls_YcAl09uT6mMR4tJxFJr9S1S_SRpS4roeLcc9UDok=.be1d4aa1-ade3-48dd-b34d-550c5ed7fd78@github.com>
 <dCa3iODAOckBcn9AqNKBD9i71SQB0i6jBHSmmbjD18E=.77387cbd-dc49-4bdc-acab-6087daa8b1ef@github.com>
 <ChLzYXErOx0QjWlidMUV5PdpGYNFVX80IQQvi8kafE0=.20e45810-ed07-45ea-9170-7b4569676eae@github.com>
Message-ID: <x_BmizITysQfqzrHqfk3mjc0FTE6LGeWweaeQVlBnYU=.51784419-52ad-4061-9d34-836fff8028e0@github.com>

On Wed, 20 Aug 2025 11:58:25 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> Hi, as you mostly touched the auto-vectorization part of c2, could you please run these float16 tests as well (most of these enable auto-vectorization for Float16) - 
>> 
>> `compiler/vectorization/TestFloat16VectorOperations.java`
>> `compiler/vectorization/TestFloatConversionsVectorNaN.java`
>> `compiler/vectorization/TestFloatConversionsVector.java`
>> `compiler/vectorization/TestFloat16ToFloatConv.java`
>> `compiler/vectorization/TestFloat16VectorConvChain.java`
>> `compiler/intrinsics/float16/*`
>
> @Bhavana-Kilambi I've run these tests:
> 
> 
>   "test/hotspot/jtreg/compiler/c2/irTests/ConvF2HFIdealizationTests.java"
>   "test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java"
>   "test/hotspot/jtreg/compiler/intrinsics/float16/*"
>   "test/hotspot/jtreg/compiler/vectorization/TestFloat16ToFloatConv.java"
>   "test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java"
>   "test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java"
>   "test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVector.java"
>   "test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java"
> 
> 
> On x86:
> 
> Test results: passed: 11; did not meet platform requirements: 1
> (TestFloatConversionsVectorNaN is for riscv)
> 
> 
> On graviton 3 aarch64:
> 
> Test results: passed: 10; failed: 1; did not meet platform requirements: 1
> 
> 
> The failure on aarch64 is already existing issue [JDK-8361582](https://bugs.openjdk.org/browse/JDK-8361582)

@galderz Excellent, that's great :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2287967911

From swen at openjdk.org  Wed Aug 20 12:19:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 12:19:57 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup [v3]
In-Reply-To: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
Message-ID: <1Bp5Ly6YZK0aWVu8fQ_asH52VzG6snNgDymevFnGbQQ=.40e990af-0f36-4cf2-a236-9bc697a9c823@github.com>

> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. 
> 
> This PR refactors `FloatingDecimal` and `DigitList` to improve efficiency and reduce code duplication.
> 
> Key changes:
> * Convert internal digit storage from `char[]` to `byte[]` for reduced memory footprint.
> *   Remove unused code and methods that are no longer needed.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Optimize BigDecimal construction in DigitList by using SharedSecrets.inflateBytesToChars
  
  Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23311/files
  - new: https://git.openjdk.org/jdk/pull/23311/files/823ecb13..3a730965

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=01-02

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23311/head:pull/23311

PR: https://git.openjdk.org/jdk/pull/23311

From dholmes at openjdk.org  Wed Aug 20 12:55:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:55:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

@sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288072431

From rgiulietti at openjdk.org  Wed Aug 20 12:58:40 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Aug 2025 12:58:40 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup
In-Reply-To: <dlnM_QhNZ4RXjWigYOx7z81r65a5a5L4-3MMzuEOtwg=.72d5f066-92b0-4ca1-ac48-24292ee6655e@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <8JHE_BIhjPI9-hwuTc_VtdGdI88zQCGSYWSN4C9KdHE=.a1e70a00-7a54-47be-904c-62435c2abdac@github.com>
 <xPoS1QAM-yuOLAmbUF91mOzJaGa_Ob-VKn-YjjeayZ4=.78367431-5844-4b24-9c2d-46875c21a948@github.com>
 <vRv1b-U1eL3AG-kdC-8hbij2MW1LDCGbmyLkCOw8uIo=.df37437c-28d4-4bbc-89b9-c38614d56c40@github.com>
 <zv01R276aJiQXC7jVvO9d8ALKpZUxvOimIYtA4wrH_I=.fe5ddca6-f5e6-42b2-a6b2-8b85383cc769@github.com>
 <dlnM_QhNZ4RXjWigYOx7z81r65a5a5L4-3MMzuEOtwg=.72d5f066-92b0-4ca1-ac48-24292ee6655e@github.com>
Message-ID: <KOiq4HjwzAviyIcpewWJADDXC8G3RtNXck3NFjiW9Zg=.ee8f8d7a-edae-4824-92b6-cb135a3a879c@github.com>

On Wed, 20 Aug 2025 11:20:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>>> @wenshao Curiously, there are now some people (you, @j3graham and myself) which are working on FloatingDecimal and related classes.
>> 
>> In PR #23310, @j3graham 's comment on January 25 mentioned FloatingDecimal, so I paid attention to this class
>
>> @wenshao In the initial description, there's a mention to reuse `DecimalDigits` to reduce code. Is that still relevant? I'm asking because I don't see any usage of `DecimalDigits`.
> 
> Thanks @rgiulietti  for the reminder, the original description is outdated and has been updated.

@wenshao There are several tests that fail, in particular in `test/jdk/java/text/Format`.
Please take a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-3206225145

From pminborg at openjdk.org  Wed Aug 20 13:00:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 20 Aug 2025 13:00:39 GMT
Subject: RFR: 8365017: The SegmentBulkOperations::copy method can be
 improved [v9]
In-Reply-To: <iWp0eekrd2VD1ef23JT_rfDSIYNHm9XD09dG8tcavu4=.71100a11-e73a-4739-bcc3-396177d82f96@github.com>
References: <qbatRfFC_hzhijh3LXoAGsaltvWCVQMRetVQcxM-s8M=.bc083507-189b-433b-97fe-92bf89e00ac8@github.com>
 <iWp0eekrd2VD1ef23JT_rfDSIYNHm9XD09dG8tcavu4=.71100a11-e73a-4739-bcc3-396177d82f96@github.com>
Message-ID: <PqvY9tvbl3T0ZPsU9_4EAnRAZRuTfPzaW9F3CiRhBU8=.4dfe8434-2164-4f7a-aaf4-fc937cc0cfad@github.com>

On Wed, 20 Aug 2025 08:51:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use overlapping memory areas in `SegmentBulkOperations::copy`, similar to what is proposed for `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383.
>> 
>> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not use overlapping copy

After careful inspection of performance figures on all the supported platforms, I believe we should abandon this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3206232797

From dfuchs at openjdk.org  Wed Aug 20 13:55:38 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Aug 2025 13:55:38 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:

 - merge latest changes from master branch
 - merge latest http3 changes
 - Hide internal classes
 - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
 - quic: remove unused fields
 - Make final fields static
 - Remove unused variable
 - merge latest changes from master branch
 - http3: update summary in H3SimpleTest.java
 - http3: review feedback - use copy() instead of thenApply(Function.identity())
 - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=12
  Stats: 105379 lines in 471 files changed: 102511 ins; 1335 del; 1533 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From syan at openjdk.org  Wed Aug 20 14:28:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 20 Aug 2025 14:28:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
Message-ID: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>

On Wed, 20 Aug 2025 12:53:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
>> 
>> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1
>
> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.

So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).

I do agree this change, what I mean is this change has some side effect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288361080

From dfuchs at openjdk.org  Wed Aug 20 14:31:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Aug 2025 14:31:03 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <Fqe4NqKF0of-gEK7KNgb56fgGpN22OgyE72Yj2BAomY=.1839272d-29a7-4f70-995b-5953767646ef@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

I have updated the PR with commits that address most review feedback. 

Among the changes is also one that simplifies how opting in for HTTP/3 is handled. Before this change our implementation would employ different default strategies depending on whether HTTP/3 was set on the client or on the request. We decided to simplify this by handling the two in the same way: whether HTTP/3 is set on the client or on the request no longer matters, as long as it is set in one of them. In both cases - the strategy will be the same: if a new HTTP/3 connection is needed, the connection will be attempted as specified in Http3DiscoveryMode.ANY, unless a more specific H3_DISCOVERY option is explicitely set on the request.

The corresponding API documentation / implNote in HttpOption.java have been updated accordingly.

There's one sentence in the JEP that will also need to be updated to match this behaviour. The apidiff/specdiff attached to the CSR will also need to be updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-3206660010

From alanb at openjdk.org  Wed Aug 20 14:34:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Aug 2025 14:34:20 GMT
Subject: RFR: 8365671: Typo in Joiner.allUntil example
Message-ID: <VMKekuhYTzY6gXXr-mY2RLIRaoiRcggsXd5qbQk9GE4=.f29c6791-887a-494d-b4ca-4d0faf76f68d@github.com>

Fix two typos in one of the examples in Joiner.allUntil's API. (We may re-visit the example in a future update, for now, just the typos).

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/26856/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26856&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365671
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26856/head:pull/26856

PR: https://git.openjdk.org/jdk/pull/26856

From swen at openjdk.org  Wed Aug 20 14:39:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 14:39:24 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup [v4]
In-Reply-To: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
Message-ID: <4ME2_o0sQZ5yTkkcHxEZXaYdnkmWaN5nWbOyZXhGnSk=.f8d35524-6a7c-4198-b978-ff7cd49469c9@github.com>

> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. 
> 
> This PR refactors `FloatingDecimal` and `DigitList` to improve efficiency and reduce code duplication.
> 
> Key changes:
> * Convert internal digit storage from `char[]` to `byte[]` for reduced memory footprint.
> *   Remove unused code and methods that are no longer needed.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  bug fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23311/files
  - new: https://git.openjdk.org/jdk/pull/23311/files/3a730965..7664a3f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23311/head:pull/23311

PR: https://git.openjdk.org/jdk/pull/23311

From djelinski at openjdk.org  Wed Aug 20 14:42:00 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 20 Aug 2025 14:42:00 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <RqpubBYkhX4M2mTEjW6ag7umJutDcNRactVm09DP04k=.97579686-8a78-4c8f-9881-231c6193b805@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3136945016

From liach at openjdk.org  Wed Aug 20 14:49:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Aug 2025 14:49:43 GMT
Subject: RFR: 8365671: Typo in Joiner.allUntil example
In-Reply-To: <VMKekuhYTzY6gXXr-mY2RLIRaoiRcggsXd5qbQk9GE4=.f29c6791-887a-494d-b4ca-4d0faf76f68d@github.com>
References: <VMKekuhYTzY6gXXr-mY2RLIRaoiRcggsXd5qbQk9GE4=.f29c6791-887a-494d-b4ca-4d0faf76f68d@github.com>
Message-ID: <oY1DgWJq6VnEylkZBPsbzzpL2V4uZRUiMQuR2H9xQl8=.ca79b2e9-c780-4890-a031-1b94b7961a55@github.com>

On Wed, 20 Aug 2025 09:17:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Fix two typos in one of the examples in Joiner.allUntil's API. (We may re-visit the example in a future update, for now, just the typos).

Looks trivially correct.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26856#pullrequestreview-3136990383

From duke at openjdk.org  Wed Aug 20 14:58:44 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 20 Aug 2025 14:58:44 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup [v4]
In-Reply-To: <4ME2_o0sQZ5yTkkcHxEZXaYdnkmWaN5nWbOyZXhGnSk=.f8d35524-6a7c-4198-b978-ff7cd49469c9@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <4ME2_o0sQZ5yTkkcHxEZXaYdnkmWaN5nWbOyZXhGnSk=.f8d35524-6a7c-4198-b978-ff7cd49469c9@github.com>
Message-ID: <lqNulwRAEYCFC5yRFvUSWbEy9JqepKK9RRT4Nx2p-Mg=.0ae240da-1e70-4f35-b807-898f745b7746@github.com>

On Wed, 20 Aug 2025 14:39:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. 
>> 
>> This PR refactors `FloatingDecimal` and `DigitList` to improve efficiency and reduce code duplication.
>> 
>> Key changes:
>> * Convert internal digit storage from `char[]` to `byte[]` for reduced memory footprint.
>> *   Remove unused code and methods that are no longer needed.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug fix

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1744:

> 1742:         }
> 1743:         byte[] buf = new byte[length];
> 1744:         for (int i = 0; i < length; i++) {

`digits` can now be passed directly to  `new ASCIIToBinaryBuffer` directly without copying it first.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23311#discussion_r2288456153

From duke at openjdk.org  Wed Aug 20 15:06:42 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 20 Aug 2025 15:06:42 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup [v4]
In-Reply-To: <4ME2_o0sQZ5yTkkcHxEZXaYdnkmWaN5nWbOyZXhGnSk=.f8d35524-6a7c-4198-b978-ff7cd49469c9@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <4ME2_o0sQZ5yTkkcHxEZXaYdnkmWaN5nWbOyZXhGnSk=.f8d35524-6a7c-4198-b978-ff7cd49469c9@github.com>
Message-ID: <ZMRtVrFeDNOWUR92HQ2SnooVrNevj7R3TSU0lbXZxxk=.509063c5-c134-421f-a321-fbb6aafd2156@github.com>

On Wed, 20 Aug 2025 14:39:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. 
>> 
>> This PR refactors `FloatingDecimal` and `DigitList` to improve efficiency and reduce code duplication.
>> 
>> Key changes:
>> * Convert internal digit storage from `char[]` to `byte[]` for reduced memory footprint.
>> *   Remove unused code and methods that are no longer needed.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug fix

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 219:

> 217:         private int nDigits;
> 218:         private final byte[] digits;
> 219:         private final byte[] buffer = new byte[26];

`buffer` appears to be unused now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23311#discussion_r2288475808

From abarashev at openjdk.org  Wed Aug 20 15:13:02 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:13:02 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <AMCgVJWdJn_DqzDv5xV98Nynbrn7MEbDIdJZ_u8XDfg=.bf6a8011-876a-40a8-95bf-0cb2169401c6@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 153:

> 151:         // certificate according to requested SNI extension.
> 152:         //
> 153:         // It is not a really HTTPS endpoint identification.

Please restore the above comment block indenting.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 181:

> 179:         // certificate according to requested SNI extension.
> 180:         //
> 181:         // It is not a really HTTPS endpoint identification.

Same as above, block indenting.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 199:

> 197: 
> 198:     // Gets algorithm constraints of QUIC TLS engine.
> 199:     private AlgorithmConstraints getAlgorithmConstraints(QuicTLSEngineImpl engine) {

This method should be moved to `X509KeyManagerCertChecking` as `protected`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288487671
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288488397
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288491094

From swen at openjdk.org  Wed Aug 20 15:15:01 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 15:15:01 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup [v5]
In-Reply-To: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
Message-ID: <QzKGVvcHNBqjbB0DCugqF6_4lzoCsnSPm7MyP77NNSQ=.b5c8e12e-71d2-4529-8aa3-ed1e45bc463e@github.com>

> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. 
> 
> This PR refactors `FloatingDecimal` and `DigitList` to improve efficiency and reduce code duplication.
> 
> Key changes:
> * Convert internal digit storage from `char[]` to `byte[]` for reduced memory footprint.
> *   Remove unused code and methods that are no longer needed.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove unused buffer, from @j3graham

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23311/files
  - new: https://git.openjdk.org/jdk/pull/23311/files/7664a3f9..2b0f0656

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23311/head:pull/23311

PR: https://git.openjdk.org/jdk/pull/23311

From abarashev at openjdk.org  Wed Aug 20 15:18:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:18:10 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <cG44tMLYSCLxUQv4RW-dzqRDkhA1piD2T5fMPdAzuTI=.e9423d38-5cbd-497d-8b8d-21a28924bee2@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 229:

> 227:             // just call the functionally limited
> 228:             // javax.net.ssl.X509KeyManager.chooseClientAlias(...)
> 229:             if (km instanceof X509KeyManagerImpl xkm) {

We no longer need a special case for `X509KeyManagerImpl` as `SunX509KeyManagerImpl` supports algorithm constraints now. See #25016 for details.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 322:

> 320:                 // and just call the functionally limited
> 321:                 // javax.net.ssl.X509KeyManager.chooseServerAlias(...)
> 322:                 if (km instanceof X509KeyManagerImpl xkm) {

Same as above, `SunX509KeyManagerImp`l supports algorithm constraints now. See https://github.com/openjdk/jdk/pull/25016 for details.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288503211
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288505103

From ihse at openjdk.org  Wed Aug 20 15:19:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:19:42 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

I don't think there is any point linking to the build source code. 

Suggestion:

certain amount of time will apply this factor. If you run in
forced compilation mode (`-Xcomp`) using `make test`, it
will automatically adjust this factor to compensate for the
interpreter not being as fast as JITed code. Defaults to 1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288510800

From abarashev at openjdk.org  Wed Aug 20 15:22:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:22:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <rZ8PCa5UY337NRqlW1dC1UdQUYXlT9NiRezCT3X5Xkw=.be5fdc48-6848-4558-94ee-7ffa2a38a1ba@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 1:

> 1: /*

Consider adding `chooseClientAlias` and `chooseServerAlias` methods for `quicTLSEngine` to the default SunX509 key manager which now supports algorithm constraints.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288514104

From ihse at openjdk.org  Wed Aug 20 15:24:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:24:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.

I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 

Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3206865824

From rgiulietti at openjdk.org  Wed Aug 20 15:30:57 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Aug 2025 15:30:57 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup [v4]
In-Reply-To: <lqNulwRAEYCFC5yRFvUSWbEy9JqepKK9RRT4Nx2p-Mg=.0ae240da-1e70-4f35-b807-898f745b7746@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <4ME2_o0sQZ5yTkkcHxEZXaYdnkmWaN5nWbOyZXhGnSk=.f8d35524-6a7c-4198-b978-ff7cd49469c9@github.com>
 <lqNulwRAEYCFC5yRFvUSWbEy9JqepKK9RRT4Nx2p-Mg=.0ae240da-1e70-4f35-b807-898f745b7746@github.com>
Message-ID: <qrC3j4R5uPD0gR7E9wtyYag-WmPNLzB91ot0MPc8X5Q=.1e56af2f-0571-425f-af77-9d0b17e18b46@github.com>

On Wed, 20 Aug 2025 14:56:27 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   bug fix
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1744:
> 
>> 1742:         }
>> 1743:         byte[] buf = new byte[length];
>> 1744:         for (int i = 0; i < length; i++) {
> 
> `digits` can now be passed directly to  `new ASCIIToBinaryBuffer` without copying it first.

> `digits` can now be passed directly to `new ASCIIToBinaryBuffer` directly without copying it first.

@wenshao Do you intend to simplify this, as suggested by @j3graham?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23311#discussion_r2288540871

From abarashev at openjdk.org  Wed Aug 20 15:36:03 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:36:03 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <oiifer9a57vZpTmTR-Ks4gvvG4t2jzVbJWQ80toqNow=.9f4aaf31-9d4c-48d2-a67a-5c4c401c5862@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/Alert.java line 1:

> 1: /*

Copyright year.

src/java.base/share/classes/sun/security/ssl/AlpnExtension.java line 1:

> 1: /*

Copyright year.

src/java.base/share/classes/sun/security/ssl/OutputRecord.java line 1:

> 1: /*

Copyright year.

src/java.base/share/classes/sun/security/ssl/QuicEngineOutputRecord.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.

Copyright year.

src/java.base/share/classes/sun/security/ssl/QuicTransportParametersExtension.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.

Copyright year.

src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 1:

> 1: /*

Copyright year.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 1:

> 1: /*

Copyright year.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288548443
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288549545
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288551390
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288552162
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288540217
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288545232
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288546200

From galder at openjdk.org  Wed Aug 20 15:39:46 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 20 Aug 2025 15:39:46 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I,
 MoveI2F [v3]
In-Reply-To: <59dW-P8qExfEfXqud1rOPax4qGcubqi9RQxM4tJLQoQ=.dd1a3fb3-8ded-4e2d-bc25-49456e7ab46f@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <pmlkzah2xc_N7JB1JoNuGOu1XiPzS4SeJ5g7bhr3pj8=.aae221a0-c81b-4a03-98ab-029071a03e15@github.com>
 <59dW-P8qExfEfXqud1rOPax4qGcubqi9RQxM4tJLQoQ=.dd1a3fb3-8ded-4e2d-bc25-49456e7ab46f@github.com>
Message-ID: <_zWcUqG-geMU1r9bYHnTjT1KtvchzWhA4UHMtEvWljU=.590aa550-3306-42aa-91e2-b7360d2e2076@github.com>

On Wed, 20 Aug 2025 06:49:41 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check at the very least that auto vectorization is supported
>
> test/micro/org/openjdk/bench/vm/compiler/VectorBitConversion.java line 90:
> 
>> 88: 
>> 89:     @Benchmark
>> 90:     public long[] doubleToLongBits() {
> 
> I wonder if we should not just extend this benchmark, that has `convertI2F` etc:
> `test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java`
> 
> Just a suggestion, we can also keep them separately. Maybe one day we should clean up the benchmarks, and put them all in some `autovectorization` subdirectory, and organize the files and benchmarks a little better.

I'll look into `TypeVectorOperations` and see what can be done there. I had missed it when I wrote the benchmark.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2288560996

From swen at openjdk.org  Wed Aug 20 15:41:25 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 20 Aug 2025 15:41:25 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup [v6]
In-Reply-To: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
Message-ID: <2zcCNPbTINbQ5-e-G9CHGmFe3NCpsgzd7E81aYqIdn4=.fcff3e8a-63eb-4196-89d7-171c1b4a40f4@github.com>

> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. 
> 
> This PR refactors `FloatingDecimal` and `DigitList` to improve efficiency and reduce code duplication.
> 
> Key changes:
> * Convert internal digit storage from `char[]` to `byte[]` for reduced memory footprint.
> *   Remove unused code and methods that are no longer needed.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  without copy digits, from @j3graham

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23311/files
  - new: https://git.openjdk.org/jdk/pull/23311/files/2b0f0656..1fe597d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23311&range=04-05

  Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23311/head:pull/23311

PR: https://git.openjdk.org/jdk/pull/23311

From abarashev at openjdk.org  Wed Aug 20 15:48:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:48:08 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <cG44tMLYSCLxUQv4RW-dzqRDkhA1piD2T5fMPdAzuTI=.e9423d38-5cbd-497d-8b8d-21a28924bee2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
 <cG44tMLYSCLxUQv4RW-dzqRDkhA1piD2T5fMPdAzuTI=.e9423d38-5cbd-497d-8b8d-21a28924bee2@github.com>
Message-ID: <wOe3xzANENy0UGHztrX6Ofb846BBPGJP-W-wMggpnqc=.4958f040-9192-431b-9ce0-2b3c99bfd06c@github.com>

On Wed, 20 Aug 2025 15:14:01 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
>> 
>>  - merge latest changes from master branch
>>  - merge latest http3 changes
>>  - Hide internal classes
>>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>>  - quic: remove unused fields
>>  - Make final fields static
>>  - Remove unused variable
>>  - merge latest changes from master branch
>>  - http3: update summary in H3SimpleTest.java
>>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 229:
> 
>> 227:             // just call the functionally limited
>> 228:             // javax.net.ssl.X509KeyManager.chooseClientAlias(...)
>> 229:             if (km instanceof X509KeyManagerImpl xkm) {
> 
> We no longer need a special case for `X509KeyManagerImpl` as `SunX509KeyManagerImpl` supports algorithm constraints now. See #25016 for details.

Correction: We can add `chooseClientAlias` and `chooseServerAlias` methods for quicTLSEngine to the default SunX509 key manager and then do `km instanceof X509KeyManagerCertChecking` check here instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288583324

From alanb at openjdk.org  Wed Aug 20 16:10:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Aug 2025 16:10:45 GMT
Subject: Integrated: 8365671: Typo in Joiner.allUntil example
In-Reply-To: <VMKekuhYTzY6gXXr-mY2RLIRaoiRcggsXd5qbQk9GE4=.f29c6791-887a-494d-b4ca-4d0faf76f68d@github.com>
References: <VMKekuhYTzY6gXXr-mY2RLIRaoiRcggsXd5qbQk9GE4=.f29c6791-887a-494d-b4ca-4d0faf76f68d@github.com>
Message-ID: <uWIjUC3CqaqqQ8qdhl1rYlGDBPdlYDoM8z7SEvxni7c=.2840abb1-7e5b-4e8d-ad4b-c50b0b8a06af@github.com>

On Wed, 20 Aug 2025 09:17:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Fix two typos in one of the examples in Joiner.allUntil's API. (We may re-visit the example in a future update, for now, just the typos).

This pull request has now been integrated.

Changeset: be6c15ec
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be6c15ecb490e86bafc15b5cd552784f7aa3ee69
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8365671: Typo in Joiner.allUntil example

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/26856

From jpai at openjdk.org  Wed Aug 20 16:25:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Aug 2025 16:25:10 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <JeKINmYcmLWz8AVolTvNOTzymhXNuV6w2mguL6VAJYg=.7f38e31b-5a56-48bf-b72e-63f829175234@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <JeKINmYcmLWz8AVolTvNOTzymhXNuV6w2mguL6VAJYg=.7f38e31b-5a56-48bf-b72e-63f829175234@github.com>
Message-ID: <jsG4kdvqj5b_S-jQPeHrGRv24QmdwdsALM-8_Svsc6M=.b121460f-8808-47b1-aff9-4a79f94883f1@github.com>

On Thu, 26 Jun 2025 18:06:03 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/Finished.java line 852:
> 
>> 850:                     QuicTLSEngineImpl engine =
>> 851:                             (QuicTLSEngineImpl) shc.conContext.transport;
>> 852:                     engine.deriveOneRTTKeys();
> 
> We should not derive the server's 1RTT read keys before processing the client's Finished message.
> 
> Also, we could skip calculating the SSL WriteCipher when QUIC is in use. Also, we're calculating the baseWriteSecret twice (deriveOneRTTKeys calculates the same secret)

We decided to do this as a follow up after the JEP is integrated. In the meantime, in https://github.com/openjdk/jdk/pull/24751/commits/8d22ca7334da8d8b49d0634ea2f23bd409613928, we now introduce a check where the endpoint doesn't decrypt an incoming 1-RTT packet until the TLS handshake is complete. This matches with what the RFC-9001 specifies.

@dfuch, @djelinski I think we can mark this conversation as resolved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288675780

From lkorinth at openjdk.org  Wed Aug 20 16:27:39 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 16:27:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
Message-ID: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>

On Wed, 20 Aug 2025 15:17:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> I don't think there is any point linking to the build source code. 
> 
> Suggestion:
> 
> certain amount of time will apply this factor. If you run in
> forced compilation mode (`-Xcomp`) using `make test`, it
> will automatically adjust this factor to compensate for the
> interpreter not being as fast as JITed code. Defaults to 1.

I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288683592

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  update testing.md, remove makefile link, fix bad text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/286a2cc6..f24a1e72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=03-04

  Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

PR: https://git.openjdk.org/jdk/pull/26749

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
 <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
Message-ID: <2Ba-EiFMVh1-nMHcihw93nZq-TkQNtvHc244Bwe8I40=.cfa54a17-0a3f-465d-a1c3-7560965376d7@github.com>

On Wed, 20 Aug 2025 16:24:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> I don't think there is any point linking to the build source code. 
>> 
>> Suggestion:
>> 
>> certain amount of time will apply this factor. If you run in
>> forced compilation mode (`-Xcomp`) using `make test`, it
>> will automatically adjust this factor to compensate for the
>> interpreter not being as fast as JITed code. Defaults to 1.
>
> I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288793081

From dfuchs at openjdk.org  Wed Aug 20 17:14:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Aug 2025 17:14:55 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <jsG4kdvqj5b_S-jQPeHrGRv24QmdwdsALM-8_Svsc6M=.b121460f-8808-47b1-aff9-4a79f94883f1@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <JeKINmYcmLWz8AVolTvNOTzymhXNuV6w2mguL6VAJYg=.7f38e31b-5a56-48bf-b72e-63f829175234@github.com>
 <jsG4kdvqj5b_S-jQPeHrGRv24QmdwdsALM-8_Svsc6M=.b121460f-8808-47b1-aff9-4a79f94883f1@github.com>
Message-ID: <CL4ae3Ugh4Kyjq8904lR4mY-Wm8H5JdGzAnCuqOiMF0=.0b9603ab-e468-47a4-adb6-da848b69f46a@github.com>

On Wed, 20 Aug 2025 16:21:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/Finished.java line 852:
>> 
>>> 850:                     QuicTLSEngineImpl engine =
>>> 851:                             (QuicTLSEngineImpl) shc.conContext.transport;
>>> 852:                     engine.deriveOneRTTKeys();
>> 
>> We should not derive the server's 1RTT read keys before processing the client's Finished message.
>> 
>> Also, we could skip calculating the SSL WriteCipher when QUIC is in use. Also, we're calculating the baseWriteSecret twice (deriveOneRTTKeys calculates the same secret)
>
> We decided to do this as a follow up after the JEP is integrated. In the meantime, in https://github.com/openjdk/jdk/pull/24751/commits/8d22ca7334da8d8b49d0634ea2f23bd409613928, we now introduce a check where the endpoint doesn't decrypt an incoming 1-RTT packet until the TLS handshake is complete. This matches with what the RFC-9001 specifies.
> 
> @dfuch, @djelinski I think we can mark this conversation as resolved.

Logged as https://bugs.openjdk.org/browse/JDK-8365872 (thanks @jaikiran)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288810658

From abarashev at openjdk.org  Wed Aug 20 18:13:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 18:13:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <tkKRHU9wJYvRzrMhMlEodUGE6wFwIt1lH7dN_NyCgEA=.18f8f0a6-b503-4500-b444-6c562e81316c@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 800:

> 798:             // a ServerHello or a HelloRetryRequest.
> 799:             // (RFC 8446, Appendix D.4)
> 800:             if (clientHello.sessionId.length() != 0) {

What's the reason for this change? A short comment would be helpful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288932593

From rriggs at openjdk.org  Wed Aug 20 18:50:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Aug 2025 18:50:38 GMT
Subject: RFR: 8363972: Lenient parsing of minus sign pattern in
 DecimalFormat/CompactNumberFormat [v10]
In-Reply-To: <fL10ZLA1KeHGufyjiTHLLC9HBCNzWEGFeXbv0klsLW8=.d9136fb0-a20e-41f3-a985-56aea04d19cc@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <fL10ZLA1KeHGufyjiTHLLC9HBCNzWEGFeXbv0klsLW8=.d9136fb0-a20e-41f3-a985-56aea04d19cc@github.com>
Message-ID: <fYYfecViE1BAbpAbognD5xYVaKOXUT2p9tW1s-UEdBo=.80a4044f-2e67-455b-a779-0418e48116f7@github.com>

On Wed, 6 Aug 2025 20:24:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added description in `parse()`

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26580#pullrequestreview-3137831304

From ihse at openjdk.org  Wed Aug 20 19:36:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 19:36:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <Pw1uYaqAPK95BsoZ0xgNA1c3rsXjxHCiz-xACzocwqA=.e6cb7fcf-4438-4e4a-aeef-7d9c707c87c8@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

Build changes look good now. Thanks!

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3137980952

From rriggs at openjdk.org  Wed Aug 20 20:19:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Aug 2025 20:19:45 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v4]
In-Reply-To: <vU6LdPF1aj7fNJkXSc4CcFSG4XRLwV7SsWlRNqa1100=.02f63842-5de1-43b6-ad42-25fa2ace1c98@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <BwaqlzimwTEQlIaW0oZ4-lQ6Z-22PQVeuxTA4RboP24=.861e2a28-26ff-435b-8e6f-70ffbb4ed965@github.com>
 <vU6LdPF1aj7fNJkXSc4CcFSG4XRLwV7SsWlRNqa1100=.02f63842-5de1-43b6-ad42-25fa2ace1c98@github.com>
Message-ID: <rx_gN1GLsDuXjXVcCU47kt8M6lEIAYMJvpz2jHWBXso=.14e3de36-1c4e-4479-aaed-3cc775596132@github.com>

On Tue, 19 Aug 2025 21:52:10 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revisited handling of IOExceptions to throw instead of completely ignoring or logging.
>
> src/java.base/share/classes/java/lang/Process.java line 652:
> 
>> 650:      */
>> 651:     public void close() throws IOException {
>> 652:         synchronized(this) {
> 
> Might be safer to create a dedicated, private object to use for locking here instead of `this`. Otherwise there's a possibility of deadlock (or indefinite delay), for example, if a subclass happens to have a `synchronized` method that could block while trying to communicate with the process, etc.

There are other `synchronized(this)` within Process, its cleaner to stay consistent and update them later in a separate PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2289204143

From rriggs at openjdk.org  Wed Aug 20 20:34:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Aug 2025 20:34:35 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v5]
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: <lsaHPeJ1kPktyQqT54trZQbefEtDzpDlshwsn5WetFQ=.7d4f5809-289e-41b7-9314-40ff21ad46ed@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:

  Misc, javadoc cleanup
  Simplified the Interrupt handling in ProcessCloseTest.ProcessCommand.ExpectExit.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/6f393df1..96b3d0df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=03-04

  Stats: 14 lines in 2 files changed: 2 ins; 3 del; 9 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 rriggs at openjdk.org  Wed Aug 20 20:43:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Aug 2025 20:43:27 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement close
 and be AutoCloseable [v6]
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: <ZLP0H2XbB09TdYHgdJ_az1-sEpCX8RKPwWMeFJc6ngI=.2918a734-6744-4049-856b-8f30e7bcb97e@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:

  javadoc tweaks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/96b3d0df..d0c74cb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=04-05

  Stats: 3 lines in 1 file changed: 1 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 duke at openjdk.org  Wed Aug 20 21:28:41 2025
From: duke at openjdk.org (Thomas Zimmermann)
Date: Wed, 20 Aug 2025 21:28:41 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup [v6]
In-Reply-To: <2zcCNPbTINbQ5-e-G9CHGmFe3NCpsgzd7E81aYqIdn4=.fcff3e8a-63eb-4196-89d7-171c1b4a40f4@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <2zcCNPbTINbQ5-e-G9CHGmFe3NCpsgzd7E81aYqIdn4=.fcff3e8a-63eb-4196-89d7-171c1b4a40f4@github.com>
Message-ID: <GvwzpIBGo2RAv7XJdJBGSUi7ZuZEA0Ccgs6K-EynAIg=.f183ca00-67bf-4723-b0a8-72d379b6b4e7@github.com>

On Wed, 20 Aug 2025 15:41:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and Double.toString, some code in FloatingDecimal is not used. 
>> 
>> This PR refactors `FloatingDecimal` and `DigitList` to improve efficiency and reduce code duplication.
>> 
>> Key changes:
>> * Convert internal digit storage from `char[]` to `byte[]` for reduced memory footprint.
>> *   Remove unused code and methods that are no longer needed.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   without copy digits, from @j3graham

I'm not an official reviewer, but looks good to me ? 

P.S.: While looking why you might have preferred `ISO_8859_1` over `US_ASCII` (latin1 can skip the mapping of replacement characters because it defines the entire byte range, correct?), I stumbled upon a reference to the removed `SecurityManager` in [a comment](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L652).

-------------

Marked as reviewed by zimmi at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/23311#pullrequestreview-3138290097

From dholmes at openjdk.org  Wed Aug 20 21:32:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 21:32:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <j5ndr4sR6OHgBGlCY-e1I-VdfMKpG2GS98Wv2qbshtU=.d5aad200-1bc2-4080-ad71-218c59a7e491@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, 

@magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

For this exercise existing explicit timeout values need to be multiplied by 4 to keep the same absolute timeout value. In addition a number of tests that use the implicit default timeout (120*4) now need an explicit timeout (480 generally).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3208143195

From duke at openjdk.org  Wed Aug 20 21:37:37 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 20 Aug 2025 21:37:37 GMT
Subject: RFR: 8328874: Class::forName0 should validate the class name
 length early [v5]
In-Reply-To: <mmb5HxGx_id_9uuM_BhrcITS8_fDIPyof-kI_lj5khU=.2148ac1f-e853-4d5e-aafb-f708aa6da00f@github.com>
References: <aRkN6oEvmwY7tiadiFHEgH3nMNxBRKstNVRn2pUCcSc=.e1e002cf-d01e-47f5-8835-8ce889c49942@github.com>
 <mmb5HxGx_id_9uuM_BhrcITS8_fDIPyof-kI_lj5khU=.2148ac1f-e853-4d5e-aafb-f708aa6da00f@github.com>
Message-ID: <tVdJRxGo6iTazE_szG_74UMSuEVig7KRthFgsNRYkKU=.12808b02-9301-4ac5-9c0f-525f4dd2b451@github.com>

On Wed, 20 Aug 2025 01:30:27 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Class.java
>   
>   updates the class name length validation logic on the Java side

src/java.base/share/classes/java/lang/Class.java line 4160:

> 4158:     // Checks whether the class name exceeds the maximum allowed length.
> 4159:     private static boolean classNameLengthIsValid(String name) {
> 4160:         Objects.requireNonNull(name);

This?is not?needed as?the?`name.length()`?call already?performs an?implicit `null`?check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2289354748

From rriggs at openjdk.org  Wed Aug 20 21:38:41 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Aug 2025 21:38:41 GMT
Subject: RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust
 [v3]
In-Reply-To: <y8vmYNc7ul7YQHkujvSffSg692k4JyJHzVXhfUnrOVg=.bbeb8e03-acd9-4126-b1b5-904c4525575f@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <y8vmYNc7ul7YQHkujvSffSg692k4JyJHzVXhfUnrOVg=.bbeb8e03-acd9-4126-b1b5-904c4525575f@github.com>
Message-ID: <zLExeDkIr47YdlPNVpwOy6rujn3hI7UZQhphSORXpnU=.8cb63f42-028c-4904-b169-6f613a4ac064@github.com>

On Sun, 10 Aug 2025 03:36:06 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
>> 
>> 
>> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
>> 
>> 
>> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @liach

src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 134:

> 132:      * @return the adjusted temporal, or the original if no overrides are present in the formatter
> 133:      * @implNote Optimizes for the common case where formatters don't specify chronology/time-zone
> 134:      *           by avoiding unnecessary processing. Most formatters have null for these properties.

@implNote should be before @param

src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 146:

> 144:         // The chronology and zone fields of Formatter are usually null,
> 145:         // so the non-null processing code is placed in a separate method
> 146:         return adjustWithOverride(temporal, overrideChrono, overrideZone);

The "so..." doesn't explain much, perhaps:
Placing the non-null cases in a separate method allows more flexible code optimizations"

src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 241:

> 239:             Chronology effectiveChrono,
> 240:             Chronology temporalChrono
> 241:     ) {

Join with previous line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2289343238
PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2289347338
PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2289356956

From roger.riggs at oracle.com  Wed Aug 20 21:48:56 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 20 Aug 2025 17:48:56 -0400
Subject: I'd like add no-argument overloads to CharSequence, String, and
 StringBuilder (JDK-8364007)
In-Reply-To: <TYVPR01MB11356224F9CB1EF0786E2E6829128A@TYVPR01MB11356.jpnprd01.prod.outlook.com>
References: <TYVPR01MB11356224F9CB1EF0786E2E6829128A@TYVPR01MB11356.jpnprd01.prod.outlook.com>
Message-ID: <62c6f1c9-9dbd-464d-ada8-23b1c439331c@oracle.com>

HI,

This seems like a reasonable idea.
For CharSequence, I would add them as default methods on CharSequence
and include the API Character.codePointCount(csq, begin, end)).
The char array version will still need to be in Character.

Regards, Roger

On 8/11/25 7:37 PM, Uchino Tatsunori wrote:
> Dear Chen-san,
>
> The beginIndex there is just a mistake that must have been removed.
>
> String.codePointCount()
>
> is the correct suggestion, as you can imagine. I am sorry for the 
> confusion.
>
> Regards,
>
> Tatsunori Uchino
>
> 2025/08/12 7:29 Chen Liang <chen.l.liang at oracle.com>:
>
>     Hi Uchino, I think your request is sensible in general.
>
>     Do you intend to require a beginIndex for the codePointCount for
>     String? I think a no-arg version suffices.
>
>     Also forwarding this to i18n-dev as it is the locale-related list.
>
>     P.S. When you reply, make sure you click "Reply all" so all the
>     recipients of this current mail gets your reply. Otherwise, the
>     reply is only sent to me, and others on the list won't see your reply.
>
>     Regards, Chen
>     ------------------------------------------------------------------------
>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf
>     of Uchino Tatsunori <tats.u at live.jp>
>     *Sent:* Monday, August 11, 2025 6:54 AM
>     *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>     *Subject:* I'd like add no-argument overloads to CharSequence,
>     String, and StringBuilder (JDK-8364007)
>     Dear core-libs developers,
>
>     I'd like to add the following overloads:
>
>     ? Character.codePointCount(CharSequence seq)
>     ? Character.codePointCount(char[] a)
>     ? String.codePointCount(int beginIndex)
>     ? StringBuffer.codePointCount()
>     ? StringBuilder.codePointCount()
>
>     and created a patch (https://github.com/openjdk/jdk/pull/26461).
>
>     Why:
>
>     There have already been similar overloads with the start and end
>     indicies by JSR 204 (JDK-4985217). They are thought to have been
>     designed with a priority on versatility. They make the
>     specification of indices mandatory, but have the following
>     disadvantages:
>
>     1. The string expression have to be written twice. Unlike C#, Java
>     has no equivalent of extended methods.
>     2. Unneccesary boundary checks are mixed in.
>     3. The most userland code tries to calculate the number of code
>     points in the entire stirng.
>     4. Some other languages can count the number of code points in a
>     single function without extra arguments (e.g. len() in Python3)
>
>     For 3., e.g.:
>
>     ? VARCHAR in MySQL & PostgreSQL counts the number of characters in
>     the unit of code points. e.g. VARCHAR(20) means that the limit is
>     20 code points, not 20 UTF-16 code units (20 chars in Java)
>     ? NIST Special Publication 800-63B stiplates that the password
>     length must be counted as the unit of code points. (Quote from
>     https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers
>     : "For purposes of the above length requirements, each Unicode
>     code point SHALL be counted as a single character.")
>
>     I would like to get agreement on these changes and would like to
>     know what I have to do outside of GitHub (e.g how to submit CSRs).
>     If you have a GitHub account, it would be helpful if you could
>     reply to the PR. If not, you can reply directly to this email.
>
>     Best Regards,
>
>     Tatsunori Uchino
>     https://github.com/tats-u/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250820/1e5e5311/attachment.htm>

From liach at openjdk.org  Wed Aug 20 22:10:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Aug 2025 22:10:40 GMT
Subject: RFR: 8365832: Optimize FloatingDecimal and DigitList with byte[]
 and cleanup [v6]
In-Reply-To: <GvwzpIBGo2RAv7XJdJBGSUi7ZuZEA0Ccgs6K-EynAIg=.f183ca00-67bf-4723-b0a8-72d379b6b4e7@github.com>
References: <GdTJKcA2i1XOr5pzi1AWmDY04O2SqIB61VW0XGEXX10=.759cc998-6b8c-4a2d-809f-8fe497d195cf@github.com>
 <2zcCNPbTINbQ5-e-G9CHGmFe3NCpsgzd7E81aYqIdn4=.fcff3e8a-63eb-4196-89d7-171c1b4a40f4@github.com>
 <GvwzpIBGo2RAv7XJdJBGSUi7ZuZEA0Ccgs6K-EynAIg=.f183ca00-67bf-4723-b0a8-72d379b6b4e7@github.com>
Message-ID: <c90_u0aFPKq8eAUCSav13VkPCLXsW2hLyeT5LTLJZz0=.6c30e461-257b-436a-879f-fd2650fed230@github.com>

On Wed, 20 Aug 2025 21:25:33 GMT, Thomas Zimmermann <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   without copy digits, from @j3graham
>
> I'm not an official reviewer, but looks good to me ? 
> 
> P.S.: While looking why you might have preferred `ISO_8859_1` over `US_ASCII` (latin1 can skip the mapping of replacement characters because it defines the entire byte range, correct?), I stumbled upon a reference to the removed `SecurityManager` in [a comment](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L652).

@zimmi, I created a simple issue for this outdated comment at https://bugs.openjdk.org/browse/JDK-8365887

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23311#issuecomment-3208202488

From liach at openjdk.org  Wed Aug 20 22:22:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Aug 2025 22:22:15 GMT
Subject: RFR: 8365885: Clean up constant pool reflection native code
Message-ID: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>

When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion.

-------------

Commit messages:
 - 8365885: Clean up constant pool reflection native code

Changes: https://git.openjdk.org/jdk/pull/26870/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365885
  Stats: 142 lines in 6 files changed: 18 ins; 3 del; 121 mod
  Patch: https://git.openjdk.org/jdk/pull/26870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26870/head:pull/26870

PR: https://git.openjdk.org/jdk/pull/26870

From smarks at openjdk.org  Wed Aug 20 23:13:57 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 20 Aug 2025 23:13:57 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
Message-ID: <rJ3QSq3t7ltPQFZT29uxH40dxr2vaIkJcE1ZZTZohv8=.9c51b9cb-b71c-4483-89a7-0f7cf8e274df@github.com>

On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by smarks (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26273#pullrequestreview-3138508798

From almatvee at openjdk.org  Thu Aug 21 00:17:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 21 Aug 2025 00:17:05 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v3]
In-Reply-To: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
Message-ID: <qAa4xHhgB-JUsmJcBmgbiKPI5Ud7nMsKhZ6DHTyHSdQ=.c1556026-77e3-4102-86dd-8861161b8e4a@github.com>

> - Added following note for `--app-content` on macOS to help and man page: `The value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the application bundle). Otherwise, jpackage may produce invalid application bundle which may fail code signing and/or notarization.`
> - Added warning if `--app-content` if it points to non-standard subdirectory in "Contents" directory.
> - Added test to cover warning message.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8356218: [macos] Document --app-content [v3]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26848/files
  - new: https://git.openjdk.org/jdk/pull/26848/files/18d37f69..44d8982f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26848&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26848&range=01-02

  Stats: 53 lines in 5 files changed: 31 ins; 11 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26848/head:pull/26848

PR: https://git.openjdk.org/jdk/pull/26848

From almatvee at openjdk.org  Thu Aug 21 00:17:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 21 Aug 2025 00:17:05 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v2]
In-Reply-To: <L7Qf1r3tu4ByoBrNC7m49Gd7MLCALQvq1JB8-dWZesI=.2015e27d-5196-453c-b2e5-77e9ae5e3ec5@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
 <L7Qf1r3tu4ByoBrNC7m49Gd7MLCALQvq1JB8-dWZesI=.2015e27d-5196-453c-b2e5-77e9ae5e3ec5@github.com>
Message-ID: <ssG-iOp7tQJs2J50W8XcAU1i6jrmFERY9gS1wr6BrQY=.0d9c7c3e-8c7a-4967-99ee-0bb3bea319cc@github.com>

On Tue, 19 Aug 2025 22:10:53 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added following note for `--app-content` on macOS to help and man page: `The value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the application bundle). Otherwise, jpackage may produce invalid application bundle which may fail code signing and/or notarization.`
>> - Added warning if `--app-content` if it points to non-standard subdirectory in "Contents" directory.
>> - Added test to cover warning message.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356218: [macos] Document --app-content [v2]

8356218: [macos] Document --app-content [v3]
- Fixed latest review comments.
- Test moved from `ErrorTest` to `AppContentTest`.
- Added `setIgnoreExitCode()` to `JPackageCommand` to ignore exit code. Added test case may or may not fail depending on macOS version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26848#issuecomment-3208513977

From almatvee at openjdk.org  Thu Aug 21 00:17:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 21 Aug 2025 00:17:05 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v2]
In-Reply-To: <1Tocftaax86p3LY8y0m-1zJktjWBUEYn96oAPXm9QcI=.b784748b-c9bf-427c-9694-dbf73a3b534e@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
 <L7Qf1r3tu4ByoBrNC7m49Gd7MLCALQvq1JB8-dWZesI=.2015e27d-5196-453c-b2e5-77e9ae5e3ec5@github.com>
 <1Tocftaax86p3LY8y0m-1zJktjWBUEYn96oAPXm9QcI=.b784748b-c9bf-427c-9694-dbf73a3b534e@github.com>
Message-ID: <XNcN-jWYtXKsWop5kDDrvkYT9bxEu2vg3EBW53UZOXg=.1ebc5c3c-b436-49d3-9e9c-6d43f64d4395@github.com>

On Wed, 20 Aug 2025 01:19:16 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356218: [macos] Document --app-content [v2]
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 130:
> 
>> 128:     private static void validateAppContentDirs(Application app) {
>> 129:         for (var contentDir : app.contentDirs()) {
>> 130:             if (!CONTENTS_SUB_DIRS.stream()
> 
> You could replace `CONTENTS_SUB_DIRS` with a `Set<String>`, and the inspection with `CONTENTS_SUB_DIRS.contains(contentDir.getFileName().toString())`.

Updated as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2289566359

From almatvee at openjdk.org  Thu Aug 21 00:17:06 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 21 Aug 2025 00:17:06 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v3]
In-Reply-To: <NZD7RZu6MkHNhntZE4xEMU5CK5zx5n4BmDrcItKpLiY=.b5a10621-d774-4126-8827-c4aef6801720@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
 <NZD7RZu6MkHNhntZE4xEMU5CK5zx5n4BmDrcItKpLiY=.b5a10621-d774-4126-8827-c4aef6801720@github.com>
Message-ID: <OUfN63dLLChkuF2sX3bZXUOINa151vCyHSj6ADkpQqk=.ffb527af-100f-4707-aaa8-e87c2f0a0850@github.com>

On Tue, 19 Aug 2025 21:05:53 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356218: [macos] Document --app-content [v3]
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 88:
> 
>> 86: warning.unsigned.app.image=Warning: Using unsigned app-image to build signed {0}.
>> 87: warning.per.user.app.image.signed=Warning: Support for per-user configuration of the installed application will not be supported due to missing "{0}" in predefined signed application image.
>> 88: warning.non.standard.contents.sub.dir=Warning: --app-content value "{0}" points to the non-standard subdirectory in the "Contents" directory of the application bundle.
> 
> This warning is not particularly helpful:
>  - It doesn't provide details;
>  - It is misleading. The value of the `--app-content` cli option specifies directories and files that will be copied into the application bundle, not those in the bundle.
> 
> I'd issue a warning for every unexpected directory/file found in the value of the `--app-content` option.
> 
> I suggest we have two warning messages:
> 
> Warning: The file name of the directory "{0}" specified for the --app-content option is not a standard subdirectory name in the "Contents" directory of the application bundle. The result application bundle may fail notarization.
> 
> 
> 
> Warning: The value "{0}" of the --app-content option is not a directory. The result application bundle may fail notarization.

Updated as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2289566184

From smarks at openjdk.org  Thu Aug 21 00:19:54 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 21 Aug 2025 00:19:54 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v3]
In-Reply-To: <sKL_UHmzbiD_x6fg5zV38_txopTyYtrTxnl9TZ6z_MQ=.2036fac0-c1ba-4b4a-ae28-55247391d342@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <sKL_UHmzbiD_x6fg5zV38_txopTyYtrTxnl9TZ6z_MQ=.2036fac0-c1ba-4b4a-ae28-55247391d342@github.com>
Message-ID: <y47CZdb_GdmqGOR0x8sC-pvTsOBLbML5QpKHYNxzDrY=.d8eeaf1c-d4de-49b3-b21c-819959323667@github.com>

On Mon, 14 Jul 2025 20:58:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Wording change, isTerminal() always returns true
>>  - Merge branch 'master' into JDK-8361972-System-console-condition
>>  - Wording modification
>>  - initial commit
>
> src/java.base/share/classes/java/io/Console.java line 47:
> 
>> 45:  * output streams then its console will exist and will typically be
>> 46:  * connected to the keyboard and display from which the virtual machine
>> 47:  * was launched.  If the virtual machine is started automatically, for
> 
> I think it might read easier if we reword the structure of the sentence to make it more concise.
> 
> E.g.
> 
>> The virtual machine may not have a console if started automatically, (e.g., by a background scheduler) or if either the standard input or output has been redirected.

I took another look at this and I agree that some rewording is necessary. There are several inconsistencies in the wording here, e.g., between "exists / does not exist" or "the virtual machine has a console / does not have a console" or "a console / a console device". I rewrote the first couple paragraphs here to unify the wording around a console as a noun (that is, no "console device") and to use "exists / does not exist" consistently. I also made some areas a bit more definite.

    * <p> Whether a virtual machine's console exists is dependent upon the
    * underlying platform and also upon the manner in which the virtual
    * machine is invoked.  If the virtual machine is started from an
    * interactive command line without redirecting the standard input and
    * output streams, then its console will generally exist and will be
    * connected to the keyboard and display from which the virtual machine
    * was launched. If the standard input or standard output have been
    * redirected (for example, to a file or to a pipe), or if the virtual
    * machine was started from a background job scheduler, the console
    * will not exist.
    * <p>
    * If the console exists, then it is represented by a unique instance of this
    * class which can be obtained by invoking the {@link System#console()} method.
    * If the console does not exist, that method will return {@code null}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2289573821

From asemenyuk at openjdk.org  Thu Aug 21 00:24:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 21 Aug 2025 00:24:52 GMT
Subject: RFR: 8356218: [macos] Document --app-content [v3]
In-Reply-To: <qAa4xHhgB-JUsmJcBmgbiKPI5Ud7nMsKhZ6DHTyHSdQ=.c1556026-77e3-4102-86dd-8861161b8e4a@github.com>
References: <NrddEY8yIP2x1un4W9Zt93-oJBYY_fJaGd0NldORFuo=.2c43b1da-d5dd-47b1-b17c-278ba774d27b@github.com>
 <qAa4xHhgB-JUsmJcBmgbiKPI5Ud7nMsKhZ6DHTyHSdQ=.c1556026-77e3-4102-86dd-8861161b8e4a@github.com>
Message-ID: <tp1uWxSgvJf7-CmKwFeA6ISYxxb_GydOBsZrOuXmVqw=.f52eb493-b2e5-40d3-92d8-be08f8f7ae43@github.com>

On Thu, 21 Aug 2025 00:17:05 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added following note for `--app-content` on macOS to help and man page: `The value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the application bundle). Otherwise, jpackage may produce invalid application bundle which may fail code signing and/or notarization.`
>> - Added warning if `--app-content` if it points to non-standard subdirectory in "Contents" directory.
>> - Added test to cover warning message.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356218: [macos] Document --app-content [v3]

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 748:

> 746:         ignoreExitCode = v;
> 747:         return this;
> 748:     }

This is bad. It makes unclear semantics of the `JPackageCommand.execute(int expectedExitCode)` function.

I suggest adding `JPackageCommand.executeIgnoreExitCode()` function instead in the following way:

public Executor.Result executeIgnoreExitCode() {
    return execute(Optional.empty());
}

public Executor.Result execute(int expectedExitCode) {
    return execute(Optional.of(expectedExitCode));
} 

private Executor.Result execute(Optional expectedExitCode) {
    // Here goes the implementation of the current execute(int expectedExitCode) function adjusted accordingly
}

test/jdk/tools/jpackage/share/AppContentTest.java line 122:

> 120:     @Parameter({TEST_DIR, "warning.non.standard.contents.sub.dir"})
> 121:     @Parameter({TEST_DUKE, "warning.app.content.is.not.dir"})
> 122:     public void testWarnings(String... args) throws Exception {

`String... args` -> `String testPath, String warningId`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2289575904
PR Review Comment: https://git.openjdk.org/jdk/pull/26848#discussion_r2289578904

From naoto at openjdk.org  Thu Aug 21 00:37:59 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 21 Aug 2025 00:37:59 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v4]
In-Reply-To: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
Message-ID: <SQhbtE_iMlIEg11bQQ8EVRqDVr2e7htu93I5Iev5H8U=.0de80381-658b-4552-a46d-6390c3289e62@github.com>

> This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26299/files
  - new: https://git.openjdk.org/jdk/pull/26299/files/a3b39049..8453c434

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26299&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26299&range=02-03

  Stats: 11 lines in 1 file changed: 0 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26299.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26299/head:pull/26299

PR: https://git.openjdk.org/jdk/pull/26299

From naoto at openjdk.org  Thu Aug 21 00:53:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 21 Aug 2025 00:53:09 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v4]
In-Reply-To: <y47CZdb_GdmqGOR0x8sC-pvTsOBLbML5QpKHYNxzDrY=.d8eeaf1c-d4de-49b3-b21c-819959323667@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <sKL_UHmzbiD_x6fg5zV38_txopTyYtrTxnl9TZ6z_MQ=.2036fac0-c1ba-4b4a-ae28-55247391d342@github.com>
 <y47CZdb_GdmqGOR0x8sC-pvTsOBLbML5QpKHYNxzDrY=.d8eeaf1c-d4de-49b3-b21c-819959323667@github.com>
Message-ID: <5Te0GovAhxvKd8u_Vjl85Xnz4s4cnugfa30oguz5mZE=.59a3464e-9672-4881-ae58-e7bde40b1790@github.com>

On Thu, 21 Aug 2025 00:17:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 47:
>> 
>>> 45:  * output streams then its console will exist and will typically be
>>> 46:  * connected to the keyboard and display from which the virtual machine
>>> 47:  * was launched.  If the virtual machine is started automatically, for
>> 
>> I think it might read easier if we reword the structure of the sentence to make it more concise.
>> 
>> E.g.
>> 
>>> The virtual machine may not have a console if started automatically, (e.g., by a background scheduler) or if either the standard input or output has been redirected.
>
> I took another look at this and I agree that some rewording is necessary. There are several inconsistencies in the wording here, e.g., between "exists / does not exist" or "the virtual machine has a console / does not have a console" or "a console / a console device". I rewrote the first couple paragraphs here to unify the wording around a console as a noun (that is, no "console device") and to use "exists / does not exist" consistently. I also made some areas a bit more definite.
> 
>     * <p> Whether a virtual machine's console exists is dependent upon the
>     * underlying platform and also upon the manner in which the virtual
>     * machine is invoked.  If the virtual machine is started from an
>     * interactive command line without redirecting the standard input and
>     * output streams, then its console will generally exist and will be
>     * connected to the keyboard and display from which the virtual machine
>     * was launched. If the standard input or standard output have been
>     * redirected (for example, to a file or to a pipe), or if the virtual
>     * machine was started from a background job scheduler, the console
>     * will not exist.
>     * <p>
>     * If the console exists, then it is represented by a unique instance of this
>     * class which can be obtained by invoking the {@link System#console()} method.
>     * If the console does not exist, that method will return {@code null}.

Thanks, Stuart. Updated those paragraphs as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2289606530