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 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 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 dholmes at openjdk.org  Mon Aug  4 02:25:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 02:25:37 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
Message-ID: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>

TBD

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

Commit messages:
 - Make os::snprintf "nodiscard" and adjust final callsites
 - Convert os::snprintf() to os::snprintf_checked() where appropriate.
 - Forbid C library snprintf
 - Change return-value using snprintf to explicit os::snprintf
 - Change raw snprintf to os::snprintf_checked, whereever truncation would not
 - Change os::snprintf_checked to be void function.
 - Mark os::vsnprintf as nodiscard and update the callsites.

Changes: https://git.openjdk.org/jdk/pull/26470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26470&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347707
  Stats: 197 lines in 46 files changed: 15 ins; 5 del; 177 mod
  Patch: https://git.openjdk.org/jdk/pull/26470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26470/head:pull/26470

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

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 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 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 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: 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 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 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 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 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 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 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 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 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 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 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 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 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 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 yzheng at openjdk.org  Mon Aug 11 14:06:56 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 11 Aug 2025 14:06:56 GMT
Subject: RFR: 8365218: [JVMCI] AArch64 CPU features are not computed correctly
 after 8364128
Message-ID: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>

https://github.com/openjdk/jdk/pull/26515 changes the `VM_Version::CPU_` constant values on AArch64 and Graal now sees unsupported CPU features. This may result in SIGILL due to Graal emitting unsupported instructions, such as `CPU_SHA3`-based eor3 instructions in AArch64 SHA3 stubs.

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

Commit messages:
 - [JVMCI] AArch64 CPU features are not computed correctly after 8364128

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

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

From dnsimon at openjdk.org  Mon Aug 11 14:47:10 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 11 Aug 2025 14:47:10 GMT
Subject: RFR: 8365218: [JVMCI] AArch64 CPU features are not computed
 correctly after 8364128
In-Reply-To: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
References: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
Message-ID: <pZ-2mx9WvPnzPFxQ593q_FDmPoXKQPakWyWl1OdPeR4=.a3b211a6-dcdb-4cf5-b11f-e9c3c659e7bc@github.com>

On Mon, 11 Aug 2025 13:59:55 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/26515 changes the `VM_Version::CPU_` constant values on AArch64 and Graal now sees unsupported CPU features. This may result in SIGILL due to Graal emitting unsupported instructions, such as `CPU_SHA3`-based eor3 instructions in AArch64 SHA3 stubs.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 45:

