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