From mhaessig at openjdk.org  Tue Jul  1 09:34:50 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 1 Jul 2025 09:34:50 GMT
Subject: RFR: 8361086: JVMCIGlobals::check_jvmci_flags_are_consistent has
 incorrect format string
In-Reply-To: <Bqt0YYN9gmZyL5u1OBa6Prk0oc3WBWi8NGF96l5RM8o=.b8c7163a-ae24-45b4-9312-9c0cd87786c2@github.com>
References: <Bqt0YYN9gmZyL5u1OBa6Prk0oc3WBWi8NGF96l5RM8o=.b8c7163a-ae24-45b4-9312-9c0cd87786c2@github.com>
Message-ID: <5kdHAQ86j5eDq6OgIb6Bn7HFWxgc24W8ywubudeGa-Q=.5d8b392a-de5c-49d7-a3f2-3ade541c6643@github.com>

On Mon, 30 Jun 2025 16:14:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial fix of a format string. The value being printed is
> TieredStopAtLevel, which is of type intx, so "%zd" should be used instead of "%d".
> 
> Testing: mach5 tier1

Looks good and trivial to me.

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

Marked as reviewed by mhaessig (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26051#pullrequestreview-2974517185

From yzheng at openjdk.org  Tue Jul  1 09:38:48 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 1 Jul 2025 09:38:48 GMT
Subject: RFR: 8361086: JVMCIGlobals::check_jvmci_flags_are_consistent has
 incorrect format string
In-Reply-To: <Bqt0YYN9gmZyL5u1OBa6Prk0oc3WBWi8NGF96l5RM8o=.b8c7163a-ae24-45b4-9312-9c0cd87786c2@github.com>
References: <Bqt0YYN9gmZyL5u1OBa6Prk0oc3WBWi8NGF96l5RM8o=.b8c7163a-ae24-45b4-9312-9c0cd87786c2@github.com>
Message-ID: <LXuVQ969I8n0dE4bnbd204nn2TrHOXCX7pIjqyv5vtc=.b42eb3b6-621e-46b8-84ea-8f909cd2795a@github.com>

On Mon, 30 Jun 2025 16:14:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial fix of a format string. The value being printed is
> TieredStopAtLevel, which is of type intx, so "%zd" should be used instead of "%d".
> 
> Testing: mach5 tier1

LGTM

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26051#pullrequestreview-2974540441

From duke at openjdk.org  Tue Jul  1 15:09:12 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 1 Jul 2025 15:09:12 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
Message-ID: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>

Hi, please consider the following changes:

this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 

The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 

Tested in tiers 1-3 and GHA.

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

Commit messages:
 - 8320353: Fixed comment
 - 8320353: Fixed whitespace error
 - 8320353:  Fiixed build problem
 - 8320353: Added debug only case
 - 8320353: More work
 - 8320353: More work
 - 8320353: Reenabled stringop-overflow warning for linux zero/fastdebug

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

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

From mchevalier at openjdk.org  Tue Jul  1 16:14:00 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 1 Jul 2025 16:14:00 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v2]
In-Reply-To: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
Message-ID: <1cFRkcs5JmgnbWEIaEoT8I9RiUtNxgKieAdkSB2Fgmc=.1d97b5c4-b6ef-43c6-b721-1e52eee19d3a@github.com>

> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
> 
> This is enforced by restoring the old state, like in
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
> 
> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
> 
> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
> 
> 
> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
> 
> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
> 
> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
> 
> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
> 
> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
> 
> And here there is the challenge:
> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
> - we can't really change the pointer, just the content
> -...

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

  Remove useless loop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25936/files
  - new: https://git.openjdk.org/jdk/pull/25936/files/54b07e94..d51853ca

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

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

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

From ihse at openjdk.org  Tue Jul  1 19:04:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 19:04:37 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <bxWyyE5VCVY0EhzEwu3fgOwoK1g1eH-1ar3VEE2RbHw=.30e71e59-041e-4280-8b11-ce40bf154990@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

Build changes look good. Someone else will have to review the hotspot changes.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26067#pullrequestreview-2976656855

From kbarrett at openjdk.org  Wed Jul  2 00:30:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 00:30:44 GMT
Subject: RFR: 8361086: JVMCIGlobals::check_jvmci_flags_are_consistent has
 incorrect format string
In-Reply-To: <e7EwRSQ2g0rp6tiQYCi_CiXNjJNSkDQBNEceJfLR4Bo=.4fba92a3-934a-401d-8444-3d669f02f7cc@github.com>
References: <Bqt0YYN9gmZyL5u1OBa6Prk0oc3WBWi8NGF96l5RM8o=.b8c7163a-ae24-45b4-9312-9c0cd87786c2@github.com>
 <e7EwRSQ2g0rp6tiQYCi_CiXNjJNSkDQBNEceJfLR4Bo=.4fba92a3-934a-401d-8444-3d669f02f7cc@github.com>
Message-ID: <C5pYBJynimdvUz5Oue_cWIby4eg4PJuPyvIm7PVM5Bw=.f0c97514-2232-4563-83dd-46ce4e9284c9@github.com>

On Mon, 30 Jun 2025 23:16:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Please review this trivial fix of a format string. The value being printed is
>> TieredStopAtLevel, which is of type intx, so "%zd" should be used instead of "%d".
>> 
>> Testing: mach5 tier1
>
> Thank you for checking other solutions.
> 
> Current fix is good.

Thanks for reviews @vnkozlov , @mhaessig , and @mur47x111

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

PR Comment: https://git.openjdk.org/jdk/pull/26051#issuecomment-3025913681

From kbarrett at openjdk.org  Wed Jul  2 00:30:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 00:30:44 GMT
Subject: Integrated: 8361086: JVMCIGlobals::check_jvmci_flags_are_consistent
 has incorrect format string
In-Reply-To: <Bqt0YYN9gmZyL5u1OBa6Prk0oc3WBWi8NGF96l5RM8o=.b8c7163a-ae24-45b4-9312-9c0cd87786c2@github.com>
References: <Bqt0YYN9gmZyL5u1OBa6Prk0oc3WBWi8NGF96l5RM8o=.b8c7163a-ae24-45b4-9312-9c0cd87786c2@github.com>
Message-ID: <rYmQxlOGfNPmXwutMA9uRZM4sGMYPnReU7yukb5zfMA=.e1891e82-a255-4d8e-a4f5-a7d62c05b45d@github.com>

On Mon, 30 Jun 2025 16:14:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial fix of a format string. The value being printed is
> TieredStopAtLevel, which is of type intx, so "%zd" should be used instead of "%d".
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: c6448dc3
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6448dc3afb1da9d93bb94804aa1971a650b91b7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361086: JVMCIGlobals::check_jvmci_flags_are_consistent has incorrect format string

Reviewed-by: kvn, mhaessig, yzheng

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

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

From dholmes at openjdk.org  Wed Jul  2 06:57:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 06:57:40 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <LIm3kaxNVCwLe6hk7kwoQ8yoiL9EJOiqI3c0U7GSY1s=.3088b118-a78c-47f1-9d84-97b3ac823cc8@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

Sorry but I really dislike seeing this compiler-specific pollution in shared code. It is even worse that you have to put it in two places (what is so special about the jvmci code to require this?) just because gcc is "too dumb" keep track of things.

Also IIUC from JBS the problem was only seen building Zero, so maybe we can do something there that is Zero specific?

Sorry.

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

PR Review: https://git.openjdk.org/jdk/pull/26067#pullrequestreview-2977963403

From yzheng at openjdk.org  Wed Jul  2 07:22:29 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 07:22:29 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v9]
In-Reply-To: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
Message-ID: <8HUFsVgvqriVdKkkm-tkU-_XisP9uFPzSlhBFiGd9i8=.ca3a9645-e01b-4072-bdc8-6c3fb2f7bb81@github.com>

> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.

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 11 additional commits since the last revision:

 - address comments
 - Merge remote-tracking branch 'upstream/master' into JDK-8357424
 - Merge tag 'jdk-26+3' into JDK-8357424
   
   Added tag jdk-26+3 for changeset 08b1fa4c
 - Merge tag 'jdk-26+2' into JDK-8357424
   
   Added tag jdk-26+2 for changeset d7aa3498
 - fix compilation error
 - address comments
 - Merge remote-tracking branch 'upstream/master' into JDK-8357424
 - address comments
 - address comments
 - update copyright
 - ... and 1 more: https://git.openjdk.org/jdk/compare/dcb21872...022546a0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25356/files
  - new: https://git.openjdk.org/jdk/pull/25356/files/fb32a8c7..022546a0

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

  Stats: 13776 lines in 672 files changed: 6912 ins; 3534 del; 3330 mod
  Patch: https://git.openjdk.org/jdk/pull/25356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25356/head:pull/25356

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

From yzheng at openjdk.org  Wed Jul  2 07:24:42 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 07:24:42 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v7]
In-Reply-To: <Y_CBG-Cq-k1SvYWgzDR4I5-qP3yk9BR9dGUH5QgZrpM=.a0c9d62b-cb23-47c2-ad43-90547630b712@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <jK9lKheluCp0kBQUfIw0aOeLrtosIrBW3DtWoSStTEM=.f312343e-05d1-4a21-b0ea-bf8179599218@github.com>
 <Y_CBG-Cq-k1SvYWgzDR4I5-qP3yk9BR9dGUH5QgZrpM=.a0c9d62b-cb23-47c2-ad43-90547630b712@github.com>
Message-ID: <JBa8jXAyBzHCPwzUBtzTuKMKj59NcUkIzvhB_is7cOI=.8a551733-765b-4abc-88ca-bb8650edb650@github.com>

On Fri, 13 Jun 2025 20:59:05 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> 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 eight additional commits since the last revision:
>> 
>>  - Merge tag 'jdk-26+2' into JDK-8357424
>>    
>>    Added tag jdk-26+2 for changeset d7aa3498
>>  - fix compilation error
>>  - address comments
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8357424
>>  - address comments
>>  - address comments
>>  - update copyright
>>  - [JVMCI] Avoid incrementing decompilation count for hosted compiled nmethod
>
> src/hotspot/share/code/nmethod.cpp line 1951:
> 
>> 1949:   // Could be gated by ProfileTraps, but do not bother...
>> 1950: #if INCLUDE_JVMCI
>> 1951:   if (is_jvmci_hosted()) {
> 
> Someone (like me!) is going to see this code a while from now and try remember why the decompilation count is not being decremented for JVMCI hosted nmethods. I think it's worth adding a comment.

See https://github.com/openjdk/jdk/pull/25356/commits/022546a09ed9ca06898459df2f7b6ddc2877f69b

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25356#discussion_r2179317632

From yzheng at openjdk.org  Wed Jul  2 07:24:43 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 07:24:43 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v7]
In-Reply-To: <kTQsJam-H-l24jhzIztbGbn7V0Lf2TxpI5eYTk6SKIE=.c2f32a12-ef80-4d7f-8edd-0959bc717470@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <jK9lKheluCp0kBQUfIw0aOeLrtosIrBW3DtWoSStTEM=.f312343e-05d1-4a21-b0ea-bf8179599218@github.com>
 <kTQsJam-H-l24jhzIztbGbn7V0Lf2TxpI5eYTk6SKIE=.c2f32a12-ef80-4d7f-8edd-0959bc717470@github.com>
Message-ID: <QhBGF44CWOEDGWj_QhvSlGIJ6xVRGuHlLr4SUd1ZFUM=.fe8adef0-16dc-427e-9e46-a72495def25f@github.com>

On Tue, 17 Jun 2025 17:06:14 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> 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 eight additional commits since the last revision:
>> 
>>  - Merge tag 'jdk-26+2' into JDK-8357424
>>    
>>    Added tag jdk-26+2 for changeset d7aa3498
>>  - fix compilation error
>>  - address comments
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8357424
>>  - address comments
>>  - address comments
>>  - update copyright
>>  - [JVMCI] Avoid incrementing decompilation count for hosted compiled nmethod
>
> src/hotspot/share/runtime/deoptimization.cpp line 2367:
> 
>> 2365: 
>> 2366: #if INCLUDE_JVMCI
>> 2367:     if (nm->is_jvmci_hosted()) {
> 
> A comment here will probably be helpful as well.

See https://github.com/openjdk/jdk/pull/25356/commits/022546a09ed9ca06898459df2f7b6ddc2877f69b

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25356#discussion_r2179317776

From dnsimon at openjdk.org  Wed Jul  2 08:58:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 2 Jul 2025 08:58:41 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <wMHIciMZ4QYUToxmNokc5_kGX8T_fnwXxmbHlQXt7Qg=.d0cb5bfa-64d4-42b0-b76d-6b5bd81a2956@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 929:

> 927:   if (thread == nullptr) {
> 928:     // This is to prevent --stringop-overflow warning from GCC on linux/fastdebug.
> 929:     // GCC does believe that JavaThread::current() can return nullptr,

`does believe` -> `believes`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2179510064

From jwaters at openjdk.org  Wed Jul  2 09:07:44 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Jul 2025 09:07:44 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <T6noB03P0f3RK2RfhSkBqKzxwv8Nvgilrp-8KUPfkNo=.1398d88c-5e1a-4a17-84f1-7e98d9875eaf@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

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

> 1068:   // Returns the running thread as a JavaThread
> 1069:   static JavaThread* current() {
> 1070:     auto result = JavaThread::cast(Thread::current());

Why auto when the type is known?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2179528150

From dnsimon at openjdk.org  Wed Jul  2 09:10:45 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 2 Jul 2025 09:10:45 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v9]
In-Reply-To: <8HUFsVgvqriVdKkkm-tkU-_XisP9uFPzSlhBFiGd9i8=.ca3a9645-e01b-4072-bdc8-6c3fb2f7bb81@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <8HUFsVgvqriVdKkkm-tkU-_XisP9uFPzSlhBFiGd9i8=.ca3a9645-e01b-4072-bdc8-6c3fb2f7bb81@github.com>
Message-ID: <AM3xZo4mO-a52COruDpMMKZx2pa4JEo6wW0zVjH66eM=.ece42ba7-da61-40e1-a90d-153a9c1aa78f@github.com>

On Wed, 2 Jul 2025 07:22:29 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> 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 11 additional commits since the last revision:
> 
>  - address comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357424
>  - Merge tag 'jdk-26+3' into JDK-8357424
>    
>    Added tag jdk-26+3 for changeset 08b1fa4c
>  - Merge tag 'jdk-26+2' into JDK-8357424
>    
>    Added tag jdk-26+2 for changeset d7aa3498
>  - fix compilation error
>  - address comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357424
>  - address comments
>  - address comments
>  - update copyright
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f01309be...022546a0

src/hotspot/share/code/nmethod.cpp line 1939:

> 1937:   // Could be gated by ProfileTraps, but do not bother...
> 1938: #if INCLUDE_JVMCI
> 1939:   // Deoptimizations from non-default (non-CompileBroker) compilations should not

Suggestion:

  // Deoptimization count is used by the CompileBroker to reason about compilations
  // it requests so do not pollute the count for deoptimizations in non-default (i.e.
  // non-CompilerBroker) compilations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25356#discussion_r2179536365

From jwaters at openjdk.org  Wed Jul  2 09:12:40 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Jul 2025 09:12:40 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <0_bgDyCHArbkXPSDNQdNWLbrhY2AOJT_BjFTMD38tuY=.9ca01026-bf7e-4d59-8326-d5c4537acc17@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

A less messy solution could be to use PRAGMA_STRINGOP_OVERFLOW_IGNORED instead. The conditionals for the PRAGMA IGNORED macros are already all handled for you, so there's no need to put conditionalizations at the use sites. As an example, simply do the following:


PRAGMA_DIAG_PUSH
PRAGMA_STRINGOP_OVERFLOW_IGNORED
// Problem code here
PRAGMA_DIAG_POP


The first 2 macros are placed directly in front of the problem code, and the last goes behind.

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

PR Comment: https://git.openjdk.org/jdk/pull/26067#issuecomment-3027075027

From yzheng at openjdk.org  Wed Jul  2 11:27:25 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 11:27:25 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
Message-ID: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>

> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.

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/25356/files
  - new: https://git.openjdk.org/jdk/pull/25356/files/022546a0..d6221921

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

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

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

From dnsimon at openjdk.org  Wed Jul  2 11:47:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 2 Jul 2025 11:47:41 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
Message-ID: <QIsi0QjccJ_REav4WWL85PnJ2Zj3XrLSV5ImIlNE73A=.a2e0873d-2109-485b-a0d2-1ec8bb3de4b1@github.com>

On Wed, 2 Jul 2025 11:27:25 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25356#pullrequestreview-2978826504

From kbarrett at openjdk.org  Wed Jul  2 14:01:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 14:01:41 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <LLpd1-mLP3Q6EoLyOgM65uXPooSxUuw51szHOjR6bF0=.8a18dc2a-6b9a-49a6-b3f9-fad520377a7c@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 926:

> 924: JVMCI::CodeInstallResult CodeInstaller::initialize_buffer(JVMCIObject compiled_code, CodeBuffer& buffer, HotSpotCompiledCodeStream* stream, u1 code_flags, JVMCI_TRAPS) {
> 925:   JavaThread* thread = stream->thread();
> 926: #if defined(__GNUC__) && !defined(__clang__) && !defined(PRODUCT)

Note that `!PRODUCT` does not imply `ASSERT`. There is also the "optimized" build type, which
defines neither `PRODUCT` nor `ASSERT`. I have no idea whether the false-positive gcc warnings
occur in that build configuration. If so, then my suggestion of using an assertion to give the compiler
the clue it needs won't work. But I'm guessing that isn't a problem, in which case the macro check
should be `defined(ASSERT)`.

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 936:

> 934:     __builtin_unreachable();
> 935:   }
> 936: #endif

I think this could be replaced with asserting non-null.  A failed assert calls a noreturn reporting
function.

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

> 1077:   }
> 1078: #endif
> 1079:     return result;

Similarly here, I think this could be replaced with asserting non-null.

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

PR Review: https://git.openjdk.org/jdk/pull/26067#pullrequestreview-2979254552
PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2180140733
PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2180123147
PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2180120768

From iklam at openjdk.org  Wed Jul  2 17:39:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 17:39:18 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop()
Message-ID: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>

A module has both a Java and a C++ representation

- C++: `ModuleEntry`
- Java: `java.lang.Module`

In C++, we have the following two methods

- `ModuleEntry* InstanceKlass::module()`
- `oop ModuleEntry::module()`

This can lead to confusing code like this:


InstanceKlass* ik = ...;
oop module = ik->module()->module()


Proposal:

- Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
- Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:


InstanceKlass* ik = ...;
oop module = ik->module()->module_oop()

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

Commit messages:
 - 8361292: Rename ModuleEntry::module() to module_oop()

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

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

From never at openjdk.org  Wed Jul  2 17:40:44 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 2 Jul 2025 17:40:44 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
Message-ID: <wJxNwBEgrbJAdOeKL81u4lqNiQrwP8ARHc8klKxCoEI=.380309ef-80b2-4832-9099-424826d4e616@github.com>

On Wed, 2 Jul 2025 11:27:25 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

Looks great.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25356#pullrequestreview-2980076551

From coleenp at openjdk.org  Wed Jul  2 17:54:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Jul 2025 17:54:40 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop()
In-Reply-To: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
Message-ID: <M_GjZP2maUrKXs-aaPPYEGCTlsbz7NUALRmMESxNpXI=.6b58c427-0063-4776-b62d-dc6ad6e6512e@github.com>

On Wed, 2 Jul 2025 17:33:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> A module has both a Java and a C++ representation
> 
> - C++: `ModuleEntry`
> - Java: `java.lang.Module`
> 
> In C++, we have the following two methods
> 
> - `ModuleEntry* InstanceKlass::module()`
> - `oop ModuleEntry::module()`
> 
> This can lead to confusing code like this:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module()
> 
> 
> Proposal:
> 
> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module_oop()

I like this change other than precond().  ModuleEntry vs java.lang.Module oops is clearer with a different method name. I've been confused by this too.

src/hotspot/share/runtime/reflection.cpp line 555:

> 553:       } else {
> 554:         oop module_oop = module_to->module_oop();
> 555:         precond(module_oop != nullptr);

I don't like precond() when you could have a useful assert message instead.

src/hotspot/share/runtime/reflection.cpp line 582:

> 580:       } else {
> 581:         oop module_oop = module_from->module_oop();
> 582:         precond(module_oop != nullptr);

same here.  "Module oop should be non-null in ModuleEntry"

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980107062
PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2180644851
PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2180646204

From iklam at openjdk.org  Wed Jul  2 18:14:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 18:14:57 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <M_GjZP2maUrKXs-aaPPYEGCTlsbz7NUALRmMESxNpXI=.6b58c427-0063-4776-b62d-dc6ad6e6512e@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <M_GjZP2maUrKXs-aaPPYEGCTlsbz7NUALRmMESxNpXI=.6b58c427-0063-4776-b62d-dc6ad6e6512e@github.com>
Message-ID: <70Nl64CPVziB0aP054IDyxJE2YC5QV55GhkxmMgQs0E=.560e3a99-5e84-4b67-be2f-10925c6367d2@github.com>

On Wed, 2 Jul 2025 17:50:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @coleenp comments
>
> src/hotspot/share/runtime/reflection.cpp line 582:
> 
>> 580:       } else {
>> 581:         oop module_oop = module_from->module_oop();
>> 582:         precond(module_oop != nullptr);
> 
> same here.  "Module oop should be non-null in ModuleEntry"

We have just read the oop from the module entry and assert that it's not null, so the original message didn't add any extra information. That's why I removed it.

I have added back a message, "should have been initialized".

The real story is more complex, but I think this message willl give enough hints -- the module oop is usually initialized inside the ModuleEntry constructor, except for a few cases for the java.base module where the module oop is retroactively updated. In any case, by the time we reach this assert, the module oop must have been initialized in one of those possible paths.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2180678283

From iklam at openjdk.org  Wed Jul  2 18:14:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 18:14:57 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
Message-ID: <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>

> A module has both a Java and a C++ representation
> 
> - C++: `ModuleEntry`
> - Java: `java.lang.Module`
> 
> In C++, we have the following two methods
> 
> - `ModuleEntry* InstanceKlass::module()`
> - `oop ModuleEntry::module()`
> 
> This can lead to confusing code like this:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module()
> 
> 
> Proposal:
> 
> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module_oop()

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

  @coleenp comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26102/files
  - new: https://git.openjdk.org/jdk/pull/26102/files/69b453e2..f58f2852

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

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

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

From cslucas at openjdk.org  Wed Jul  2 18:24:39 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 2 Jul 2025 18:24:39 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
Message-ID: <3XqBb7N7ypUenwmwX2F8lRjRTeJxrXb8BfqN4vwvPa8=.eb0f51d5-8718-41b1-b89e-20b00ab9820e@github.com>

On Wed, 2 Jul 2025 11:27:25 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

LGTM. Thanks.

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

Marked as reviewed by cslucas (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25356#pullrequestreview-2980201037

From yzheng at openjdk.org  Wed Jul  2 18:41:46 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 18:41:46 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
Message-ID: <tA3DNbYHPp6qW4-869cSMGMDwnU9SVUp9WGv1gCuYVM=.b7f6baef-206e-44a9-8efe-f803a77a45f5@github.com>

On Wed, 2 Jul 2025 11:27:25 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

Thanks for the review! Passed Tier1-3

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

PR Comment: https://git.openjdk.org/jdk/pull/25356#issuecomment-3028957076

From yzheng at openjdk.org  Wed Jul  2 18:41:47 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 18:41:47 GMT
Subject: Integrated: 8357424: [JVMCI] Avoid incrementing decompilation count
 for hosted compiled nmethod
In-Reply-To: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
Message-ID: <i43UWll9T0ApM3y8LxSFSR4V8_y9mLcEzG_gtD-HEHk=.0b4acb86-0823-4c05-99f9-bade4e7a8f68@github.com>

On Wed, 21 May 2025 15:00:29 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.

This pull request has now been integrated.

Changeset: ea86a20e
Author:    Yudi Zheng <yzheng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea86a20e6d74baea54df32415d9096d3b7bba1d7
Stats:     58 lines in 5 files changed: 48 ins; 1 del; 9 mod

8357424: [JVMCI] Avoid incrementing decompilation count for hosted compiled nmethod

Reviewed-by: dnsimon, never, cslucas

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

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

From coleenp at openjdk.org  Wed Jul  2 19:04:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Jul 2025 19:04:38 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
Message-ID: <ZDpGtEPKiX9ABvT2DVwM3EbindU67prj_rfEIf1szUQ=.e557edf9-b673-46dd-887d-a33297cd28c8@github.com>

On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A module has both a Java and a C++ representation
>> 
>> - C++: `ModuleEntry`
>> - Java: `java.lang.Module`
>> 
>> In C++, we have the following two methods
>> 
>> - `ModuleEntry* InstanceKlass::module()`
>> - `oop ModuleEntry::module()`
>> 
>> This can lead to confusing code like this:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module()
>> 
>> 
>> Proposal:
>> 
>> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
>> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module_oop()
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980324205

From ccheung at openjdk.org  Wed Jul  2 21:28:40 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Jul 2025 21:28:40 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
Message-ID: <xvphoMpF8eAF7GtuW56aL_bt4DfQGXjOFdEFt6mJkqU=.c15cce10-eabb-432a-b349-c8f28e8bea8e@github.com>

On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A module has both a Java and a C++ representation
>> 
>> - C++: `ModuleEntry`
>> - Java: `java.lang.Module`
>> 
>> In C++, we have the following two methods
>> 
>> - `ModuleEntry* InstanceKlass::module()`
>> - `oop ModuleEntry::module()`
>> 
>> This can lead to confusing code like this:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module()
>> 
>> 
>> Proposal:
>> 
>> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
>> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module_oop()
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments

Looks good.

src/hotspot/share/classfile/moduleEntry.cpp line 52:

> 50: ModuleEntry* ModuleEntryTable::_javabase_module = nullptr;
> 51: 
> 52: oop ModuleEntry::module_oop() const { return _module_handle.resolve(); }

(Pre-existing) Just wondering why this one-liner function doesn't reside in the moduleEntry.hpp?

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980677723
PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2181000093

From iklam at openjdk.org  Wed Jul  2 21:52:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 21:52:44 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <xvphoMpF8eAF7GtuW56aL_bt4DfQGXjOFdEFt6mJkqU=.c15cce10-eabb-432a-b349-c8f28e8bea8e@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
 <xvphoMpF8eAF7GtuW56aL_bt4DfQGXjOFdEFt6mJkqU=.c15cce10-eabb-432a-b349-c8f28e8bea8e@github.com>
Message-ID: <padCj8omasOBWPUeezaLtnnERaKzLK_TttkYctLT_p0=.578c9522-263f-46a1-93e2-a1bd6dd50b99@github.com>

On Wed, 2 Jul 2025 21:25:04 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @coleenp comments
>
> src/hotspot/share/classfile/moduleEntry.cpp line 52:
> 
>> 50: ModuleEntry* ModuleEntryTable::_javabase_module = nullptr;
>> 51: 
>> 52: oop ModuleEntry::module_oop() const { return _module_handle.resolve(); }
> 
> (Pre-existing) Just wondering why this one-liner function doesn't reside in the moduleEntry.hpp?

I think it's because `OopHandle::resolve()` is an inline function, but we are not allowed to include `xxx.inline.hpp` in non-inlined `.hpp` files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2181036271

From sspitsyn at openjdk.org  Wed Jul  2 22:04:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 2 Jul 2025 22:04:43 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
Message-ID: <qrt85ua0kWKGSSGyDO0XDyFFBzsiOYQ_Rurhk5BgTKA=.6f6e079b-7685-4854-8aec-8c7a6135c4f9@github.com>

On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A module has both a Java and a C++ representation
>> 
>> - C++: `ModuleEntry`
>> - Java: `java.lang.Module`
>> 
>> In C++, we have the following two methods
>> 
>> - `ModuleEntry* InstanceKlass::module()`
>> - `oop ModuleEntry::module()`
>> 
>> This can lead to confusing code like this:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module()
>> 
>> 
>> Proposal:
>> 
>> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
>> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module_oop()
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980760653

From kbarrett at openjdk.org  Thu Jul  3 01:32:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 3 Jul 2025 01:32:53 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <LLpd1-mLP3Q6EoLyOgM65uXPooSxUuw51szHOjR6bF0=.8a18dc2a-6b9a-49a6-b3f9-fad520377a7c@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
 <LLpd1-mLP3Q6EoLyOgM65uXPooSxUuw51szHOjR6bF0=.8a18dc2a-6b9a-49a6-b3f9-fad520377a7c@github.com>
Message-ID: <fN-YSbHIJgK0sJ_O9fEtRgXSPyzrVT10D7_Cds5zvn0=.9a06b83c-984c-4f87-bce8-46639c458e4f@github.com>

On Wed, 2 Jul 2025 13:51:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
>> 
>> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
>> 
>> Tested in tiers 1-3 and GHA.
>
> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 936:
> 
>> 934:     __builtin_unreachable();
>> 935:   }
>> 936: #endif
> 
> I think this could be replaced with asserting non-null.  A failed assert calls a noreturn reporting
> function.

Although I wonder why the assert in Thread::current() isn't sufficient? Maybe non-null info isn't
propagating through the cast to JavaThread?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2181311538

From kbarrett at openjdk.org  Thu Jul  3 01:52:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 3 Jul 2025 01:52:41 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <SPURRbg_QDlnGackOfs8p6LKFH3f9AdHgRZu_s_bUkA=.183c6e9d-48be-4bf4-8f85-9923da9da039@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

make/hotspot/lib/CompileJvm.gmk line 199:

> 197:     DISABLED_WARNINGS_gcc_macroAssembler_ppc_sha.cpp := unused-const-variable, \
> 198:     DISABLED_WARNINGS_gcc_postaloc.cpp := address, \
> 199:     DISABLED_WARNINGS_gcc_shenandoahLock.cpp := stringop-overflow, \

What about this one in shenandoahLock.cpp?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2181357398

From kbarrett at openjdk.org  Thu Jul  3 05:36:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 3 Jul 2025 05:36:42 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <M6RgvhXwuZ6Rl3z62kcTVsbRMAlOVGuodqbsKyKHzFo=.bca79592-4adc-4027-88c3-1d70b7f86090@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

My suggestion of using assertions instead doesn't seem to work, still getting
bogus warnings. This is with gcc14.2 on linux-aarch64, which also uses
__atomic_load. That is mysteriously weird. The noreturn reporting function
should be roughly equivalent to calling an ordinary function with an
"unreachable" following it. But then, this whole issue is mysteriously weird.

But that's okay; I wasn't really all that keen on adding assertions to
suppress bogus compiler warnings anyway.

At this point I think this change should just not be made. It's a compiler
bug. The existing suppression of the warnings is fine with me.

I think what's really needed is for someone to file a gcc bug.  It's too bad
nobody did that when the issue was first noticed.  There's already a bug that
is similar, and might even be the same, even though it involves sanitizers and
ours doesn't:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775

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

PR Comment: https://git.openjdk.org/jdk/pull/26067#issuecomment-3030839463

From duke at openjdk.org  Thu Jul  3 07:47:40 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 3 Jul 2025 07:47:40 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <M6RgvhXwuZ6Rl3z62kcTVsbRMAlOVGuodqbsKyKHzFo=.bca79592-4adc-4027-88c3-1d70b7f86090@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
 <M6RgvhXwuZ6Rl3z62kcTVsbRMAlOVGuodqbsKyKHzFo=.bca79592-4adc-4027-88c3-1d70b7f86090@github.com>
Message-ID: <YunUc3j5XRipL9egR5B7dqs0ANTJ6ETSL2udnFcBXDY=.ea2ee97d-caf9-4a06-b02a-f63aebe00f8a@github.com>

On Thu, 3 Jul 2025 05:34:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> My suggestion of using assertions instead doesn't seem to work, still getting bogus warnings. This is with gcc14.2 on linux-aarch64, which also uses __atomic_load. That is mysteriously weird. The noreturn reporting function should be roughly equivalent to calling an ordinary function with an "unreachable" following it. But then, this whole issue is mysteriously weird.
> 
> But that's okay; I wasn't really all that keen on adding assertions to suppress bogus compiler warnings anyway.
> 
> At this point I think this change should just not be made. It's a compiler bug. The existing suppression of the warnings is fine with me.
> 
> I think what's really needed is for someone to file a gcc bug. It's too bad nobody did that when the issue was first noticed. There's already a bug that is similar, and might even be the same, even though it involves sanitizers and ours doesn't: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775

Thanks @kimbarrett, after looking at your findings I agree that it looks like a GCC bug, and therefore we should not do this change. I will try to make the smallest reproducible example and submit a bug report.

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

PR Comment: https://git.openjdk.org/jdk/pull/26067#issuecomment-3031232698

From bmaillard at openjdk.org  Thu Jul  3 08:09:41 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Thu, 3 Jul 2025 08:09:41 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v3]
In-Reply-To: <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
Message-ID: <maWBIt8kcPudZMLrGDrx_mg-VSg4619DYZjoMGjSP0w=.2f7d61ee-64ca-4045-bdf2-b38cc09e0dfe@github.com>