> 43: 
> 44:     /**
> 45:      * Converts a bit mask of CPU features to enum constants.

What's the difference between this new method and the existing `convertFeatures` methods? Is there some way we can consolidate all these versions as they look quite similar at a glance. If not, then please add javadoc to each explaining what's unique about it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26727#discussion_r2267009657

From jsjolen at openjdk.org  Mon Aug 11 16:04:00 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 11 Aug 2025 16:04:00 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable
Message-ID: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>

Hi,

This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.

I didn't change any copyright years for this change.

Thanks

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

Commit messages:
 - Rename file
 - Rename ResourceHashtable to HashTable

Changes: https://git.openjdk.org/jdk/pull/26729/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365264
  Stats: 1841 lines in 67 files changed: 856 ins; 856 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/26729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729

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

From jsjolen at openjdk.org  Mon Aug 11 17:32:11 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 11 Aug 2025 17:32:11 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <m99dOANXZzBqMUZ5L6W4Gjgwc9oRfTTZ3oTmmmN0FX0=.de28b77d-98b9-4ea7-8033-6c1d80ba539d@github.com>

On Mon, 11 Aug 2025 15:57:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Aha, of course I forgot about re-sorting the headers.

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

PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3176028919

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 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 jsjolen at openjdk.org  Tue Aug 12 07:53:58 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 12 Aug 2025 07:53:58 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v2]
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <mHhs1WqspGpuC60gVOPC_Bp7cOuNt98lFhfSalC8-J4=.cc04e2b6-2af2-4b09-932d-6f38ae6f7d21@github.com>

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  What does the test think about this sorting?

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26729/files
  - new: https://git.openjdk.org/jdk/pull/26729/files/fa1794d0..c7ce8dea

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

  Stats: 87 lines in 29 files changed: 42 ins; 45 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729

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

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 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 jsjolen at openjdk.org  Tue Aug 12 10:45:09 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 12 Aug 2025 10:45:09 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v3]
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <QcElZQEd_MYS0yNkkDFsE72uu96FzEz4grNVhvOfrLQ=.ed3309f7-7465-4580-8662-3de9c4e7db1d@github.com>

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  This should be preferred

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26729/files
  - new: https://git.openjdk.org/jdk/pull/26729/files/c7ce8dea..4e143035

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

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

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

From jsjolen at openjdk.org  Tue Aug 12 12:02:13 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 12 Aug 2025 12:02:13 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4]
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Found the instructions for how to run the script in the error log

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26729/files
  - new: https://git.openjdk.org/jdk/pull/26729/files/4e143035..5c58e011

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

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

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

From yzheng at openjdk.org  Tue Aug 12 17:09:07 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 12 Aug 2025 17:09:07 GMT
Subject: RFR: 8365218: [JVMCI] AArch64 CPU features are not computed
 correctly after 8364128 [v2]
In-Reply-To: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
References: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
Message-ID: <bJBp5ar6vX5O-VuQHMMDjmKhNluMyk5uVxum-c3Rq48=.5d26a6d4-4aae-4c59-b967-f15393d4214e@github.com>

> https://github.com/openjdk/jdk/pull/26515 changes the `VM_Version::CPU_` constant values on AArch64 and Graal now sees unsupported CPU features. This may result in SIGILL due to Graal emitting unsupported instructions, such as `CPU_SHA3`-based eor3 instructions in AArch64 SHA3 stubs.

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

  address comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26727/files
  - new: https://git.openjdk.org/jdk/pull/26727/files/87f4700a..3e378957

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

  Stats: 132 lines in 4 files changed: 15 ins; 102 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26727/head:pull/26727

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

From yzheng at openjdk.org  Tue Aug 12 17:12:26 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 12 Aug 2025 17:12:26 GMT
Subject: RFR: 8365218: [JVMCI] AArch64 CPU features are not computed
 correctly after 8364128 [v3]
In-Reply-To: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
References: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
Message-ID: <2fFSOt9xWkOX8rkgkSjKquHPzBCwnmzzstcUNJ16klU=.b2aeeb5f-7d74-4ad4-b0c3-53ae76824a6e@github.com>

> https://github.com/openjdk/jdk/pull/26515 changes the `VM_Version::CPU_` constant values on AArch64 and Graal now sees unsupported CPU features. This may result in SIGILL due to Graal emitting unsupported instructions, such as `CPU_SHA3`-based eor3 instructions in AArch64 SHA3 stubs.

Yudi Zheng has updated the pull request incrementally with two additional commits since the last revision:

 - style
 - style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26727/files
  - new: https://git.openjdk.org/jdk/pull/26727/files/3e378957..6aa51798

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

  Stats: 21 lines in 4 files changed: 6 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26727/head:pull/26727

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

From dnsimon at openjdk.org  Tue Aug 12 18:05:12 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 12 Aug 2025 18:05:12 GMT
Subject: RFR: 8365218: [JVMCI] AArch64 CPU features are not computed
 correctly after 8364128 [v3]
In-Reply-To: <2fFSOt9xWkOX8rkgkSjKquHPzBCwnmzzstcUNJ16klU=.b2aeeb5f-7d74-4ad4-b0c3-53ae76824a6e@github.com>
References: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
 <2fFSOt9xWkOX8rkgkSjKquHPzBCwnmzzstcUNJ16klU=.b2aeeb5f-7d74-4ad4-b0c3-53ae76824a6e@github.com>
Message-ID: <bxtGB1coEkFKdfEIXgOwQOHF0-GoQk27PM6Sz4CqP6Q=.6ea29de9-c601-4a0e-807b-06ff9467a66f@github.com>

On Tue, 12 Aug 2025 17:12:26 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/pull/26515 changes the `VM_Version::CPU_` constant values on AArch64 and Graal now sees unsupported CPU features. This may result in SIGILL due to Graal emitting unsupported instructions, such as `CPU_SHA3`-based eor3 instructions in AArch64 SHA3 stubs.
>
> Yudi Zheng has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - style
>  - style

LGTM.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26727#pullrequestreview-3112105684

From ayang at openjdk.org  Tue Aug 12 19:24:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 12 Aug 2025 19:24:15 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4]
In-Reply-To: <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
Message-ID: <TCfUAC7klNvLxuPKGOqNSYxx3mXy6TqS09lI5nNEYkE=.c6e4187e-2d7f-4281-8d66-2b901e0f0ac2@github.com>

On Tue, 12 Aug 2025 12:02:13 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
>> 
>> I didn't change any copyright years for this change.
>> 
>> Thanks
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Found the instructions for how to run the script in the error log

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26729#pullrequestreview-3112432948

From iklam at openjdk.org  Wed Aug 13 00:15:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 13 Aug 2025 00:15:10 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4]
In-Reply-To: <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
Message-ID: <iBjD0epjpW2xtraeXWH46hGnkwbb1oLoRH_OLN7_OZk=.73c35038-1caa-4964-82fc-c9b36b88d4a4@github.com>

On Tue, 12 Aug 2025 12:02:13 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
>> 
>> I didn't change any copyright years for this change.
>> 
>> Thanks
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Found the instructions for how to run the script in the error log

`hashtable.hpp` should become `hashTable.hpp`, which defines the type `HashTable`. (Existing example:  `concurrentHashTable.hpp` defines the type `ConcurrentHashTable`).

`resizeableResourceHash.hpp` should be renamed to `resizeableHashTable.hpp`

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

PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3181661293

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 yzheng at openjdk.org  Wed Aug 13 07:04:12 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 13 Aug 2025 07:04:12 GMT
Subject: RFR: 8365218: [JVMCI] AArch64 CPU features are not computed
 correctly after 8364128 [v4]
In-Reply-To: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
References: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
Message-ID: <LoOp6KqtmW5YNsXA36hEIowwkOisF41iQRqPgNpMEkk=.5438bfa3-195f-4c1a-a62c-dc3f83e45c27@github.com>

> https://github.com/openjdk/jdk/pull/26515 changes the `VM_Version::CPU_` constant values on AArch64 and Graal now sees unsupported CPU features. This may result in SIGILL due to Graal emitting unsupported instructions, such as `CPU_SHA3`-based eor3 instructions in AArch64 SHA3 stubs.

Yudi Zheng 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 master
 - style
 - style
 - address comments
 - [JVMCI] AArch64 CPU features are not computed correctly after 8364128

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26727/files
  - new: https://git.openjdk.org/jdk/pull/26727/files/6aa51798..0056275f

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

  Stats: 3509 lines in 92 files changed: 1362 ins; 1559 del; 588 mod
  Patch: https://git.openjdk.org/jdk/pull/26727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26727/head:pull/26727

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

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 jsjolen at openjdk.org  Wed Aug 13 07:47:05 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 13 Aug 2025 07:47:05 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v5]
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Ioi's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26729/files
  - new: https://git.openjdk.org/jdk/pull/26729/files/5c58e011..eb5a4ea6

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

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

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

From jsjolen at openjdk.org  Wed Aug 13 09:30:15 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 13 Aug 2025 09:30:15 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4]
In-Reply-To: <iBjD0epjpW2xtraeXWH46hGnkwbb1oLoRH_OLN7_OZk=.73c35038-1caa-4964-82fc-c9b36b88d4a4@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <qN0GBSqc1EpbaGJh8bL3ztYgcz5QHDIoAhHDzcgHzHg=.e4c04880-3543-433c-b57b-f3ff990c401e@github.com>
 <iBjD0epjpW2xtraeXWH46hGnkwbb1oLoRH_OLN7_OZk=.73c35038-1caa-4964-82fc-c9b36b88d4a4@github.com>
Message-ID: <Y05W9DYpeNTXrJRH4Ko0ZPs8zybf-wXgXLnLOQ9HMSQ=.41b87f6c-9761-4dfa-bbd8-f35e8adf4507@github.com>

On Wed, 13 Aug 2025 00:13:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `hashtable.hpp` should become `hashTable.hpp`, which defines the type `HashTable`. (Existing example: `concurrentHashTable.hpp` defines the type `ConcurrentHashTable`).
> 
> `resizeableResourceHash.hpp` should be renamed to `resizeableHashTable.hpp`

Done!

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

PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3182953039

From dnsimon at openjdk.org  Wed Aug 13 09:42:10 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 13 Aug 2025 09:42:10 GMT
Subject: RFR: 8365218: [JVMCI] AArch64 CPU features are not computed
 correctly after 8364128 [v4]
In-Reply-To: <LoOp6KqtmW5YNsXA36hEIowwkOisF41iQRqPgNpMEkk=.5438bfa3-195f-4c1a-a62c-dc3f83e45c27@github.com>
References: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
 <LoOp6KqtmW5YNsXA36hEIowwkOisF41iQRqPgNpMEkk=.5438bfa3-195f-4c1a-a62c-dc3f83e45c27@github.com>
Message-ID: <ZcL4VnodJtXURdQgIEjpG2Uu4zBduq9sx4af76UgEOc=.33992189-bdfe-42f5-a17b-81cb756f214b@github.com>

On Wed, 13 Aug 2025 07:04:12 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/pull/26515 changes the `VM_Version::CPU_` constant values on AArch64 and Graal now sees unsupported CPU features. This may result in SIGILL due to Graal emitting unsupported instructions, such as `CPU_SHA3`-based eor3 instructions in AArch64 SHA3 stubs.
>
> Yudi Zheng 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 master
>  - style
>  - style
>  - address comments
>  - [JVMCI] AArch64 CPU features are not computed correctly after 8364128

Still good.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26727#pullrequestreview-3114873479

From bulasevich at openjdk.org  Wed Aug 13 12:38:59 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 13 Aug 2025 12:38:59 GMT
Subject: RFR: 8365071: ARM32: JFR intrinsic jvm_commit triggers C2 regalloc
 assert
Message-ID: <6MHwDW0E9bOzpj5B3pzlNmOCRPtFtnrk55NmTTxbhLM=.f0026c26-2c80-4766-8984-da9f34a31c8d@github.com>

On 32-bit ARM, the jvm_commit JFR intrinsic builder feeds null (RegP) into a TypeLong Phi, causing mixed long/pointer register sizing and triggering the C2 register allocator assert(_num_regs == reg || !_num_regs).

The fix is trivial: use an appropriate ConL constant instead. This has no effect on 64-bit systems (the generated assembly is identical) but resolves a JFR issue on 32-bit systems.

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

Commit messages:
 - 8365071: ARM32: JFR intrinsic jvm_commit triggers C2 regalloc assert

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

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

From bulasevich at openjdk.org  Wed Aug 13 12:41:12 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 13 Aug 2025 12:41:12 GMT
Subject: RFR: 8365071: ARM32: JFR intrinsic jvm_commit triggers C2 regalloc
 assert
In-Reply-To: <6MHwDW0E9bOzpj5B3pzlNmOCRPtFtnrk55NmTTxbhLM=.f0026c26-2c80-4766-8984-da9f34a31c8d@github.com>
References: <6MHwDW0E9bOzpj5B3pzlNmOCRPtFtnrk55NmTTxbhLM=.f0026c26-2c80-4766-8984-da9f34a31c8d@github.com>
Message-ID: <SH53X1mdLAmgqlVli0A1MtOtinTYECwcsf1vIa9cMVw=.47644553-db9c-4708-9c78-cf73fd49ceec@github.com>

On Fri, 8 Aug 2025 01:54:46 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> On 32-bit ARM, the jvm_commit JFR intrinsic builder feeds null (RegP) into a TypeLong Phi, causing mixed long/pointer register sizing and triggering the C2 register allocator assert(_num_regs == reg || !_num_regs).
> 
> The fix is trivial: use an appropriate ConL constant instead. This has no effect on 64-bit systems (the generated assembly is identical) but resolves a JFR issue on 32-bit systems.

@mgronlun You might be interested in this

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

PR Comment: https://git.openjdk.org/jdk/pull/26684#issuecomment-3183746220

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 iklam at openjdk.org  Wed Aug 13 15:57:11 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 13 Aug 2025 15:57:11 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v5]
In-Reply-To: <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>
Message-ID: <1IxUyzkDpUinf8oPCbLLRXldc_btUhDSnEcQUEj8ikM=.9f65e529-d65a-461b-aa73-b666eebcaac3@github.com>

On Wed, 13 Aug 2025 07:47:05 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
>> 
>> I didn't change any copyright years for this change.
>> 
>> Thanks
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi's comments

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26729#pullrequestreview-3116642805

From jsjolen at openjdk.org  Wed Aug 13 18:42:19 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 13 Aug 2025 18:42:19 GMT
Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v5]
In-Reply-To: <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
 <s2gOzC1jg8RTIY455yGGXWlx-sVTOMEV0nX6X2m904s=.35dfb0ff-bb26-4cde-8ed7-4bc73c19f022@github.com>
Message-ID: <G5395SQOqM_TDe3afc8qLjMhd7xi2vUzWSTY9uxbwa4=.40662d4b-32fb-42e0-bcf1-ff000bdeacd0@github.com>

On Wed, 13 Aug 2025 07:47:05 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
>> 
>> I didn't change any copyright years for this change.
>> 
>> Thanks
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi's comments

Cheers!

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

PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3185064264

From jsjolen at openjdk.org  Wed Aug 13 18:45:21 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 13 Aug 2025 18:45:21 GMT
Subject: Integrated: 8365264: Rename ResourceHashtable to HashTable
In-Reply-To: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
References: <tUyaUBBm6LMcUI0gxIlCIzpt9K3_GeUTrjIvBKlrZw0=.9d6dbb4a-8373-4686-ac12-a8e7acbe39e1@github.com>
Message-ID: <mXg82pP5OF-UsFOyhb0Lz5dzJDvv97t_KSrm2188lMg=.5c8a1c52-fb22-4e28-b421-9e8ebb3cfd32@github.com>

On Mon, 11 Aug 2025 15:57:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot.
> 
> I didn't change any copyright years for this change.
> 
> Thanks

This pull request has now been integrated.

Changeset: 4680dc98
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4680dc983169d48fcf83eb50dc60e32e79d5d976
Stats:     2233 lines in 71 files changed: 1058 ins; 1059 del; 116 mod

8365264: Rename ResourceHashtable to HashTable

Reviewed-by: iklam, ayang

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

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

From dnsimon at openjdk.org  Wed Aug 13 21:39:21 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 13 Aug 2025 21:39:21 GMT
Subject: RFR: 8365468: EagerJVMCI should only apply to the CompilerBroker JVMCI
 runtime
Message-ID: <bwUCbPxZ6hcpmbeOevzzqDTHyzo1wHFpVYXBV29PwEw=.8eb0cbaa-33ff-4db4-b5fe-6d9516a5271e@github.com>

The primary goal of [JDK-8356447](https://bugs.openjdk.org/browse/JDK-8356447) was to have initialization of the Graal JIT occur in the same phase as the rest of VM startup such that initialization problems are detected and reported prior to executing any user code.

This change caused a performance regression for Truffle when it is used in a JDK that includes both jargraal and libgraal. The problem is that Truffle needs jarjvmci but does not need jargraal when libgraal is available. Initializing jargraal in that configuration delays initialization of Truffle (not just Truffle compilation). Additionally, the jargraal instance created will never be used, wasting memory.

The solution in this PR is to make EagerJVMCI only apply when initializing jarjvmci on a CompileBroker thread.

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

Commit messages:
 - only apply EagerJVMCI on a CompileBroker thread

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

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

From dnsimon at openjdk.org  Wed Aug 13 21:48:51 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 13 Aug 2025 21:48:51 GMT
Subject: RFR: 8365468: EagerJVMCI should only apply to the CompilerBroker
 JVMCI runtime [v2]
In-Reply-To: <bwUCbPxZ6hcpmbeOevzzqDTHyzo1wHFpVYXBV29PwEw=.8eb0cbaa-33ff-4db4-b5fe-6d9516a5271e@github.com>
References: <bwUCbPxZ6hcpmbeOevzzqDTHyzo1wHFpVYXBV29PwEw=.8eb0cbaa-33ff-4db4-b5fe-6d9516a5271e@github.com>
Message-ID: <Gi7-xoBr4YHfF1uO4sffv6c3DueBVB4IjdpeDaIeUuo=.0075f469-1b86-4f35-baa3-cf101f1d90e8@github.com>

> The primary goal of [JDK-8356447](https://bugs.openjdk.org/browse/JDK-8356447) was to have initialization of the Graal JIT occur in the same phase as the rest of VM startup such that initialization problems are detected and reported prior to executing any user code.
> 
> This change caused a performance regression for Truffle when it is used in a JDK that includes both jargraal and libgraal. The problem is that Truffle needs jarjvmci but does not need jargraal when libgraal is available. Initializing jargraal in that configuration delays initialization of Truffle (not just Truffle compilation). Additionally, the jargraal instance created will never be used, wasting memory.
> 
> The solution in this PR is to make EagerJVMCI only apply when initializing jarjvmci on a CompileBroker thread.

Doug Simon 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:

  only apply EagerJVMCI on a CompileBroker thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26768/files
  - new: https://git.openjdk.org/jdk/pull/26768/files/9e858561..a14d8e8f

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

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

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

From yzheng at openjdk.org  Thu Aug 14 07:40:25 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 14 Aug 2025 07:40:25 GMT
Subject: RFR: 8365218: [JVMCI] AArch64 CPU features are not computed
 correctly after 8364128 [v4]
In-Reply-To: <LoOp6KqtmW5YNsXA36hEIowwkOisF41iQRqPgNpMEkk=.5438bfa3-195f-4c1a-a62c-dc3f83e45c27@github.com>
References: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
 <LoOp6KqtmW5YNsXA36hEIowwkOisF41iQRqPgNpMEkk=.5438bfa3-195f-4c1a-a62c-dc3f83e45c27@github.com>
Message-ID: <6ROAi0cU9btXwVfPLA8qrBFsLG_FSDnu8XuxCPR_S1k=.fbc3af8d-dd59-4b2e-8ab9-9f1b4422955d@github.com>

On Wed, 13 Aug 2025 07:04:12 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/pull/26515 changes the `VM_Version::CPU_` constant values on AArch64 and Graal now sees unsupported CPU features. This may result in SIGILL due to Graal emitting unsupported instructions, such as `CPU_SHA3`-based eor3 instructions in AArch64 SHA3 stubs.
>
> Yudi Zheng 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 master
>  - style
>  - style
>  - address comments
>  - [JVMCI] AArch64 CPU features are not computed correctly after 8364128

Thanks for the review!
Passed tier1-3, most of tier9, failures seem unrelated.

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

PR Comment: https://git.openjdk.org/jdk/pull/26727#issuecomment-3187300572

From yzheng at openjdk.org  Thu Aug 14 07:43:16 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 14 Aug 2025 07:43:16 GMT
Subject: Integrated: 8365218: [JVMCI] AArch64 CPU features are not computed
 correctly after 8364128
In-Reply-To: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
References: <lm66pDmpZs7juZLkT7MGzZhSWiZH4pIpPpQho4-Qgwg=.f36021e3-cc37-4298-9df6-6eac75edc75a@github.com>
Message-ID: <s2vQsiHNypZzhbZNGgLWHmqiwVhWm5qMPvdmNC9gUNw=.079a5762-3f43-49f2-ad74-6bd933a70b59@github.com>

On Mon, 11 Aug 2025 13:59:55 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/26515 changes the `VM_Version::CPU_` constant values on AArch64 and Graal now sees unsupported CPU features. This may result in SIGILL due to Graal emitting unsupported instructions, such as `CPU_SHA3`-based eor3 instructions in AArch64 SHA3 stubs.

This pull request has now been integrated.

Changeset: e3201628
Author:    Yudi Zheng <yzheng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e320162815d529bc65cd058b34ec39d60d032ce7
Stats:     74 lines in 4 files changed: 9 ins; 54 del; 11 mod

8365218: [JVMCI] AArch64 CPU features are not computed correctly after 8364128

Reviewed-by: dnsimon

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

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

From never at openjdk.org  Thu Aug 14 15:35:11 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 14 Aug 2025 15:35:11 GMT
Subject: RFR: 8365468: EagerJVMCI should only apply to the CompilerBroker
 JVMCI runtime [v2]
In-Reply-To: <Gi7-xoBr4YHfF1uO4sffv6c3DueBVB4IjdpeDaIeUuo=.0075f469-1b86-4f35-baa3-cf101f1d90e8@github.com>
References: <bwUCbPxZ6hcpmbeOevzzqDTHyzo1wHFpVYXBV29PwEw=.8eb0cbaa-33ff-4db4-b5fe-6d9516a5271e@github.com>
 <Gi7-xoBr4YHfF1uO4sffv6c3DueBVB4IjdpeDaIeUuo=.0075f469-1b86-4f35-baa3-cf101f1d90e8@github.com>
Message-ID: <Toih6hfyNrT4XVDPH865Q_vqabnVxS_QwvrOTeSKdpU=.628d4bcf-c8c0-423c-ad2b-fd89e64ad0ed@github.com>

On Wed, 13 Aug 2025 21:48:51 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The primary goal of [JDK-8356447](https://bugs.openjdk.org/browse/JDK-8356447) was to have initialization of the Graal JIT occur in the same phase as the rest of VM startup such that initialization problems are detected and reported prior to executing any user code.
>> 
>> This change caused a performance regression for Truffle when it is used in a JDK that includes both jargraal and libgraal. The problem is that Truffle needs jarjvmci but does not need jargraal when libgraal is available. Initializing jargraal in that configuration delays initialization of Truffle (not just Truffle compilation). Additionally, the jargraal instance created will never be used, wasting memory.
>> 
>> The solution in this PR is to make EagerJVMCI only apply when initializing JVMCI on a CompileBroker thread.
>
> Doug Simon 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:
> 
>   only apply EagerJVMCI on a CompileBroker thread

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26768#pullrequestreview-3121062237

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 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 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 dnsimon at openjdk.org  Fri Aug 15 07:36:18 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 15 Aug 2025 07:36:18 GMT
Subject: RFR: 8365468: EagerJVMCI should only apply to the CompilerBroker
 JVMCI runtime [v2]
In-Reply-To: <Gi7-xoBr4YHfF1uO4sffv6c3DueBVB4IjdpeDaIeUuo=.0075f469-1b86-4f35-baa3-cf101f1d90e8@github.com>
References: <bwUCbPxZ6hcpmbeOevzzqDTHyzo1wHFpVYXBV29PwEw=.8eb0cbaa-33ff-4db4-b5fe-6d9516a5271e@github.com>
 <Gi7-xoBr4YHfF1uO4sffv6c3DueBVB4IjdpeDaIeUuo=.0075f469-1b86-4f35-baa3-cf101f1d90e8@github.com>
Message-ID: <5yXPwTpZXpI2TyZWk2ZWfLzhwMxjEXC8ufeEEX5aNc0=.6e34d5ea-4723-4180-949d-58a7d66bb1e5@github.com>

On Wed, 13 Aug 2025 21:48:51 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The primary goal of [JDK-8356447](https://bugs.openjdk.org/browse/JDK-8356447) was to have initialization of the Graal JIT occur in the same phase as the rest of VM startup such that initialization problems are detected and reported prior to executing any user code.
>> 
>> This change caused a performance regression for Truffle when it is used in a JDK that includes both jargraal and libgraal. The problem is that Truffle needs jarjvmci but does not need jargraal when libgraal is available. Initializing jargraal in that configuration delays initialization of Truffle (not just Truffle compilation). Additionally, the jargraal instance created will never be used, wasting memory.
>> 
>> The solution in this PR is to make EagerJVMCI only apply when initializing JVMCI on a CompileBroker thread.
>
> Doug Simon 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:
> 
>   only apply EagerJVMCI on a CompileBroker thread

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26768#issuecomment-3190847699

From dnsimon at openjdk.org  Fri Aug 15 07:39:18 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 15 Aug 2025 07:39:18 GMT
Subject: Integrated: 8365468: EagerJVMCI should only apply to the
 CompilerBroker JVMCI runtime
In-Reply-To: <bwUCbPxZ6hcpmbeOevzzqDTHyzo1wHFpVYXBV29PwEw=.8eb0cbaa-33ff-4db4-b5fe-6d9516a5271e@github.com>
References: <bwUCbPxZ6hcpmbeOevzzqDTHyzo1wHFpVYXBV29PwEw=.8eb0cbaa-33ff-4db4-b5fe-6d9516a5271e@github.com>
Message-ID: <MIKD5Xyc6FiqxLe2Ay-NjAA7b5ctMmOJMYfVEMM-Keo=.e7565f66-e8bb-40d4-a1bf-d51bd8684a8b@github.com>

On Wed, 13 Aug 2025 21:18:45 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The primary goal of [JDK-8356447](https://bugs.openjdk.org/browse/JDK-8356447) was to have initialization of the Graal JIT occur in the same phase as the rest of VM startup such that initialization problems are detected and reported prior to executing any user code.
> 
> This change caused a performance regression for Truffle when it is used in a JDK that includes both jargraal and libgraal. The problem is that Truffle needs jarjvmci but does not need jargraal when libgraal is available. Initializing jargraal in that configuration delays initialization of Truffle (not just Truffle compilation). Additionally, the jargraal instance created will never be used, wasting memory.
> 
> The solution in this PR is to make EagerJVMCI only apply when initializing JVMCI on a CompileBroker thread.

This pull request has now been integrated.

Changeset: e3aeebec
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3aeebec1798b9adbb02e11f285951d4275c52e8
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8365468: EagerJVMCI should only apply to the CompilerBroker JVMCI runtime

Reviewed-by: never

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

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

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 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 asemenov at openjdk.org  Fri Aug 15 12:04:56 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 15 Aug 2025 12:04:56 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
Message-ID: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>

The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.

The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.

According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

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

Commit messages:
 - The same issue is present in src/hotspot/share/runtime/continuationFreezeThaw.cpp FreezeBase::finalize_freeze()
 - The same issue is present in src/hotspot/share/jvmci/jvmciEnv.cpp JVMCICompileState::JVMCICompileState()
 - The same issue is present in src/hotspot/share/c1/c1_LinearScan.cpp Interval::split()
 - The same issue is present in src/hotspot/share/nmt/mallocSiteTable.cpp MallocSiteTable::malloc_site()
 - The same issue is present in src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp JfrThreadSampler::set_period()
 - The same issue is present in src/hotspot/share/opto/vectorIntrinsics.cpp LibraryCallKit::inline_vector_gather_scatter()
 - 8365604 Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()

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

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

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 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 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 mgronlun at openjdk.org  Mon Aug 18 18:12:13 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 18:12:13 GMT
Subject: RFR: 8365071: ARM32: JFR intrinsic jvm_commit triggers C2 regalloc
 assert
In-Reply-To: <6MHwDW0E9bOzpj5B3pzlNmOCRPtFtnrk55NmTTxbhLM=.f0026c26-2c80-4766-8984-da9f34a31c8d@github.com>
References: <6MHwDW0E9bOzpj5B3pzlNmOCRPtFtnrk55NmTTxbhLM=.f0026c26-2c80-4766-8984-da9f34a31c8d@github.com>
Message-ID: <J5L4ETkMbnHdZVqlZBDhUkrnrQS3ZXfG-sxujSkWOFQ=.038da6b3-7c08-4534-ab49-e69e532ad4dd@github.com>

On Fri, 8 Aug 2025 01:54:46 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> On 32-bit ARM, the jvm_commit JFR intrinsic builder feeds null (RegP) into a TypeLong Phi, causing mixed long/pointer register sizing and triggering the C2 register allocator assert(_num_regs == reg || !_num_regs).
> 
> The fix is trivial: use an appropriate ConL constant instead. This has no effect on 64-bit systems (the generated assembly is identical) but resolves a JFR issue on 32-bit systems.

Looks good.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26684#pullrequestreview-3129401730

From bulasevich at openjdk.org  Tue Aug 19 04:43:48 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 19 Aug 2025 04:43:48 GMT
Subject: RFR: 8365071: ARM32: JFR intrinsic jvm_commit triggers C2 regalloc
 assert
In-Reply-To: <6MHwDW0E9bOzpj5B3pzlNmOCRPtFtnrk55NmTTxbhLM=.f0026c26-2c80-4766-8984-da9f34a31c8d@github.com>
References: <6MHwDW0E9bOzpj5B3pzlNmOCRPtFtnrk55NmTTxbhLM=.f0026c26-2c80-4766-8984-da9f34a31c8d@github.com>
Message-ID: <RwM7UNpaYnoZFRn4ikURxeB-y_-e3puWAimTy4-aGrc=.bf81d1fa-deeb-42b9-ab87-836ebc995294@github.com>

On Fri, 8 Aug 2025 01:54:46 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> On 32-bit ARM, the jvm_commit JFR intrinsic builder feeds null (RegP) into a TypeLong Phi, causing mixed long/pointer register sizing and triggering the C2 register allocator assert(_num_regs == reg || !_num_regs).
> 
> The fix is trivial: use an appropriate ConL constant instead. This has no effect on 64-bit systems (the generated assembly is identical) but resolves a JFR issue on 32-bit systems.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26684#issuecomment-3199179245

From bulasevich at openjdk.org  Tue Aug 19 04:43:49 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 19 Aug 2025 04:43:49 GMT
Subject: Integrated: 8365071: ARM32: JFR intrinsic jvm_commit triggers C2
 regalloc assert
In-Reply-To: <6MHwDW0E9bOzpj5B3pzlNmOCRPtFtnrk55NmTTxbhLM=.f0026c26-2c80-4766-8984-da9f34a31c8d@github.com>
References: <6MHwDW0E9bOzpj5B3pzlNmOCRPtFtnrk55NmTTxbhLM=.f0026c26-2c80-4766-8984-da9f34a31c8d@github.com>
Message-ID: <r8QuGIznjmc9m8IWq9sSBU0idzZ2qMcwHX8PzzeQOu0=.c64299ae-987b-4110-9fda-c8a7d17775f1@github.com>

On Fri, 8 Aug 2025 01:54:46 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> On 32-bit ARM, the jvm_commit JFR intrinsic builder feeds null (RegP) into a TypeLong Phi, causing mixed long/pointer register sizing and triggering the C2 register allocator assert(_num_regs == reg || !_num_regs).
> 
> The fix is trivial: use an appropriate ConL constant instead. This has no effect on 64-bit systems (the generated assembly is identical) but resolves a JFR issue on 32-bit systems.

This pull request has now been integrated.

Changeset: f2f7a490
Author:    Boris Ulasevich <bulasevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f2f7a490c091734ae1aa6cd402a117acbc1c699e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8365071: ARM32: JFR intrinsic jvm_commit triggers C2 regalloc assert

Reviewed-by: mgronlun

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

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

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 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 dholmes at openjdk.org  Tue Aug 19 21:41:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 21:41:42 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>
References: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>
Message-ID: <0DEFfBCDPJsd5_MXkS5Uo1gAI-SYfnhKtnomWrC4G4I=.d8e4efe9-ce78-48bf-9df4-e75b0a1ffbc1@github.com>

On Fri, 25 Jul 2025 01:40:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> EDIT: I've just realized that the `[[nodiscard]]` attribute is not currently permitted. So I may have to revise this aspect of the changes.
> 
> This is a proposal to standardize on the use of os::snprintf and os::snprintf_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of jio_printf at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf...

I am replacing this PR with a refreshed one.

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

PR Comment: https://git.openjdk.org/jdk/pull/26470#issuecomment-3202320187

From dholmes at openjdk.org  Tue Aug 19 21:41:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 21:41:43 GMT
Subject: Withdrawn: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>
References: <Kql5HjvUDMYZKYKdv6J7obxic6laB5aDPMNkXk0n8rg=.0b97fec1-2dd8-4692-8310-cff4e34b3009@github.com>
Message-ID: <Jc0qJTFY71x04QWXkZUCUfZme4CHC0ka9Ydok_uAhvc=.8f2ad11f-20e7-4e0f-a7f1-b34c4fff2728@github.com>

On Fri, 25 Jul 2025 01:40:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> EDIT: I've just realized that the `[[nodiscard]]` attribute is not currently permitted. So I may have to revise this aspect of the changes.
> 
> This is a proposal to standardize on the use of os::snprintf and os::snprintf_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of jio_printf at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf...

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Tue Aug 19 22:09:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 22:09:19 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
Message-ID: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>

This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)

From: https://bugs.openjdk.org/browse/JDK-8347707

The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.

To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.

The potential errors are, generally speaking, not something we should encounter in our own well-written code:

- encoding error: not applicable as we are not using extended character sets
- invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
- mal-formed formatting directives
- overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).

As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.

The potential clients of this API then fall into a number of camps:

1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.

For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.

2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.

For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.

3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.

These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.

4. Those who present a buffer but know that truncation is a possibility, and either need to handle it themselves, or else need to use the return value in subsequent operations.

These clients are also directed to use `os::snprintf`.

In summary we provide the following API:
- `[[nodiscard]] int os::vsnprintf` is the building block for the other methods, it:
  - asserts on precondition failures
  - asserts on error
  - guarantees null-termination in the case of unexpected errors (as the standards are still unclear on that point
  - is declared `[[nodiscard[]]` so that callers cannot ignore the return value (they can explicitly cast to `void` to indicate they don't need it)
- `void os::snprintf_checked`
  - calls `os::vnsprintf`` so asserts on errors
  - asserts on truncation
- `[[nodiscard]] int os::snprintf`
  - calls `os::vnsprintf` so asserts on errors

In terms of the effects on the existing code we:
- Change callers of `::snprintf`/`os::snprintf` that ignore the return value and ensure the buffer is large enough to use `os::snprintf_checked`
  - those that allow truncation to happen must use `os::snprintf`.
- Change all callers of `::snprintf`/`os::snprintf` that use the return value to use `os::snprintf`, plus any additional assertions needed
- Change the 9 callers of `os::snprintf_checked` that do use the return value, to use `os::snprintf` with their own assertions added
- Callers of `os::vnsprintf` are adjusted as needed

The PR  is comprising multiple dependent commits so that you can view things in stages.  There are 46 modified files. The bulk of the changes replace calls to `snprintf`/`os::snprintf` with calls to `os::snprintf_checked`.

Note the use of `[[nodiscard]]` is permitted but not yet documented as such in the style-guide.

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

Commit messages:
 - Merge
 - Make os::snprintf "nodiscard" and adjust final callsites
 - Convert os::snprintf() to os::snprintf_checked() where appropriate.
 - Forbid C library snprintf
 - Change return-value using snprintf to explicit os::snprintf
 - Change raw snprintf to os::snprintf_checked, whereever truncation would not
 - Change os::snprintf_checked to be void function.
 - Mark os::vsnprintf as nodiscard and update the callsites.

Changes: https://git.openjdk.org/jdk/pull/26849/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26849&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347707
  Stats: 195 lines in 46 files changed: 14 ins; 5 del; 176 mod
  Patch: https://git.openjdk.org/jdk/pull/26849.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26849/head:pull/26849

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

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 dholmes at openjdk.org  Wed Aug 20 12:28:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:28:38 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

Some alignment nits where you have added additional condition clauses.

Some of these are difficult to evaluate in isolation and will need review from the specific component areas.

src/hotspot/share/adlc/output_h.cpp line 1952:

> 1950:     }*/
> 1951:     else if( instr->is_ideal_copy() &&
> 1952:     (instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr) &&

Suggestion:

            (instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr) &&

src/hotspot/share/c1/c1_LinearScan.cpp line 4422:

> 4420: 
> 4421:   if ((cur != nullptr) &&
> 4422:   (cur->from() < split_pos)) {

Suggestion:

      (cur->from() < split_pos)) {

src/hotspot/share/nmt/mallocSiteTable.cpp line 172:

> 170:        index < pos_idx && head != nullptr;
> 171:        index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head :
> 172:       (MallocSiteHashtableEntry*)head->next()) {}

This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1319:

> 1317:     log_if_needed("  ** not supported: arity=%d op=%s vlen=%d etype=%s atype=%s ismask=no",
> 1318:                     is_scatter, is_scatter ? "scatter" : "gather",
> 1319:                     num_elem, type2name(elem_bt), type2name(arr_type->elem()->array_element_basic_type()));

There is  a bug here but I'm not sure it is what you think it is.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26798#pullrequestreview-3136325292
PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287976814
PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287984002
PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287993050
PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287996530

From dholmes at openjdk.org  Wed Aug 20 12:32:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:32:42 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <O_bhdRkPTNNPMh-njv0iY0vTStYNWjOclqPxxfX4elg=.8a79282a-c985-442b-a105-f178852e60d5@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

I've added some additional mailing lists to ensure better coverage here.

Also I think you need to update the JBS (and PR) title to reflect the broader scope of the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3206112684

From adinn at openjdk.org  Wed Aug 20 14:22:37 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 20 Aug 2025 14:22:37 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <mm_qPZgVNqoihxb53bJCzsnvmNg15xdfOr6tj3FcVvA=.cf3562a5-a2bf-4c6f-8250-fa07f2939143@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

I'm not clear that the original issue is necessarily a bug that needs fixing with a skip to the next else if case.

The justification for adding `instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr` to the if branch test is that earlier code allows for the possibility that `instr->_matrule` might be null. However, that check is performed in an unconditional context for any value of `instr` whereas this specific else branch limits the circumstance to the case where `instr->is_ideal_copy()` is found to be true.

So, the prior test offers no guarantee that in this restricted case a null pointer should or should not be possible. The original design may assume that a successful test for `instr->is_ideal_copy()` ought to guarantee that both `instr->_matrule` and `instr->_matrule->_rChild` are non-null. That cannot be determined by the evidence offered. It can only be determined by looking at how instr is constructed.

So, rather than just skip to the next case we might need to handle this with an assert and fix whatever code is producing an ideal copy with null fields.

Given the level of analysis offered for this case I am suspicious as to whether the other cases tacked onto this issue ought to be accepted at face value without some justification as to why a null check and skip to the next case is correct.

I'm also wondering how and why all these cases and associated amendments were arrived at? Is this perhaps based on output from a code analysis tool (perhaps even a genAI tool). If so then I think 1) we ought to be told and 2) we ought to treat its recommendations with a very healthy dose of skepticism.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3206613521

From kbarrett at openjdk.org  Wed Aug 20 20:19:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 20 Aug 2025 20:19:39 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

I noticed there are a number of calls with `buflen - 1`. Probably from the bad
old days when some snprintf variants didn't guarantee null termination. I
didn't see forced null terminations for the few I spot-checked though, and
it's not obvious in some cases that the final byte is certain to be null going
in. Nothing to be done about that here, but there might be some following
cleanup work called for.

src/hotspot/os/linux/os_linux.cpp line 4801:

> 4799:     char buf [16]; // according to glibc manpage, 16 chars incl. '/0'
> 4800:     (void) os::snprintf(buf, sizeof(buf), "%s", name);
> 4801:     buf[sizeof(buf) - 1] = '\0';

pre-existing.  Adding null termination at the end hasn't been needed for a while. There are probably
others like this that can be deferred to following cleanup.

src/hotspot/os/posix/attachListener_posix.cpp line 351:

> 349:   int n = os::snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d",
> 350:                        os::get_temp_directory(), os::current_process_id());
> 351:   assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow");