On Mon, 23 Jun 2025 12:39:23 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> A first part toward a better support of pure functions, but this time, with guidance from @iwanowww.
>> 
>> ## Pure Functions
>> 
>> Pure functions (considered here) are functions that have no side effects, no effect on the control flow (no exception or such), cannot deopt etc.. It's really a function that you can execute anywhere, with whichever arguments without effect other than wasting time. Integer division is not pure as dividing by zero is throwing. But many floating point functions will just return `NaN` or `+/-infinity` in problematic cases.
>> 
>> ## Scope
>> 
>> We are not going all powerful for now! It's mostly about identifying some pure functions and being able to remove them if the result is unused. Some other things are not part of this PR, on purpose. Especially, this PR doesn't propose a way to move pure calls around. The reason is that pure calls are later expanded into regular calls, which require a control input. To be able to do the expansion, we just keep the control in the pure call as well.
>> 
>> ## Implementation Overview
>> 
>> We created here some new node kind for pure calls, inheriting leaf calls, that are expanded into regular leaf calls during final graph reshaping. The possibility to support pure call directly in AD file is left open.
>> 
>> This PR also introduces `TupleNode` (largely based on an original idea/implem of @iwanowww), that just tie multiple input together and play well with `ProjNode`: the n-th projection of a `TupleNode` is the n-th input of the tuple. This is a convenient way to skip and remove nodes from the graph while delegating the difficulty of the surgery to the trusted IGVN's implementation.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mostly comments

src/hotspot/share/opto/parse2.cpp line 1100:

> 1098: Node* Parse::floating_point_mod(Node* a, Node* b, BasicType type) {
> 1099:   assert(type == BasicType::T_FLOAT || type == BasicType::T_DOUBLE, "only float and double are floating points");
> 1100:   CallLeafPureNode* mod = type == BasicType::T_DOUBLE ? static_cast<CallLeafPureNode*>(new ModDNode(C, a, b)) : new ModFNode(C, a, b);

May I ask why we only need the `static_cast` for the `ModDNode` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2180229177

From mchevalier at openjdk.org  Thu Jul  3 08:21:41 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 3 Jul 2025 08:21:41 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v3]
In-Reply-To: <maWBIt8kcPudZMLrGDrx_mg-VSg4619DYZjoMGjSP0w=.2f7d61ee-64ca-4045-bdf2-b38cc09e0dfe@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
 <maWBIt8kcPudZMLrGDrx_mg-VSg4619DYZjoMGjSP0w=.2f7d61ee-64ca-4045-bdf2-b38cc09e0dfe@github.com>
Message-ID: <CuisgEPT41ufLR9y4Gh7uSHe9XnYDFEznWcmfn1k0p8=.0c5e19be-1058-49d7-b3d3-f076c05efe67@github.com>

On Wed, 2 Jul 2025 14:35:26 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mostly comments
>
> src/hotspot/share/opto/parse2.cpp line 1100:
> 
>> 1098: Node* Parse::floating_point_mod(Node* a, Node* b, BasicType type) {
>> 1099:   assert(type == BasicType::T_FLOAT || type == BasicType::T_DOUBLE, "only float and double are floating points");
>> 1100:   CallLeafPureNode* mod = type == BasicType::T_DOUBLE ? static_cast<CallLeafPureNode*>(new ModDNode(C, a, b)) : new ModFNode(C, a, b);
> 
> May I ask why we only need the `static_cast` for the `ModDNode` here?

It's C/C++ being annoying here: both branches of the ternary must have the same type, or something compatible. If I remove the cast:

error: conditional expression between distinct pointer types 'ModDNode*' and 'ModFNode*' lacks a cast

With the case, C++ can converrt the `ModFNode*` into a `CallLeafPureNode*` just fine.

I didn't invent the cast, it was here before, but good to question it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2182166387

From duke at openjdk.org  Thu Jul  3 12:04:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 3 Jul 2025 12:04:44 GMT
Subject: Withdrawn: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <ifHIvUSdpFXevUEdGdw4H2NlTNegBILudXcalRwNBpQ=.7f952342-0bcb-4ba4-be49-6618d4b6755d@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

This pull request has been closed without being integrated.

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

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

From dnsimon at openjdk.org  Thu Jul  3 13:04:19 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 3 Jul 2025 13:04:19 GMT
Subject: RFR: 8361355: Negative cases of Annotated.getAnnotationData
 implementations are broken
Message-ID: <cohGbjCNQm82-Z5NSUgZG99WKJvpM5MI8USxpGp83r8=.2760c8ac-2b2d-4723-9a59-7b5c0ad894c4@github.com>

This PR fixes bugs in the implementation of `jdk.vm.ci.meta.Annotated.getAnnotationData`:
1. Calling `getAnnotatedData(annotationType)` fails with an ArrayIndexOutOfBoundsException instead of returning null when the receiver type is not annotated by `annotationType`.
2. Calling either of the `getAnnotatedData` methods with an `annotationType` value that does not represent an annotation interface silently succeeds when the receiver type does not (or can not) have any annotations (e.g. array and primitive types).

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

Commit messages:
 - fixed negative cases in getAnnotationData

Changes: https://git.openjdk.org/jdk/pull/26116/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361355
  Stats: 100 lines in 7 files changed: 89 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26116/head:pull/26116

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

From dnsimon at openjdk.org  Thu Jul  3 14:13:23 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 3 Jul 2025 14:13:23 GMT
Subject: RFR: 8361355: Negative cases of Annotated.getAnnotationData
 implementations are broken [v2]
In-Reply-To: <cohGbjCNQm82-Z5NSUgZG99WKJvpM5MI8USxpGp83r8=.2760c8ac-2b2d-4723-9a59-7b5c0ad894c4@github.com>
References: <cohGbjCNQm82-Z5NSUgZG99WKJvpM5MI8USxpGp83r8=.2760c8ac-2b2d-4723-9a59-7b5c0ad894c4@github.com>
Message-ID: <qLrEtZyJoMNuLbTvInqMDNq4zXQOCKTiDB-RALaWlfI=.df688f18-847e-4c19-8df0-741684de0f5d@github.com>

> This PR fixes bugs in the implementation of `jdk.vm.ci.meta.Annotated.getAnnotationData`:
> 1. Calling `getAnnotatedData(annotationType)` fails with an ArrayIndexOutOfBoundsException instead of returning null when the receiver type is not annotated by `annotationType`.
> 2. Calling either of the `getAnnotatedData` methods with an `annotationType` value that does not represent an annotation interface silently succeeds when the receiver type does not (or can not) have any annotations (e.g. array and primitive types).

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:

  fixed negative cases in getAnnotationData

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26116/files
  - new: https://git.openjdk.org/jdk/pull/26116/files/86b41636..b25684f7

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

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

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

From never at openjdk.org  Thu Jul  3 14:59:39 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 3 Jul 2025 14:59:39 GMT
Subject: RFR: 8361355: Negative cases of Annotated.getAnnotationData
 implementations are broken [v2]
In-Reply-To: <qLrEtZyJoMNuLbTvInqMDNq4zXQOCKTiDB-RALaWlfI=.df688f18-847e-4c19-8df0-741684de0f5d@github.com>
References: <cohGbjCNQm82-Z5NSUgZG99WKJvpM5MI8USxpGp83r8=.2760c8ac-2b2d-4723-9a59-7b5c0ad894c4@github.com>
 <qLrEtZyJoMNuLbTvInqMDNq4zXQOCKTiDB-RALaWlfI=.df688f18-847e-4c19-8df0-741684de0f5d@github.com>
Message-ID: <Fsba_umnU1gPwEHktfkrSxPYO60SMFOwkruPZV6fNi8=.3296d600-05b9-421f-9fca-97a983b2b393@github.com>

On Thu, 3 Jul 2025 14:13:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes bugs in the implementation of `jdk.vm.ci.meta.Annotated.getAnnotationData`:
>> 1. Calling `getAnnotatedData(annotationType)` fails with an ArrayIndexOutOfBoundsException instead of returning null when the receiver type is not annotated by `annotationType`.
>> 2. Calling either of the `getAnnotatedData` methods with an `annotationType` value that does not represent an annotation interface silently succeeds when the receiver type does not (or can not) have any annotations (e.g. array and primitive types).
>
> 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:
> 
>   fixed negative cases in getAnnotationData

Looks good.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26116#pullrequestreview-2983525519

From iklam at openjdk.org  Thu Jul  3 16:55:45 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 16:55:45 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <ZDpGtEPKiX9ABvT2DVwM3EbindU67prj_rfEIf1szUQ=.e557edf9-b673-46dd-887d-a33297cd28c8@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
 <ZDpGtEPKiX9ABvT2DVwM3EbindU67prj_rfEIf1szUQ=.e557edf9-b673-46dd-887d-a33297cd28c8@github.com>
Message-ID: <7t8AhNKgTL2MU_ba0F3rCllEqaodLFmshj_9QvGwY00=.1ba3ff82-905d-4b7a-8b4a-6944f5b22b5e@github.com>

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

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @coleenp comments
>
> Marked as reviewed by coleenp (Reviewer).

Thanks @coleenp @calvinccheung @sspitsyn for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26102#issuecomment-3032931506

From iklam at openjdk.org  Thu Jul  3 16:55:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 16:55:46 GMT
Subject: Integrated: 8361292: Rename ModuleEntry::module() to module_oop()
In-Reply-To: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
Message-ID: <fXTbvFMYMe66iLraa3BsajA01nJEjlG-7x5AF-n9UcE=.c1e291d9-ed1d-4ca8-bd3b-8917f838f55b@github.com>

On Wed, 2 Jul 2025 17:33:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> A module has both a Java and a C++ representation
> 
> - C++: `ModuleEntry`
> - Java: `java.lang.Module`
> 
> In C++, we have the following two methods
> 
> - `ModuleEntry* InstanceKlass::module()`
> - `oop ModuleEntry::module()`
> 
> This can lead to confusing code like this:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module()
> 
> 
> Proposal:
> 
> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module_oop()

This pull request has now been integrated.

Changeset: 66836d40
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66836d40b80f9c5482c1322d1d07f078ad9dcc02
Stats:     35 lines in 12 files changed: 0 ins; 0 del; 35 mod

8361292: Rename ModuleEntry::module() to module_oop()

Reviewed-by: coleenp, ccheung, sspitsyn

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

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

From dnsimon at openjdk.org  Thu Jul  3 17:30:56 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 3 Jul 2025 17:30:56 GMT
Subject: RFR: 8361355: Negative cases of Annotated.getAnnotationData
 implementations are broken [v3]
In-Reply-To: <cohGbjCNQm82-Z5NSUgZG99WKJvpM5MI8USxpGp83r8=.2760c8ac-2b2d-4723-9a59-7b5c0ad894c4@github.com>
References: <cohGbjCNQm82-Z5NSUgZG99WKJvpM5MI8USxpGp83r8=.2760c8ac-2b2d-4723-9a59-7b5c0ad894c4@github.com>
Message-ID: <83aGkzmp5J7JllBsWK5ZzwZAa4GVsNk5VjmkH0O3FjE=.2507d7ce-65df-4121-acdf-35125d530d39@github.com>

> This PR fixes bugs in the implementation of `jdk.vm.ci.meta.Annotated.getAnnotationData`:
> 1. Calling `getAnnotatedData(annotationType)` fails with an ArrayIndexOutOfBoundsException instead of returning null when the receiver type is not annotated by `annotationType`.
> 2. Calling either of the `getAnnotatedData` methods with an `annotationType` value that does not represent an annotation interface silently succeeds when the receiver type does not (or can not) have any annotations (e.g. array and primitive types).

Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge tag 'jdk-26+4' into JDK-8361355
   
   Added tag jdk-26+4 for changeset 1ca008fd
 - fixed negative cases in getAnnotationData

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26116/files
  - new: https://git.openjdk.org/jdk/pull/26116/files/b25684f7..ec161d59

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

  Stats: 6616 lines in 362 files changed: 3437 ins; 1484 del; 1695 mod
  Patch: https://git.openjdk.org/jdk/pull/26116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26116/head:pull/26116

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

From dnsimon at openjdk.org  Fri Jul  4 07:39:45 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 4 Jul 2025 07:39:45 GMT
Subject: RFR: 8361355: Negative cases of Annotated.getAnnotationData
 implementations are broken [v3]
In-Reply-To: <83aGkzmp5J7JllBsWK5ZzwZAa4GVsNk5VjmkH0O3FjE=.2507d7ce-65df-4121-acdf-35125d530d39@github.com>
References: <cohGbjCNQm82-Z5NSUgZG99WKJvpM5MI8USxpGp83r8=.2760c8ac-2b2d-4723-9a59-7b5c0ad894c4@github.com>
 <83aGkzmp5J7JllBsWK5ZzwZAa4GVsNk5VjmkH0O3FjE=.2507d7ce-65df-4121-acdf-35125d530d39@github.com>
Message-ID: <Qh_2AKnayOXRa-epSEYLlQxTyPjsccDj5M9_keDIUo4=.414de626-661f-4238-8029-0c30076e24c8@github.com>

On Thu, 3 Jul 2025 17:30:56 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes bugs in the implementation of `jdk.vm.ci.meta.Annotated.getAnnotationData`:
>> 1. Calling `getAnnotatedData(annotationType)` fails with an ArrayIndexOutOfBoundsException instead of returning null when the receiver type is not annotated by `annotationType`.
>> 2. Calling either of the `getAnnotatedData` methods with an `annotationType` value that does not represent an annotation interface silently succeeds when the receiver type does not (or can not) have any annotations (e.g. array and primitive types).
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge tag 'jdk-26+4' into JDK-8361355
>    
>    Added tag jdk-26+4 for changeset 1ca008fd
>  - fixed negative cases in getAnnotationData

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26116#issuecomment-3034837278

From dnsimon at openjdk.org  Fri Jul  4 07:39:46 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 4 Jul 2025 07:39:46 GMT
Subject: Integrated: 8361355: Negative cases of Annotated.getAnnotationData
 implementations are broken
In-Reply-To: <cohGbjCNQm82-Z5NSUgZG99WKJvpM5MI8USxpGp83r8=.2760c8ac-2b2d-4723-9a59-7b5c0ad894c4@github.com>
References: <cohGbjCNQm82-Z5NSUgZG99WKJvpM5MI8USxpGp83r8=.2760c8ac-2b2d-4723-9a59-7b5c0ad894c4@github.com>
Message-ID: <X1MHi5lX4GL1k7rdwaAUH-54ybpbpn5JTl5HuQChb4o=.4831eb8a-ede8-4946-bfe1-348871a11bdc@github.com>

On Thu, 3 Jul 2025 12:52:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR fixes bugs in the implementation of `jdk.vm.ci.meta.Annotated.getAnnotationData`:
> 1. Calling `getAnnotatedData(annotationType)` fails with an ArrayIndexOutOfBoundsException instead of returning null when the receiver type is not annotated by `annotationType`.
> 2. Calling either of the `getAnnotatedData` methods with an `annotationType` value that does not represent an annotation interface silently succeeds when the receiver type does not (or can not) have any annotations (e.g. array and primitive types).

This pull request has now been integrated.

Changeset: 5cf349c3
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cf349c3b08324e994a4143dcc34a59fd81323f9
Stats:     111 lines in 7 files changed: 94 ins; 1 del; 16 mod

8361355: Negative cases of Annotated.getAnnotationData implementations are broken

Reviewed-by: never

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

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

From dnsimon at openjdk.org  Sat Jul  5 10:31:37 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 5 Jul 2025 10:31:37 GMT
Subject: RFR: 8361417: JVMCI getModifiers incorrect for inner classes
Message-ID: <rHz-CKdAzIvHj_WLHRJPgmJkF2cq4XXmxZE7hjvfRo4=.fa83568f-7edd-41ae-ae8a-7c01064baafa@github.com>

The result of `ResolvedJavaType.getModifiers()` should always have been the same as `Class.getModifiers()`. This is currently not the case for inner classes. Instead, the value is derived from `Klass::_access_flags` where as it should be derived from the `InnerClasses` attribute (as it is for `Class`).

This PR aligns `ResolvedJavaType.getModifiers()` with `Class.getModifiers()`.

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

Commit messages:
 - fix getModifiers() for inner classes

Changes: https://git.openjdk.org/jdk/pull/26135/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361417
  Stats: 71 lines in 7 files changed: 36 ins; 20 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26135/head:pull/26135

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

From missa at openjdk.org  Mon Jul  7 03:10:15 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 7 Jul 2025 03:10:15 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
Message-ID: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>

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.

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

Commit messages:
 - x86_64 intrinsic for sinh using libm

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

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

From fweimer at openjdk.org  Mon Jul  7 04:50:37 2025
From: fweimer at openjdk.org (Florian Weimer)
Date: Mon, 7 Jul 2025 04:50:37 GMT
Subject: RFR: 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: <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@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.

Isn't this effectively a libm benchmark (where the `sinh` implementation resides)? Please include the libm version for reference here. Thanks.

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

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

From thartmann at openjdk.org  Mon Jul  7 07:45:46 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Jul 2025 07:45:46 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v2]
In-Reply-To: <1cFRkcs5JmgnbWEIaEoT8I9RiUtNxgKieAdkSB2Fgmc=.1d97b5c4-b6ef-43c6-b721-1e52eee19d3a@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <1cFRkcs5JmgnbWEIaEoT8I9RiUtNxgKieAdkSB2Fgmc=.1d97b5c4-b6ef-43c6-b721-1e52eee19d3a@github.com>
Message-ID: <MLgVzZUWbtjxLMCCCV-fBKTxt8RtEJdZ2lxpN0M1zyY=.691d18b0-b34e-4dab-aa87-1dd1367a33ca@github.com>

On Tue, 1 Jul 2025 16:14:00 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove useless loop

Nice analysis! In general, the fix looks good to me. I added a few comments / suggestions.

src/hotspot/share/opto/library_call.cpp line 1732:

> 1730:     return false;
> 1731:   }
> 1732:   destruct_map_clone(old_state.map);

I think `destruct_map_clone` could be refactored to take a `SavedState`.

src/hotspot/share/opto/library_call.cpp line 2376:

> 2374:   state.map = clone_map();
> 2375:   for (DUIterator_Fast imax, i = control()->fast_outs(imax); i < imax; i++) {
> 2376:     Node* out = control()->fast_out(i);

Could we have a similar issue with non-control users? For example, couldn't we also have stray memory users after bailout?

src/hotspot/share/opto/library_call.cpp line 2393:

> 2391:     Node* out = control()->fast_out(i);
> 2392:     if (out->is_CFG() && out->in(0) == control() && out != map() && !state.ctrl_succ.member(out)) {
> 2393:       out->set_req(0, C->top());

Could `out` already be in the GVN hash ("remove node from hash table before modifying it")?

src/hotspot/share/opto/library_call.hpp line 129:

> 127:   virtual int reexecute_sp() { return _reexecute_sp; }
> 128: 
> 129:   struct SavedState {

Please add a comment describing what it's used for.

test/hotspot/jtreg/compiler/intrinsics/VectorIntoArrayInvalidControlFlow.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 104:

> 102:     public static final String START = "(\\d+(\\s){2}(";
> 103:     public static final String MID = ".*)+(\\s){2}===.*";
> 104:     public static final String END = ")";

I don't like exposing these outside the IR framework but then again I don't really have an idea on how to check the "graph should not have both nodes" invariant. Maybe we should extend the `counts` annotation to support something like `@IR(counts = {IRNode.CallStaticJava, IRNode.OpaqueNotNull, "<= 1"} [...]`?

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25936#pullrequestreview-2992473824
PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2189175998
PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2189211960
PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2189198041
PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2189172691
PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2189212910
PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2189244934

From thartmann at openjdk.org  Mon Jul  7 08:35:50 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Jul 2025 08:35:50 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v3]
In-Reply-To: <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
Message-ID: <bRDGJYkDtDsmXI8ye0z8mlfr57k58MpSUHF5mz0rjOQ=.966e1317-1b56-4d46-a9be-743711fc7018@github.com>

On Mon, 23 Jun 2025 12:39:23 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> A first part toward a better support of pure functions, but this time, with guidance from @iwanowww.
>> 
>> ## Pure Functions
>> 
>> Pure functions (considered here) are functions that have no side effects, no effect on the control flow (no exception or such), cannot deopt etc.. It's really a function that you can execute anywhere, with whichever arguments without effect other than wasting time. Integer division is not pure as dividing by zero is throwing. But many floating point functions will just return `NaN` or `+/-infinity` in problematic cases.
>> 
>> ## Scope
>> 
>> We are not going all powerful for now! It's mostly about identifying some pure functions and being able to remove them if the result is unused. Some other things are not part of this PR, on purpose. Especially, this PR doesn't propose a way to move pure calls around. The reason is that pure calls are later expanded into regular calls, which require a control input. To be able to do the expansion, we just keep the control in the pure call as well.
>> 
>> ## Implementation Overview
>> 
>> We created here some new node kind for pure calls, inheriting leaf calls, that are expanded into regular leaf calls during final graph reshaping. The possibility to support pure call directly in AD file is left open.
>> 
>> This PR also introduces `TupleNode` (largely based on an original idea/implem of @iwanowww), that just tie multiple input together and play well with `ProjNode`: the n-th projection of a `TupleNode` is the n-th input of the tuple. This is a convenient way to skip and remove nodes from the graph while delegating the difficulty of the surgery to the trusted IGVN's implementation.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mostly comments

Thanks for digging into this Marc. The changes look good to me. I just added a few minor comments / questions.

> this PR doesn't propose a way to move pure calls around

Should we have a separate RFE for that?

src/hotspot/share/opto/divnode.cpp line 1522:

> 1520:   Node* super = CallLeafPureNode::Ideal(phase, can_reshape);
> 1521:   if (super != nullptr) {
> 1522:     return super;

Can't we just do `return CallLeafPureNode::Ideal(phase, can_reshape);` at the end of `ModFNode::Ideal` instead of `return nullptr`? That's what we usually do in C2, for example in `CallStaticJavaNode::Ideal` -> `CallNode::Ideal`. Feels more natural to me and would avoid the `super != nullptr` check. Also for the other `Ideal` methods that you modified.

src/hotspot/share/opto/divnode.cpp line 1528:

> 1526:   bool not_dead = proj_out_or_null(TypeFunc::Control) != nullptr;
> 1527:   if (result_is_unused && not_dead) {
> 1528:     return replace_with_con(igvn, TypeF::make(0.));

Can we replace all the other usages of `ModFloatingNode::replace_with_con` by `TupleNode` and get rid of that method?

src/hotspot/share/opto/graphKit.cpp line 1916:

> 1914:   if (call->is_CallLeafPure()) {
> 1915:     // Pure function have only control (for now) and data output, in particular
> 1916:     // the don't touch the memory, so we don't want a memory proj that is set after.

Suggestion:

    // they don't touch the memory, so we don't want a memory proj that is set after.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25760#pullrequestreview-2992602888
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2189268498
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2189357774
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2189261824

From tschatzl at openjdk.org  Mon Jul  7 12:36:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Jul 2025 12:36:40 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@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 57 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
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - * indentation fix
 - ... and 47 more: https://git.openjdk.org/jdk/compare/d75ea7e6...441c234a

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=40
  Stats: 7121 lines in 112 files changed: 2585 ins; 3590 del; 946 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  Mon Jul  7 13:07:55 2025
From: duke at openjdk.org (Andrej =?UTF-8?B?UGXEjWltw7p0aA==?=)
Date: Mon, 7 Jul 2025 13:07:55 GMT
Subject: RFR: 8357689: Refactor JVMCI to enable replay compilation in Graal
Message-ID: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>

This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.

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

Commit messages:
 - Remove an unused import.
 - Use a pattern variable.
 - use list when applicable
 - JVMCI refactorings to enable replay compilation in Graal.

Changes: https://git.openjdk.org/jdk/pull/25433/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25433&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357689
  Stats: 434 lines in 21 files changed: 310 ins; 8 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/25433.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25433/head:pull/25433

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

From dnsimon at openjdk.org  Mon Jul  7 13:07:56 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 7 Jul 2025 13:07:56 GMT
Subject: RFR: 8357689: Refactor JVMCI to enable replay compilation in Graal
In-Reply-To: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
References: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
Message-ID: <sh7-AGVGRDZHBuAWLfPu2J_t8oW-sAhV_xDLdZj6mvE=.11c545fa-d2cf-426c-bc0c-68e1712010bf@github.com>

On Sat, 24 May 2025 16:49:23 GMT, Andrej Pe?im?th <duke at openjdk.org> wrote:

> This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/BytecodeFrame.java line 397:

> 395:      * @return a copy of the slot kinds array
> 396:      */
> 397:     public JavaKind[] getSlotKinds() {

Keep in mind that `slotKinds` is being [converted](https://github.com/openjdk/jdk/pull/25442/files#diff-43834727ed7dcd5128c10238ba56963c7d8feb66578b036c75dcf734bfa2ec92R80) to a List. In that context, can we return the list without making a copy? Or is the caller expected to be able to mutate the return value?

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/VirtualObject.java line 293:

> 291:             return true;
> 292:         }
> 293:         if (o instanceof VirtualObject) {

Rename `l` to `that` and use pattern instanceof:
Suggestion:

        if (o instanceof VirtualObject that) {

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/VirtualObject.java line 325:

> 323:      *         values have not been initialized.
> 324:      */
> 325:     public JavaKind[] getSlotKinds() {

Same comments as for BytecodeFrame.getSlotKinds. This applies to all other non-primitive array return values added by this PR.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCode.java line 225:

> 223:      * Returns a copy of the array of {@link ResolvedJavaMethod} objects representing the methods
> 224:      * whose bytecodes were used as input to the compilation. If the compilation did not record
> 225:      * method dependencies, this method returns {@code null}. Otherwise, the first element of the

null -> empty list?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25433#discussion_r2109017920
PR Review Comment: https://git.openjdk.org/jdk/pull/25433#discussion_r2109025913
PR Review Comment: https://git.openjdk.org/jdk/pull/25433#discussion_r2109034172
PR Review Comment: https://git.openjdk.org/jdk/pull/25433#discussion_r2109040017

From duke at openjdk.org  Mon Jul  7 13:07:56 2025
From: duke at openjdk.org (Andrej =?UTF-8?B?UGXEjWltw7p0aA==?=)
Date: Mon, 7 Jul 2025 13:07:56 GMT
Subject: RFR: 8357689: Refactor JVMCI to enable replay compilation in Graal
In-Reply-To: <sh7-AGVGRDZHBuAWLfPu2J_t8oW-sAhV_xDLdZj6mvE=.11c545fa-d2cf-426c-bc0c-68e1712010bf@github.com>
References: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
 <sh7-AGVGRDZHBuAWLfPu2J_t8oW-sAhV_xDLdZj6mvE=.11c545fa-d2cf-426c-bc0c-68e1712010bf@github.com>
Message-ID: <vbv4FtV4iNsmHdzrdrwNs5gr1S4rBtuqvBKZSkOgt-c=.c3c85f5d-a7f7-4d11-bd57-7af328e8677a@github.com>

On Tue, 27 May 2025 12:10:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/BytecodeFrame.java line 397:
> 
>> 395:      * @return a copy of the slot kinds array
>> 396:      */
>> 397:     public JavaKind[] getSlotKinds() {
> 
> Keep in mind that `slotKinds` is being [converted](https://github.com/openjdk/jdk/pull/25442/files#diff-43834727ed7dcd5128c10238ba56963c7d8feb66578b036c75dcf734bfa2ec92R80) to a List. In that context, can we return the list without making a copy? Or is the caller expected to be able to mutate the return value?

Applied the changes provided by @mur47x111.

> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/VirtualObject.java line 325:
> 
>> 323:      *         values have not been initialized.
>> 324:      */
>> 325:     public JavaKind[] getSlotKinds() {
> 
> Same comments as for BytecodeFrame.getSlotKinds. This applies to all other non-primitive array return values added by this PR.

I left `Object[]` as the return value of `EncodedSpeculationReason#getReason` since the array could contain null elements, preventing the use of an immutable list like everywhere else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25433#discussion_r2189993024
PR Review Comment: https://git.openjdk.org/jdk/pull/25433#discussion_r2190003945

From darcy at openjdk.org  Mon Jul  7 18:03:40 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 7 Jul 2025 18:03:40 GMT
Subject: RFR: 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: <yyN0jPn_XoNypYbnSd4IZqOwTGBArdUT_AVuHAalmA4=.71b030d8-281a-4ea3-8790-85ad7c8bb8fa@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.

Are there plans for a cosh intrinsic as follow-up work? There was a previous effort to intrinsify tanh.

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

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

From darcy at openjdk.org  Mon Jul  7 18:06:39 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 7 Jul 2025 18:06:39 GMT
Subject: RFR: 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: <rF2JkysAnRhQJe6P2RLD0H94OFzaY2vIXyaTQJVa42c=.3d07381b-3c2e-49d4-8446-a91ea50c5ae8@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.

A large fraction of floating-point numbers are in the [-2^(-28), 2^(-28)] range where there is a performance degradation with the new implementation.

What is the expected distribution of arguments to sinh?

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

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

From missa at openjdk.org  Mon Jul  7 23:36:39 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 7 Jul 2025 23:36:39 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <rF2JkysAnRhQJe6P2RLD0H94OFzaY2vIXyaTQJVa42c=.3d07381b-3c2e-49d4-8446-a91ea50c5ae8@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <rF2JkysAnRhQJe6P2RLD0H94OFzaY2vIXyaTQJVa42c=.3d07381b-3c2e-49d4-8446-a91ea50c5ae8@github.com>
Message-ID: <DhH0T1l6DljbZXq4tstMPUjmUeLSqE7HCDFCHyL-7A0=.d5b0e360-3f53-440b-9226-3d21e0619745@github.com>

On Mon, 7 Jul 2025 18:03:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A large fraction of floating-point numbers are in the [-2^(-28), 2^(-28)] range where there is a performance degradation with the new implementation.
> 
> What is the expected distribution of arguments to sinh?

I don't know about an expected distribution of distribution of arguments to sinh. From glancing through research papers though, I get the sense that the [-2^(-28), 2^(-28)] range isn't used all that much. A couple of papers showing this are linked below.

1. [An Analysis of the Hyperbolic Bid Stacking Technique's Use in Modeling Power Prices](https://dl.acm.org/doi/10.1145/3640115.3640182)
2. [Experimental Validation of a 3GPP compliant 5G-based Positioning System](https://dl.acm.org/doi/10.1145/3636534.3697324)

I think the [-2^(-28), 2^(-28)] range isn't all that interesting for sinh anyway as it just returns the input itself. So, I doubt any applications are relying all that heavily on it.

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

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

From missa at openjdk.org  Mon Jul  7 23:47:38 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 7 Jul 2025 23:47:38 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <yyN0jPn_XoNypYbnSd4IZqOwTGBArdUT_AVuHAalmA4=.71b030d8-281a-4ea3-8790-85ad7c8bb8fa@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <yyN0jPn_XoNypYbnSd4IZqOwTGBArdUT_AVuHAalmA4=.71b030d8-281a-4ea3-8790-85ad7c8bb8fa@github.com>
Message-ID: <Drup9Nkvcw7CHLGlJGtJmzSvYFQZd7dIU6qmnzBLXPQ=.940e6988-52d1-43fc-804c-30e87220a0a4@github.com>

On Mon, 7 Jul 2025 18:01:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Are there plans for a cosh intrinsic as follow-up work? There was a previous effort to intrinsify tanh.

Yes, the intention is to have cosh as next math intrinsic.

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

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

From missa at openjdk.org  Mon Jul  7 23:55:39 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 7 Jul 2025 23:55:39 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>
Message-ID: <Wse6mX1Slo3KvItTvCLqE_BMswyGSTDinY-Lp9Y-6nw=.54164a56-2d48-4c8a-8dcf-98c4e85fcbc5@github.com>

On Mon, 7 Jul 2025 04:48:18 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> Isn't this effectively a libm benchmark (where the `sinh` implementation resides)? Please include the libm version for reference here. Thanks.

I'm not sure which libm version you're referring to. The only current sinh benchmark I'm aware of is in MathBench.java, and the benchmarks in SinhPerf.java didn't exist until now. Could you clarify?

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

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

From duke at openjdk.org  Tue Jul  8 08:41:59 2025
From: duke at openjdk.org (Andrej =?UTF-8?B?UGXEjWltw7p0aA==?=)
Date: Tue, 8 Jul 2025 08:41:59 GMT
Subject: RFR: 8357689: Refactor JVMCI to enable replay compilation in Graal
 [v2]
In-Reply-To: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
References: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
Message-ID: <iqN9QLD_matBDQ38zBLTkLhCtqEJcLUvlcqwr_e6EXY=.fb994799-9b1d-4ec8-ba0f-f330c1f88ccc@github.com>

> This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.

Andrej Pe?im?th 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:

  JVMCI refactorings to enable replay compilation in Graal.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25433/files
  - new: https://git.openjdk.org/jdk/pull/25433/files/c12f507c..c6c3bb62

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

  Stats: 204 lines in 10 files changed: 3 ins; 88 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/25433.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25433/head:pull/25433

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

From duke at openjdk.org  Tue Jul  8 08:41:59 2025
From: duke at openjdk.org (Andrej =?UTF-8?B?UGXEjWltw7p0aA==?=)
Date: Tue, 8 Jul 2025 08:41:59 GMT
Subject: RFR: 8357689: Refactor JVMCI to enable replay compilation in Graal
 [v2]
In-Reply-To: <iqN9QLD_matBDQ38zBLTkLhCtqEJcLUvlcqwr_e6EXY=.fb994799-9b1d-4ec8-ba0f-f330c1f88ccc@github.com>
References: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
 <iqN9QLD_matBDQ38zBLTkLhCtqEJcLUvlcqwr_e6EXY=.fb994799-9b1d-4ec8-ba0f-f330c1f88ccc@github.com>
Message-ID: <MUMlhL0J9qcNXV5_OunP71qpi8fNznAIdAnMUzjrgj8=.40cd10a4-b86d-4af7-aa77-030c2da14024@github.com>

On Tue, 8 Jul 2025 08:37:53 GMT, Andrej Pe?im?th <duke at openjdk.org> wrote:

>> This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.
>
> Andrej Pe?im?th 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:
> 
>   JVMCI refactorings to enable replay compilation in Graal.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/BytecodeFrame.java line 227:

> 225:         this.duringCall = duringCall;
> 226:         this.values = values;
> 227:         this.slotKinds = listFromTrustedArray(slotKinds);

`ImmutableCollections#listFromTrustedArray` asserts that the array class is `Object[].class`, but the type of `slotKinds` is `JavaKind[]` - so these refactorings do not work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25433#discussion_r2190153203

From mchevalier at openjdk.org  Tue Jul  8 13:38:26 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 8 Jul 2025 13:38:26 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v3]
In-Reply-To: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
Message-ID: <l3CJvcJVP7GAX6FBbBdpYZkAhF8pgoluIa2yVL7OnkM=.8821362e-7b65-4e1d-9038-5862158d7bf2@github.com>

> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
> 
> This is enforced by restoring the old state, like in
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
> 
> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
> 
> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
> 
> 
> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
> 
> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
> 
> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
> 
> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
> 
> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
> 
> And here there is the challenge:
> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
> - we can't really change the pointer, just the content
> -...

Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge remote-tracking branch 'origin/master' into fix/too-many-ctrl-successor-after-intrinsic
 - Address comments
 - Remove useless loop
 - whoops Forgot to remove a bit, and restore sp
 - Urgh
 - Adapt test
 - Re-try
 - Fix test
 - Trying something

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

Changes: https://git.openjdk.org/jdk/pull/25936/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25936&range=02
  Stats: 349 lines in 7 files changed: 230 ins; 50 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/25936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25936/head:pull/25936

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

From mchevalier at openjdk.org  Tue Jul  8 13:38:26 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 8 Jul 2025 13:38:26 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v2]
In-Reply-To: <MLgVzZUWbtjxLMCCCV-fBKTxt8RtEJdZ2lxpN0M1zyY=.691d18b0-b34e-4dab-aa87-1dd1367a33ca@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <1cFRkcs5JmgnbWEIaEoT8I9RiUtNxgKieAdkSB2Fgmc=.1d97b5c4-b6ef-43c6-b721-1e52eee19d3a@github.com>
 <MLgVzZUWbtjxLMCCCV-fBKTxt8RtEJdZ2lxpN0M1zyY=.691d18b0-b34e-4dab-aa87-1dd1367a33ca@github.com>
Message-ID: <IimPEYdzOwWkrNrM-wZ-N27NBF3pgGwDnop960nvb7g=.7c53e368-fa49-4674-b860-2bed100fc5a9@github.com>

On Mon, 7 Jul 2025 07:28:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove useless loop
>
> src/hotspot/share/opto/library_call.cpp line 2376:
> 
>> 2374:   state.map = clone_map();
>> 2375:   for (DUIterator_Fast imax, i = control()->fast_outs(imax); i < imax; i++) {
>> 2376:     Node* out = control()->fast_out(i);
> 
> Could we have a similar issue with non-control users? For example, couldn't we also have stray memory users after bailout?

We could, but it should be relatively harmless. Control is more annoying to have more than one successor.

> src/hotspot/share/opto/library_call.cpp line 2393:
> 
>> 2391:     Node* out = control()->fast_out(i);
>> 2392:     if (out->is_CFG() && out->in(0) == control() && out != map() && !state.ctrl_succ.member(out)) {
>> 2393:       out->set_req(0, C->top());
> 
> Could `out` already be in the GVN hash ("remove node from hash table before modifying it")?

I've added it, since indeed, it could. As far as I understand, I was just lucky in the situation where it happens, but there is no reason it would always hold.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2192553330
PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2192556138

From mchevalier at openjdk.org  Tue Jul  8 13:44:45 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 8 Jul 2025 13:44:45 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v2]
In-Reply-To: <MLgVzZUWbtjxLMCCCV-fBKTxt8RtEJdZ2lxpN0M1zyY=.691d18b0-b34e-4dab-aa87-1dd1367a33ca@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <1cFRkcs5JmgnbWEIaEoT8I9RiUtNxgKieAdkSB2Fgmc=.1d97b5c4-b6ef-43c6-b721-1e52eee19d3a@github.com>
 <MLgVzZUWbtjxLMCCCV-fBKTxt8RtEJdZ2lxpN0M1zyY=.691d18b0-b34e-4dab-aa87-1dd1367a33ca@github.com>
Message-ID: <053aI6bIhjDWZgWQSx_KRGcDzAxg2DF86WNVBco2DkA=.7ccf19bf-3fa7-471d-929c-d20f01006235@github.com>

On Mon, 7 Jul 2025 07:18:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove useless loop
>
> src/hotspot/share/opto/library_call.cpp line 1732:
> 
>> 1730:     return false;
>> 1731:   }
>> 1732:   destruct_map_clone(old_state.map);
> 
> I think `destruct_map_clone` could be refactored to take a `SavedState`.

I've made an override of destruct_map_clone taking a SavedState (and delegating to the existing one) rather than changing the existing one for the following reasons:
- `destruct_map_clone` is in `GraphKit` so doesn't know about `SavedState`. Either I'd need to bring `SavedState` to the base class (useless visibility) (or something with forward declarations...) or move `destruct_map_clone` to the derived class `LibraryCallKit`
- `destruct_map_clone` makes sense to have next to `clone_map`. But `clone_map` is used also in `GraphKit`, so not possible to move to the derived class
- The existing `destruct_map_clone` doesn't need a `SavedState` and makes sense without. Requiring more information just make it less usable, but it's fine to have a thin adapter that one can by-pass if one has a `SafePointNode` and not a whole `SavedState`.

> test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 104:
> 
>> 102:     public static final String START = "(\\d+(\\s){2}(";
>> 103:     public static final String MID = ".*)+(\\s){2}===.*";
>> 104:     public static final String END = ")";
> 
> I don't like exposing these outside the IR framework but then again I don't really have an idea on how to check the "graph should not have both nodes" invariant. Maybe we should extend the `counts` annotation to support something like `@IR(counts = {IRNode.CallStaticJava, IRNode.OpaqueNotNull, "<= 1"} [...]`?

As discussed, I now have a JBS issue about this, and I factored the duplicated regex into a single final String with name and comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2192570629
PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2192574207

From mchevalier at openjdk.org  Tue Jul  8 13:53:25 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 8 Jul 2025 13:53:25 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v4]
In-Reply-To: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
Message-ID: <FMa_FzdeADnxmgIvU8yklkM-Ux2WrBqe-eEL7RlMCtg=.10a9cebf-2e49-4d7d-8d87-55ae45dac7af@github.com>

> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
> 
> This is enforced by restoring the old state, like in
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
> 
> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
> 
> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
> 
> 
> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
> 
> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
> 
> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
> 
> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
> 
> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
> 
> And here there is the challenge:
> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
> - we can't really change the pointer, just the content
> -...

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

  Somehow intellij doesn't remove empty indented line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25936/files
  - new: https://git.openjdk.org/jdk/pull/25936/files/e57cf47f..09b24ec4

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

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

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

From mchevalier at openjdk.org  Tue Jul  8 13:56:39 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 8 Jul 2025 13:56:39 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v4]
In-Reply-To: <FMa_FzdeADnxmgIvU8yklkM-Ux2WrBqe-eEL7RlMCtg=.10a9cebf-2e49-4d7d-8d87-55ae45dac7af@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <FMa_FzdeADnxmgIvU8yklkM-Ux2WrBqe-eEL7RlMCtg=.10a9cebf-2e49-4d7d-8d87-55ae45dac7af@github.com>
Message-ID: <kZRqH7h-11fvIF3LYG9YHjCSIyoGkzNSzre7NY7PV40=.fdef0a61-292f-41c5-a95e-b30f34376dd9@github.com>

On Tue, 8 Jul 2025 13:53:25 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Somehow intellij doesn't remove empty indented line

I've addressed the comments, ready for a second pass!

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

PR Comment: https://git.openjdk.org/jdk/pull/25936#issuecomment-3049067672

From mchevalier at openjdk.org  Tue Jul  8 14:26:28 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 8 Jul 2025 14:26:28 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v4]
In-Reply-To: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
Message-ID: <rxMW7D0DHcGf-4XAQnMigK0u0ODmmwqeICvOsUljDW8=.efedfa1c-5eba-44fe-87c8-752c581e3cb3@github.com>

> A first part toward a better support of pure functions, but this time, with guidance from @iwanowww.
> 
> ## Pure Functions
> 
> Pure functions (considered here) are functions that have no side effects, no effect on the control flow (no exception or such), cannot deopt etc.. It's really a function that you can execute anywhere, with whichever arguments without effect other than wasting time. Integer division is not pure as dividing by zero is throwing. But many floating point functions will just return `NaN` or `+/-infinity` in problematic cases.
> 
> ## Scope
> 
> We are not going all powerful for now! It's mostly about identifying some pure functions and being able to remove them if the result is unused. Some other things are not part of this PR, on purpose. Especially, this PR doesn't propose a way to move pure calls around. The reason is that pure calls are later expanded into regular calls, which require a control input. To be able to do the expansion, we just keep the control in the pure call as well.
> 
> ## Implementation Overview
> 
> We created here some new node kind for pure calls, inheriting leaf calls, that are expanded into regular leaf calls during final graph reshaping. The possibility to support pure call directly in AD file is left open.
> 
> This PR also introduces `TupleNode` (largely based on an original idea/implem of @iwanowww), that just tie multiple input together and play well with `ProjNode`: the n-th projection of a `TupleNode` is the n-th input of the tuple. This is a convenient way to skip and remove nodes from the graph while delegating the difficulty of the surgery to the trusted IGVN's implementation.
> 
> Thanks,
> Marc

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25760/files
  - new: https://git.openjdk.org/jdk/pull/25760/files/7028b561..7f18c9f6

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

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

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

From mchevalier at openjdk.org  Tue Jul  8 14:26:29 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 8 Jul 2025 14:26:29 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v3]
In-Reply-To: <bRDGJYkDtDsmXI8ye0z8mlfr57k58MpSUHF5mz0rjOQ=.966e1317-1b56-4d46-a9be-743711fc7018@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
 <bRDGJYkDtDsmXI8ye0z8mlfr57k58MpSUHF5mz0rjOQ=.966e1317-1b56-4d46-a9be-743711fc7018@github.com>
Message-ID: <Vp5_znI0mJQj5JjKYhMQ_5bEMhg6NtZ38WlBxdenT-c=.023039a1-1040-47b2-84de-a99010718cf4@github.com>

On Mon, 7 Jul 2025 07:53:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mostly comments
>
> src/hotspot/share/opto/divnode.cpp line 1522:
> 
>> 1520:   Node* super = CallLeafPureNode::Ideal(phase, can_reshape);
>> 1521:   if (super != nullptr) {
>> 1522:     return super;
> 
> Can't we just do `return CallLeafPureNode::Ideal(phase, can_reshape);` at the end of `ModFNode::Ideal` instead of `return nullptr`? That's what we usually do in C2, for example in `CallStaticJavaNode::Ideal` -> `CallNode::Ideal`. Feels more natural to me and would avoid the `super != nullptr` check. Also for the other `Ideal` methods that you modified.

We could but it's not that direct. `ModFNode::Ideal` has 6 `return`s (without mine):
- 3 are `return replace_with_con(...);` which in their turn return `nullptr` but after making changes in the graph.
- 2 are `return nullptr;`
- 1 is actually returning a node.
And especially the final one is

return replace_with_con(igvn, TypeF::make(jfloat_cast(xr)));

If we change `replace_with_con` to actually return a `TupleNode` to do the job, we still have 2 places where to call the base class' `Ideal`. So I'm not sure how much better it would be to duplicate the call. It also adds a maintenance burden: if one adds another case where we don't want to make changes, one needs to add another call to `CallLeafPureNode::Ideal`. I think it's because of the structure of this function: rather than selecting cases where we want to do something and reaching the end with only the leftover cases, we select the cases we don't want to continue with, and we return early, making more cases where we should call the super method.

I'll try something.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2192664653

From mchevalier at openjdk.org  Tue Jul  8 14:26:29 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 8 Jul 2025 14:26:29 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v4]
In-Reply-To: <bRDGJYkDtDsmXI8ye0z8mlfr57k58MpSUHF5mz0rjOQ=.966e1317-1b56-4d46-a9be-743711fc7018@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
 <bRDGJYkDtDsmXI8ye0z8mlfr57k58MpSUHF5mz0rjOQ=.966e1317-1b56-4d46-a9be-743711fc7018@github.com>
Message-ID: <X4Ztr1xB_W7WbxTrYs_yB0yWBTPHWcMORJiepPb-gSg=.93f4c98a-6710-4c33-94f1-fd183a40ab0a@github.com>

On Mon, 7 Jul 2025 08:30:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/hotspot/share/opto/divnode.cpp line 1528:
> 
>> 1526:   bool not_dead = proj_out_or_null(TypeFunc::Control) != nullptr;
>> 1527:   if (result_is_unused && not_dead) {
>> 1528:     return replace_with_con(igvn, TypeF::make(0.));
> 
> Can we replace all the other usages of `ModFloatingNode::replace_with_con` by `TupleNode` and get rid of that method?

Yes, that sounds like a good idea. One still need to build the right `TupleNode`, which takes a bit of code. So in detail, I'd rather replace `replace_with_con` with a function returning the right `TupleNode` to be as concise on the call-site.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2192669986

From thartmann at openjdk.org  Tue Jul  8 15:13:40 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 8 Jul 2025 15:13:40 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v2]
In-Reply-To: <IimPEYdzOwWkrNrM-wZ-N27NBF3pgGwDnop960nvb7g=.7c53e368-fa49-4674-b860-2bed100fc5a9@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <1cFRkcs5JmgnbWEIaEoT8I9RiUtNxgKieAdkSB2Fgmc=.1d97b5c4-b6ef-43c6-b721-1e52eee19d3a@github.com>
 <MLgVzZUWbtjxLMCCCV-fBKTxt8RtEJdZ2lxpN0M1zyY=.691d18b0-b34e-4dab-aa87-1dd1367a33ca@github.com>
 <IimPEYdzOwWkrNrM-wZ-N27NBF3pgGwDnop960nvb7g=.7c53e368-fa49-4674-b860-2bed100fc5a9@github.com>
Message-ID: <R3ezqHYt0oWniEDQrXLu2xGn2j5dj-gvj37B_rNMKmw=.8a0350e2-b1fd-4c43-98fd-607b5098c522@github.com>

On Tue, 8 Jul 2025 13:35:27 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 2393:
>> 
>>> 2391:     Node* out = control()->fast_out(i);
>>> 2392:     if (out->is_CFG() && out->in(0) == control() && out != map() && !state.ctrl_succ.member(out)) {
>>> 2393:       out->set_req(0, C->top());
>> 
>> Could `out` already be in the GVN hash ("remove node from hash table before modifying it")?
>
> I've added it, since indeed, it could. As far as I understand, I was just lucky in the situation where it happens, but there is no reason it would always hold.

I think you also need to re-insert it via `hash_find_insert`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2192795199

From thartmann at openjdk.org  Tue Jul  8 15:16:42 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 8 Jul 2025 15:16:42 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v4]
In-Reply-To: <FMa_FzdeADnxmgIvU8yklkM-Ux2WrBqe-eEL7RlMCtg=.10a9cebf-2e49-4d7d-8d87-55ae45dac7af@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <FMa_FzdeADnxmgIvU8yklkM-Ux2WrBqe-eEL7RlMCtg=.10a9cebf-2e49-4d7d-8d87-55ae45dac7af@github.com>
Message-ID: <OZR92GyafIsHviyowkHi_WO4JGdTOQsXOqtgxR6fd_M=.99d81ee1-8fb5-47fa-ae0d-a5cfe7fa49d6@github.com>

On Tue, 8 Jul 2025 13:53:25 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Somehow intellij doesn't remove empty indented line

src/hotspot/share/opto/library_call.cpp line 2507:

> 2505: 
> 2506:   if (alias_type->adr_type() == TypeInstPtr::KLASS ||
> 2507:   alias_type->adr_type() == TypeAryPtr::RANGE) {

The indentation is off here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2192803477

From thartmann at openjdk.org  Tue Jul  8 15:16:44 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 8 Jul 2025 15:16:44 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v2]
In-Reply-To: <053aI6bIhjDWZgWQSx_KRGcDzAxg2DF86WNVBco2DkA=.7ccf19bf-3fa7-471d-929c-d20f01006235@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <1cFRkcs5JmgnbWEIaEoT8I9RiUtNxgKieAdkSB2Fgmc=.1d97b5c4-b6ef-43c6-b721-1e52eee19d3a@github.com>
 <MLgVzZUWbtjxLMCCCV-fBKTxt8RtEJdZ2lxpN0M1zyY=.691d18b0-b34e-4dab-aa87-1dd1367a33ca@github.com>
 <053aI6bIhjDWZgWQSx_KRGcDzAxg2DF86WNVBco2DkA=.7ccf19bf-3fa7-471d-929c-d20f01006235@github.com>
Message-ID: <5ezM7iZKoLDPycAuRWgVXAIOQ2d9ukvK28kxE7dklDE=.1740e1e7-5482-4239-99bf-75edecd41e6a@github.com>

On Tue, 8 Jul 2025 13:42:14 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 104:
>> 
>>> 102:     public static final String START = "(\\d+(\\s){2}(";
>>> 103:     public static final String MID = ".*)+(\\s){2}===.*";
>>> 104:     public static final String END = ")";
>> 
>> I don't like exposing these outside the IR framework but then again I don't really have an idea on how to check the "graph should not have both nodes" invariant. Maybe we should extend the `counts` annotation to support something like `@IR(counts = {IRNode.CallStaticJava, IRNode.OpaqueNotNull, "<= 1"} [...]`?
>
> As discussed, I now have a JBS issue about this, and I factored the duplicated regex into a single final String with name and comment.

Thanks, that looks good!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2192804630

From thartmann at openjdk.org  Tue Jul  8 15:19:43 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 8 Jul 2025 15:19:43 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v3]
In-Reply-To: <Vp5_znI0mJQj5JjKYhMQ_5bEMhg6NtZ38WlBxdenT-c=.023039a1-1040-47b2-84de-a99010718cf4@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
 <bRDGJYkDtDsmXI8ye0z8mlfr57k58MpSUHF5mz0rjOQ=.966e1317-1b56-4d46-a9be-743711fc7018@github.com>
 <Vp5_znI0mJQj5JjKYhMQ_5bEMhg6NtZ38WlBxdenT-c=.023039a1-1040-47b2-84de-a99010718cf4@github.com>
Message-ID: <zBwlWtpWoFBOsqthIs8Kr1LdrnmkUrWIgqQhqu7FtzY=.3fd85f19-44b6-42cc-a7c8-8f841be7e6de@github.com>

On Tue, 8 Jul 2025 14:19:23 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/divnode.cpp line 1522:
>> 
>>> 1520:   Node* super = CallLeafPureNode::Ideal(phase, can_reshape);
>>> 1521:   if (super != nullptr) {
>>> 1522:     return super;
>> 
>> Can't we just do `return CallLeafPureNode::Ideal(phase, can_reshape);` at the end of `ModFNode::Ideal` instead of `return nullptr`? That's what we usually do in C2, for example in `CallStaticJavaNode::Ideal` -> `CallNode::Ideal`. Feels more natural to me and would avoid the `super != nullptr` check. Also for the other `Ideal` methods that you modified.
>
> We could but it's not that direct. `ModFNode::Ideal` has 6 `return`s (without mine):
> - 3 are `return replace_with_con(...);` which in their turn return `nullptr` but after making changes in the graph.
> - 2 are `return nullptr;`
> - 1 is actually returning a node.
> And especially the final one is
> 
> return replace_with_con(igvn, TypeF::make(jfloat_cast(xr)));
> 
> If we change `replace_with_con` to actually return a `TupleNode` to do the job, we still have 2 places where to call the base class' `Ideal`. So I'm not sure how much better it would be to duplicate the call. It also adds a maintenance burden: if one adds another case where we don't want to make changes, one needs to add another call to `CallLeafPureNode::Ideal`. I think it's because of the structure of this function: rather than selecting cases where we want to do something and reaching the end with only the leftover cases, we select the cases we don't want to continue with, and we return early, making more cases where we should call the super method.
> 
> I'll try something.

Ah, makes sense. Feel free to leave as-is then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2192809070

From thartmann at openjdk.org  Tue Jul  8 15:19:44 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 8 Jul 2025 15:19:44 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v4]
In-Reply-To: <X4Ztr1xB_W7WbxTrYs_yB0yWBTPHWcMORJiepPb-gSg=.93f4c98a-6710-4c33-94f1-fd183a40ab0a@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
 <bRDGJYkDtDsmXI8ye0z8mlfr57k58MpSUHF5mz0rjOQ=.966e1317-1b56-4d46-a9be-743711fc7018@github.com>
 <X4Ztr1xB_W7WbxTrYs_yB0yWBTPHWcMORJiepPb-gSg=.93f4c98a-6710-4c33-94f1-fd183a40ab0a@github.com>
Message-ID: <7CvQqj41V2ysWMJACPif3jOCSF9xFypACLH9DiKYnc0=.aad8e7fe-56ba-44a3-bc31-187618af35d6@github.com>

On Tue, 8 Jul 2025 14:21:20 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/divnode.cpp line 1528:
>> 
>>> 1526:   bool not_dead = proj_out_or_null(TypeFunc::Control) != nullptr;
>>> 1527:   if (result_is_unused && not_dead) {
>>> 1528:     return replace_with_con(igvn, TypeF::make(0.));
>> 
>> Can we replace all the other usages of `ModFloatingNode::replace_with_con` by `TupleNode` and get rid of that method?
>
> Yes, that sounds like a good idea. One still need to build the right `TupleNode`, which takes a bit of code. So in detail, I'd rather replace `replace_with_con` with a function returning the right `TupleNode` to be as concise on the call-site.

Yes, that sounds good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2192809839

From mchevalier at openjdk.org  Tue Jul  8 15:28:39 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 8 Jul 2025 15:28:39 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v2]
In-Reply-To: <R3ezqHYt0oWniEDQrXLu2xGn2j5dj-gvj37B_rNMKmw=.8a0350e2-b1fd-4c43-98fd-607b5098c522@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <1cFRkcs5JmgnbWEIaEoT8I9RiUtNxgKieAdkSB2Fgmc=.1d97b5c4-b6ef-43c6-b721-1e52eee19d3a@github.com>
 <MLgVzZUWbtjxLMCCCV-fBKTxt8RtEJdZ2lxpN0M1zyY=.691d18b0-b34e-4dab-aa87-1dd1367a33ca@github.com>
 <IimPEYdzOwWkrNrM-wZ-N27NBF3pgGwDnop960nvb7g=.7c53e368-fa49-4674-b860-2bed100fc5a9@github.com>
 <R3ezqHYt0oWniEDQrXLu2xGn2j5dj-gvj37B_rNMKmw=.8a0350e2-b1fd-4c43-98fd-607b5098c522@github.com>
Message-ID: <uTsH6qFe_3NwK9VeTTr9rtD5GQpl-NhaIEALB18BVFk=.9f0d0ffb-757f-46b6-b14b-ca6a925ed3a4@github.com>

On Tue, 8 Jul 2025 15:11:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> I've added it, since indeed, it could. As far as I understand, I was just lucky in the situation where it happens, but there is no reason it would always hold.
>
> I think you also need to re-insert it via `hash_find_insert`.

// Some Ideal and other transforms delete --> modify --> insert values

yes, indeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2192831829

From yzheng at openjdk.org  Tue Jul  8 16:03:50 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 8 Jul 2025 16:03:50 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimiztaion profile
Message-ID: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>

In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

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

Commit messages:
 - [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimiztaion profile

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

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

From dnsimon at openjdk.org  Tue Jul  8 17:13:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 8 Jul 2025 17:13:41 GMT
Subject: RFR: 8357689: Refactor JVMCI to enable replay compilation in Graal
 [v2]
In-Reply-To: <iqN9QLD_matBDQ38zBLTkLhCtqEJcLUvlcqwr_e6EXY=.fb994799-9b1d-4ec8-ba0f-f330c1f88ccc@github.com>
References: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
 <iqN9QLD_matBDQ38zBLTkLhCtqEJcLUvlcqwr_e6EXY=.fb994799-9b1d-4ec8-ba0f-f330c1f88ccc@github.com>
Message-ID: <HS6OhLXowe3ImK6DfonfxawEcL17F1918uU9tAkrAVo=.53e297aa-b259-461a-b776-542539c58e88@github.com>

On Tue, 8 Jul 2025 08:41:59 GMT, Andrej Pe?im?th <duke at openjdk.org> wrote:

>> This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.
>
> Andrej Pe?im?th 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:
> 
>   JVMCI refactorings to enable replay compilation in Graal.

Looks good.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25433#pullrequestreview-2998482956

From duke at openjdk.org  Tue Jul  8 17:37:57 2025
From: duke at openjdk.org (Andrej Pecimuth)
Date: Tue, 8 Jul 2025 17:37:57 GMT
Subject: RFR: 8357689: Refactor JVMCI to enable replay compilation in Graal
 [v3]
In-Reply-To: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
References: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
Message-ID: <YKG0n5sQN45DHijIr09kQjrI-xjauBCIhIXyPjFvB3o=.be6f4334-28c4-470b-b4b4-c0c39d339311@github.com>

> This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.

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

  Remove unnecessary public modifier.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25433/files
  - new: https://git.openjdk.org/jdk/pull/25433/files/c6c3bb62..1b845fa9

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

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

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

From dnsimon at openjdk.org  Tue Jul  8 17:50:42 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 8 Jul 2025 17:50:42 GMT
Subject: RFR: 8357689: Refactor JVMCI to enable replay compilation in Graal
 [v3]
In-Reply-To: <YKG0n5sQN45DHijIr09kQjrI-xjauBCIhIXyPjFvB3o=.be6f4334-28c4-470b-b4b4-c0c39d339311@github.com>
References: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
 <YKG0n5sQN45DHijIr09kQjrI-xjauBCIhIXyPjFvB3o=.be6f4334-28c4-470b-b4b4-c0c39d339311@github.com>
Message-ID: <0ZpzR9oc9eKbKHiDI6XTpi5tN28FhHq4ywHrF4nxSzI=.314d1794-a540-45db-8ab1-26eeb65b77f5@github.com>

On Tue, 8 Jul 2025 17:37:57 GMT, Andrej Pecimuth <duke at openjdk.org> wrote:

>> This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.
>
> Andrej Pecimuth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary public modifier.

Still good.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25433#pullrequestreview-2998590011

From yzheng at openjdk.org  Tue Jul  8 19:23:31 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 8 Jul 2025 19:23:31 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimiztaion profile [v2]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <s7HwZc0l4IfiaXWKiAxGmAdKOB08l87ON3N815GtJkc=.e9489f7d-c419-4102-89e1-761685383b22@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

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

  restore HotSpotNmethod constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/53c9279d..b17efc69

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

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

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

From dnsimon at openjdk.org  Tue Jul  8 19:52:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 8 Jul 2025 19:52:41 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimiztaion profile [v2]
In-Reply-To: <s7HwZc0l4IfiaXWKiAxGmAdKOB08l87ON3N815GtJkc=.e9489f7d-c419-4102-89e1-761685383b22@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <s7HwZc0l4IfiaXWKiAxGmAdKOB08l87ON3N815GtJkc=.e9489f7d-c419-4102-89e1-761685383b22@github.com>
Message-ID: <qoiWbiOxTJRcJhYiK8usTd2NchcoJJhSOA5FPbwA5mc=.578d314d-3eb4-4d56-820d-3e76211b2191@github.com>

On Tue, 8 Jul 2025 19:23:31 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore HotSpotNmethod constructor

Looks good to me.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-2998930031

From kvn at openjdk.org  Tue Jul  8 20:25:45 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 8 Jul 2025 20:25:45 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v4]
In-Reply-To: <FMa_FzdeADnxmgIvU8yklkM-Ux2WrBqe-eEL7RlMCtg=.10a9cebf-2e49-4d7d-8d87-55ae45dac7af@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <FMa_FzdeADnxmgIvU8yklkM-Ux2WrBqe-eEL7RlMCtg=.10a9cebf-2e49-4d7d-8d87-55ae45dac7af@github.com>
Message-ID: <lp0wWxcPaI96rrpDOR_UA51hXHdHU3be_5lFzX_O8hw=.6e038d52-13c6-41d4-93cf-eb95f617ba12@github.com>

On Tue, 8 Jul 2025 13:53:25 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Somehow intellij doesn't remove empty indented line

src/hotspot/share/opto/library_call.hpp line 150:

> 148:   void restore_state(const SavedState&);
> 149:   void destruct_map_clone(const SavedState& sfp);
> 150: 

Can this be a class instead of struct? These methods could be members. Initialization can be done through constructor. The destructor can do restoration by default unless `destruct_map_clone()` was called before.
I don't like name  `destruct_map_clone()` for this. How about `SavedState::remove()` or something.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2193378458

From yzheng at openjdk.org  Tue Jul  8 20:36:19 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 8 Jul 2025 20:36:19 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimiztaion profile [v3]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <HSCGUK540U-viHG3dLVaFqWs6VW49WKBl4uRe4-C_SQ=.59b0a7a7-4981-407e-b4c0-4b0c383f2a28@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

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

  JNIJVMCI::HotSpotNmethod::constructor() cannot be overloaded

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/b17efc69..c0afd3c1

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

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

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

From duke at openjdk.org  Wed Jul  9 07:29:39 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Jul 2025 07:29:39 GMT
Subject: RFR: 8357689: Refactor JVMCI to enable replay compilation in Graal
 [v3]
In-Reply-To: <YKG0n5sQN45DHijIr09kQjrI-xjauBCIhIXyPjFvB3o=.be6f4334-28c4-470b-b4b4-c0c39d339311@github.com>
References: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
 <YKG0n5sQN45DHijIr09kQjrI-xjauBCIhIXyPjFvB3o=.be6f4334-28c4-470b-b4b4-c0c39d339311@github.com>
Message-ID: <J76mol1A5uLq3qp0EtebAYLHI90RcKq3aTKEeDhCvQk=.8eec4a9f-c0db-4ccf-a0be-fdf8b547a79b@github.com>

On Tue, 8 Jul 2025 17:37:57 GMT, Andrej Pecimuth <duke at openjdk.org> wrote:

>> This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.
>
> Andrej Pecimuth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary public modifier.

@pecimuth 
Your change (at version 1b845fa92383367026d8072ba5a9525ded15dccb) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25433#issuecomment-3051484038

From yzheng at openjdk.org  Wed Jul  9 08:01:52 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 08:01:52 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v4]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <xbILPDRQ329SWqbJliW_WxlZT0qOeC_2P9DKY5S_EhA=.732a38fb-9ec2-47e0-92a4-f6d586bab9ae@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

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

  fix compilation error in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/c0afd3c1..3f7b2362

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

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

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

From dnsimon at openjdk.org  Wed Jul  9 08:09:38 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 9 Jul 2025 08:09:38 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v4]
In-Reply-To: <xbILPDRQ329SWqbJliW_WxlZT0qOeC_2P9DKY5S_EhA=.732a38fb-9ec2-47e0-92a4-f6d586bab9ae@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <xbILPDRQ329SWqbJliW_WxlZT0qOeC_2P9DKY5S_EhA=.732a38fb-9ec2-47e0-92a4-f6d586bab9ae@github.com>
Message-ID: <3uFGBbe0KELpzdGDivwsEUR8DWZSoQhGXuT_t6qD_Bg=.1c4cc3f2-aa64-4901-bc4c-3639171feda4@github.com>

On Wed, 9 Jul 2025 08:01:52 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix compilation error in test

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-3000496268

From duke at openjdk.org  Wed Jul  9 08:22:44 2025
From: duke at openjdk.org (Andrej Pecimuth)
Date: Wed, 9 Jul 2025 08:22:44 GMT
Subject: Integrated: 8357689: Refactor JVMCI to enable replay compilation in
 Graal
In-Reply-To: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
References: <D7U7H3osMLxu1zAXzrtsVlqUGkbfFS6UPnZR9_2HkEs=.38240f41-cd31-480c-8734-bf9ba003d19d@github.com>
Message-ID: <XvBfN7ZAAnU0xC09rsoyMEUWO9Lwu-gepAPtt6mTJAI=.c28d4334-d9f9-4f3a-920c-501478188345@github.com>

On Sat, 24 May 2025 16:49:23 GMT, Andrej Pecimuth <duke at openjdk.org> wrote:

> This PR introduces a few minor JVMCI refactorings to make replay compilation possible in the Graal compiler.

This pull request has now been integrated.

Changeset: 963b83fc
Author:    Andrej Pecimuth <andrej.pecimuth at oracle.com>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/963b83fcf158d273e9433b6845380184b3ad0de5
Stats:     258 lines in 16 files changed: 224 ins; 7 del; 27 mod

8357689: Refactor JVMCI to enable replay compilation in Graal

Reviewed-by: dnsimon

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

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

From yzheng at openjdk.org  Wed Jul  9 10:53:20 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 10:53:20 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v5]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

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

  fix compilation error, update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/3f7b2362..b67bd1bb

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

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

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

From gdub at openjdk.org  Wed Jul  9 11:27:39 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 9 Jul 2025 11:27:39 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v5]
In-Reply-To: <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>
Message-ID: <GP5nYib3TRaCRYc27QTvJL0oFj5d0LoZYN3iNLXqrOc=.425fbd16-8758-441b-a6f0-d184896575cb@github.com>

On Wed, 9 Jul 2025 10:53:20 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix compilation error, update copyright year

Marked as reviewed by gdub (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-3001149894

From dnsimon at openjdk.org  Wed Jul  9 11:46:42 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 9 Jul 2025 11:46:42 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v5]
In-Reply-To: <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>
Message-ID: <Rub6OGY03C1lTLF6-AVtOUQDnUmwRr3JLTmZSNo7XCU=.796f2178-f53d-41b3-bb6a-c3ce04c92475@github.com>

On Wed, 9 Jul 2025 10:53:20 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix compilation error, update copyright year

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-3001204538

From mchevalier at openjdk.org  Wed Jul  9 12:36:31 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Jul 2025 12:36:31 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v5]
In-Reply-To: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
Message-ID: <SD_ml-YJLiuPiQOGOxVnlX7dmlHAAqFsWqHqwee62U0=.d3435d76-d21c-409c-acb6-c73b8cfcf6a7@github.com>

> A first part toward a better support of pure functions, but this time, with guidance from @iwanowww.
> 
> ## Pure Functions
> 
> Pure functions (considered here) are functions that have no side effects, no effect on the control flow (no exception or such), cannot deopt etc.. It's really a function that you can execute anywhere, with whichever arguments without effect other than wasting time. Integer division is not pure as dividing by zero is throwing. But many floating point functions will just return `NaN` or `+/-infinity` in problematic cases.
> 
> ## Scope
> 
> We are not going all powerful for now! It's mostly about identifying some pure functions and being able to remove them if the result is unused. Some other things are not part of this PR, on purpose. Especially, this PR doesn't propose a way to move pure calls around. The reason is that pure calls are later expanded into regular calls, which require a control input. To be able to do the expansion, we just keep the control in the pure call as well.
> 
> ## Implementation Overview
> 
> We created here some new node kind for pure calls, inheriting leaf calls, that are expanded into regular leaf calls during final graph reshaping. The possibility to support pure call directly in AD file is left open.
> 
> This PR also introduces `TupleNode` (largely based on an original idea/implem of @iwanowww), that just tie multiple input together and play well with `ProjNode`: the n-th projection of a `TupleNode` is the n-th input of the tuple. This is a convenient way to skip and remove nodes from the graph while delegating the difficulty of the surgery to the trusted IGVN's implementation.
> 
> Thanks,
> Marc

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

  Tentative to address Tobias' comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25760/files
  - new: https://git.openjdk.org/jdk/pull/25760/files/7f18c9f6..7553e307

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

  Stats: 118 lines in 2 files changed: 29 ins; 38 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/25760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25760/head:pull/25760

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

From mchevalier at openjdk.org  Wed Jul  9 12:36:32 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Jul 2025 12:36:32 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v3]
In-Reply-To: <zBwlWtpWoFBOsqthIs8Kr1LdrnmkUrWIgqQhqu7FtzY=.3fd85f19-44b6-42cc-a7c8-8f841be7e6de@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@github.com>
 <bRDGJYkDtDsmXI8ye0z8mlfr57k58MpSUHF5mz0rjOQ=.966e1317-1b56-4d46-a9be-743711fc7018@github.com>
 <Vp5_znI0mJQj5JjKYhMQ_5bEMhg6NtZ38WlBxdenT-c=.023039a1-1040-47b2-84de-a99010718cf4@github.com>
 <zBwlWtpWoFBOsqthIs8Kr1LdrnmkUrWIgqQhqu7FtzY=.3fd85f19-44b6-42cc-a7c8-8f841be7e6de@github.com>
Message-ID: <785hwTKUD5k99LD_yX2GOLlWWk0-6fsQ3piigA_FIhs=.ed24d7c7-9ea6-4815-a738-1f61bade24e4@github.com>

On Tue, 8 Jul 2025 15:16:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> We could but it's not that direct. `ModFNode::Ideal` has 6 `return`s (without mine):
>> - 3 are `return replace_with_con(...);` which in their turn return `nullptr` but after making changes in the graph.
>> - 2 are `return nullptr;`
>> - 1 is actually returning a node.
>> And especially the final one is
>> 
>> return replace_with_con(igvn, TypeF::make(jfloat_cast(xr)));
>> 
>> If we change `replace_with_con` to actually return a `TupleNode` to do the job, we still have 2 places where to call the base class' `Ideal`. So I'm not sure how much better it would be to duplicate the call. It also adds a maintenance burden: if one adds another case where we don't want to make changes, one needs to add another call to `CallLeafPureNode::Ideal`. I think it's because of the structure of this function: rather than selecting cases where we want to do something and reaching the end with only the leftover cases, we select the cases we don't want to continue with, and we return early, making more cases where we should call the super method.
>> 
>> I'll try something.
>
> Ah, makes sense. Feel free to leave as-is then.

There, you can see the thing I've tried. It changes a bit more code, but overall, I think it makes it clearer and address your comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2194912203

From mchevalier at openjdk.org  Wed Jul  9 12:38:26 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Jul 2025 12:38:26 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v5]
In-Reply-To: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
Message-ID: <UdKkbP2yrpzvIDqE2U49YaT_0nKnJnyTtKV1DIMIcBc=.32d40855-e5e6-44ce-9761-6a1c823d47fd@github.com>

> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
> 
> This is enforced by restoring the old state, like in
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
> 
> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
> 
> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
> 
> 
> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
> 
> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
> 
> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
> 
> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
> 
> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
> 
> And here there is the challenge:
> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
> - we can't really change the pointer, just the content
> -...

Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:

 - Tentative addressing Vladimir's comments
 - Re-insert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25936/files
  - new: https://git.openjdk.org/jdk/pull/25936/files/09b24ec4..59133778

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

  Stats: 83 lines in 3 files changed: 12 ins; 29 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/25936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25936/head:pull/25936

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

From mchevalier at openjdk.org  Wed Jul  9 12:40:42 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Jul 2025 12:40:42 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v4]
In-Reply-To: <lp0wWxcPaI96rrpDOR_UA51hXHdHU3be_5lFzX_O8hw=.6e038d52-13c6-41d4-93cf-eb95f617ba12@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <FMa_FzdeADnxmgIvU8yklkM-Ux2WrBqe-eEL7RlMCtg=.10a9cebf-2e49-4d7d-8d87-55ae45dac7af@github.com>
 <lp0wWxcPaI96rrpDOR_UA51hXHdHU3be_5lFzX_O8hw=.6e038d52-13c6-41d4-93cf-eb95f617ba12@github.com>
Message-ID: <xEEIBVdOh78QX2cU-uslIx4IzEHYDkHu0YocPcpIkE0=.9c7847bf-a40c-41b3-b020-ff96a857d3c5@github.com>