I don't see any other uses of `n` besides this assert. Maybe this should be using `os::snprintf_checked`?

src/hotspot/share/opto/idealGraphPrinter.cpp line 644:

> 642:         // Only use up to 4 chars and fall back to a generic "I" to keep it short.
> 643:         int written_chars = os::snprintf(buffer, sizeof(buffer), "%d", value);
> 644:         if (written_chars > 0 && written_chars <= 4) {

I don't understand the addition of `written_chars > 0` here and line 658?

src/hotspot/share/runtime/os.hpp line 810:

> 808:   // Performs vsnprintf and asserts the result is non-negative (so there was not
> 809:   // an encoding error or any other kind of usage error).
> 810:   [[nodiscard]] static int vsnprintf(char* buf, size_t len, const char* fmt, va_list args) ATTRIBUTE_PRINTF(3, 0);

Consider moving the `ATTRIBUTE_PRINTF` to the front so all the attributes are together?
And maybe a line break between the attributes and the signature, just to avoid pushing the
signature way over to the right.

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

PR Review: https://git.openjdk.org/jdk/pull/26849#pullrequestreview-3138069291
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289177595
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289182600
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289195737
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289201763

From dlong at openjdk.org  Wed Aug 20 21:23:36 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 20 Aug 2025 21:23:36 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <PbADd4u7EmBU7pjkN6wcPdHJIXqr2eXsCEm2dDtrAXA=.494b3350-9371-4486-987b-bf25b9abb011@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

Could we map snprintf to os::snprintf_checked with a macro or some kind of namespace magic?  It would reduce the number of files changed and catch any new cases of snprintf that might get accidentally added in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3208122700

From dlong at openjdk.org  Wed Aug 20 21:55:36 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 20 Aug 2025 21:55:36 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <Hmt3c2mNVEianKx4WIVhs9MHNM1j7BrcdvlGt7I_yyQ=.c57aef4e-efe7-405b-8e84-84004ae7979a@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 727:

> 725: 
> 726:   int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 ");
> 727:   get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len);