On Tue, 8 Jul 2025 20:23:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Somehow intellij doesn't remove empty indented line
>
> src/hotspot/share/opto/library_call.hpp line 150:
> 
>> 148:   void restore_state(const SavedState&);
>> 149:   void destruct_map_clone(const SavedState& sfp);
>> 150: 
> 
> Can this be a class instead of struct? These methods could be members. Initialization can be done through constructor. The destructor can do restoration by default unless `destruct_map_clone()` was called before.
> I don't like name  `destruct_map_clone()` for this. How about `SavedState::remove()` or something.

I like it. Since intrinsic implementations have mostly bailing out returns, and few success paths, it's nice to say when we are good, rather than every path that ends with bailing out.

I've called the member function `discard`. It gives as `old_state.discard()`, which reads well, I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2194921677

From thartmann at openjdk.org  Wed Jul  9 12:47:41 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 9 Jul 2025 12:47:41 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v5]
In-Reply-To: <UdKkbP2yrpzvIDqE2U49YaT_0nKnJnyTtKV1DIMIcBc=.32d40855-e5e6-44ce-9761-6a1c823d47fd@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <UdKkbP2yrpzvIDqE2U49YaT_0nKnJnyTtKV1DIMIcBc=.32d40855-e5e6-44ce-9761-6a1c823d47fd@github.com>
Message-ID: <uCyUHH_bwmDyPzjCiGrXmVEhv_iJdc0kABR1yX5KnUA=.05d60ba5-39d8-47c6-bc4b-d590cd063c12@github.com>

On Wed, 9 Jul 2025 12:38:26 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tentative addressing Vladimir's comments
>  - Re-insert

Nice! Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25936#pullrequestreview-3001409938

From thartmann at openjdk.org  Wed Jul  9 13:11:44 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 9 Jul 2025 13:11:44 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v5]
In-Reply-To: <SD_ml-YJLiuPiQOGOxVnlX7dmlHAAqFsWqHqwee62U0=.d3435d76-d21c-409c-acb6-c73b8cfcf6a7@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <SD_ml-YJLiuPiQOGOxVnlX7dmlHAAqFsWqHqwee62U0=.d3435d76-d21c-409c-acb6-c73b8cfcf6a7@github.com>
Message-ID: <dD-aPvoEJ4wa6fvo6ffCFGp1bD8acHfBP_hkIOJcqeQ=.149075fe-bc8a-4aa9-be4a-aef930589a0c@github.com>

On Wed, 9 Jul 2025 12:36:31 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> A first part toward a better support of pure functions, but this time, with guidance from @iwanowww.
>> 
>> ## Pure Functions
>> 
>> Pure functions (considered here) are functions that have no side effects, no effect on the control flow (no exception or such), cannot deopt etc.. It's really a function that you can execute anywhere, with whichever arguments without effect other than wasting time. Integer division is not pure as dividing by zero is throwing. But many floating point functions will just return `NaN` or `+/-infinity` in problematic cases.
>> 
>> ## Scope
>> 
>> We are not going all powerful for now! It's mostly about identifying some pure functions and being able to remove them if the result is unused. Some other things are not part of this PR, on purpose. Especially, this PR doesn't propose a way to move pure calls around. The reason is that pure calls are later expanded into regular calls, which require a control input. To be able to do the expansion, we just keep the control in the pure call as well.
>> 
>> ## Implementation Overview
>> 
>> We created here some new node kind for pure calls, inheriting leaf calls, that are expanded into regular leaf calls during final graph reshaping. The possibility to support pure call directly in AD file is left open.
>> 
>> This PR also introduces `TupleNode` (largely based on an original idea/implem of @iwanowww), that just tie multiple input together and play well with `ProjNode`: the n-th projection of a `TupleNode` is the n-th input of the tuple. This is a convenient way to skip and remove nodes from the graph while delegating the difficulty of the surgery to the trusted IGVN's implementation.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tentative to address Tobias' comments

Thanks for making these changes, I like that version more.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25760#pullrequestreview-3001503959

From yzheng at openjdk.org  Wed Jul  9 13:37:56 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 13:37:56 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v6]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <a3nk2yBJulOtA4gJtYJUpyg52epibbzoziphcvYli2I=.3f9fb4c8-9fe2-42ae-98b1-c9792474c6ae@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

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

  fix method not found in truffle tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/b67bd1bb..ca92354e

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

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

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

From yzheng at openjdk.org  Wed Jul  9 15:20:29 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 15:20:29 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v7]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

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

 - Merge remote-tracking branch 'upstream/master' into JDK-8361569
 - update signature
 - fix method not found in truffle tests
 - fix compilation error, update copyright year
 - fix compilation error in test
 - JNIJVMCI::HotSpotNmethod::constructor() cannot be overloaded
 - restore HotSpotNmethod constructor
 - [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimiztaion profile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/ca92354e..413c1f38

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

  Stats: 6846 lines in 241 files changed: 3657 ins; 830 del; 2359 mod
  Patch: https://git.openjdk.org/jdk/pull/26192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26192/head:pull/26192

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

From kvn at openjdk.org  Wed Jul  9 16:36:39 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Jul 2025 16:36:39 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v5]
In-Reply-To: <UdKkbP2yrpzvIDqE2U49YaT_0nKnJnyTtKV1DIMIcBc=.32d40855-e5e6-44ce-9761-6a1c823d47fd@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <UdKkbP2yrpzvIDqE2U49YaT_0nKnJnyTtKV1DIMIcBc=.32d40855-e5e6-44ce-9761-6a1c823d47fd@github.com>
Message-ID: <06SLl1SEu1oWp3YWh9xR3LbQR5rDGs6thA5UAS_kMtk=.5fb6e090-7ac6-4e99-9700-b767f2a08348@github.com>