Suggestion:

  int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 ");
  if (desc_len < CPU_DETAILED_DESC_BUF_SIZE) {
    get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len);
  }

If there is truncation, _cpu_desc + desc_len will be past the end of the buffer and CPU_DETAILED_DESC_BUF_SIZE - desc_len will be negative in get_compatible_board(), which will cause problems when converted to size_t.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289384784

From dlong at openjdk.org  Wed Aug 20 22:24:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 20 Aug 2025 22:24:58 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

src/hotspot/os/aix/attachListener_aix.cpp line 423:

> 421:     log_trace(attach)("Failed to find attach file: %s, trying alternate", fn);
> 422:     os::snprintf_checked(fn, sizeof(fn), "%s/.attach_pid%d",
> 423:                          os::get_temp_directory(), os::current_process_id());

This could fail if os::get_temp_directory() returns an extremely long path.  How about doing a truncation check like at line 354?

src/hotspot/os/aix/os_aix.cpp line 1055:

> 1053:     if (ebuf != nullptr && ebuflen > 0) {
> 1054:       os::snprintf_checked(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
> 1055:                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);

Suggestion:

      (void) os::snprintf(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
                           filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);

This could easily truncate, based on LIBPATH and LD_LIBRARY_PATH.

src/hotspot/os/aix/os_aix.cpp line 1097:

> 1095:   struct utsname name;
> 1096:   uname(&name);
> 1097:   os::snprintf_checked(buf, buflen, "%s %s", name.release, name.version);

Suggestion:

  (void) os::snprintf(buf, buflen, "%s %s", name.release, name.version);

src/hotspot/os/aix/porting_aix.cpp line 939:

> 937:   // retrieve the path to the currently running executable binary
> 938:   // to open it
> 939:   os::snprintf_checked(buffer, 100, "/proc/%ld/object/a.out", (long)getpid());

Suggestion:

  os::snprintf_checked(buffer, sizeof(buffer), "/proc/%ld/object/a.out", (long)getpid());

src/hotspot/os/aix/porting_aix.cpp line 1157:

> 1155:       }
> 1156:       if (ebuf != nullptr && ebuflen > 0) {
> 1157:         os::snprintf_checked(ebuf, ebuflen - 1, "%s", error_report);

Suggestion:

        (void) os::snprintf(ebuf, ebuflen - 1, "%s", error_report);

src/hotspot/share/gc/shared/satbMarkQueue.cpp line 324:

> 322: 
> 323:     virtual void do_thread(Thread* t) {
> 324:       os::snprintf_checked(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());

Suggestion:

      (void) os::snprintf(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());

Can this be a JavaThread with an arbitrarily long name()?

src/hotspot/share/utilities/virtualizationSupport.cpp line 76:

> 74:     if (sg_error == VMGUESTLIB_ERROR_SUCCESS) {
> 75:       has_host_information = true;
> 76:       os::snprintf_checked(host_information, sizeof(host_information), "%s", result_info);

Are these two guaranteed not to overflow/truncate?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289418676
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289425021
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289426575
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289429123
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289430247
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289397586
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289406269

From dlong at openjdk.org  Wed Aug 20 23:02:51 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 20 Aug 2025 23:02:51 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <7bUyzA85sBzPhzJMPaLcMflpd4QPUUXBy5z0A7gNbnE=.335d09e8-d7fc-4381-b77e-71c2636748d1@github.com>

On Wed, 20 Aug 2025 22:13:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/os/aix/attachListener_aix.cpp line 423:
> 
>> 421:     log_trace(attach)("Failed to find attach file: %s, trying alternate", fn);
>> 422:     os::snprintf_checked(fn, sizeof(fn), "%s/.attach_pid%d",
>> 423:                          os::get_temp_directory(), os::current_process_id());
> 
> This could fail if os::get_temp_directory() returns an extremely long path.  How about doing a truncation check like at line 354?

Nevermind, same thing.  We would need to fix a lot of code if os::get_temp_directory() returned a pathologically long string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289472350

From dholmes at openjdk.org  Thu Aug 21 05:37:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 05:37:52 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
Message-ID: <6mwFNPgecEzR5PYjXk61WNnz3KrKFIgiRhBxUy5W4H4=.846ebbef-9b26-47e2-937e-5be9c4bfe3b4@github.com>

On Wed, 20 Aug 2025 20:03:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/os/linux/os_linux.cpp line 4801:
> 
>> 4799:     char buf [16]; // according to glibc manpage, 16 chars incl. '/0'
>> 4800:     (void) os::snprintf(buf, sizeof(buf), "%s", name);
>> 4801:     buf[sizeof(buf) - 1] = '\0';
> 
> pre-existing.  Adding null termination at the end hasn't been needed for a while. There are probably
> others like this that can be deferred to following cleanup.

Okay I have filed [JDK-8365896](https://bugs.openjdk.org/browse/JDK-8365896) to clean this up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289902515

From dholmes at openjdk.org  Thu Aug 21 05:40:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 05:40:51 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
Message-ID: <vuvqkzwTfev5-30GKomtO_uU9FA5LOc-3WmtyxHM_Gs=.5e747bfa-d109-4b70-8cc6-15aeed4794b7@github.com>

On Wed, 20 Aug 2025 20:05:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/os/posix/attachListener_posix.cpp line 351:
> 
>> 349:   int n = os::snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d",
>> 350:                        os::get_temp_directory(), os::current_process_id());
>> 351:   assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow");
> 
> I don't see any other uses of `n` besides this assert. Maybe this should be using `os::snprintf_checked`?

Agreed - changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289906758

From dholmes at openjdk.org  Thu Aug 21 05:45:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 05:45:52 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
Message-ID: <chK5pTh1EuC4GUMm1fyr4GV_HS6HWkPQ1mDvQqU1280=.3808e7b1-953e-495d-b246-63f217186fcd@github.com>

On Wed, 20 Aug 2025 20:12:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/share/opto/idealGraphPrinter.cpp line 644:
> 
>> 642:         // Only use up to 4 chars and fall back to a generic "I" to keep it short.
>> 643:         int written_chars = os::snprintf(buffer, sizeof(buffer), "%d", value);
>> 644:         if (written_chars > 0 && written_chars <= 4) {
> 
> I don't understand the addition of `written_chars > 0` here and line 658?

Well in theory, in a release build, `os::snprintf` could return -1 and I didn't want any static analysis tools pointing this out to me later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289912608

From dholmes at openjdk.org  Thu Aug 21 06:00:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:00:51 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <PbADd4u7EmBU7pjkN6wcPdHJIXqr2eXsCEm2dDtrAXA=.494b3350-9371-4486-987b-bf25b9abb011@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <PbADd4u7EmBU7pjkN6wcPdHJIXqr2eXsCEm2dDtrAXA=.494b3350-9371-4486-987b-bf25b9abb011@github.com>
Message-ID: <kRbYl_y9DmuZDKgwra2hz2RRlk0FnVXRSg2N2Fchtng=.a3c139d6-e68e-466f-a269-70be79c81c39@github.com>

On Wed, 20 Aug 2025 21:20:50 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> Could we map snprintf to os::snprintf_checked with a macro or some kind of namespace magic?  It would reduce the number of files changed and catch any new cases of snprintf that might get accidentally added in the future.

Thanks for looking at this @dean-long !

> Could we map snprintf to os::snprintf_checked with a macro or some kind of namespace magic? It would reduce the number of files changed and catch any new cases of snprintf that might get accidentally added in the future.

Raw `snprintf` is now prohibited so no future accidental additions are possible. I don't think hiding the fact we are not using the library `snprintf` is a good thing either.

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3209102280

From dholmes at openjdk.org  Thu Aug 21 06:06:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:06:52 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <Hmt3c2mNVEianKx4WIVhs9MHNM1j7BrcdvlGt7I_yyQ=.c57aef4e-efe7-405b-8e84-84004ae7979a@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <Hmt3c2mNVEianKx4WIVhs9MHNM1j7BrcdvlGt7I_yyQ=.c57aef4e-efe7-405b-8e84-84004ae7979a@github.com>
Message-ID: <uV3sVWzxe7N1AhvxVk8XeT5kwwfZhq1mmiezaqHAvG8=.da944b8c-21ea-4861-9b69-d27a51d965c5@github.com>

On Wed, 20 Aug 2025 21:53:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 727:
> 
>> 725: 
>> 726:   int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 ");
>> 727:   get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len);
> 
> Suggestion:
> 
>   int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 ");
>   if (desc_len < CPU_DETAILED_DESC_BUF_SIZE) {
>     get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len);
>   }
> 
> If there is truncation, _cpu_desc + desc_len will be past the end of the buffer and CPU_DETAILED_DESC_BUF_SIZE - desc_len will be negative in get_compatible_board(), which will cause problems when converted to size_t.

There cannot be truncation here. We are writing a fixed-size string of 8 characters (plus nul-terminator) to a buffer of size 4096.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289943417

From dholmes at openjdk.org  Thu Aug 21 06:25:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:25:52 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <M4J7UWfsMdIrOZTjEbPBGCeE6SyxG9tTgzgDUVkuRC8=.44e4e513-a139-4c2b-9465-c6c26b745b7c@github.com>

On Wed, 20 Aug 2025 21:59:17 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/share/gc/shared/satbMarkQueue.cpp line 324:
> 
>> 322: 
>> 323:     virtual void do_thread(Thread* t) {
>> 324:       os::snprintf_checked(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());
> 
> Suggestion:
> 
>       (void) os::snprintf(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());
> 
> Can this be a JavaThread with an arbitrarily long name()?

Yes it could - thanks. It is likely enough that we could hit this during testing that asserting if it happens is not really useful. Long Java thread names are not necessarily errors to be fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289969498

From dholmes at openjdk.org  Thu Aug 21 06:25:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:25:53 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <M4J7UWfsMdIrOZTjEbPBGCeE6SyxG9tTgzgDUVkuRC8=.44e4e513-a139-4c2b-9465-c6c26b745b7c@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
 <M4J7UWfsMdIrOZTjEbPBGCeE6SyxG9tTgzgDUVkuRC8=.44e4e513-a139-4c2b-9465-c6c26b745b7c@github.com>
Message-ID: <y2oW-0shWVXbE05RROhwYMHtfXOXb-AO_0ksRP1b3Ss=.3640272c-0273-4751-b3c3-221e22561f19@github.com>

On Thu, 21 Aug 2025 06:21:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/satbMarkQueue.cpp line 324:
>> 
>>> 322: 
>>> 323:     virtual void do_thread(Thread* t) {
>>> 324:       os::snprintf_checked(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());
>> 
>> Suggestion:
>> 
>>       (void) os::snprintf(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name());
>> 
>> Can this be a JavaThread with an arbitrarily long name()?
>
> Yes it could - thanks. It is likely enough that we could hit this during testing that asserting if it happens is not really useful. Long Java thread names are not necessarily errors to be fixed.

In addition, if we were to hit such a name we are not likely to increase the buffer size just for this extreme case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289973406

From dholmes at openjdk.org  Thu Aug 21 06:28:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:28:56 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <6JAI2s1fJRYWYXtcyA_b2Bhn_7_GGAc67YuAFoGUrso=.55792b10-d6c0-4625-84b2-953ace2cf039@github.com>

On Wed, 20 Aug 2025 22:05:10 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/share/utilities/virtualizationSupport.cpp line 76:
> 
>> 74:     if (sg_error == VMGUESTLIB_ERROR_SUCCESS) {
>> 75:       has_host_information = true;
>> 76:       os::snprintf_checked(host_information, sizeof(host_information), "%s", result_info);
> 
> Are these two guaranteed not to overflow/truncate?

The issue is not whether they can overflow, but if they do is it something we want to detect during testing so we can take action - e.g. by increasing the buffer size. This is very subjective, but my initial position in most cases has been yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289978047

From dholmes at openjdk.org  Thu Aug 21 06:33:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:33:51 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7bUyzA85sBzPhzJMPaLcMflpd4QPUUXBy5z0A7gNbnE=.335d09e8-d7fc-4381-b77e-71c2636748d1@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
 <7bUyzA85sBzPhzJMPaLcMflpd4QPUUXBy5z0A7gNbnE=.335d09e8-d7fc-4381-b77e-71c2636748d1@github.com>
Message-ID: <5WIH7DnsEDDENhwj3xVo2Y7Qq6g7ULcdkoGnJWAlZZE=.09e34d8a-048d-4e01-9ada-d0fd54ff6ee4@github.com>

On Wed, 20 Aug 2025 22:59:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/os/aix/attachListener_aix.cpp line 423:
>> 
>>> 421:     log_trace(attach)("Failed to find attach file: %s, trying alternate", fn);
>>> 422:     os::snprintf_checked(fn, sizeof(fn), "%s/.attach_pid%d",
>>> 423:                          os::get_temp_directory(), os::current_process_id());
>> 
>> This could fail if os::get_temp_directory() returns an extremely long path.  How about doing a truncation check like at line 354?
>
> Nevermind, same thing.  We would need to fix a lot of code if os::get_temp_directory() returned a pathologically long string.

I've changed line 352 as per Kim's comment above because `snprintf` followed by an assert for truncation is what `snprintf_checked` does.

Again the question to ask is: if we hit this during testing do we think it indicates we need to increase the buffer size. Again I am initially in the yes camp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289987176

From dholmes at openjdk.org  Thu Aug 21 06:38:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:38:55 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <idaZ8CjLSYTU2tp0vkAjZ080E3dWoqPxKVIH8Obw9yk=.89f5598c-8591-4bf0-9d51-88151051c608@github.com>

On Wed, 20 Aug 2025 22:18:28 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/os/aix/os_aix.cpp line 1055:
> 
>> 1053:     if (ebuf != nullptr && ebuflen > 0) {
>> 1054:       os::snprintf_checked(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
>> 1055:                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);
> 
> Suggestion:
> 
>       (void) os::snprintf(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
>                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);
> 
> This could easily truncate, based on LIBPATH and LD_LIBRARY_PATH.

Yes but again if that happens during testing we need to know and fix the buffer size to get the non-truncated values.

> src/hotspot/os/aix/os_aix.cpp line 1097:
> 
>> 1095:   struct utsname name;
>> 1096:   uname(&name);
>> 1097:   os::snprintf_checked(buf, buflen, "%s %s", name.release, name.version);
> 
> Suggestion:
> 
>   (void) os::snprintf(buf, buflen, "%s %s", name.release, name.version);

See previous replies.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289995061
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289996137

From dholmes at openjdk.org  Thu Aug 21 06:38:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:38:56 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
Message-ID: <9ON1pRJ6eZcRYoDahh1w2hCT95YZS9Z_2ORMj-laVZs=.aabd607e-72a7-4c6b-a2b6-8475feff4d41@github.com>

On Wed, 20 Aug 2025 20:15:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> src/hotspot/share/runtime/os.hpp line 810:
> 
>> 808:   // Performs vsnprintf and asserts the result is non-negative (so there was not
>> 809:   // an encoding error or any other kind of usage error).
>> 810:   [[nodiscard]] static int vsnprintf(char* buf, size_t len, const char* fmt, va_list args) ATTRIBUTE_PRINTF(3, 0);
> 
> Consider moving the `ATTRIBUTE_PRINTF` to the front so all the attributes are together?
> And maybe a line break between the attributes and the signature, just to avoid pushing the
> signature way over to the right.

I have done that and placed each attribute on its own line (we should have a style guide entry for this :) ). But I note that all the other ATTRIBUTE_PRINTF's are placed after the function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289993291

From dholmes at openjdk.org  Thu Aug 21 06:46:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:46:03 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

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

  Reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26849/files
  - new: https://git.openjdk.org/jdk/pull/26849/files/2de6ac98..38003a22

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

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

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

From dholmes at openjdk.org  Thu Aug 21 06:46:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 06:46:05 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
Message-ID: <4UAB8nFSiBclUHIOuDsRkEpX_ZUma9yvK11iRkMOTtM=.4f9402f4-7f44-4f6e-a854-6e2313c412c9@github.com>

On Wed, 20 Aug 2025 22:21:45 GMT, Dean Long <dlong at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reviewer feedback
>
> src/hotspot/os/aix/porting_aix.cpp line 939:
> 
>> 937:   // retrieve the path to the currently running executable binary
>> 938:   // to open it
>> 939:   os::snprintf_checked(buffer, 100, "/proc/%ld/object/a.out", (long)getpid());
> 
> Suggestion:
> 
>   os::snprintf_checked(buffer, sizeof(buffer), "/proc/%ld/object/a.out", (long)getpid());

It doesn't really matter as we only need at most 30 bytes.

> src/hotspot/os/aix/porting_aix.cpp line 1157:
> 
>> 1155:       }
>> 1156:       if (ebuf != nullptr && ebuflen > 0) {
>> 1157:         os::snprintf_checked(ebuf, ebuflen - 1, "%s", error_report);
> 
> Suggestion:
> 
>         (void) os::snprintf(ebuf, ebuflen - 1, "%s", error_report);

See previous replies.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290002985
PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290003771

From dlong at openjdk.org  Thu Aug 21 07:48:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 21 Aug 2025 07:48:57 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <idaZ8CjLSYTU2tp0vkAjZ080E3dWoqPxKVIH8Obw9yk=.89f5598c-8591-4bf0-9d51-88151051c608@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
 <idaZ8CjLSYTU2tp0vkAjZ080E3dWoqPxKVIH8Obw9yk=.89f5598c-8591-4bf0-9d51-88151051c608@github.com>
Message-ID: <qqr1wCRNhu-dnJWGmqNiJpokOR6i23eHaH84qRjNFBw=.0cf37006-2bb8-4509-99c1-3b0db4ed39f0@github.com>

On Thu, 21 Aug 2025 06:35:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/aix/os_aix.cpp line 1055:
>> 
>>> 1053:     if (ebuf != nullptr && ebuflen > 0) {
>>> 1054:       os::snprintf_checked(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
>>> 1055:                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);
>> 
>> Suggestion:
>> 
>>       (void) os::snprintf(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s",
>>                            filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report);
>> 
>> This could easily truncate, based on LIBPATH and LD_LIBRARY_PATH.
>
> Yes but again if that happens during testing we need to know and fix the buffer size to get the non-truncated values.

In this case the buffer size comes from shared code.  Whatever size we choose for the static buffer, we can trigger the assert by setting LIBPATH and LD_LIBRARY_PATH to very long strings.  This is just the error message, so it might be OK to truncate it.  Otherwise we could need to allocate the buffer using malloc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290181959

From asemenov at openjdk.org  Thu Aug 21 09:01:12 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 09:01:12 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/c1/c1_LinearScan.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/adlc/output_h.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26798/files
  - new: https://git.openjdk.org/jdk/pull/26798/files/80777ced..dd21148b

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

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

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

From asemenov at openjdk.org  Thu Aug 21 09:11:53 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 09:11:53 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
Message-ID: <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>

On Wed, 20 Aug 2025 12:20:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/adlc/output_h.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/nmt/mallocSiteTable.cpp line 172:
> 
>> 170:        index < pos_idx && head != nullptr;
>> 171:        index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head :
>> 172:       (MallocSiteHashtableEntry*)head->next()) {}
> 
> This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null.

A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290418847

From adinn at openjdk.org  Thu Aug 21 10:01:59 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 10:01:59 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
Message-ID: <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>

On Thu, 21 Aug 2025 09:08:58 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> src/hotspot/share/nmt/mallocSiteTable.cpp line 172:
>> 
>>> 170:        index < pos_idx && head != nullptr;
>>> 171:        index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head :
>>> 172:       (MallocSiteHashtableEntry*)head->next()) {}
>> 
>> This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null.
>
> A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error

Hmm, is it possible?

Perhaps you could explain how pos_idx is being used in this loop to guard against that happening and why that does not make this safe?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290543955

From adinn at openjdk.org  Thu Aug 21 10:17:56 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 10:17:56 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
Message-ID: <t1IN7M1W44RGuPkysGDxmmdmADmc6lFc0R11i4dKrcI=.de45ee4c-9a8d-436a-80e2-2d6224bf3ad0@github.com>

On Thu, 21 Aug 2025 09:01:12 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
>> 
>> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.
>
> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/adlc/output_h.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

n.b. Before accepting any of the changes in this PR I'd really like to know whether they have arisen from reports of an actual null pointer dereference or they are simply derived from some theoretical analysis. In the latter case then I think we would need a better explanation of why an error can happen than we have seen so far. Given that requirement I also think each of the changes should be submitted in its own PR with its own justification. We should not modify control flow logic on the nod.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3209906082

From asemenov at openjdk.org  Thu Aug 21 10:34:03 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 10:34:03 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <O_bhdRkPTNNPMh-njv0iY0vTStYNWjOclqPxxfX4elg=.8a79282a-c985-442b-a105-f178852e60d5@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <O_bhdRkPTNNPMh-njv0iY0vTStYNWjOclqPxxfX4elg=.8a79282a-c985-442b-a105-f178852e60d5@github.com>
Message-ID: <sFP5T-Udewsb3RPw1JazXkAEFMWbtqADYzq-2VTyaAE=.e757c87b-1eb3-4bc0-8a0d-a76ff6a3a9ad@github.com>

On Wed, 20 Aug 2025 12:29:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I've added some additional mailing lists to ensure better coverage here.
> 
> Also I think you need to update the JBS (and PR) title to reflect the broader scope of the changes.

Please provide an example of an updated title?

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3209975632

From asemenov at openjdk.org  Thu Aug 21 10:34:04 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 10:34:04 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
Message-ID: <MQRWuZVpXil3heDuvAQ5rXpMeTvYPUr0dUfO_Vv35oo=.688e7cea-48e5-425a-ab7c-4e6a6e8f202a@github.com>

On Wed, 20 Aug 2025 12:22:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/adlc/output_h.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1319:
> 
>> 1317:     log_if_needed("  ** not supported: arity=%d op=%s vlen=%d etype=%s atype=%s ismask=no",
>> 1318:                     is_scatter, is_scatter ? "scatter" : "gather",
>> 1319:                     num_elem, type2name(elem_bt), type2name(arr_type->elem()->array_element_basic_type()));
> 
> There is  a bug here but I'm not sure it is what you think it is.

```addr_type->isa_aryptr();``` might return nullptr, while in ```elem_consistent_with_arr(elem_bt, arr_type, false)```, arr_type is only checked with an assert.
Moreover, the presence of a check in the original version indicates that arr_type can be null, and there is no protection against this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290615638

From asemenov at openjdk.org  Thu Aug 21 11:11:56 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 11:11:56 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
Message-ID: <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>

On Thu, 21 Aug 2025 09:59:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error
>
> Hmm, is it possible?
> 
> Perhaps you could explain how pos_idx is being used in this loop to guard against that happening and why that does not make this safe?

```head->next()``` returns a pointer to _next without any checks.

In turn, the _next pointer is marked as volatile, which means it can be modified at any moment, for example, in another thread.

>From this, I conclude that a check in this location is desirable. Moreover, pos_idx is also not being checked. It is quite possible that ```head->next()``` could turn out to be nullptr.

But I don?t mind. If you are sure that there can?t be a nullptr in this place, I will withdraw this patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290701959

From adinn at openjdk.org  Thu Aug 21 12:11:53 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 12:11:53 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
Message-ID: <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>

On Thu, 21 Aug 2025 11:09:12 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Moreover, pos_idx is also not being checked

I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test.

The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference  here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so.

n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290852355

From kbarrett at openjdk.org  Thu Aug 21 12:23:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 21 Aug 2025 12:23:55 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
Message-ID: <uGR1xhnP0aLT8_PuXtleC9aT0y3JiFclC0YXtYo1LK0=.fcc6460a-b5e7-4c05-81a0-81e3e0896886@github.com>

On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26849#pullrequestreview-3140418082

From kbarrett at openjdk.org  Thu Aug 21 12:23:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 21 Aug 2025 12:23:56 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <9ON1pRJ6eZcRYoDahh1w2hCT95YZS9Z_2ORMj-laVZs=.aabd607e-72a7-4c6b-a2b6-8475feff4d41@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com>
 <9ON1pRJ6eZcRYoDahh1w2hCT95YZS9Z_2ORMj-laVZs=.aabd607e-72a7-4c6b-a2b6-8475feff4d41@github.com>
Message-ID: <RN-6ZkB7h5TEX6meG2y4jN6o_5pCfpS4FVmXM8bhe2I=.afb0cbc1-9fe9-466f-beb7-62f74ef2e946@github.com>

On Thu, 21 Aug 2025 06:34:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.hpp line 810:
>> 
>>> 808:   // Performs vsnprintf and asserts the result is non-negative (so there was not
>>> 809:   // an encoding error or any other kind of usage error).
>>> 810:   [[nodiscard]] static int vsnprintf(char* buf, size_t len, const char* fmt, va_list args) ATTRIBUTE_PRINTF(3, 0);
>> 
>> Consider moving the `ATTRIBUTE_PRINTF` to the front so all the attributes are together?
>> And maybe a line break between the attributes and the signature, just to avoid pushing the
>> signature way over to the right.
>
> I have done that and placed each attribute on its own line (we should have a style guide entry for this :) ). But I note that all the other ATTRIBUTE_PRINTF's are placed after the function.

What you've done here matches what I did when adding `[[noreturn]]` to `report_xxx` functions
in debug.hpp.  So I'm good with that.  The style guide already has this guidance:
https://github.com/openjdk/jdk/blame/02fe095d29994bec28c85beb6bf2a69b0f49b206/doc/hotspot-style.md#L1120-L1122
There's just lots of old, non-conforming code. :)
I forgot about that when I said "Consider moving", and should have pointed to the style guide.
Whether and where there should be line breaks is something the style guide leaves to authors and reviewers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290880828

From asemenov at openjdk.org  Thu Aug 21 13:21:02 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 13:21:02 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
 <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
Message-ID: <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>

On Thu, 21 Aug 2025 12:09:38 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> ```head->next()``` returns a pointer to _next without any checks.
>> 
>> In turn, the _next pointer is marked as volatile, which means it can be modified at any moment, for example, in another thread.
>> 
>> From this, I conclude that a check in this location is desirable. Moreover, pos_idx is also not being checked. It is quite possible that ```head->next()``` could turn out to be nullptr.
>> 
>> But I don?t mind. If you are sure that there can?t be a nullptr in this place, I will withdraw this patch.
>
>> Moreover, pos_idx is also not being checked
> 
> I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test.
> 
> The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference  here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so.
> 
> n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works.

pos_idx receives its value when calling a certain function pos_idx_from_marker(marker), and there is no check before the loop to ensure that it is within the bounds of the _table size.

I mentioned above that I am not insisting on this particular patch. This issue was detected by a static analyzer and confirmed by a specialist from another organization. After that, based on my limited knowledge, I considered it confirmed? If you have any refutation, please share your thoughts. In that case, I will revert this patch and mark the trigger as ?NO FIX REQUIRED?.

As far as I have checked, there are no checks anywhere in the calls to this function to compare the marker with the table or any other entities in any form.

I certainly do not claim to understand this code as well as you or any other member of the hotspot team.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2291041769

From adinn at openjdk.org  Thu Aug 21 14:34:53 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 14:34:53 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
 <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
 <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>
Message-ID: <KS-ahFFjB-Ehnk_gU_5pM3mfuhHOvOYySiL5Q1wZeVc=.a8bef526-8f2b-495d-b2b7-efa88f1ed6d6@github.com>

On Thu, 21 Aug 2025 13:18:26 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>>> Moreover, pos_idx is also not being checked
>> 
>> I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test.
>> 
>> The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference  here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so.
>> 
>> n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works.
>
> pos_idx receives its value when calling a certain function pos_idx_from_marker(marker), and there is no check before the loop to ensure that it is within the bounds of the _table size.
> 
> I mentioned above that I am not insisting on this particular patch. This issue was detected by a static analyzer. After that, based on my limited knowledge, I considered it confirmed? If you have any refutation, please share your thoughts. In that case, I will revert this patch and mark the trigger as ?NO FIX REQUIRED?.
> 
> As far as I have checked, there are no checks anywhere in the calls to this function to compare the marker with the table or any other entities in any form.
> 
> I certainly do not claim to understand this code as well as you or any other member of the hotspot team.

Well, this leads right to the root of the problem I have with this report. As you say, pos_idx does indeed come out of a marker object. It took me abut a minute to identify that this marker object is created in the function that sits right above the one your code assistant flagged as problematic -- even though I am not at all familiar with this code. It looks clear to me that, given the right call sequence for calls that create a marker and then consume it here, the check on pos_idx will ensure that we don't drop off the end of the list with a null pointer. So, it looks very liek this code has been designed so that the presence of a marker with a suitable pos_idx is intended to ensure this loop terminates before that happens. I am sure someone in this project knows whether that is the case but it is not you or your coding assistant.

I'm not suggesting that that calling sequence is actually right and that the check for pos_idx will definitely avoid dropping off the end. Indeed, I would welcome a bug that proved it to be wrong. However, what is clear that both you and your coding assistant have failed to appreciate how some relatively obvious parts of this design actually operate. That renders your (or your tool's) analysis a shallow and unhelpful distraction; using it as an excuse to raise a purported 'issue' in the absence of any evidence of an actual issue is very much a waste of time for this project's reviewers.

Your error is compounded by the fact that you (or more likely your coding assistant) are suggesting changes which, because they are not founded in a correct understanding of the design, could potentially lead to worse outcomes than the speculative nullptr dereference they are intended to remedy -- as I explained when discussing your change to the control flow logic in the ALDC code. So, not only is this report unhelpful it is potentially harmful.

Ultimately the takeaway here is that the OpenJDK bug system is not here to report, review and add patches to remedy issues that you or your code assistant tool invents on the basis of misinformed assumptions. It is here to report, review and add patches to remedy issues that can be shown to actually affect the correct operation of the JVM and JDK,either by a reproducible test or by well-reasoned argument. So, please do not continue to spam the project with bug reports like this simply because a potentially bogus patch will improve your experience with what is clearly a decidedly fallible tool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2291265263

From tschatzl at openjdk.org  Fri Aug 22 11:08:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 22 Aug 2025 11:08:27 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v48]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <dWZnZeSX-673v9WP7YerO0Q5toEkPJChI8LqgQxrW7k=.90265caa-5f1e-496c-b717-7219e707c48c@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 65 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
 - 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
 - ... and 55 more: https://git.openjdk.org/jdk/compare/e1c58f85...6c88f1de

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=47
  Stats: 7111 lines in 112 files changed: 2587 ins; 3587 del; 937 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 tschatzl at openjdk.org  Fri Aug 22 11:41:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 22 Aug 2025 11:41:27 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v49]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <8ed2PRthKJNDf-El4SVUWmu-FZm311FTDmgr7mcokaI=.9f9a74ee-3306-474a-8eb4-8c6b4bd3db70@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 incrementally with one additional commit since the last revision:

  * forgot to actually save the files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/6c88f1de..e8a8282b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=47-48

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 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 dlong at openjdk.org  Fri Aug 22 12:01:59 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 22 Aug 2025 12:01:59 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
Message-ID: <MEJsxrF4K-t_cRGvOO3KpBBiUcF4MtHCxigyJD64WeU=.c5cf9542-204b-4e5f-b57d-61f900062352@github.com>