On Wed, 9 Jul 2025 12:38:26 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tentative addressing Vladimir's comments
>  - Re-insert

src/hotspot/share/opto/library_call.hpp line 147:

> 145:     SafePointNode* _map;
> 146:     Unique_Node_List _ctrl_succ;
> 147:     bool discarded = false;

`discarded` is not static field. I suggest to initialize it in constructor. And use `_` prefix.

Otherwise changes are good. Thank you for taking my suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2195470155

From dnsimon at openjdk.org  Wed Jul  9 18:50:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 9 Jul 2025 18:50:41 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v7]
In-Reply-To: <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>
Message-ID: <77OT73LZ631dhxno_DH8ul9EGtW5b4kPcKLDtW3H6Lk=.23dd5f7c-d300-4d68-a1a0-241635bb89b3@github.com>

On Wed, 9 Jul 2025 15:20:29 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> 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 eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8361569
>  - update signature
>  - fix method not found in truffle tests
>  - fix compilation error, update copyright year
>  - fix compilation error in test
>  - JNIJVMCI::HotSpotNmethod::constructor() cannot be overloaded
>  - restore HotSpotNmethod constructor
>  - [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimiztaion profile

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-3002711174

From yzheng at openjdk.org  Wed Jul  9 19:15:47 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 19:15:47 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v7]
In-Reply-To: <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>
Message-ID: <S_XPMGEI7Jj1UjbxgjwDps0evlCKoxMuk1vi2GGG1SU=.bb5e4109-1d4f-4c96-abc6-f532e225f61e@github.com>

On Wed, 9 Jul 2025 15:20:29 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> 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 eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8361569
>  - update signature
>  - fix method not found in truffle tests
>  - fix compilation error, update copyright year
>  - fix compilation error in test
>  - JNIJVMCI::HotSpotNmethod::constructor() cannot be overloaded
>  - restore HotSpotNmethod constructor
>  - [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimiztaion profile

Thanks for the review! Passed Tier1-3

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

PR Comment: https://git.openjdk.org/jdk/pull/26192#issuecomment-3053725076

From yzheng at openjdk.org  Wed Jul  9 19:15:47 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 19:15:47 GMT
Subject: Integrated: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod
 that should not collect deoptimization profile
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <OBh8fMmnSCqn3OED0HMwsir3Y86JwToliIJXN6DdBXo=.745a4c20-9261-4d8e-b6c2-2d511c1fa9c5@github.com>

On Tue, 8 Jul 2025 15:59:10 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

This pull request has now been integrated.

Changeset: 6681fc72
Author:    Yudi Zheng <yzheng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6681fc72d3463e13876eb84a285eb580ee92b464
Stats:     86 lines in 18 files changed: 39 ins; 5 del; 42 mod

8361569: [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimization profile

Reviewed-by: dnsimon, gdub

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

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

From darcy at openjdk.org  Thu Jul 10 04:54:37 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 10 Jul 2025 04:54:37 GMT
Subject: RFR: 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: <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@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.

What is the accuracy of the algorithm in ulps (units the last place)?

The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet.

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

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

From mchevalier at openjdk.org  Thu Jul 10 06:13:27 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 10 Jul 2025 06:13:27 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v6]
In-Reply-To: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
Message-ID: <-rnlrm6PHRZeO1izbXh5nOrm368YKrsFft1u6SHXzWA=.9c8e6646-0b72-4705-895e-f795f74f3906@github.com>

> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
> 
> This is enforced by restoring the old state, like in
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
> 
> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
> 
> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
> 
> 
> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
> 
> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
> 
> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
> 
> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
> 
> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
> 
> And here there is the challenge:
> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
> - we can't really change the pointer, just the content
> -...

Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:

 - Forgot to destruct_map_clone
 - +'_' and ctor init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25936/files
  - new: https://git.openjdk.org/jdk/pull/25936/files/59133778..be5c0241

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

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

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

From mchevalier at openjdk.org  Thu Jul 10 06:13:27 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 10 Jul 2025 06:13:27 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v5]
In-Reply-To: <UdKkbP2yrpzvIDqE2U49YaT_0nKnJnyTtKV1DIMIcBc=.32d40855-e5e6-44ce-9761-6a1c823d47fd@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <UdKkbP2yrpzvIDqE2U49YaT_0nKnJnyTtKV1DIMIcBc=.32d40855-e5e6-44ce-9761-6a1c823d47fd@github.com>
Message-ID: <KvrMmZ0t0NWuM-mltmkN7rczzuUxqScz9qIlEzHp-WY=.d24e22af-587f-4779-9099-d67707c2da29@github.com>

On Wed, 9 Jul 2025 12:38:26 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tentative addressing Vladimir's comments
>  - Re-insert

Turns out in this `SavedState` tiny refactoring, I removed the underlying call to `destruct_map_clone`. It's probably benign up to memory consumption, and it made no test fail. Nevertheless, it's back.

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

PR Comment: https://git.openjdk.org/jdk/pull/25936#issuecomment-3055733721

From mchevalier at openjdk.org  Thu Jul 10 06:13:28 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 10 Jul 2025 06:13:28 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v5]
In-Reply-To: <06SLl1SEu1oWp3YWh9xR3LbQR5rDGs6thA5UAS_kMtk=.5fb6e090-7ac6-4e99-9700-b767f2a08348@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <UdKkbP2yrpzvIDqE2U49YaT_0nKnJnyTtKV1DIMIcBc=.32d40855-e5e6-44ce-9761-6a1c823d47fd@github.com>
 <06SLl1SEu1oWp3YWh9xR3LbQR5rDGs6thA5UAS_kMtk=.5fb6e090-7ac6-4e99-9700-b767f2a08348@github.com>
Message-ID: <4cs83TE2oMQrKZJBJy72dLKotjXgyh2WLheJyTPvvSM=.e22e5aea-befe-4857-86b3-a86ef6e9a57a@github.com>

On Wed, 9 Jul 2025 16:34:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tentative addressing Vladimir's comments
>>  - Re-insert
>
> src/hotspot/share/opto/library_call.hpp line 147:
> 
>> 145:     SafePointNode* _map;
>> 146:     Unique_Node_List _ctrl_succ;
>> 147:     bool discarded = false;
> 
> `discarded` is not static field. I suggest to initialize it in constructor. And use `_` prefix.
> 
> Otherwise changes are good. Thank you for taking my suggestion.

Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25936#discussion_r2196677989

From thartmann at openjdk.org  Thu Jul 10 07:17:43 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Jul 2025 07:17:43 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v6]
In-Reply-To: <-rnlrm6PHRZeO1izbXh5nOrm368YKrsFft1u6SHXzWA=.9c8e6646-0b72-4705-895e-f795f74f3906@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <-rnlrm6PHRZeO1izbXh5nOrm368YKrsFft1u6SHXzWA=.9c8e6646-0b72-4705-895e-f795f74f3906@github.com>
Message-ID: <ck6iz3wKnRF6m0EoI0dpt3jlUJs_WgaPaf5Uy0SZLRo=.36af4cfe-c964-4daa-b215-be3d885d260a@github.com>

On Thu, 10 Jul 2025 06:13:27 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to destruct_map_clone
>  - +'_' and ctor init

Marked as reviewed by thartmann (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25936#pullrequestreview-3004286462

From fweimer at openjdk.org  Thu Jul 10 10:07:38 2025
From: fweimer at openjdk.org (Florian Weimer)
Date: Thu, 10 Jul 2025 10:07:38 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <Wse6mX1Slo3KvItTvCLqE_BMswyGSTDinY-Lp9Y-6nw=.54164a56-2d48-4c8a-8dcf-98c4e85fcbc5@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>
 <Wse6mX1Slo3KvItTvCLqE_BMswyGSTDinY-Lp9Y-6nw=.54164a56-2d48-4c8a-8dcf-98c4e85fcbc5@github.com>
Message-ID: <pjgNDrlkQfhfDwybzk2t0HJ2pTBNIDKmWNjt7jVOi9A=.a757ed01-fb48-4f25-ac6d-828cccb4c723@github.com>

On Mon, 7 Jul 2025 23:53:14 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> I'm not sure which libm version you're referring to. The only current sinh benchmark I'm aware of is in MathBench.java, and the benchmarks in SinhPerf.java didn't exist until now. Could you clarify?

I didn't notice the code you ported over from the Intel math library at first. I assumed ?libm? referred to the system libm version.

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

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

From mchevalier at openjdk.org  Thu Jul 10 10:48:43 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 10 Jul 2025 10:48:43 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v5]
In-Reply-To: <SD_ml-YJLiuPiQOGOxVnlX7dmlHAAqFsWqHqwee62U0=.d3435d76-d21c-409c-acb6-c73b8cfcf6a7@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <SD_ml-YJLiuPiQOGOxVnlX7dmlHAAqFsWqHqwee62U0=.d3435d76-d21c-409c-acb6-c73b8cfcf6a7@github.com>
Message-ID: <rFqxJh720WefOlVUnmllF5JGaT5fNc3u8y2kqZwDJKM=.4e0e7bed-4902-4213-952d-28289adf804d@github.com>

On Wed, 9 Jul 2025 12:36:31 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> A first part toward a better support of pure functions, but this time, with guidance from @iwanowww.
>> 
>> ## Pure Functions
>> 
>> Pure functions (considered here) are functions that have no side effects, no effect on the control flow (no exception or such), cannot deopt etc.. It's really a function that you can execute anywhere, with whichever arguments without effect other than wasting time. Integer division is not pure as dividing by zero is throwing. But many floating point functions will just return `NaN` or `+/-infinity` in problematic cases.
>> 
>> ## Scope
>> 
>> We are not going all powerful for now! It's mostly about identifying some pure functions and being able to remove them if the result is unused. Some other things are not part of this PR, on purpose. Especially, this PR doesn't propose a way to move pure calls around. The reason is that pure calls are later expanded into regular calls, which require a control input. To be able to do the expansion, we just keep the control in the pure call as well.
>> 
>> ## Implementation Overview
>> 
>> We created here some new node kind for pure calls, inheriting leaf calls, that are expanded into regular leaf calls during final graph reshaping. The possibility to support pure call directly in AD file is left open.
>> 
>> This PR also introduces `TupleNode` (largely based on an original idea/implem of @iwanowww), that just tie multiple input together and play well with `ProjNode`: the n-th projection of a `TupleNode` is the n-th input of the tuple. This is a convenient way to skip and remove nodes from the graph while delegating the difficulty of the surgery to the trusted IGVN's implementation.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tentative to address Tobias' comments

@iwanowww would you like to take a look at it, since you have quite some context already?

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

PR Comment: https://git.openjdk.org/jdk/pull/25760#issuecomment-3056888461

From vyazici at openjdk.org  Thu Jul 10 12:58:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:54 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ 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: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@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 C++ methods, 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");
>         }
>     }
> }
> 
> 2. Comp...

src/hotspot/share/opto/library_call.cpp line 963:

> 961: 
> 962:   if (bailout->req() > 1) {
> 963:     if (halt) {

Toggle to force a VM crash to be used to surface intrinsic Java wrappers failing to spot invalid input.

src/java.base/share/classes/java/lang/StringCoding.java line 140:

> 138:      *
> 139:      * @param sa the source byte array containing characters encoded in UTF-16
> 140:      * @param sp the index of the <em>byte (not character!)</em> from the source array to start reading from

Note the `byte (not character!)` emphasis here and below.

src/java.base/share/classes/java/lang/StringCoding.java line 150:

> 148:      */
> 149:     static int encodeISOArray(byte[] sa, int sp, byte[] da, int dp, int len) {
> 150:         checkFromIndexSize(sp, len << 1, requireNonNull(sa, "sa").length, AIOOBE_FORMATTER);

`sa` contains 2-byte `char`s, and `sp` points to an index of this inflated array. Though, `len` denotes the codepoint count, hence the `len << 1` while checking `sp` and `len` bounds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2197576759
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2197566783
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2197572078

From liach at openjdk.org  Thu Jul 10 12:58:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Jul 2025 12:58:55 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
Message-ID: <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>

On Fri, 27 Jun 2025 07:22:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringCoding.java line 93:
>> 
>>> 91:     public static int countPositives(byte[] ba, int off, int len) {
>>> 92:         Objects.requireNonNull(ba, "ba");
>>> 93:         Objects.checkFromIndexSize(off, len, ba.length);
>> 
>> I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the `len` argument to be non-negative? That allows us to simplify this to `Objects.checkIndex(off, ba.length - len)`. See this usage in perf-sensitive FFM API: https://github.com/openjdk/jdk/blob/149882416a956dec728a964c150b826dd589908f/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java#L401
>
> But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative`
> 
> This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately.

My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2172044145

From duke at openjdk.org  Thu Jul 10 12:58:56 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 10 Jul 2025 12:58:56 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
Message-ID: <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>

On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative`
>> 
>> This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately.
>
> My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression.

Maybe?use `jdk.internal.util.Preconditions` directly?instead?
Suggestion:

        Preconditions.checkFromIndexSize(off, len, ba.length, null);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2172823303

From liach at openjdk.org  Thu Jul 10 12:58:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Jul 2025 12:58:55 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ 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: <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@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 C++ methods, 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");
>         }
>     }
> }
> 
> 2. Comp...

src/java.base/share/classes/java/lang/StringCoding.java line 93:

> 91:     public static int countPositives(byte[] ba, int off, int len) {
> 92:         Objects.requireNonNull(ba, "ba");
> 93:         Objects.checkFromIndexSize(off, len, ba.length);

I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the `len` argument to be non-negative? That allows us to simplify this to `Objects.checkIndex(off, ba.length - len)`. See this usage in perf-sensitive FFM API: https://github.com/openjdk/jdk/blob/149882416a956dec728a964c150b826dd589908f/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java#L401

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2169545990

From vyazici at openjdk.org  Thu Jul 10 12:58:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:56 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
Message-ID: <bAdxgImspJYrluIITQe3keO4y7QC4SRR_pO-dWvcdFk=.a4d45d2f-bffa-4762-be24-868901cad785@github.com>

On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative`
>> 
>> This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately.
>
> My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression.

@liach, thanks for sharing your feedback on this draft, much appreciated. ? In order to address your (rightful) concerns (which I also share) regarding the performance impact, in 196fc5d, I've added `StringCodingCountPositives` JMH benchmark and produced the following results:

*OS:* Ubuntu 24.04.2
*CPU:* Intel Core Ultra 9 185H x 22


Mode  Cnt  Score   Error  Units
avgt   10  8.617 ? 0.646  ns/op          # 149882416a9 (strIntrinCheck)
avgt   10  8.787 ? 0.313  ns/op          # 5a1301df195 (master)


AFAICT, (even though the patched version appears to be performing better ?) the scores do match. Note that I will run the entire `test/micro/org/openjdk/bench/java/lang/String*.java` suite on various platforms and make sure there are no (visible?) performance regressions, before promoting this draft to a PR.

Let me know if this addresses your concerns and if there is anything else I can do to better assess the performance impact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2185582087

From vyazici at openjdk.org  Thu Jul 10 12:58:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:53 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
Message-ID: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>

Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, 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");
        }
    }
}

2. Compiled the JDK and run the test:

$ bash jib.sh configure -p linux-x64-slowdebug
$ CONF=linux-x64-slowdebug make jdk
$ ./build/linux-x64-slowdebug/jdk/bin/java -XX:+VerifyIntrinsicChecks --add-exports java.base/jdk.internal.access=ALL-UNNAMED StrIntri.java
java.lang.ArrayIndexOutOfBoundsException: Range [2, 2 + 5) out of bounds for length 3

Received `AIOOBE` as expected.

3. Removed all checks in `StringCodec.java`, and re-compiled the JDK
4. Set the `countPositives(...)` arguments in the program to `(null, 1, 1)`, run it, and observed the VM crash with `unexpected null in intrinsic`.
5. Set the `countPositives(...)` arguments in the program to `(new byte[]{1,2,3}, 2, 5)`, run it, and observed the VM crash with `unexpected guard failure in intrinsic`.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
 - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
 - Improve intrinsics in `StringCoding`
 - Add `StringCodingCountPositives` benchmark
 - Apply review feedback
 - Move `StringCoding::countPositives` checks from C++ to Java

Changes: https://git.openjdk.org/jdk/pull/25998/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361842
  Stats: 271 lines in 18 files changed: 157 ins; 19 del; 95 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  Thu Jul 10 12:58:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:56 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
 <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>
Message-ID: <vtqgBq-5e9-5EF_Co_DeFx3gSp4n1n_kZ-GvtZBUqcc=.aa4d90b1-b154-4cbc-bf63-44b27d02fe18@github.com>

On Fri, 27 Jun 2025 20:21:31 GMT, ExE Boss <duke at openjdk.org> wrote:

>> My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression.
>
> Maybe?use `jdk.internal.util.Preconditions` directly?instead?
> Suggestion:
> 
>         Preconditions.checkFromIndexSize(off, len, ba.length, null);

@ExE-Boss, I consulted this internally and decided to stick to using public APIs, unless there is a reason not to do so. In short, given `Objects::checkFromIndexSize` directly delegates to `Preconditions::checkFromIndexSize`, I expect that C2 will do its magic. Note my remark above that, prior to promoting this draft to a PR, a comprehensive benchmark suite run will be performed when all intrinsics of concern are addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2185587428

From thartmann at openjdk.org  Thu Jul 10 12:58:55 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Jul 2025 12:58:55 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
Message-ID: <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>

On Thu, 26 Jun 2025 17:26:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, 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();
>>   ...
>
> src/java.base/share/classes/java/lang/StringCoding.java line 93:
> 
>> 91:     public static int countPositives(byte[] ba, int off, int len) {
>> 92:         Objects.requireNonNull(ba, "ba");
>> 93:         Objects.checkFromIndexSize(off, len, ba.length);
> 
> I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the `len` argument to be non-negative? That allows us to simplify this to `Objects.checkIndex(off, ba.length - len)`. See this usage in perf-sensitive FFM API: https://github.com/openjdk/jdk/blob/149882416a956dec728a964c150b826dd589908f/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java#L401

But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative`

This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2170997677

From vyazici at openjdk.org  Thu Jul 10 12:58:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:56 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <vtqgBq-5e9-5EF_Co_DeFx3gSp4n1n_kZ-GvtZBUqcc=.aa4d90b1-b154-4cbc-bf63-44b27d02fe18@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
 <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>
 <vtqgBq-5e9-5EF_Co_DeFx3gSp4n1n_kZ-GvtZBUqcc=.aa4d90b1-b154-4cbc-bf63-44b27d02fe18@github.com>
Message-ID: <WSlx76BipS-RhuSlJyR8jV_uiWs5_ZJ5PrxD8toqhaw=.44efab1a-c960-4b56-90b1-a0af0e64c5bd@github.com>

On Fri, 4 Jul 2025 15:03:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Maybe?use `jdk.internal.util.Preconditions` directly?instead?
>> Suggestion:
>> 
>>         Preconditions.checkFromIndexSize(off, len, ba.length, null);
>
> @ExE-Boss, I consulted this internally and decided to stick to using public APIs, unless there is a reason not to do so. In short, given `Objects::checkFromIndexSize` directly delegates to `Preconditions::checkFromIndexSize`, I expect that C2 will do its magic. Note my remark above that, prior to promoting this draft to a PR, a comprehensive benchmark suite run will be performed when all intrinsics of concern are addressed.

Doh! I've just noticed `Objects::checkFromIndexSize` throws `IndexOutOfBoundsException`, though we need `ArrayIndexOutOfBoundsException`. `Objects::checkFromIndexSize` doesn't accept an exception supplier, replacing it with `Preconditions::checkFromIndexSize`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2185930404

From missa at openjdk.org  Thu Jul 10 14:33:40 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 10 Jul 2025 14:33:40 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
Message-ID: <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>

On Thu, 10 Jul 2025 04:52:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> What is the accuracy of the algorithm in ulps (units the last place)?
> 
> The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet.

0.51 ulps

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

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

From kvn at openjdk.org  Thu Jul 10 17:04:40 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 10 Jul 2025 17:04:40 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v6]
In-Reply-To: <-rnlrm6PHRZeO1izbXh5nOrm368YKrsFft1u6SHXzWA=.9c8e6646-0b72-4705-895e-f795f74f3906@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <-rnlrm6PHRZeO1izbXh5nOrm368YKrsFft1u6SHXzWA=.9c8e6646-0b72-4705-895e-f795f74f3906@github.com>
Message-ID: <SUQGU1fMoQucN4MWkIYcgtHzkSQStaRP3rdaXNYDxIk=.3e368fce-099f-4337-aaeb-68f0f310a75a@github.com>

On Thu, 10 Jul 2025 06:13:27 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to destruct_map_clone
>  - +'_' and ctor init

Looks good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25936#pullrequestreview-3006571921

From jrose at openjdk.org  Thu Jul 10 20:56:38 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 10 Jul 2025 20:56:38 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ 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: <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@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 C++ methods, 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");
>         }
>     }
> }
> 
> 2. Comp...

I disagree with a small part of the statement of goals:

> Always validate all input at the intrinsic (but preferably behind a VM flag)

As formulated above, this is a violation of DRY and if embraced the wrong way will lead to code that is harder to review and prove bug-free.  Performing 100% accurate range/null/validation checks is deeply impractical for an assembly-based or IR-based intrinsic.  It?s too hard to verify by code review, and coverage testing is suspect.

We must frankly put all the weight of verification on Java code, including Java bytecode intrinsic behaviors.  Java code is high-level and can be read mostly as a declarative spec, if clearly written (as straight-line code, then the intrinsic call).  Also, such simple Java code shapes (and their underlying bytecodes) are tested many orders of magnitude more than any given intrinsic.

I see two bits of evidence that you agree with me on this: 1. The intrinsic-local validation (IR or assembly) is allowed to Halt instead of throw, and 2. the intrinsic-local validation is optional, turned on only by a stress test mode.  This tells me that the extra optional testing is also not required to be 100%.

Thus, I think the above goal would be better stated this way:

> Validate input in the IR or assembly code of the intrinsic in an ad hoc manner to catch bugs in the Java validation.

> Note:  IR or assembly based validation code should not obscure the code or add large maintenance costs, and under a VM diagnostic flag (or debug flag), and causing a VM halt instead of a Java throw.

I think I'm agreeing with you on the material points.  It is important to summarize our intentions accurately at the top, for those readers that are reading only the top as a summary.

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3059044829

From darcy at openjdk.org  Thu Jul 10 21:26:37 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 10 Jul 2025 21:26:37 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
 <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>