On Thu, 21 Aug 2025 09:01:12 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
>> 
>> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.
>
> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/adlc/output_h.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Most of these mitigations to guard against a possible null pointer dereference are inside `if` expressions, which means if there was a null pointer, then we will now end up in the `else` clause, changing the behavior of the code to something that was perhaps unintended, and we still don't know what caused the null pointer.  So this is just silently masking potential problems, and in my experience is usually not the correct fix.  Most of the time the correct fix is to tell the static analyzer that it is a false positive and move on.  Sometimes it is appropriate to add an assert or guarantee, and yes sometimes it is appropriate to do something different if there is a null, for example if it is a result of an allocation that can fail.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3212300703

From asemenov at openjdk.org  Fri Aug 22 12:02:00 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 22 Aug 2025 12:02:00 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <KS-ahFFjB-Ehnk_gU_5pM3mfuhHOvOYySiL5Q1wZeVc=.a8bef526-8f2b-495d-b2b7-efa88f1ed6d6@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
 <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
 <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>
 <KS-ahFFjB-Ehnk_gU_5pM3mfuhHOvOYySiL5Q1wZeVc=.a8bef526-8f2b-495d-b2b7-efa88f1ed6d6@github.com>
Message-ID: <os0FO1i7DzfjdqmpWxKOPGa-6rHOdkNEA-fus5a9w8o=.dc80696d-3672-42a4-a205-977008c212bd@github.com>