Message-ID: <fuR6ms-rfPnU-30v-gBJpQE0xKOk-a9_qgx0TTrZ7bA=.f13bb99f-2863-4776-9fec-1e8b8c3873e7@github.com>

On Thu, 10 Jul 2025 14:31:02 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> > What is the accuracy of the algorithm in ulps (units the last place)?
> > The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet.
> 
> 0.51 ulps

Please add that as a comment to the changeset.

Also, if the worst-case inputs for this algorithm are known, they should the added as part of the core libraries regression tests for the math library.

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

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

From mchevalier at openjdk.org  Fri Jul 11 07:09:54 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 11 Jul 2025 07:09:54 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
 [v6]
In-Reply-To: <-rnlrm6PHRZeO1izbXh5nOrm368YKrsFft1u6SHXzWA=.9c8e6646-0b72-4705-895e-f795f74f3906@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
 <-rnlrm6PHRZeO1izbXh5nOrm368YKrsFft1u6SHXzWA=.9c8e6646-0b72-4705-895e-f795f74f3906@github.com>
Message-ID: <Up3JIjyqmjS99TMPOKZxqZnSU4APwW6uKCmbI21RolA=.323b9f87-d427-401f-92d0-15bf5ebb818e@github.com>

On Thu, 10 Jul 2025 06:13:27 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
>> 
>> This is enforced by restoring the old state, like in
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
>> 
>> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
>> 
>> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
>> 
>> 
>> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
>> 
>> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
>> 
>> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
>> 
>> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
>> 
>> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
>> 
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
>> 
>> And here there is the challenge:
>> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
>> ...
>
> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to destruct_map_clone
>  - +'_' and ctor init

Thanks @vnkozlov and @TobiHartmann for reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25936#issuecomment-3060908007

From mchevalier at openjdk.org  Fri Jul 11 07:09:55 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 11 Jul 2025 07:09:55 GMT
Subject: Integrated: 8359344: C2: Malformed control flow after intrinsic
 bailout
In-Reply-To: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
References: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@github.com>
Message-ID: <h_U5TrzllWZOna91vwroYL_wyU1DHkdqLAxtYb6JtU4=.282bbe0e-4659-4038-903b-cb70aed59307@github.com>

On Mon, 23 Jun 2025 13:09:43 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> When intrinsic bailout, we assume that the control in the `LibraryCallKit` did not change:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L137
> 
> This is enforced by restoring the old state, like in
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L1722-L1732
> 
> That is good, but not sufficient. First, the most obvious, one could have already built some structure without moving the control. For instance, we can obtain something such as:
> 
> ![1 after-intrinsic-bailout-during-late-inlining](https://github.com/user-attachments/assets/2fd255cc-0bfc-4841-8dd1-f64d502e0ee1)
> 
> 
> Here, during late inlining, the call `323` is candidate to be inline, but that bails out. Yet, a call to `make_unsafe_address` was made, which built nodes `354 If` and everything under. This is needed as tests are made on the resulting nodes (especially `366 AddP`) to know whether we should bail out or not. At the end, we get 2 control successor to `346 IfFalse`: the call that is not removed and the leftover of the intrinsic that will be cleanup much later, but not by RemoveUseless.
> 
> Another situation is somewhat worse, when happening during parsing. It can lead to such cases:
> 
> ![2 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/4524c615-6521-4f0d-8f61-c426f9179035)
> 
> The nodes `31 OpaqueNotNull`, `31 If`, `36 IfTrue`, `33 IfFalse`, `35 Halt`, `44 If`, `45 IfTrue`, `46 IfFalse` are leftover from a bailing out intrinsic. The replacement call `49 CallStaticJava` should come just under `5 Parm`, but the control was updated and the call is actually built under `36 If`. Then, why does the previous assert doesn't complain?
> 
> This is because there is more than one control, or one map. In intrinsics that need to restore their state, the initial `SafePoint` map is cloned, the clone is kept aside, and if needed (bailing out), we set the current map to this saved clone. But there is another map from which the one of the `LibraryCallKit` comes, and that survives longer, it's the one that is contained in the `JVMState`:
> 
> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/hotspot/share/opto/library_call.cpp#L101-L102
> 
> And here there is the challenge:
> - the `JVMState jvms` contains a `SafePoint` map, this map must have `jvms` as `jvms` (pointer comparison)
> - we can't really change the pointer, just the content
> -...

This pull request has now been integrated.

Changeset: 3ffc5b9e
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ffc5b9ef720a07143ef5728d2597afdf2f2c251
Stats:     358 lines in 7 files changed: 240 ins; 75 del; 43 mod

8359344: C2: Malformed control flow after intrinsic bailout

Reviewed-by: thartmann, kvn

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

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

From vyazici at openjdk.org  Fri Jul 11 08:40:40 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 11 Jul 2025 08:40:40 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics
In-Reply-To: <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com>
Message-ID: <w_UNRtKLIrLTYOorLnJUZBAW5VFt8uten6KXUwAUwwI=.54ceb4fb-85d0-465a-a5a9-9711546ad5bb@github.com>

On Thu, 10 Jul 2025 20:54:24 GMT, John R Rose <jrose 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...
>
> I disagree with a small part of the statement of goals:
> 
>> Always validate all input at the intrinsic (but preferably behind a VM flag)
> 
> As formulated above, this is a violation of DRY and if embraced the wrong way will lead to code that is harder to review and prove bug-free.  Performing 100% accurate range/null/validation checks is deeply impractical for an assembly-based or IR-based intrinsic.  It?s too hard to verify by code review, and coverage testing is suspect.
> 
> We must frankly put all the weight of verification on Java code, including Java bytecode intrinsic behaviors.  Java code is high-level and can be read mostly as a declarative spec, if clearly written (as straight-line code, then the intrinsic call).  Also, such simple Java code shapes (and their underlying bytecodes) are tested many orders of magnitude more than any given intrinsic.
> 
> I see two bits of evidence that you agree with me on this: 1. The intrinsic-local validation (IR or assembly) is allowed to Halt instead of throw, and 2. the intrinsic-local validation is optional, turned on only by a stress test mode.  This tells me that the extra optional testing is also not required to be 100%.
> 
> Thus, I think the above goal would be better stated this way:
> 
>> Validate input in the IR or assembly code of the intrinsic in an ad hoc manner to catch bugs in the Java validation.
> 
>> Note:  IR or assembly based validation code should not obscure the code or add large maintenance costs, and under a VM diagnostic flag (or debug flag), and causing a VM halt instead of a Java throw.
> 
> I think I'm agreeing with you on the material points.  It is important to summarize our intentions accurately at the top, for those readers that are reading only the top as a summary.

@rose00, thanks so much for the feedback. I agree with your remarks and get your points on _"Always validate all input at the intrinsic"_ is a violation of DRY and an impractical goal.

I incorporated your suggestions as follows:

1. Renamed the ticket to `Move input validation checks to Java for String-related intrinsics` (to better reflect the goal)
2. Replaced `Always validate all input at the intrinsic...` with your suggestion

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3061201145

From duke at openjdk.org  Sun Jul 13 18:31:59 2025
From: duke at openjdk.org (duke)
Date: Sun, 13 Jul 2025 18:31:59 GMT
Subject: Withdrawn: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <gxHnytUC-4FxOCzfdNqXlZKsKaRFxv2sIx4OQd8-3TU=.81d3f2be-1df5-45f6-b8d6-20cc4c6186df@github.com>

On Sun, 23 Feb 2025 18:53:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> 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...

This pull request has been closed without being integrated.

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

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

From tschatzl at openjdk.org  Mon Jul 14 08:03:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 08:03:47 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
Message-ID: <mmlNgBegOf3YMmUIXIzwKno1STvzS1_5o7Jhmr7-8XA=.92dac625-f773-498b-a014-addfd74e619e@github.com>

On Mon, 7 Jul 2025 12:36:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> 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 c...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 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
>  - * ayang review: remove sweep_epoch
>  - Merge branch 'master' into card-table-as-dcq-merge
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - * ayang review (part 2 - yield duration changes)
>  - * ayang review (part 1)
>  - * indentation fix
>  - ... and 47 more: https://git.openjdk.org/jdk/compare/d75ea7e6...441c234a

Not yet...

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3068246695

From aph at openjdk.org  Mon Jul 14 08:25:48 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Jul 2025 08:25:48 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
Message-ID: <gvVKJFTN6wQKkP4VxBh_6-GhYNdQSoq3KQ05pj54A0Q=.7fe80989-b668-420e-b439-179786b39800@github.com>

On Mon, 7 Jul 2025 12:36:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> 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 c...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 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
>  - * ayang review: remove sweep_epoch
>  - Merge branch 'master' into card-table-as-dcq-merge
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - * ayang review (part 2 - yield duration changes)
>  - * ayang review (part 1)
>  - * indentation fix
>  - ... and 47 more: https://git.openjdk.org/jdk/compare/d75ea7e6...441c234a

AArch64 looks good.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3015276922

From tschatzl at openjdk.org  Mon Jul 14 09:13:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:13:38 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v42]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <8lZdT84SJ-daIPPpdq35hAZ0MGa8b07TPpPa3IDp030=.201a5b52-aecb-424e-9bdf-4c64baff5e87@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 58 commits:

 - 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
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - ... and 48 more: https://git.openjdk.org/jdk/compare/14c79be1...5ab928e8

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=41
  Stats: 7124 lines in 112 files changed: 2589 ins; 3594 del; 941 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 dfenacci at openjdk.org  Mon Jul 14 10:34:45 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 14 Jul 2025 10:34:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related 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: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@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");
>         }
>     }
> }
> ...

Thanks a lot for looking into this Volkan!
I left a couple of minor comments.
I also noticed that you haven't yet added the benchmark results to the description: do you want to run them again after the reviews?

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6014:

> 6012: }
> 6013: 
> 6014: // Encode given `char[]`/`byte[]` to `byte[]` in ISO_8859_1 or ASCII

Thanks for updating the comments! Do we need the markdown back quotes here (and in other `macroAssembler-*` file comments)?

src/hotspot/share/classfile/vmIntrinsics.hpp line 417:

> 415:                                                                                                                         \
> 416:   do_class(java_lang_StringCoding,        "java/lang/StringCoding")                                                     \
> 417:   do_intrinsic(_countPositives,           java_lang_StringCoding, countPositives_name, countPositives_signature,   F_S) \

It is a matter of taste but it might be better not to change the whitespaces (it might make searching for changes (and possibly backports) harder. The rest of the file is not too consistent anyway).

src/hotspot/share/opto/c2_globals.hpp line 666:

> 664:                                                                             \
> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 666:           "Verify that Java level checks in intrinsics work as expected")   \

To make it clearer I think we might want to move "in intrinsic" after "Verify" or at the end.

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

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3015376813
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2204312397
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2204505403
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2204256430

From vyazici at openjdk.org  Tue Jul 15 19:21:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:21:28 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@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 three additional commits since the last revision:

 - Minimize the number of touched lines in `vmIntrinsics.hpp`
 - Remove Markdown-styling in comments
 - Improve wording of the `VerifyIntrinsicChecks` flag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/6af98646..7c042b35

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

  Stats: 14 lines in 5 files changed: 0 ins; 0 del; 14 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  Tue Jul 15 19:21:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:21:29 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <Jx0DTrwcRbgYJzQ0rbfBGQhVy1OEVU2gFJDAh32YpcQ=.07327b3c-e0b0-4a93-9d9e-03416abde256@github.com>

On Mon, 14 Jul 2025 08:49:44 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/hotspot/share/opto/c2_globals.hpp line 666:
> 
>> 664:                                                                             \
>> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
>> 666:           "Verify that Java level checks in intrinsics work as expected")   \
> 
> To make it clearer I think we might want to move "in intrinsic" after "Verify" or at the end.

Changed as suggested in c331fbfa.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208455093

From vyazici at openjdk.org  Tue Jul 15 19:27:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:27:44 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <pnD36-qHKsrbrg38-Znz4lP8Erb06nrjkamauxQ8PPw=.d9f91fbe-d4de-499e-8b39-4e5283456ba8@github.com>

On Mon, 14 Jul 2025 10:27:45 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/hotspot/share/classfile/vmIntrinsics.hpp line 417:
> 
>> 415:                                                                                                                         \
>> 416:   do_class(java_lang_StringCoding,        "java/lang/StringCoding")                                                     \
>> 417:   do_intrinsic(_countPositives,           java_lang_StringCoding, countPositives_name, countPositives_signature,   F_S) \
> 
> It is a matter of taste but it might be better not to change the whitespaces (it might make searching for changes (and possibly backports) harder. The rest of the file is not too consistent anyway).

Fixed in 7c042b35.

I completely agree with your point. In fact, I'm opposed to _"vertical alignment"_ due to its obvious maintainability and version control hygiene issues. Alas, that is the existing style, and I tried to adhere to it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208469532

From vyazici at openjdk.org  Tue Jul 15 19:31:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:31:42 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <wgs1GVG69QfKChew9MwaIrJQx4aVaEXnhs1P0rqa3FE=.60f3724b-d34e-4604-9b2b-86352e4c5049@github.com>

On Mon, 14 Jul 2025 09:11:08 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6014:
> 
>> 6012: }
>> 6013: 
>> 6014: // Encode given `char[]`/`byte[]` to `byte[]` in ISO_8859_1 or ASCII
> 
> Thanks for updating the comments! Do we need the markdown back quotes here (and in other `macroAssembler-*` file comments)?

No, we don't. Since Markdown has become ubiquitous in text-based typesetting, I find it easier to read and, whenever needed, share it in other mediums; Slack, GitHub, JIRA, Javadoc, Microsoft Office 365, Google Docs, etc. I presume you prefer without backticks ? removed them in b60ff457.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208477825

From vyazici at openjdk.org  Tue Jul 15 19:34:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:34:42 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <0Rbm6JuupxK9iYkXljWRpmdCAg_fmf_92FUckntpQ3A=.7c633679-c46c-4395-8431-8564301b0dbb@github.com>

On Mon, 14 Jul 2025 10:32:24 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> I left a couple of minor comments. I also noticed that you haven't yet added the benchmark results to the description: do you want to run them again after the reviews?

@dafedafe, thanks so much for the review! I've implemented the changes you requested, and shared some benchmark figures in the associated ticket. I am still actively working on evaluating the performance impact.

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3075223785

From rriggs at openjdk.org  Tue Jul 15 19:50:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 19:50:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
Message-ID: <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>

On Tue, 15 Jul 2025 19:21:28 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 three additional commits since the last revision:
> 
>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>  - Remove Markdown-styling in comments
>  - Improve wording of the `VerifyIntrinsicChecks` flag

src/java.base/share/classes/java/lang/StringCoding.java line 36:

> 34: import static java.util.Objects.requireNonNull;
> 35: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
> 36: import static jdk.internal.util.Preconditions.checkFromIndexSize;

Avoid import static of methods, it makes the code harder to read and understand where the methods come from.
Just import Preconditions.

src/java.base/share/classes/java/lang/StringCoding.java line 162:

> 160:             if (c > '\u00FF')
> 161:                 break;
> 162:             da[dp++] = (byte) c;

Revert: Omit the space after (byte); there many more usages of "(byte)c" and this file does not need to drift from the prevailing style in StringUTF16.java AbstractStringBuilder, etc.
Here and at line 195:

src/java.base/share/classes/java/lang/StringCoding.java line 189:

> 187: 
> 188:     @IntrinsicCandidate
> 189:     private static int encodeAsciiArray0(char[] sa, int sp, byte[] da, int dp, int len) {

I rather prefer the readability of the src and dest parameters being on separate lines. (but not "{" by itself
Suggestion:

    private static int encodeAsciiArray0(char[] sa, int sp, 
                                         byte[] da, int dp, int len) {

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 43:

> 41: import static java.util.Objects.requireNonNull;
> 42: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
> 43: import static jdk.internal.util.Preconditions.checkFromIndexSize;

Avoid static imports of methods, it makes it harder to read and know where the methods are especially when crossing package boundaries.

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 177:

> 175:                 if (c > '\u00FF')
> 176:                     break;
> 177:                 da[dp++] = (byte) c;

Revert extra space.

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 201:

> 199:             int len  = (dlen < slen) ? dlen : slen;
> 200:             try {
> 201:                 int ret = len <= 0 ? 0 : encodeISOArray(sa, sp, da, dp, len);

Moving the length correction into `encodeISOArray` would help other callers too.  (There's only 1 at the moment).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208470957
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208491363
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208494207
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208503099
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208504829
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208510343

From vyazici at openjdk.org  Tue Jul 15 20:24:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 20:24:04 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Apply review feedback (styling changes)
 - Minimize the number of touched lines in `vmIntrinsics.hpp`
 - Remove Markdown-styling in comments
 - Improve wording of the `VerifyIntrinsicChecks` flag
 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
 - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
   
   This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
 - Improve intrinsics in `StringCoding`
 - Add `StringCodingCountPositives` benchmark
 - ... and 2 more: https://git.openjdk.org/jdk/compare/b424f31d...85f19864

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/7c042b35..85f19864

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

  Stats: 7104 lines in 199 files changed: 2886 ins; 3418 del; 800 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  Tue Jul 15 20:24:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 20:24:04 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
 <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
Message-ID: <ugG_C0UBIiUOJV2vcib89uno7vn292iwp3rvVwMfQA4=.e30be329-5eee-4587-961d-8453bf1b3ce3@github.com>

On Tue, 15 Jul 2025 19:25:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/java.base/share/classes/java/lang/StringCoding.java line 36:
> 
>> 34: import static java.util.Objects.requireNonNull;
>> 35: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
>> 36: import static jdk.internal.util.Preconditions.checkFromIndexSize;
> 
> Avoid import static of methods, it makes the code harder to read and understand where the methods come from.
> Just import Preconditions.

Fixed in 2672f7c1ada.

> src/java.base/share/classes/java/lang/StringCoding.java line 162:
> 
>> 160:             if (c > '\u00FF')
>> 161:                 break;
>> 162:             da[dp++] = (byte) c;
> 
> Revert: Omit the space after (byte); there many more usages of "(byte)c" and this file does not need to drift from the prevailing style in StringUTF16.java AbstractStringBuilder, etc.
> Here and at line 195:

I've actually made these changes to match the code shared in intrinsics, e.g., `macroAssembler_x86.cpp`. Reverted them in 2672f7c1ada as you requested.

> src/java.base/share/classes/java/lang/StringCoding.java line 189:
> 
>> 187: 
>> 188:     @IntrinsicCandidate
>> 189:     private static int encodeAsciiArray0(char[] sa, int sp, byte[] da, int dp, int len) {
> 
> I rather prefer the readability of the src and dest parameters being on separate lines. (but not "{" by itself
> Suggestion:
> 
>     private static int encodeAsciiArray0(char[] sa, int sp, 
>                                          byte[] da, int dp, int len) {

Changed as requested in 2672f7c1ada.

> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 43:
> 
>> 41: import static java.util.Objects.requireNonNull;
>> 42: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
>> 43: import static jdk.internal.util.Preconditions.checkFromIndexSize;
> 
> Avoid static imports of methods, it makes it harder to read and know where the methods are especially when crossing package boundaries.

Changed as requested in 2672f7c1ada.

> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 177:
> 
>> 175:                 if (c > '\u00FF')
>> 176:                     break;
>> 177:                 da[dp++] = (byte) c;
> 
> Revert extra space.

Changed as requested in 2672f7c1ada.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208575103
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208578241
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208579144
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208579489
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208579689

From vyazici at openjdk.org  Tue Jul 15 20:26:41 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 20:26:41 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
 <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
Message-ID: <r4Jq9gM2GkBVZaTpjsTiRtmfYDqFbG5vfZB73pm4di0=.9a8b2793-b82f-49a8-a395-6986d7be2d25@github.com>

On Tue, 15 Jul 2025 19:45:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 201:
> 
>> 199:             int len  = (dlen < slen) ? dlen : slen;
>> 200:             try {
>> 201:                 int ret = len <= 0 ? 0 : encodeISOArray(sa, sp, da, dp, len);
> 
> Moving the length correction into `encodeISOArray` would help other callers too.  (There's only 1 at the moment).

I've tried to make the code such that wrapper functions contain nothing but argument checks. Moving `if (len <= 0) { return 0; }` logic to the wrapper function will introduce a behavior different than the one implemented by the intrinsic. @RogerRiggs, do you still prefer me to carry out this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208585771

From rriggs at openjdk.org  Tue Jul 15 20:32:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 20:32:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <r4Jq9gM2GkBVZaTpjsTiRtmfYDqFbG5vfZB73pm4di0=.9a8b2793-b82f-49a8-a395-6986d7be2d25@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
 <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
 <r4Jq9gM2GkBVZaTpjsTiRtmfYDqFbG5vfZB73pm4di0=.9a8b2793-b82f-49a8-a395-6986d7be2d25@github.com>
Message-ID: <97fQvq2H2iV-UmT7CnECiBAza6fhFXdexNzkyPOaThc=.482af2ba-78a5-4201-b1b5-476d24c93f39@github.com>

On Tue, 15 Jul 2025 20:24:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 201:
>> 
>>> 199:             int len  = (dlen < slen) ? dlen : slen;
>>> 200:             try {
>>> 201:                 int ret = len <= 0 ? 0 : encodeISOArray(sa, sp, da, dp, len);
>> 
>> Moving the length correction into `encodeISOArray` would help other callers too.  (There's only 1 at the moment).
>
> I've tried to make the code such that wrapper functions contain nothing but argument checks. Moving `if (len <= 0) { return 0; }` logic to the wrapper function will introduce a behavior different than the one implemented by the intrinsic. @RogerRiggs, do you still prefer me to carry out this change?

The wrapper is the method actually called, the intrinsic `encodeISOArray0` intrinsic would be inlined into it.
I don't have a compelling reason to change it, given the solitary caller.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208599130

From rriggs at openjdk.org  Tue Jul 15 21:52:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 21:52:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
Message-ID: <K5Vuk4SylBZ50flNAkTaUQp6fkTGYVcxiK5ZUuo9pxE=.7ecf49f9-00d0-4052-82ec-898125113034@github.com>

On Tue, 15 Jul 2025 20:24:04 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 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Apply review feedback (styling changes)
>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>  - Remove Markdown-styling in comments
>  - Improve wording of the `VerifyIntrinsicChecks` flag
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
>  - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
>    
>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>  - Improve intrinsics in `StringCoding`
>  - Add `StringCodingCountPositives` benchmark
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/611f6cea...85f19864

Looks good, thanks for the updates.
A Hotspot reviewer should approve also.

/Reviewers 2 reviewer

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3022453251
PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3075835741

From thartmann at openjdk.org  Wed Jul 16 05:32:45 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 16 Jul 2025 05:32:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
Message-ID: <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>

On Tue, 15 Jul 2025 20:24:04 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 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Apply review feedback (styling changes)
>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>  - Remove Markdown-styling in comments
>  - Improve wording of the `VerifyIntrinsicChecks` flag
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
>  - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
>    
>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>  - Improve intrinsics in `StringCoding`
>  - Add `StringCodingCountPositives` benchmark
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/32d96877...85f19864

Thanks a lot for working on this, Volkan! The changes look good to me, I just added two comments.

src/hotspot/share/opto/c2_globals.hpp line 665:

> 663:           "prints attempted and successful inlining of intrinsics")         \
> 664:                                                                             \
> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \

We should add testing that uses this new flag. Maybe we could add a run to the tests that check the affected intrinsics? We could also add it to our (Oracle internal) stress test jobs at higher tiers.

src/hotspot/share/opto/library_call.cpp line 971:

> 969:     } else {
> 970:       PreserveJVMState pjvms(this);
> 971:       set_control(_gvn.transform(bailout));

Suggestion:

    bailout = _gvn.transform(bailout);
    if (halt) {
      Node* frame = _gvn.transform(new ParmNode(C->start(), TypeFunc::FramePtr));
      Node* halt = _gvn.transform(new HaltNode(bailout, frame, "unexpected guard failure in intrinsic"));
      C->root()->add_req(halt);
    } else {
      PreserveJVMState pjvms(this);
      set_control(bailout);

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3023137214
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2209259866
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2209245394

From vyazici at openjdk.org  Wed Jul 16 07:51:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 07:51:26 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v4]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <3L2KmYco1fW5Or9Lzhp17mW-Pk-ANOp5UYQ6sL3gZfs=.d7560969-8b3f-478f-a89d-2c34cf875ec9@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:

  Improve `generate_string_range_check` changes
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/85f19864..2b89e880

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

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 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 dnsimon at openjdk.org  Wed Jul 16 08:43:49 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 08:43:49 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash
Message-ID: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>

This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

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

Commit messages:
 - fixed bug in HotSpotJVMCIRuntime.getMirror for <clinit> and injected fields

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

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

From dnsimon at openjdk.org  Wed Jul 16 08:48:53 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 08:48:53 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v2]
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <QPWrs0RqLQbzToNUjlLNd49JQL6wWJFoKqL0shEJ1kQ=.7946aa77-6363-42d6-80a0-266043b8e6cc@github.com>

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

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:

  fixed bug in HotSpotJVMCIRuntime.getMirror for <clinit> and injected fields

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26346/files
  - new: https://git.openjdk.org/jdk/pull/26346/files/8c44d9ff..cca137a3

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

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

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

From gdub at openjdk.org  Wed Jul 16 10:27:40 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 16 Jul 2025 10:27:40 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v2]
In-Reply-To: <QPWrs0RqLQbzToNUjlLNd49JQL6wWJFoKqL0shEJ1kQ=.7946aa77-6363-42d6-80a0-266043b8e6cc@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <QPWrs0RqLQbzToNUjlLNd49JQL6wWJFoKqL0shEJ1kQ=.7946aa77-6363-42d6-80a0-266043b8e6cc@github.com>
Message-ID: <WJOsh4LepQ5kPY6xyd8m7jogFJvtPwQqaD_x01Z6lA8=.a3b71d6e-7c41-43ac-9ba1-ce8aae965aa6@github.com>

On Wed, 16 Jul 2025 08:48:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> 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:
> 
>   fixed bug in HotSpotJVMCIRuntime.getMirror for <clinit> and injected fields

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3000:

> 2998: }
> 2999: 
> 3000: C2V_VMENTRY_NULL(jobject, asReflectionField, (JNIEnv* env, jobject, ARGUMENT_PAIR(klass), jint index))

There is the same pattern in `getEncodedFieldAnnotationData`, we should probably defend there as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26346#discussion_r2209921506

From dnsimon at openjdk.org  Wed Jul 16 13:17:04 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 13:17:04 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v3]
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <GcufEAiDcqThIrXq9RkfbER_cyPk4I4QPZnVU2fFolk=.39559e97-3fca-4bb7-b174-397c9b41ef92@github.com>

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

Doug Simon has updated the pull request incrementally with two additional commits since the last revision:

 - fixed bug in use of JVMCI traps
 - moved inject field check into check_field for benefit of get_encoded_annotation_data

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26346/files
  - new: https://git.openjdk.org/jdk/pull/26346/files/cca137a3..c76efe51

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

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

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

From dnsimon at openjdk.org  Wed Jul 16 13:17:04 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 13:17:04 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v2]
In-Reply-To: <WJOsh4LepQ5kPY6xyd8m7jogFJvtPwQqaD_x01Z6lA8=.a3b71d6e-7c41-43ac-9ba1-ce8aae965aa6@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <QPWrs0RqLQbzToNUjlLNd49JQL6wWJFoKqL0shEJ1kQ=.7946aa77-6363-42d6-80a0-266043b8e6cc@github.com>
 <WJOsh4LepQ5kPY6xyd8m7jogFJvtPwQqaD_x01Z6lA8=.a3b71d6e-7c41-43ac-9ba1-ce8aae965aa6@github.com>
Message-ID: <XBJm4XJWGjaFGBkqE7N-D24GjXTXC3mLUtsYxjA3G4Q=.d903e1f4-29c0-43e2-9659-93d62746c17b@github.com>

On Wed, 16 Jul 2025 10:25:24 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

>> 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:
>> 
>>   fixed bug in HotSpotJVMCIRuntime.getMirror for <clinit> and injected fields
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3000:
> 
>> 2998: }
>> 2999: 
>> 3000: C2V_VMENTRY_NULL(jobject, asReflectionField, (JNIEnv* env, jobject, ARGUMENT_PAIR(klass), jint index))
> 
> There is the same pattern in `getEncodedFieldAnnotationData`, we should probably defend there as well.

Good point: c2c41aa20ef214c5f63942cc5e257dfaaafb13ea

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26346#discussion_r2210397327

From gdub at openjdk.org  Wed Jul 16 14:42:49 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 16 Jul 2025 14:42:49 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v3]
In-Reply-To: <GcufEAiDcqThIrXq9RkfbER_cyPk4I4QPZnVU2fFolk=.39559e97-3fca-4bb7-b174-397c9b41ef92@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <GcufEAiDcqThIrXq9RkfbER_cyPk4I4QPZnVU2fFolk=.39559e97-3fca-4bb7-b174-397c9b41ef92@github.com>
Message-ID: <BzTFyTwxJgh4r8Rg37OP2YJ0i1Q17Xw6dbP0NewNb8U=.dc2b58e0-d23d-43fc-8037-766d14191361@github.com>

On Wed, 16 Jul 2025 13:17:04 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed bug in use of JVMCI traps
>  - moved inject field check into check_field for benefit of get_encoded_annotation_data

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3084:

> 3082:   CompilerThreadCanCallJava canCallJava(thread, true); // Requires Java support
> 3083:   InstanceKlass* holder = InstanceKlass::cast(UNPACK_PAIR(Klass, klass));
> 3084:   return get_encoded_annotation_data(holder, holder->class_annotations(), true, filter_length, filter_klass_pointers, THREAD, JVMCI_CHECK_NULL);

Can `JVMCI_CHECK_` be used in `return` statements? i think the "check and return default value" part would be unreachable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26346#discussion_r2210628575

From dnsimon at openjdk.org  Wed Jul 16 15:03:36 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 15:03:36 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v4]
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <oVcbnphj11M9T5DBo8zuCtInI8svIuQsgJbYOwVJKZM=.2aa4ad15-595d-4c5e-b1cf-e3d995c80507@github.com>

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

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

  revert from JVMCI_CHECK_NULL back to JVMCIENV in final return statement of method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26346/files
  - new: https://git.openjdk.org/jdk/pull/26346/files/c76efe51..7cf4b26c

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

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

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

From dnsimon at openjdk.org  Wed Jul 16 15:03:39 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 15:03:39 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v3]
In-Reply-To: <BzTFyTwxJgh4r8Rg37OP2YJ0i1Q17Xw6dbP0NewNb8U=.dc2b58e0-d23d-43fc-8037-766d14191361@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <GcufEAiDcqThIrXq9RkfbER_cyPk4I4QPZnVU2fFolk=.39559e97-3fca-4bb7-b174-397c9b41ef92@github.com>
 <BzTFyTwxJgh4r8Rg37OP2YJ0i1Q17Xw6dbP0NewNb8U=.dc2b58e0-d23d-43fc-8037-766d14191361@github.com>
Message-ID: <wTckuo7OUxX0MLvREqMx4QKVu0kIMA_OiPjjfSWcodY=.1b889750-9534-4f9d-b08a-18d06ea2ed14@github.com>

On Wed, 16 Jul 2025 14:38:35 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed bug in use of JVMCI traps
>>  - moved inject field check into check_field for benefit of get_encoded_annotation_data
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3084:
> 
>> 3082:   CompilerThreadCanCallJava canCallJava(thread, true); // Requires Java support
>> 3083:   InstanceKlass* holder = InstanceKlass::cast(UNPACK_PAIR(Klass, klass));
>> 3084:   return get_encoded_annotation_data(holder, holder->class_annotations(), true, filter_length, filter_klass_pointers, THREAD, JVMCI_CHECK_NULL);
> 
> Can `JVMCI_CHECK_` be used in `return` statements? i think the "check and return default value" part would be unreachable.

Indeed - I've been bitten by this before! In this case, it's harmless given that the return statement is anyway the last statement in the method. Still, I'll revert my "fix".
I'm also wondering (again?) why the C++ compiler does not warning about unreachable code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26346#discussion_r2210679057

From gdub at openjdk.org  Wed Jul 16 15:12:40 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 16 Jul 2025 15:12:40 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v4]
In-Reply-To: <oVcbnphj11M9T5DBo8zuCtInI8svIuQsgJbYOwVJKZM=.2aa4ad15-595d-4c5e-b1cf-e3d995c80507@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <oVcbnphj11M9T5DBo8zuCtInI8svIuQsgJbYOwVJKZM=.2aa4ad15-595d-4c5e-b1cf-e3d995c80507@github.com>
Message-ID: <6dUGyR9-38wxACBU-qXBcUdNuChfSQjPXNHpKsAJ3Y4=.f2397b87-fd84-4e87-9d52-0cda901810df@github.com>

On Wed, 16 Jul 2025 15:03:36 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert from JVMCI_CHECK_NULL back to JVMCIENV in final return statement of method

Maybe you could add a test in `TestResolvedJavaType.getClassInitializer` to check that `getMirror` doesn't crash on that and returns null?

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

PR Comment: https://git.openjdk.org/jdk/pull/26346#issuecomment-3079072065

From dnsimon at openjdk.org  Wed Jul 16 15:40:27 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 15:40:27 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v5]
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

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

  test that getMirror on clinit returns null

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26346/files
  - new: https://git.openjdk.org/jdk/pull/26346/files/7cf4b26c..fd44d95c

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

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

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

From dnsimon at openjdk.org  Wed Jul 16 15:40:27 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 15:40:27 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v4]
In-Reply-To: <6dUGyR9-38wxACBU-qXBcUdNuChfSQjPXNHpKsAJ3Y4=.f2397b87-fd84-4e87-9d52-0cda901810df@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <oVcbnphj11M9T5DBo8zuCtInI8svIuQsgJbYOwVJKZM=.2aa4ad15-595d-4c5e-b1cf-e3d995c80507@github.com>
 <6dUGyR9-38wxACBU-qXBcUdNuChfSQjPXNHpKsAJ3Y4=.f2397b87-fd84-4e87-9d52-0cda901810df@github.com>
Message-ID: <D44-f5RYIfLYtEDwSdFczoigEzhDTvALsxWW2RDNA4w=.773d6fba-0f9c-4f15-b187-646facf34b7a@github.com>

On Wed, 16 Jul 2025 15:09:43 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

> Maybe you could add a test in `TestResolvedJavaType.getClassInitializer` to check that `getMirror` doesn't crash on that and returns null?

Done: https://github.com/openjdk/jdk/pull/26346/commits/fd44d95c83bb9160395b5fe94298f1a300233001

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

PR Comment: https://git.openjdk.org/jdk/pull/26346#issuecomment-3079185834

From gdub at openjdk.org  Wed Jul 16 15:49:41 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 16 Jul 2025 15:49:41 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v5]
In-Reply-To: <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
Message-ID: <aFLGpme1BuCm0gK_fKFO9vn2H-A5-qH2VFB9PEPxXFE=.4220d3d6-4473-464e-a4d2-4b19afc2fa9c@github.com>

On Wed, 16 Jul 2025 15:40:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test that getMirror on clinit returns null

Marked as reviewed by gdub (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26346#pullrequestreview-3025670605

From vyazici at openjdk.org  Wed Jul 16 19:38:02 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 19:38:02 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v5]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <hqDqiIGVA7b4bjOO-QUsL-_7tB-3-MxUZoGZ1tBPozY=.3ca0eefe-80a1-4f1e-b01f-196f9770d51e@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:

  Add test verifying the effectiveness of `VerifyIntrinsicChecks`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/2b89e880..8941e6b6

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

  Stats: 110 lines in 3 files changed: 108 ins; 0 del; 2 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  Wed Jul 16 19:42:32 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 19:42:32 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v6]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <pozYBtbEcYQCqynctIMGBY_G3HJFLYXL8DOjrUudzsk=.ec4d7f03-938c-4728-a2c1-60f8fc549b69@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 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:

  Add test verifying the effectiveness of `VerifyIntrinsicChecks`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/8941e6b6..bcb073cb

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 cslucas at openjdk.org  Wed Jul 16 22:54:47 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 16 Jul 2025 22:54:47 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v5]
In-Reply-To: <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
Message-ID: <RdGKTvuSKrz_MrX0Brji8yD3c0P3qHA_-hRvtrPxthc=.179a3386-73ac-4378-a06d-7ee6054ade24@github.com>

On Wed, 16 Jul 2025 15:40:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test that getMirror on clinit returns null

LGTM

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

Marked as reviewed by cslucas (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26346#pullrequestreview-3027147958

From vyazici at openjdk.org  Thu Jul 17 04:37:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 04:37:49 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v6]
In-Reply-To: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
Message-ID: <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>

On Thu, 10 Jul 2025 12:23:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici 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:
>> 
>>   Add test verifying the effectiveness of `VerifyIntrinsicChecks`
>
> src/hotspot/share/opto/library_call.cpp line 963:
> 
>> 961: 
>> 962:   if (bailout->req() > 1) {
>> 963:     if (halt) {
> 
> Toggle to force a VM crash to be used to surface intrinsic Java wrappers failing to spot invalid input.

@TobiHartmann, this change results in the following compiler error:


/home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid conversion from 'Node*' to 'RegionNode*' [-fpermissive]
  958 |   generate_negative_guard(offset, bailout);
      |                                   ^~~~~~~
      |                                   |
      |                                   Node*


That is, `bailout` is supposed to be of type `RegionNode*`, but `_gvn.transform()` returns a value of type `Node*`. I will locally amend this change as


bailout = (RegionNode*) _gvn.transform(bailout);


Let me know if you disagree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212232094

From vyazici at openjdk.org  Thu Jul 17 06:13:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:13:30 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@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:

 - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
 - Fix compiler error in `generate_string_range_check`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/bcb073cb..abc0eeb3

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

  Stats: 61 lines in 4 files changed: 53 ins; 2 del; 6 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  Thu Jul 17 06:15:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:15:53 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
 <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
Message-ID: <tiD2-tEG9GB_6qJJuxMzR2V0qcrcEGjHaVme-D7fiUY=.404f5ff5-26d6-47ed-8315-532619554663@github.com>

On Wed, 16 Jul 2025 05:28:55 GMT, Tobias Hartmann <thartmann 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 12 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Apply review feedback (styling changes)
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
>>  - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
>>    
>>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>>  - Improve intrinsics in `StringCoding`
>>  - Add `StringCodingCountPositives` benchmark
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/921f85ab...85f19864
>
> src/hotspot/share/opto/c2_globals.hpp line 665:
> 
>> 663:           "prints attempted and successful inlining of intrinsics")         \
>> 664:                                                                             \
>> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 
> We should add testing that uses this new flag. Maybe we could add a run to the tests that check the affected intrinsics? We could also add it to our (Oracle internal) stress test jobs at higher tiers.

@TobiHartmann, agreed. I've pushed two commits:

1. bcb073cbb41 adds `TestVerifyIntrinsicChecks` to verify the effectiveness of the `VerifyIntrinsicChecks` VM flag. That is, does VM indeed crash if intrinsic Java wrapper fails to properly validate the input?
2. abc0eeb3bfc adds a separate `/* @test ... @run ... -XX:+VerifyIntrinsicChecks` block to the tests using `StringCoding` intrinsics

Please let me know if these two address your remarks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212371103

From vyazici at openjdk.org  Thu Jul 17 06:21:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:21:56 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
Message-ID: <66HgANGbmZLWZpH-g9ChFl_VX3WRq_WgYlq4edeVAIg=.7e3f06ab-ba80-4952-9ff5-168d64025783@github.com>

On Thu, 17 Jul 2025 06:13:30 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:
> 
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`

test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 84:

> 82:         char[] buffer = new char[length];
> 83:         for (int i = 0; i < length; i++) {
> 84:             buffer[i] = (char) (i % '\u0080');

ASCII (<= 0x7F) production

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212379110

From vyazici at openjdk.org  Thu Jul 17 06:31:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:31:55 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
Message-ID: <oS4jbFRoOs0Gk7rzDmHCW3j0HJVv8ETSkiJuyS_ocCo=.4fc13412-aba3-4884-bbed-6c9dea3bdd29@github.com>

On Thu, 17 Jul 2025 06:13:30 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:
> 
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`

test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java line 44:

> 42:     @jdk.internal.vm.annotation.ForceInline
> 43:     public static int StringCodingEncodeAsciiArray0(char[] sa, int sp, byte[] da, int dp, int len) {
> 44:         return StringCoding.encodeAsciiArray0(sa, sp, da, dp, len);

`TestVerifyIntrinsicChecks` needs to have access to an intrinsic that uses the `VerifyIntrinsicChecks` VM flag. For that purpose, I chose `StringCoding::encodeAsciiArray`, which is the guarded public door to `@IntrinsicCandidate encodeAsciiArray0()` ? note the `0` suffix! `TestVerifyIntrinsicChecks` needs to feed invalid input to `encodeAsciiArray0()` to trip the checks in the compiler intrinsic. Though, `encodeAsciiArray0()` is, as is one of the main motivations of this PR, private. In `TestVerifyIntrinsicChecks`, I first tried accessing to `encodeAsciiArray0()` using reflection, but this blocked the method get inlined, which is a requirement for intrinsification. Hence, I made the  `encodeAsciiArray0()` package-private and exposed it via `StringCodingEncodeAsciiArray0` to allow inlining, and, eventually, intrinsification. This worked.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212396003

From thartmann at openjdk.org  Thu Jul 17 07:06:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 17 Jul 2025 07:06:52 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
 <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>
Message-ID: <vHLGb2BnmEuVVmiXvpkYLejq3p6Qz3bzxvsLlz4kndI=.0d07e3de-d573-44b8-906e-e5810b6c977e@github.com>

On Thu, 17 Jul 2025 04:35:01 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 963:
>> 
>>> 961: 
>>> 962:   if (bailout->req() > 1) {
>>> 963:     if (halt) {
>> 
>> Toggle to force a VM crash to be used to surface intrinsic Java wrappers failing to spot invalid input.
>
> @TobiHartmann, this change results in the following compiler error:
> 
> 
> /home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid conversion from 'Node*' to 'RegionNode*' [-fpermissive]
>   958 |   generate_negative_guard(offset, bailout);
>       |                                   ^~~~~~~
>       |                                   |
>       |                                   Node*
> 
> 
> That is, `bailout` is supposed to be of type `RegionNode*`, but `_gvn.transform()` returns a value of type `Node*`. bfc301798d1 amends failing code with
> 
> 
> bailout = (RegionNode*) _gvn.transform(bailout);
> 
> 
> Let me know if you disagree.

Please use `->as_Region()` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212467404

From vyazici at openjdk.org  Thu Jul 17 07:20:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 07:20:34 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@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:

  Replace casting with `as_Region()` in `generate_string_range_check`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/abc0eeb3..db1ed388

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Thu Jul 17 07:20:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 07:20:34 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <vHLGb2BnmEuVVmiXvpkYLejq3p6Qz3bzxvsLlz4kndI=.0d07e3de-d573-44b8-906e-e5810b6c977e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
 <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>
 <vHLGb2BnmEuVVmiXvpkYLejq3p6Qz3bzxvsLlz4kndI=.0d07e3de-d573-44b8-906e-e5810b6c977e@github.com>
Message-ID: <ZF0kmTYixGF_s_Wv3IuCSXS4TUR3ocblRo_aisw1cRI=.32306c61-2fd2-43eb-9616-247d91b0146a@github.com>

On Thu, 17 Jul 2025 07:04:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> @TobiHartmann, this change results in the following compiler error:
>> 
>> 
>> /home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid conversion from 'Node*' to 'RegionNode*' [-fpermissive]
>>   958 |   generate_negative_guard(offset, bailout);
>>       |                                   ^~~~~~~
>>       |                                   |
>>       |                                   Node*
>> 
>> 
>> That is, `bailout` is supposed to be of type `RegionNode*`, but `_gvn.transform()` returns a value of type `Node*`. bfc301798d1 amends failing code with
>> 
>> 
>> bailout = (RegionNode*) _gvn.transform(bailout);
>> 
>> 
>> Let me know if you disagree.
>
> Please use `->as_Region()` instead.

Changed as requested in db1ed388765.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212492666

From thartmann at openjdk.org  Thu Jul 17 08:33:51 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 17 Jul 2025 08:33:51 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <fuxrNfsUsBbXxW1KDYlCeDY7Qdi2CrM0C6aruF1Vv80=.91e6bee4-2828-49a8-b17c-d07716666099@github.com>

On Thu, 17 Jul 2025 07:20:34 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:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

That looks good to me. Thanks!

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3028497094

From dfenacci at openjdk.org  Thu Jul 17 09:37:51 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 17 Jul 2025 09:37:51 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <zzkuyukdeX9XFwhjUDH1sRxly_VraGXe6lciLE1cWuQ=.fbf49cbe-9541-4676-92e0-be0cde765a29@github.com>

On Thu, 17 Jul 2025 07:20:34 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:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

Looks good to me too. Thanks @vy!

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

Marked as reviewed by dfenacci (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3028731726