On Thu, 21 Aug 2025 14:32:43 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Well, this leads right to the root of the problem I have with this report. As you say, pos_idx does indeed come out of a marker object. It took me about a minute to identify that this marker object is created in the function that sits right above the one your code assistant flagged as problematic -- even though I am not at all familiar with this code. It looks clear to me that, given the right call sequence for calls that create a marker and then consume it here, the check on pos_idx will ensure that we don't drop off the end of the list with a null pointer. So, it looks very liek this code has been designed so that the presence of a marker with a suitable pos_idx is intended to ensure this loop terminates before that happens. I am sure someone in this project knows whether that is the case but it is not you or your coding assistant.
> 
> I'm not suggesting that that calling sequence is actually right and that the check for pos_idx will definitely avoid dropping off the end. Indeed, I would welcome a bug report that proved it to be wrong. However, what is clear that both you and your coding assistant have failed to appreciate how some relatively obvious parts of this design actually operate. That renders your (or your tool's) analysis a shallow and unhelpful distraction; using it as an excuse to raise a purported 'issue' in the absence of any evidence of an actual issue is very much a waste of time for this project's reviewers.
> 
> Your error is compounded by the fact that you (or more likely your coding assistant) are suggesting changes which, because they are not founded in a correct understanding of the design, could potentially lead to worse outcomes than the speculative nullptr dereference they are intended to remedy -- as I explained when discussing your change to the control flow logic in the ALDC code. So, not only is this report unhelpful it is potentially harmful.
> 
> Ultimately the takeaway here is that the OpenJDK bug system is not here to report, review and add patches to remedy issues that you or your code assistant tool invents on the basis of misinformed assumptions. It is here to report, review and add patches to remedy issues that can be shown to actually affect the correct operation of the JVM and JDK,either by a reproducible test or by well-reasoned argument. So, please do not continue to spam the project with bug reports like this simply because a potentially bogus patch will improve your experience with what is clearly a decidedly fallible tool.

I?m sorry to have taken up your time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2293532235

From asemenov at openjdk.org  Fri Aug 22 12:02:01 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 22 Aug 2025 12:02:01 GMT
Subject: Withdrawn: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <kErw3f-D3SB4Yxj9Hi8GBrfshYhi7njMTMkZ-t9knPo=.43be4c0d-98c8-4912-82c5-807a38636cde@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

This pull request has been closed without being integrated.

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

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

From tschatzl at openjdk.org  Fri Aug 22 16:01:26 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 22 Aug 2025 16:01:26 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v50]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <RO2iN7gBK0_CMG86CLB8UP-hHscWv96C8WZ5ACf4VTU=.ef6d1f58-b322-4de8-91b1-e9b9ba9d5c51@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 incrementally with one additional commit since the last revision:

  * fix merge error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/e8a8282b..cc4b7a0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=48-49

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Fri Aug 22 18:41:33 2025
From: duke at openjdk.org (Rui Li)
Date: Fri, 22 Aug 2025 18:41:33 GMT
Subject: RFR: 8246037: Shenandoah: update man pages to mention
 -XX:+UseShenandoahGC
Message-ID: <horF8ciShj6w8t7fuSOCP4acTO-uvFueXB449GYlaog=.bf43fdd2-5105-4db3-8da7-4479382ef933@github.com>

Add documentation of Shenandoah to java man page

Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics`

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

Commit messages:
 - 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC

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

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

From duke at openjdk.org  Fri Aug 22 22:54:07 2025
From: duke at openjdk.org (Rui Li)
Date: Fri, 22 Aug 2025 22:54:07 GMT
Subject: RFR: 8246037: Shenandoah: update man pages to mention
 -XX:+UseShenandoahGC [v2]
In-Reply-To: <horF8ciShj6w8t7fuSOCP4acTO-uvFueXB449GYlaog=.bf43fdd2-5105-4db3-8da7-4479382ef933@github.com>
References: <horF8ciShj6w8t7fuSOCP4acTO-uvFueXB449GYlaog=.bf43fdd2-5105-4db3-8da7-4479382ef933@github.com>
Message-ID: <o6hZs8OSFukvZPvn3runa1EnUha4_3_-l3U5vL_UJlk=.ed3b6cfc-44bd-43cb-b76e-61fdc0bb07b6@github.com>

> Add documentation of Shenandoah to java man page
> 
> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics`

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

  Comment for aggressive. Indent.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26907/files
  - new: https://git.openjdk.org/jdk/pull/26907/files/66b99814..a9d1f6a3

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

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

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

From iklam at openjdk.org  Fri Aug 22 23:51:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 23:51:22 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast()
Message-ID: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>

We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern:


InstanceKlass* x = ....;
Klass* s = x->super(); // should call java_super()
InstanceKlass::cast(s)->xyz();


The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`:

- `super()` returns `[Ljava/lang/Object;`
- `java_super()` returns `Ljava/lang/Object;`

However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`.

See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221

Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go.

I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary  ` InstanceKlass::cast()` calls.

I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`.

To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR.

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

Commit messages:
 - Replace Klass::superklass() with Klass::java_super()
 - more fixes
 - 8366024: Remove unnecessary InstanceKlass::cast()

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

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

From dholmes at openjdk.org  Mon Aug 25 07:09:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 25 Aug 2025 07:09:02 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
Message-ID: <S8FUiC8e3Ef-uaOpHXIG3CAp1OTo4KIPiW7cFQ83f5I=.1944c558-a1af-438f-a345-49dc6a074651@github.com>

On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

Thanks for the Review Kim!

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3219089008

From dholmes at openjdk.org  Mon Aug 25 07:09:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 25 Aug 2025 07:09:02 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <qqr1wCRNhu-dnJWGmqNiJpokOR6i23eHaH84qRjNFBw=.0cf37006-2bb8-4509-99c1-3b0db4ed39f0@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com>
 <idaZ8CjLSYTU2tp0vkAjZ080E3dWoqPxKVIH8Obw9yk=.89f5598c-8591-4bf0-9d51-88151051c608@github.com>
 <qqr1wCRNhu-dnJWGmqNiJpokOR6i23eHaH84qRjNFBw=.0cf37006-2bb8-4509-99c1-3b0db4ed39f0@github.com>
Message-ID: <r1iIIS35vODae4TPbXtIFD0l4ysCBaRFIATvgogjeNc=.8be48bfb-52be-48da-b965-33fce3c26742@github.com>

On Thu, 21 Aug 2025 07:46:18 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Yes but again if that happens during testing we need to know and fix the buffer size to get the non-truncated values.
>
> In this case the buffer size comes from shared code.  Whatever size we choose for the static buffer, we can trigger the assert by setting LIBPATH and LD_LIBRARY_PATH to very long strings.  This is just the error message, so it might be OK to truncate it.  Otherwise we could need to allocate the buffer using malloc.

I'm inclined to keep the assert and address any future problems if they arise. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2297294080

From fbredberg at openjdk.org  Tue Aug 26 09:41:38 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 26 Aug 2025 09:41:38 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
Message-ID: <fU9pGo2GqB_clYfAihitW7kH983r6i5GJko0FIUTBDQ=.d48c852b-8de0-47d8-a96d-d69dd7353c1b@github.com>

On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

A good looking PR, and a good step in the right direction. Nice!

But as @kimbarrett I also noticed there are a number of calls with `buflen - 1`, which in my case consumed too mush of the review time. So it would be nice to see a follow up that deals with code like [this](https://github.com/openjdk/jdk/blob/38003a227a55dbd6adb89dcb10dc619f08bb0187/src/hotspot/os/bsd/os_bsd.cpp#L2493).

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

Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26849#pullrequestreview-3154824577

From jrose at openjdk.org  Tue Aug 26 22:45:41 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 26 Aug 2025 22:45:41 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast()
In-Reply-To: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
Message-ID: <AZuwsR0yrx4GLKIz9UMQA0UJkWNYCP0ABtH-zmnCnH4=.1ec3d563-f3dd-4d27-987d-65a207be14ca@github.com>

On Fri, 22 Aug 2025 23:45:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern:
> 
> 
> InstanceKlass* x = ....;
> Klass* s = x->super(); // should call java_super()
> InstanceKlass::cast(s)->xyz();
> 
> 
> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`:
> 
> - `super()` returns `[Ljava/lang/Object;`
> - `java_super()` returns `Ljava/lang/Object;`
> 
> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`.
> 
> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221
> 
> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go.
> 
> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary  ` InstanceKlass::cast()` calls.
> 
> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`.
> 
> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR.

Not necessarily for this PR, but I nominate `jvm_super` as the "true name" for `super`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3225953172

From dholmes at openjdk.org  Wed Aug 27 06:50:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 27 Aug 2025 06:50:44 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <fU9pGo2GqB_clYfAihitW7kH983r6i5GJko0FIUTBDQ=.d48c852b-8de0-47d8-a96d-d69dd7353c1b@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
 <fU9pGo2GqB_clYfAihitW7kH983r6i5GJko0FIUTBDQ=.d48c852b-8de0-47d8-a96d-d69dd7353c1b@github.com>
Message-ID: <V_X0D3tF1DpMHR56dBCA3hRXnDMKnRjBQdUIj9tG0ew=.2eac103c-da3e-4a67-b3dc-9cbfca39993d@github.com>

On Tue, 26 Aug 2025 09:38:54 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reviewer feedback
>
> A good looking PR, and a good step in the right direction. Nice!
> 
> But as @kimbarrett I also noticed there are a number of calls with `buflen - 1`, which in my case consumed too mush of the review time. So it would be nice to see a follow up that deals with code like [this](https://github.com/openjdk/jdk/blob/38003a227a55dbd6adb89dcb10dc619f08bb0187/src/hotspot/os/bsd/os_bsd.cpp#L2493).

Thanks for the review @fbredber . I have added your cleanup suggestion to [JDK-8365896](https://bugs.openjdk.org/browse/JDK-8365896) as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3226972822

From adinn at openjdk.org  Wed Aug 27 09:19:41 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 27 Aug 2025 09:19:41 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast()
In-Reply-To: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
Message-ID: <p6zUsenC0c3i5wG7ptRNiLnGkWgC_db4dB80U_d8CyE=.84973c4f-387f-42db-b82e-ede80212316c@github.com>

On Fri, 22 Aug 2025 23:45:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern:
> 
> 
> InstanceKlass* x = ....;
> Klass* s = x->super(); // should call java_super()
> InstanceKlass::cast(s)->xyz();
> 
> 
> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`:
> 
> - `super()` returns `[Ljava/lang/Object;`
> - `java_super()` returns `Ljava/lang/Object;`
> 
> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`.
> 
> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221
> 
> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go.
> 
> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary  ` InstanceKlass::cast()` calls.
> 
> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`.
> 
> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR.

I found two more occurrences of casting super() to InstanceKlass:

    src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp:79

        ik = (const InstanceKlass*)ik->super();

    src/hotspot/share/prims/jni.cpp:209

        Klass* field_klass = k;
        Klass* super_klass = field_klass->super();
        // With compressed oops the most super class with nonstatic fields would
        // be the owner of fields embedded in the header.
        while (InstanceKlass::cast(super_klass)->has_nonstatic_fields() &&
               InstanceKlass::cast(super_klass)->contains_field_offset(offset)) {
          field_klass = super_klass;   // super contains the field also
          super_klass = field_klass->super();
        }

The first one ought perhaps to be using InstanceKlass::superklass()?

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

PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3227432942

From adinn at openjdk.org  Wed Aug 27 09:26:43 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 27 Aug 2025 09:26:43 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast()
In-Reply-To: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
Message-ID: <X4wIRC760RuUkHNhuIgxuBKfdKQXuNArMsMq0QyBn7Q=.51da0e8f-5ba4-443a-97c4-9a50d7bba6d3@github.com>

On Fri, 22 Aug 2025 23:45:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern:
> 
> 
> InstanceKlass* x = ....;
> Klass* s = x->super(); // should call java_super()
> InstanceKlass::cast(s)->xyz();
> 
> 
> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`:
> 
> - `super()` returns `[Ljava/lang/Object;`
> - `java_super()` returns `Ljava/lang/Object;`
> 
> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`.
> 
> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221
> 
> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go.
> 
> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary  ` InstanceKlass::cast()` calls.
> 
> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`.
> 
> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR.

src/hotspot/share/runtime/deoptimization.cpp line 1479:

> 1477: // Gets the fields of `klass` that are eliminated by escape analysis and need to be reassigned
> 1478: static GrowableArray<ReassignedField>* get_reassigned_fields(InstanceKlass* klass, GrowableArray<ReassignedField>* fields, bool is_jvmci) {
> 1479:   InstanceKlass* super = klass->java_super();

What is wrong with using `superklass()` here? We already know that `klass` is an `InstanceKlass*` so we don't need to make a virtual call to `java_super()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26908#discussion_r2303382149

From iklam at openjdk.org  Wed Aug 27 18:07:43 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 27 Aug 2025 18:07:43 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast()
In-Reply-To: <X4wIRC760RuUkHNhuIgxuBKfdKQXuNArMsMq0QyBn7Q=.51da0e8f-5ba4-443a-97c4-9a50d7bba6d3@github.com>
References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
 <X4wIRC760RuUkHNhuIgxuBKfdKQXuNArMsMq0QyBn7Q=.51da0e8f-5ba4-443a-97c4-9a50d7bba6d3@github.com>
Message-ID: <B4PJ14lctvUe9aiLHXunC0R2d3Vxs8S2lYBikeLFAX0=.e1172b8e-7d08-489d-a5f6-5be0729e8c6f@github.com>

On Wed, 27 Aug 2025 09:23:38 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern:
>> 
>> 
>> InstanceKlass* x = ....;
>> Klass* s = x->super(); // should call java_super()
>> InstanceKlass::cast(s)->xyz();
>> 
>> 
>> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`:
>> 
>> - `super()` returns `[Ljava/lang/Object;`
>> - `java_super()` returns `Ljava/lang/Object;`
>> 
>> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`.
>> 
>> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221
>> 
>> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go.
>> 
>> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary  ` InstanceKlass::cast()` calls.
>> 
>> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`.
>> 
>> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR.
>
> src/hotspot/share/runtime/deoptimization.cpp line 1479:
> 
>> 1477: // Gets the fields of `klass` that are eliminated by escape analysis and need to be reassigned
>> 1478: static GrowableArray<ReassignedField>* get_reassigned_fields(InstanceKlass* klass, GrowableArray<ReassignedField>* fields, bool is_jvmci) {
>> 1479:   InstanceKlass* super = klass->java_super();
> 
> What is wrong with using `superklass()` here? We already know that `klass` is an `InstanceKlass*` so we don't need to make a virtual call to `java_super()`.

I got rid of `superklass()` because it was yet another way of looking for a "super" that has no documentation. 

In this particular case, the cost of a virtual code will be negligible compared to what happens in the following loop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26908#discussion_r2304917105

From iklam at openjdk.org  Wed Aug 27 18:11:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 27 Aug 2025 18:11:33 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2]
In-Reply-To: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
Message-ID: <O466ukwfzStQhTZTNlZGXE2GEyEcl98aClGvQHqGfp8=.af68e5e1-b706-4410-88a6-62d8b1eb89b7@github.com>

> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern:
> 
> 
> InstanceKlass* x = ....;
> Klass* s = x->super(); // should call java_super()
> InstanceKlass::cast(s)->xyz();
> 
> 
> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`:
> 
> - `super()` returns `[Ljava/lang/Object;`
> - `java_super()` returns `Ljava/lang/Object;`
> 
> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`.
> 
> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221
> 
> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go.
> 
> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary  ` InstanceKlass::cast()` calls.
> 
> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`.
> 
> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR.

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

  @adinn comment - remove InstanceKlass::cast() in edgeUtils.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26908/files
  - new: https://git.openjdk.org/jdk/pull/26908/files/930d6524..074ea8b2

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

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

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

From coleenp at openjdk.org  Wed Aug 27 18:22:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 18:22:42 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2]
In-Reply-To: <O466ukwfzStQhTZTNlZGXE2GEyEcl98aClGvQHqGfp8=.af68e5e1-b706-4410-88a6-62d8b1eb89b7@github.com>
References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
 <O466ukwfzStQhTZTNlZGXE2GEyEcl98aClGvQHqGfp8=.af68e5e1-b706-4410-88a6-62d8b1eb89b7@github.com>
Message-ID: <i_71-nGl4o7PALYF3OBM5fSxKCb_nFJ7_t5Szyj_Nxo=.4ddf9270-b73f-4ab4-bbea-01db36cc8620@github.com>

On Wed, 27 Aug 2025 18:11:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern:
>> 
>> 
>> InstanceKlass* x = ....;
>> Klass* s = x->super(); // should call java_super()
>> InstanceKlass::cast(s)->xyz();
>> 
>> 
>> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`:
>> 
>> - `super()` returns `[Ljava/lang/Object;`
>> - `java_super()` returns `Ljava/lang/Object;`
>> 
>> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`.
>> 
>> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221
>> 
>> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go.
>> 
>> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary  ` InstanceKlass::cast()` calls.
>> 
>> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`.
>> 
>> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @adinn comment - remove InstanceKlass::cast() in edgeUtils.cpp

This looks good.  We've had several passes of narrowing the Klass types to InstanceKlass so thank you for doing this one.  super() is tricky because of array covariance in subtype checking.  I don't see that this affects that code.
Thank @adinn  for finding more.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26908#pullrequestreview-3161236083

From iklam at openjdk.org  Wed Aug 27 18:22:43 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 27 Aug 2025 18:22:43 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast()
In-Reply-To: <p6zUsenC0c3i5wG7ptRNiLnGkWgC_db4dB80U_d8CyE=.84973c4f-387f-42db-b82e-ede80212316c@github.com>
References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
 <p6zUsenC0c3i5wG7ptRNiLnGkWgC_db4dB80U_d8CyE=.84973c4f-387f-42db-b82e-ede80212316c@github.com>
Message-ID: <2HnUt2UzQH-ItShoUc4HI8c3pyh-HJHxYMGsmf2jHHQ=.1a14101d-f662-4820-8ad1-f73d8e22045f@github.com>

On Wed, 27 Aug 2025 09:17:31 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> I found two more occurrences of casting super() to InstanceKlass:
> 
> ```
> src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp:79
> 
>     ik = (const InstanceKlass*)ik->super();
> ```

I fixed this one with `java_super()`. Similar to the case in deoptimization.cpp, the cost is dominated by the JavaFieldStream so a virtual call should be fine here.

> ```src/hotspot/share/prims/jni.cpp:209
> 
> intptr_t jfieldIDWorkaround::encode_klass_hash(Klass* k, int offset) {
>  if (offset <= small_offset_mask) {
>     Klass* field_klass = k;
>     Klass* super_klass = field_klass->super();
>     // With compressed oops the most super class with nonstatic fields would
>     // be the owner of fields embedded in the header.
>     while (InstanceKlass::cast(super_klass)->has_nonstatic_fields() &&
>            InstanceKlass::cast(super_klass)->contains_field_offset(offset)) {
>       field_klass = super_klass;   // super contains the field also
>       super_klass = field_klass->super();
>     }
> ```

Here we have the same logic as in the (removed) `superklass()` function, without any explanation why the cast is safe. The code seems to assume that the incoming `k` parameter cannot be a type such as `[Ljava/lang/String;`. I am not familiar with this code, so I will leave it as is.

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

PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3229259517

From dholmes at openjdk.org  Thu Aug 28 06:15:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 06:15:44 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2]
In-Reply-To: <O466ukwfzStQhTZTNlZGXE2GEyEcl98aClGvQHqGfp8=.af68e5e1-b706-4410-88a6-62d8b1eb89b7@github.com>
References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
 <O466ukwfzStQhTZTNlZGXE2GEyEcl98aClGvQHqGfp8=.af68e5e1-b706-4410-88a6-62d8b1eb89b7@github.com>
Message-ID: <xuZTWUV-SEqjHjqG5yKoQ5RVLO3apxAvPAbzF5FBsL4=.60139826-f8ba-4b97-a63e-4ef91761e332@github.com>

On Wed, 27 Aug 2025 18:11:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern:
>> 
>> 
>> InstanceKlass* x = ....;
>> Klass* s = x->super(); // should call java_super()
>> InstanceKlass::cast(s)->xyz();
>> 
>> 
>> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`:
>> 
>> - `super()` returns `[Ljava/lang/Object;`
>> - `java_super()` returns `Ljava/lang/Object;`
>> 
>> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`.
>> 
>> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221
>> 
>> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go.
>> 
>> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary  ` InstanceKlass::cast()` calls.
>> 
>> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`.
>> 
>> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @adinn comment - remove InstanceKlass::cast() in edgeUtils.cpp

FWIW `jfieldIDWorkaround::encode_klass_hash` does seem to end up getting called only when `k` is an `instanceKlass` but we should file a cleanup RFE to change the parameter type.

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

PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3232037750

From cslucas at openjdk.org  Fri Aug 29 00:08:16 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 29 Aug 2025 00:08:16 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
Message-ID: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>

Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.

The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

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

Commit messages:
 - Change shenandoah nmethod entry barrier fence.

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

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

From iklam at openjdk.org  Fri Aug 29 06:08:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 29 Aug 2025 06:08:42 GMT
Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2]
In-Reply-To: <xuZTWUV-SEqjHjqG5yKoQ5RVLO3apxAvPAbzF5FBsL4=.60139826-f8ba-4b97-a63e-4ef91761e332@github.com>
References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com>
 <O466ukwfzStQhTZTNlZGXE2GEyEcl98aClGvQHqGfp8=.af68e5e1-b706-4410-88a6-62d8b1eb89b7@github.com>
 <xuZTWUV-SEqjHjqG5yKoQ5RVLO3apxAvPAbzF5FBsL4=.60139826-f8ba-4b97-a63e-4ef91761e332@github.com>
Message-ID: <8ctJLegzZC9BnjyHMmgP4mBsrKgYjw9q29jLpQvFmuw=.9ab7631b-013d-4dc1-8178-8c76eff6f64b@github.com>

On Thu, 28 Aug 2025 06:13:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

> FWIW `jfieldIDWorkaround::encode_klass_hash` does seem to end up getting called only when `k` is an `instanceKlass` but we should file a cleanup RFE to change the parameter type.

I have filed [JDK-8366417](https://bugs.openjdk.org/browse/JDK-8366417) - jfieldIDWorkaround should use InstanceKlass* instead of Klass*

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

PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3235833281

From shade at openjdk.org  Fri Aug 29 06:35:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 29 Aug 2025 06:35:41 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
In-Reply-To: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
Message-ID: <notSe0AbMi16PxhpA10j_6wP1DYOs0YwuW4OiV9gd7Q=.317dc2b1-afa2-4b28-8b5e-5a42869512ec@github.com>

On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
> 
> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

I see `virtual NMethodPatchingType nmethod_patching_type() { return NMethodPatchingType::conc_data_patch; }` in Shenandoah PPC64 and RISC-V barrier sets as well. Those should likely go away as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3235890936

From dzhang at openjdk.org  Fri Aug 29 07:04:41 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Fri, 29 Aug 2025 07:04:41 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
In-Reply-To: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
Message-ID: <133lBie4di5uGvczIdenGraY_OY6vmMRIY4CFOc2xYo=.c1635af8-f715-456c-910c-a63809916179@github.com>

On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
> 
> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

Thanks for this patch! I've made similar changes on RISC-V.
Could you please add those as well? https://github.com/DingliZhang/jdk/commit/495b07fe690ef7e3fe828fd2be27c4259c739c23
I've tested the `hotspot_gc_shenandoah` on the SG2042 with fastdebug and found no failures.
Specjbb testing on the SG2042 is ongoing. I'll update the results later.

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

PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3235958508

From dholmes at openjdk.org  Sun Aug 31 21:37:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 31 Aug 2025 21:37:47 GMT
Subject: RFR: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked [v2]
In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
 <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com>
Message-ID: <XBdP6GOMc7itm_zkl6xFFvgYs2ZO_hgaOKuIyGaoiHA=.7bff7d39-7cb8-405b-a231-ff3f8d7ee9c2@github.com>

On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
>> 
>> From: https://bugs.openjdk.org/browse/JDK-8347707
>> 
>> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
>> 
>> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
>> 
>> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
>> 
>> - encoding error: not applicable as we are not using extended character sets
>> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
>> - mal-formed formatting directives
>> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
>> 
>> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
>> 
>> The potential clients of this API then fall into a number of camps:
>> 
>> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
>> 
>> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
>> 
>> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
>> 
>> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
>> 
>> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
>> 
>> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

Note, before integrating I merged locally with master, checked the incoming changes and re-ran tier 1-3 builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3240430237

From dholmes at openjdk.org  Sun Aug 31 21:37:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 31 Aug 2025 21:37:48 GMT
Subject: Integrated: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
References: <hz-VCoRbJ0v_a5jOEaTIksvYHaH07UvMtPl3dZ_sPnY=.76643540-c3c2-47ae-90ce-7b49a526d8a4@github.com>
Message-ID: <YeeMGoFUJKMyrxnsuN0QH6ZIR1iulNzok8JqoHCxKog=.665b544b-4bb8-4eda-98b8-dcbba78afc10@github.com>

On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.
> 
> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`.
> 
> The potential errors are, generally speaking, not something we should encounter in our own well-written code:
> 
> - encoding error: not applicable as we are not using extended character sets
> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature)
> - mal-formed formatting directives
> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`).
> 
> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions.
> 
> The potential clients of this API then fall into a number of camps:
> 
> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error.
> 
> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation.
> 
> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen.
> 
> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation.
> 
> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use.
> 
> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error.
> ...

This pull request has now been integrated.

Changeset: 80ab094a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80ab094a75a6474c33214e3347e08ea7b9177ec8
Stats:     202 lines in 46 files changed: 19 ins; 7 del; 176 mod

8347707: Standardise the use of os::snprintf and os::snprintf_checked

Reviewed-by: kbarrett, fbredberg

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

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