From dholmes at openjdk.org  Mon Jun  2 02:11:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 02:11:57 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
Message-ID: <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>

On Fri, 30 May 2025 19:34:16 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() 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:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) 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 a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set address attributes in movapd assembly instruction function definition

This change also broke most of the non-x86 platforms, due to the new intrinsic not being implemented on those platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2928415483

From duke at openjdk.org  Mon Jun  2 03:52:07 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Mon, 2 Jun 2025 03:52:07 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
 <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>
Message-ID: <CJ6XTFRmKm7TsbS74Vb1viZQDP9YqiZPUZOGFJYJ_cs=.37f559f3-d1c5-48d8-9b89-f103d1b1b053@github.com>

On Mon, 2 Jun 2025 02:08:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This change also broke most of the non-x86 platforms, due to the new intrinsic not being implemented on those platforms.

When you say "most of the non-x86 platforms", are you referring to the ones with processor types listed below?

1. jdk/src/hotspot/cpu/**arm**
2. jdk/src/hotspot/cpu/**ppc**
3. jdk/src/hotspot/cpu/**s390**

I don't see a cbrt intrinsic implementation in the non-x86 platforms. However, the ones listed above appear to get to the _ShouldNotReachHere_ error state if a particular intrinsic isn't found in `TemplateInterpreterGenerator::generate_math_entry` (`templateInterpreterGenerator_*.cpp`). It looks like aarch64 and riscv don't take that route and would fall back to the default cbrt implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2928618217

From dholmes at openjdk.org  Mon Jun  2 04:44:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 04:44:57 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <CJ6XTFRmKm7TsbS74Vb1viZQDP9YqiZPUZOGFJYJ_cs=.37f559f3-d1c5-48d8-9b89-f103d1b1b053@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
 <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>
 <CJ6XTFRmKm7TsbS74Vb1viZQDP9YqiZPUZOGFJYJ_cs=.37f559f3-d1c5-48d8-9b89-f103d1b1b053@github.com>
Message-ID: <Ncc03SW7hV4CiyaaSbqb1yn1YtvVP3cWkYr8b0n33v0=.2ebaa5ec-4af4-455a-8a57-8883bf4339e9@github.com>

On Mon, 2 Jun 2025 03:49:42 GMT, Mohamed Issa <duke at openjdk.org> wrote:

> When you say "most of the non-x86 platforms", are you referring to the ones with processor types listed below?

Yes - 3 of the 5 non-x86 platforms.

> It looks like aarch64 and riscv don't take that route and would fall back to the default cbrt implementation.

I was wondering why Aarch64 didn't fail. I guess the other platforms may use this to detect new intrinsics being added.

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

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2928722575

From duke at openjdk.org  Mon Jun  2 08:15:36 2025
From: duke at openjdk.org (Tom Shull)
Date: Mon, 2 Jun 2025 08:15:36 GMT
Subject: RFR: 8357987: [JVMCI] Add support for retrieving all methods of a
 ResolvedJavaType [v2]
In-Reply-To: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
Message-ID: <CYkGPLcHWGMU-tVCTaiz4r7jAjCDVRlRMgOq_Z4Ne24=.6ee8dafc-8808-48ef-ad30-a9cd5cd4f140@github.com>

> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
> 
> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.

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

  format javadoc and update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25498/files
  - new: https://git.openjdk.org/jdk/pull/25498/files/1f42f05f..0de1feae

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

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

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

From shade at openjdk.org  Mon Jun  2 08:18:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 08:18:53 GMT
Subject: RFR: 8358169: Shenandoah/JVMCI: Export GC state constants
In-Reply-To: <AW1S5EQJ3RBD_SuBNPbncl9eCsbYcw7jG9ovqryyijo=.b15a6da5-39c8-45dd-8824-6064f237da11@github.com>
References: <AW1S5EQJ3RBD_SuBNPbncl9eCsbYcw7jG9ovqryyijo=.b15a6da5-39c8-45dd-8824-6064f237da11@github.com>
Message-ID: <DfqOIkMbWJpUSIDMaVTH90Hvnj6-L8zolxMcFHyXKtM=.29bf4412-b980-4106-9952-65196a895730@github.com>

On Fri, 30 May 2025 16:09:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We need the GC state enum constants available in JVMCI.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25552#pullrequestreview-2887264825

From duke at openjdk.org  Mon Jun  2 08:39:31 2025
From: duke at openjdk.org (Tom Shull)
Date: Mon, 2 Jun 2025 08:39:31 GMT
Subject: RFR: 8357660: [JVMCI] Add support for retrieving all
 BootstrapMethodInvocations directly from ConstantPool [v2]
In-Reply-To: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
References: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
Message-ID: <COtEDoFezYJO5tFLBOcxaIOBNAs1HvGxQLdr5CmZgxc=.36ee7465-d0b0-4a19-bed7-ca860cc7610b@github.com>

> This PR adds support for directly retrieving both all invokedynamic and all condy BootstrapMethodInvocations from a ConstantPool via the new method `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean invokeDynamic)`.
> 
> In addition, two methods are added to the BootstrapMethodInvocations:
> 1. `void resolve()`
> 2. `JavaConstant lookup()`
> 
> The combination of these two features allows one to directly interact with all BSM information of a given ConstantPool without having to iterate through all of the Classfile's methods to find all invokedynamic bytecodes and/or iterate through all Constant Pool entries.

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

  reviewer feedback and update javadoc formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25420/files
  - new: https://git.openjdk.org/jdk/pull/25420/files/519be178..60c39b5e

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

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

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

From rkennke at openjdk.org  Mon Jun  2 08:59:56 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 2 Jun 2025 08:59:56 GMT
Subject: Integrated: 8358169: Shenandoah/JVMCI: Export GC state constants
In-Reply-To: <AW1S5EQJ3RBD_SuBNPbncl9eCsbYcw7jG9ovqryyijo=.b15a6da5-39c8-45dd-8824-6064f237da11@github.com>
References: <AW1S5EQJ3RBD_SuBNPbncl9eCsbYcw7jG9ovqryyijo=.b15a6da5-39c8-45dd-8824-6064f237da11@github.com>
Message-ID: <NFSz2KtMZ1xzkZE8QuTqfA9pPv4l22wvyGHF01CUXVs=.61b1dd9a-60d9-4fc7-8086-dc9ac25533d1@github.com>

On Fri, 30 May 2025 16:09:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We need the GC state enum constants available in JVMCI.

This pull request has now been integrated.

Changeset: eb9badd8
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb9badd8a4ea6dca834525fd49429e2ce771a76c
Stats:     8 lines in 1 file changed: 8 ins; 0 del; 0 mod

8358169: Shenandoah/JVMCI: Export GC state constants

Reviewed-by: dnsimon, shade

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

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

From dnsimon at openjdk.org  Mon Jun  2 11:11:52 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 2 Jun 2025 11:11:52 GMT
Subject: RFR: 8357987: [JVMCI] Add support for retrieving all methods of a
 ResolvedJavaType [v2]
In-Reply-To: <CYkGPLcHWGMU-tVCTaiz4r7jAjCDVRlRMgOq_Z4Ne24=.6ee8dafc-8808-48ef-ad30-a9cd5cd4f140@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
 <CYkGPLcHWGMU-tVCTaiz4r7jAjCDVRlRMgOq_Z4Ne24=.6ee8dafc-8808-48ef-ad30-a9cd5cd4f140@github.com>
Message-ID: <tqK7bdorwAk0uqYmRQ_hUvl9SfR1BWUuzkyXJtnbKr8=.1bbded68-70d9-429c-ad53-dac758f83a47@github.com>

On Mon, 2 Jun 2025 08:15:36 GMT, Tom Shull <duke at openjdk.org> wrote:

>> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
>> 
>> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.
>
> Tom Shull has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format javadoc and update test

Looks good to me.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25498#pullrequestreview-2887897833

From dnsimon at openjdk.org  Mon Jun  2 11:16:53 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 2 Jun 2025 11:16:53 GMT
Subject: RFR: 8357660: [JVMCI] Add support for retrieving all
 BootstrapMethodInvocations directly from ConstantPool [v2]
In-Reply-To: <COtEDoFezYJO5tFLBOcxaIOBNAs1HvGxQLdr5CmZgxc=.36ee7465-d0b0-4a19-bed7-ca860cc7610b@github.com>
References: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
 <COtEDoFezYJO5tFLBOcxaIOBNAs1HvGxQLdr5CmZgxc=.36ee7465-d0b0-4a19-bed7-ca860cc7610b@github.com>
Message-ID: <1jDUbEJHRDYuT4RDOHlEeY5C4IWwwcenweFgZcwnUsU=.bc8d84ad-13bb-4b5a-9d02-de020301e3d6@github.com>

On Mon, 2 Jun 2025 08:39:31 GMT, Tom Shull <duke at openjdk.org> wrote:

>> This PR adds support for directly retrieving both all invokedynamic and all condy BootstrapMethodInvocations from a ConstantPool via the new method `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean invokeDynamic)`.
>> 
>> In addition, two methods are added to the BootstrapMethodInvocations:
>> 1. `void resolve()`
>> 2. `JavaConstant lookup()`
>> 
>> The combination of these two features allows one to directly interact with all BSM information of a given ConstantPool without having to iterate through all of the Classfile's methods to find all invokedynamic bytecodes and/or iterate through all Constant Pool entries.
>
> Tom Shull has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviewer feedback and update javadoc formatting

Looks good to me.

Please enable GitHub Actions on your JDK fork.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25420#pullrequestreview-2887908832

From yzheng at openjdk.org  Mon Jun  2 12:11:57 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 2 Jun 2025 12:11:57 GMT
Subject: RFR: 8357987: [JVMCI] Add support for retrieving all methods of a
 ResolvedJavaType [v2]
In-Reply-To: <CYkGPLcHWGMU-tVCTaiz4r7jAjCDVRlRMgOq_Z4Ne24=.6ee8dafc-8808-48ef-ad30-a9cd5cd4f140@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
 <CYkGPLcHWGMU-tVCTaiz4r7jAjCDVRlRMgOq_Z4Ne24=.6ee8dafc-8808-48ef-ad30-a9cd5cd4f140@github.com>
Message-ID: <0o43MdXkVHVU8JQIoBSQ-46j3jLJjvAEqARhk88aeEw=.a202168b-af3f-4ce4-b274-f1cbbd4295fa@github.com>

On Mon, 2 Jun 2025 08:15:36 GMT, Tom Shull <duke at openjdk.org> wrote:

>> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
>> 
>> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.
>
> Tom Shull has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format javadoc and update test

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java line 1079:

> 1077:             return List.of();
> 1078:         }
> 1079:         return Collections.unmodifiableList(Arrays.asList(instanceMethods));

`return List.of(instanceMethods);` should work. We can then replace the above with `return List.of(runtime().compilerToVm.getAllMethods(this));`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25498#discussion_r2120952854

From dnsimon at openjdk.org  Mon Jun  2 15:53:02 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 2 Jun 2025 15:53:02 GMT
Subject: RFR: 8358254: [AOT]
 runtime/cds/appcds/applications/JavacBench.java#aot crashes with SEGV in
 ClassLoaderData::holder
Message-ID: <p6CAQbI0mzIbMHL2JmM6iXTO27nBLW7HDQC1Y0dWMo4=.e76a073d-03a5-4e40-ba8e-259f69362636@github.com>

JVMCI needs to be aware of unloaded classes in type profiles just like [CI does](https://github.com/openjdk/jdk/pull/24886/files#diff-cda53c3ed39c4e59f73f3298933ebed1912daeaf854f0b31f40332be109f6c30R317).

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

Commit messages:
 - support unloaded classes in type profiles in AOT mode
 - convert RawItemProfile to a record

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

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

From dnsimon at openjdk.org  Mon Jun  2 16:42:35 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 2 Jun 2025 16:42:35 GMT
Subject: RFR: 8357619: [JVMCI] Revisit phantom_ref parameter in
 JVMCINMethodData::get_nmethod_mirror [v2]
In-Reply-To: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
References: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
Message-ID: <TULOf75PvXmfS9Y05KVt6YDoB8kOaf2PdRG2xyL9XNk=.f93f5e56-11c1-4c53-abae-b234c15c3f49@github.com>

> The point of the `phantom_ref` parameter (introduced by [JDK-8234359](https://bugs.openjdk.org/browse/JDK-8234359)) of `JVMCINMethodData::get_nmethod_mirror` is to avoid the special resurrection semantics of a phantom read when reading the field during GC, which is when `JVMCINMethodData::invalidate_nmethod_mirror` can be called.
> This case can be handled directly in `JVMCINMethodData::invalidate_nmethod_mirror` and so the `phantom_ref` parameter can be removed.

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

  still rely on get_nmethod_mirror in invalidate_nmethod_mirror

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25488/files
  - new: https://git.openjdk.org/jdk/pull/25488/files/0dcb1c78..7456988a

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

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

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

From never at openjdk.org  Mon Jun  2 16:42:35 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 2 Jun 2025 16:42:35 GMT
Subject: RFR: 8357619: [JVMCI] Revisit phantom_ref parameter in
 JVMCINMethodData::get_nmethod_mirror [v2]
In-Reply-To: <TULOf75PvXmfS9Y05KVt6YDoB8kOaf2PdRG2xyL9XNk=.f93f5e56-11c1-4c53-abae-b234c15c3f49@github.com>
References: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
 <TULOf75PvXmfS9Y05KVt6YDoB8kOaf2PdRG2xyL9XNk=.f93f5e56-11c1-4c53-abae-b234c15c3f49@github.com>
Message-ID: <LaD5oFiSBCIT_qxaoezdyMtdyJUawPKTjTyIvir1jzk=.0bd3a6b9-481a-4dbd-a9df-0f8c57ce3c5c@github.com>

On Mon, 2 Jun 2025 16:39:42 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The point of the `phantom_ref` parameter (introduced by [JDK-8234359](https://bugs.openjdk.org/browse/JDK-8234359)) of `JVMCINMethodData::get_nmethod_mirror` is to avoid the special resurrection semantics of a phantom read when reading the field during GC, which is when `JVMCINMethodData::invalidate_nmethod_mirror` can be called.
>> This case can be handled directly in `JVMCINMethodData::invalidate_nmethod_mirror` and so the `phantom_ref` parameter can be removed.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   still rely on get_nmethod_mirror in invalidate_nmethod_mirror

Marked as reviewed by never (Reviewer).

src/hotspot/share/jvmci/jvmciRuntime.cpp line 807:

> 805:   oop nmethod_mirror = get_nmethod_mirror(nm, /* phantom_ref */ false);
> 806:   if (nmethod_mirror == nullptr) {
> 807:     return;

minor typo

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

PR Review: https://git.openjdk.org/jdk/pull/25488#pullrequestreview-2889188965
PR Review Comment: https://git.openjdk.org/jdk/pull/25488#discussion_r2121662248

From dnsimon at openjdk.org  Mon Jun  2 16:42:36 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 2 Jun 2025 16:42:36 GMT
Subject: RFR: 8357619: [JVMCI] Revisit phantom_ref parameter in
 JVMCINMethodData::get_nmethod_mirror [v2]
In-Reply-To: <OHFtgLyztrGVE9Q0p_HFrta3a7pK_uLVnVJU6g-76vA=.a7bd8695-9b7e-4149-a462-52b0429dffd8@github.com>
References: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
 <OHFtgLyztrGVE9Q0p_HFrta3a7pK_uLVnVJU6g-76vA=.a7bd8695-9b7e-4149-a462-52b0429dffd8@github.com>
Message-ID: <_hhDZ4c8Kic5tPWMwNHv_G21vpCK2eKjTFJQOqW_nEw=.1c90159f-ee23-441c-b72f-283bd2b35c80@github.com>

On Fri, 30 May 2025 16:05:23 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   still rely on get_nmethod_mirror in invalidate_nmethod_mirror
>
> src/hotspot/share/jvmci/jvmciRuntime.cpp line 801:
> 
>> 799: 
>> 800: void JVMCINMethodData::invalidate_nmethod_mirror(nmethod* nm) {
>> 801:   if (_nmethod_mirror_index == -1) {
> 
> This part is actually wrong as that's the first part of `get_nmethod_mirror` and we must always check that `get_nmethod_mirror` doesn't return nullptr.  I'd assumed that the mirror was always non-null if `_nmethod_mirror_index != -1` but that's not true.  The slot is reserved for all non-default nmethods and must stay around so that `translate` can work.

Fixed: https://github.com/openjdk/jdk/pull/25488/commits/7456988a6fcab00bf13e602553f9e5a295d75b0f

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25488#discussion_r2121658848

From dnsimon at openjdk.org  Mon Jun  2 16:48:16 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 2 Jun 2025 16:48:16 GMT
Subject: RFR: 8357619: [JVMCI] Revisit phantom_ref parameter in
 JVMCINMethodData::get_nmethod_mirror [v3]
In-Reply-To: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
References: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
Message-ID: <yNgwXLCy9zmCebi3PGDLRZKKEwNDN1hHNQ4xTScBQFo=.ffec97d7-2361-41fb-b168-f58d580cbba9@github.com>

> The point of the `phantom_ref` parameter (introduced by [JDK-8234359](https://bugs.openjdk.org/browse/JDK-8234359)) of `JVMCINMethodData::get_nmethod_mirror` is to avoid the special resurrection semantics of a phantom read when reading the field during GC, which is when `JVMCINMethodData::invalidate_nmethod_mirror` can be called.
> This case can be handled directly in `JVMCINMethodData::invalidate_nmethod_mirror` and so the `phantom_ref` parameter can be removed.

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

  fixed typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25488/files
  - new: https://git.openjdk.org/jdk/pull/25488/files/7456988a..e02be82c

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

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

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

From eosterlund at openjdk.org  Mon Jun  2 16:59:57 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 16:59:57 GMT
Subject: RFR: 8357619: [JVMCI] Revisit phantom_ref parameter in
 JVMCINMethodData::get_nmethod_mirror [v3]
In-Reply-To: <yNgwXLCy9zmCebi3PGDLRZKKEwNDN1hHNQ4xTScBQFo=.ffec97d7-2361-41fb-b168-f58d580cbba9@github.com>
References: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
 <yNgwXLCy9zmCebi3PGDLRZKKEwNDN1hHNQ4xTScBQFo=.ffec97d7-2361-41fb-b168-f58d580cbba9@github.com>
Message-ID: <zcHGzkfkKNEds_wIym4zbI8Mxbc8GFIVw4hTASU0QF0=.10429277-1998-455d-885b-b7798a566024@github.com>

On Mon, 2 Jun 2025 16:48:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The point of the `phantom_ref` parameter (introduced by [JDK-8234359](https://bugs.openjdk.org/browse/JDK-8234359)) of `JVMCINMethodData::get_nmethod_mirror` is to avoid the special resurrection semantics of a phantom read when reading the field during GC, which is when `JVMCINMethodData::invalidate_nmethod_mirror` can be called.
>> This case can be handled directly in `JVMCINMethodData::invalidate_nmethod_mirror` and so the `phantom_ref` parameter can be removed.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25488#pullrequestreview-2889256264

From duke at openjdk.org  Mon Jun  2 17:04:07 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Mon, 2 Jun 2025 17:04:07 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <Ncc03SW7hV4CiyaaSbqb1yn1YtvVP3cWkYr8b0n33v0=.2ebaa5ec-4af4-455a-8a57-8883bf4339e9@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
 <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>
 <CJ6XTFRmKm7TsbS74Vb1viZQDP9YqiZPUZOGFJYJ_cs=.37f559f3-d1c5-48d8-9b89-f103d1b1b053@github.com>
 <Ncc03SW7hV4CiyaaSbqb1yn1YtvVP3cWkYr8b0n33v0=.2ebaa5ec-4af4-455a-8a57-8883bf4339e9@github.com>
Message-ID: <B45nnM4tVAIuccbJPIC5l6xz9VeMgJf6srnwSDfE_SU=.7d105a23-3f7b-4b2c-854e-ca371f7d41c3@github.com>

On Mon, 2 Jun 2025 04:42:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > When you say "most of the non-x86 platforms", are you referring to the ones with processor types listed below?
> 
> Yes - 3 of the 5 non-x86 platforms.
> 
> > It looks like aarch64 and riscv don't take that route and would fall back to the default cbrt implementation.
> 
> I was wondering why Aarch64 didn't fail. I guess the other platforms may use this to detect new intrinsics being added.

The arm, ppc, and s390 breaks are resolved by #25568.

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

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2931613343

From dnsimon at openjdk.org  Mon Jun  2 18:21:53 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 2 Jun 2025 18:21:53 GMT
Subject: RFR: 8358254: [AOT]
 runtime/cds/appcds/applications/JavacBench.java#aot crashes with SEGV in
 ClassLoaderData::holder
In-Reply-To: <p6CAQbI0mzIbMHL2JmM6iXTO27nBLW7HDQC1Y0dWMo4=.e76a073d-03a5-4e40-ba8e-259f69362636@github.com>
References: <p6CAQbI0mzIbMHL2JmM6iXTO27nBLW7HDQC1Y0dWMo4=.e76a073d-03a5-4e40-ba8e-259f69362636@github.com>
Message-ID: <aQrA7Ik0sz0Xl7kbko0NFTL7aUOned7JxveppFMY5TU=.7f6273af-89d2-4e20-9ac8-a97a15d5b66e@github.com>

On Mon, 2 Jun 2025 15:47:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> JVMCI needs to be aware of unloaded classes in type profiles just like [CI does](https://github.com/openjdk/jdk/pull/24886/files#diff-cda53c3ed39c4e59f73f3298933ebed1912daeaf854f0b31f40332be109f6c30R317).

src/hotspot/share/oops/trainingData.hpp line 286:

> 284:   static bool assembling_data() { return have_data() && CDSConfig::is_dumping_final_static_archive() && CDSConfig::is_dumping_aot_linked_classes(); }
> 285: 
> 286:   static bool is_klass_loaded(Klass* k) {

This code was moved unmodified from ciMethodData.cpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25592#discussion_r2121856022

From duke at openjdk.org  Mon Jun  2 19:12:19 2025
From: duke at openjdk.org (Tom Shull)
Date: Mon, 2 Jun 2025 19:12:19 GMT
Subject: RFR: 8357660: [JVMCI] Add support for retrieving all
 BootstrapMethodInvocations directly from ConstantPool [v3]
In-Reply-To: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
References: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
Message-ID: <23ZmqystynFesmzLG1GXybdGxQSChcwZQt4cM__DbYw=.ae8a7c39-7fc2-4e27-82a3-6f4e879debd9@github.com>

> This PR adds support for directly retrieving both all invokedynamic and all condy BootstrapMethodInvocations from a ConstantPool via the new method `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean invokeDynamic)`.
> 
> In addition, two methods are added to the BootstrapMethodInvocations:
> 1. `void resolve()`
> 2. `JavaConstant lookup()`
> 
> The combination of these two features allows one to directly interact with all BSM information of a given ConstantPool without having to iterate through all of the Classfile's methods to find all invokedynamic bytecodes and/or iterate through all Constant Pool entries.

Tom Shull has updated the pull request incrementally with two additional commits since the last revision:

 - commit to trigger testing
 - commit to trigger testing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25420/files
  - new: https://git.openjdk.org/jdk/pull/25420/files/60c39b5e..4d508fc4

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

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

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

From never at openjdk.org  Mon Jun  2 20:05:51 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 2 Jun 2025 20:05:51 GMT
Subject: RFR: 8358254: [AOT]
 runtime/cds/appcds/applications/JavacBench.java#aot crashes with SEGV in
 ClassLoaderData::holder
In-Reply-To: <p6CAQbI0mzIbMHL2JmM6iXTO27nBLW7HDQC1Y0dWMo4=.e76a073d-03a5-4e40-ba8e-259f69362636@github.com>
References: <p6CAQbI0mzIbMHL2JmM6iXTO27nBLW7HDQC1Y0dWMo4=.e76a073d-03a5-4e40-ba8e-259f69362636@github.com>
Message-ID: <L5w2CI232gqAG8Ibu9ZUU2xegvuM1OqRpO0iBoPSf8U=.72e2c2e2-a3d4-455e-b26a-a931cb745619@github.com>

On Mon, 2 Jun 2025 15:47:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> JVMCI needs to be aware of unloaded classes in type profiles just like [CI does](https://github.com/openjdk/jdk/pull/24886/files#diff-cda53c3ed39c4e59f73f3298933ebed1912daeaf854f0b31f40332be109f6c30R317).

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25592#pullrequestreview-2889770600

From duke at openjdk.org  Mon Jun  2 20:36:37 2025
From: duke at openjdk.org (Tom Shull)
Date: Mon, 2 Jun 2025 20:36:37 GMT
Subject: RFR: 8357987: [JVMCI] Add support for retrieving all methods of a
 ResolvedJavaType [v3]
In-Reply-To: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
Message-ID: <7qRH8PFpSXJTshHNvxEMqEbc34N5wSnpknQaMUbWrCg=.6de4f71a-8c22-492f-b156-b25a07f3b428@github.com>

> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
> 
> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.

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

  return List.of() from getAllMethods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25498/files
  - new: https://git.openjdk.org/jdk/pull/25498/files/0de1feae..ae81d46f

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

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

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

From cslucas at openjdk.org  Tue Jun  3 05:40:09 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 3 Jun 2025 05:40:09 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v2]
In-Reply-To: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
Message-ID: <lOmNXUnYvOECIgfnhj7JNL1MZ6sVT_1-vGYYSm2zp_M=.4c371ac4-fd07-4b21-a651-5f6d83b7a39e@github.com>

> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
> 
> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Address PR feedback: modify emum to be scoped.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25338/files
  - new: https://git.openjdk.org/jdk/pull/25338/files/933b958d..b3bb4365

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

  Stats: 83 lines in 13 files changed: 55 ins; 4 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/25338.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25338/head:pull/25338

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

From dnsimon at openjdk.org  Tue Jun  3 06:21:55 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 3 Jun 2025 06:21:55 GMT
Subject: RFR: 8358254: [AOT]
 runtime/cds/appcds/applications/JavacBench.java#aot crashes with SEGV in
 ClassLoaderData::holder
In-Reply-To: <p6CAQbI0mzIbMHL2JmM6iXTO27nBLW7HDQC1Y0dWMo4=.e76a073d-03a5-4e40-ba8e-259f69362636@github.com>
References: <p6CAQbI0mzIbMHL2JmM6iXTO27nBLW7HDQC1Y0dWMo4=.e76a073d-03a5-4e40-ba8e-259f69362636@github.com>
Message-ID: <KhSDMORz2XvM2X24SqR0RSD2KQmBdtX9ocqK1qWWbg4=.7f791cfd-9e38-4eb3-bcda-fd54bdd4046f@github.com>

On Mon, 2 Jun 2025 15:47:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> JVMCI needs to be aware of unloaded classes in type profiles just like [CI does](https://github.com/openjdk/jdk/pull/24886/files#diff-cda53c3ed39c4e59f73f3298933ebed1912daeaf854f0b31f40332be109f6c30R317).

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25592#issuecomment-2933645017

From dnsimon at openjdk.org  Tue Jun  3 06:21:56 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 3 Jun 2025 06:21:56 GMT
Subject: Integrated: 8358254: [AOT]
 runtime/cds/appcds/applications/JavacBench.java#aot crashes with SEGV in
 ClassLoaderData::holder
In-Reply-To: <p6CAQbI0mzIbMHL2JmM6iXTO27nBLW7HDQC1Y0dWMo4=.e76a073d-03a5-4e40-ba8e-259f69362636@github.com>
References: <p6CAQbI0mzIbMHL2JmM6iXTO27nBLW7HDQC1Y0dWMo4=.e76a073d-03a5-4e40-ba8e-259f69362636@github.com>
Message-ID: <7NMm1SDt9UaKrkgEPeFaSbkz97Lwqof1TVjyAKEyGY4=.d4792765-e2e2-4e0c-8a28-b5583cfed394@github.com>

On Mon, 2 Jun 2025 15:47:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> JVMCI needs to be aware of unloaded classes in type profiles just like [CI does](https://github.com/openjdk/jdk/pull/24886/files#diff-cda53c3ed39c4e59f73f3298933ebed1912daeaf854f0b31f40332be109f6c30R317).

This pull request has now been integrated.

Changeset: 497a1822
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/497a1822cabcc0475ce0495d56430f1e99b1fb13
Stats:     33 lines in 4 files changed: 13 ins; 16 del; 4 mod

8358254: [AOT] runtime/cds/appcds/applications/JavacBench.java#aot crashes with SEGV in ClassLoaderData::holder

Reviewed-by: never

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

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

From dnsimon at openjdk.org  Tue Jun  3 06:22:57 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 3 Jun 2025 06:22:57 GMT
Subject: RFR: 8357619: [JVMCI] Revisit phantom_ref parameter in
 JVMCINMethodData::get_nmethod_mirror [v3]
In-Reply-To: <yNgwXLCy9zmCebi3PGDLRZKKEwNDN1hHNQ4xTScBQFo=.ffec97d7-2361-41fb-b168-f58d580cbba9@github.com>
References: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
 <yNgwXLCy9zmCebi3PGDLRZKKEwNDN1hHNQ4xTScBQFo=.ffec97d7-2361-41fb-b168-f58d580cbba9@github.com>
Message-ID: <4HicVmT-d5SBUtqg8Q2JqQSDhCXmzZdGMcc-CrCu8Bw=.7483a779-a992-4153-9a55-55dd20c7f029@github.com>

On Mon, 2 Jun 2025 16:48:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The point of the `phantom_ref` parameter (introduced by [JDK-8234359](https://bugs.openjdk.org/browse/JDK-8234359)) of `JVMCINMethodData::get_nmethod_mirror` is to avoid the special resurrection semantics of a phantom read when reading the field during GC, which is when `JVMCINMethodData::invalidate_nmethod_mirror` can be called.
>> This case can be handled directly in `JVMCINMethodData::invalidate_nmethod_mirror` and so the `phantom_ref` parameter can be removed.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25488#issuecomment-2933646688

From dnsimon at openjdk.org  Tue Jun  3 06:22:57 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 3 Jun 2025 06:22:57 GMT
Subject: Integrated: 8357619: [JVMCI] Revisit phantom_ref parameter in
 JVMCINMethodData::get_nmethod_mirror
In-Reply-To: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
References: <37LbN00VRPqAt9LN8jx43xx3QGsF6jnPFS_OQLUa-0U=.687f6afe-d13a-4d03-af0c-ac91a9862b13@github.com>
Message-ID: <BVdlk4znvRZRijQp7f8jDMrd_vhiuDViqBRv6U3giQs=.54ab27a3-5b85-4169-b189-b07240a1359e@github.com>

On Wed, 28 May 2025 10:28:38 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The point of the `phantom_ref` parameter (introduced by [JDK-8234359](https://bugs.openjdk.org/browse/JDK-8234359)) of `JVMCINMethodData::get_nmethod_mirror` is to avoid the special resurrection semantics of a phantom read when reading the field during GC, which is when `JVMCINMethodData::invalidate_nmethod_mirror` can be called.
> This case can be handled directly in `JVMCINMethodData::invalidate_nmethod_mirror` and so the `phantom_ref` parameter can be removed.

This pull request has now been integrated.

Changeset: 6cfd4057
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cfd4057dce9262f54e71a3930e16da84aa0d9f1
Stats:     12 lines in 3 files changed: 0 ins; 4 del; 8 mod

8357619: [JVMCI] Revisit phantom_ref parameter in JVMCINMethodData::get_nmethod_mirror

Reviewed-by: eosterlund, never

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

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

From dnsimon at openjdk.org  Tue Jun  3 06:32:54 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 3 Jun 2025 06:32:54 GMT
Subject: RFR: 8357987: [JVMCI] Add support for retrieving all methods of a
 ResolvedJavaType [v3]
In-Reply-To: <7qRH8PFpSXJTshHNvxEMqEbc34N5wSnpknQaMUbWrCg=.6de4f71a-8c22-492f-b156-b25a07f3b428@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
 <7qRH8PFpSXJTshHNvxEMqEbc34N5wSnpknQaMUbWrCg=.6de4f71a-8c22-492f-b156-b25a07f3b428@github.com>
Message-ID: <XSPullgXMcJBelTK5gdnk-Lgbu1xK9Y54fOPdr1D3Fg=.3cdfb333-0e5a-4fe8-a2ec-602127dbb7b3@github.com>

On Mon, 2 Jun 2025 20:36:37 GMT, Tom Shull <duke at openjdk.org> wrote:

>> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
>> 
>> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.
>
> Tom Shull has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return List.of() from getAllMethods

Still looks good to me.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25498#pullrequestreview-2890872094

From yzheng at openjdk.org  Tue Jun  3 06:53:53 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 3 Jun 2025 06:53:53 GMT
Subject: RFR: 8357987: [JVMCI] Add support for retrieving all methods of a
 ResolvedJavaType [v3]
In-Reply-To: <7qRH8PFpSXJTshHNvxEMqEbc34N5wSnpknQaMUbWrCg=.6de4f71a-8c22-492f-b156-b25a07f3b428@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
 <7qRH8PFpSXJTshHNvxEMqEbc34N5wSnpknQaMUbWrCg=.6de4f71a-8c22-492f-b156-b25a07f3b428@github.com>
Message-ID: <UnNBQty8t0dJWVujFQAn-6LX-vioHtakDF0Tg73Ft4Q=.87e161bb-9c89-4745-b37e-2ea2668c7b96@github.com>

On Mon, 2 Jun 2025 20:36:37 GMT, Tom Shull <duke at openjdk.org> wrote:

>> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
>> 
>> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.
>
> Tom Shull has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return List.of() from getAllMethods

Marked as reviewed by yzheng (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25498#pullrequestreview-2890926150

From shade at openjdk.org  Tue Jun  3 08:45:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 08:45:52 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v2]
In-Reply-To: <lOmNXUnYvOECIgfnhj7JNL1MZ6sVT_1-vGYYSm2zp_M=.4c371ac4-fd07-4b21-a651-5f6d83b7a39e@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <lOmNXUnYvOECIgfnhj7JNL1MZ6sVT_1-vGYYSm2zp_M=.4c371ac4-fd07-4b21-a651-5f6d83b7a39e@github.com>
Message-ID: <ibBdoSG9K09rqwu23ESkLq95c4n1aAmlrCnoMap57PU=.bd4f86e1-1f5f-47ca-a93d-2fa5cac95644@github.com>

On Tue, 3 Jun 2025 05:40:09 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
>> 
>> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feedback: modify emum to be scoped.

Looks conceptually fine. Cosmetics:

src/hotspot/share/code/nmethod.hpp line 498:

> 496: 
> 497: 
> 498:   static const char* NMethodChangeReason_to_string(NMethodChangeReason reason) {

Uh, use a switch:


 switch(reason) {
    case C1_deoptimize: return "C1 deoptimized";
    case C1_codepatch:  return "C1 code patch";
    ...
    default:
       assert(false, "Unhandled reason");
       return "Unknown";
 }

src/hotspot/share/jvmci/jvmciEnv.cpp line 1755:

> 1753: 
> 1754: 
> 1755: void JVMCIEnv::invalidate_nmethod_mirror(JVMCIObject mirror, bool deoptimize, nmethod::NMethodChangeReason statusReason, JVMCI_TRAPS) {

Suggestion:

void JVMCIEnv::invalidate_nmethod_mirror(JVMCIObject mirror, bool deoptimize, nmethod::NMethodChangeReason change_reason, JVMCI_TRAPS) {

src/hotspot/share/jvmci/jvmciEnv.hpp line 465:

> 463:   // If `deoptimize` is true, the nmethod is immediately deoptimized.
> 464:   // The HotSpotNmethod.address field is zero upon returning.
> 465:   void invalidate_nmethod_mirror(JVMCIObject mirror, bool deoptimze, nmethod::NMethodChangeReason statusReason, JVMCI_TRAPS);

Suggestion:

  void invalidate_nmethod_mirror(JVMCIObject mirror, bool deoptimize, nmethod::NMethodChangeReason change_reason, JVMCI_TRAPS);

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

PR Review: https://git.openjdk.org/jdk/pull/25338#pullrequestreview-2891309126
PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2123138594
PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2123153641
PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2123152309

From shade at openjdk.org  Tue Jun  3 08:45:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 08:45:53 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v2]
In-Reply-To: <ibBdoSG9K09rqwu23ESkLq95c4n1aAmlrCnoMap57PU=.bd4f86e1-1f5f-47ca-a93d-2fa5cac95644@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <lOmNXUnYvOECIgfnhj7JNL1MZ6sVT_1-vGYYSm2zp_M=.4c371ac4-fd07-4b21-a651-5f6d83b7a39e@github.com>
 <ibBdoSG9K09rqwu23ESkLq95c4n1aAmlrCnoMap57PU=.bd4f86e1-1f5f-47ca-a93d-2fa5cac95644@github.com>
Message-ID: <j7FHh_sHOfwI73QMWpIf1afkcmTlvlDTL370O7S7pk8=.849dd5cd-6297-4ca6-b33a-c9e1aafc58b1@github.com>

On Tue, 3 Jun 2025 08:36:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address PR feedback: modify emum to be scoped.
>
> src/hotspot/share/code/nmethod.hpp line 498:
> 
>> 496: 
>> 497: 
>> 498:   static const char* NMethodChangeReason_to_string(NMethodChangeReason reason) {
> 
> Uh, use a switch:
> 
> 
>  switch(reason) {
>     case C1_deoptimize: return "C1 deoptimized";
>     case C1_codepatch:  return "C1 code patch";
>     ...
>     default:
>        assert(false, "Unhandled reason");
>        return "Unknown";
>  }

Also, names: `change_reason_to_string(ChangeReason reason)`. Now that enum is scoped to `nmethod`, there is no need for `NMethod` prefix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2123148319

From cslucas at openjdk.org  Tue Jun  3 17:06:56 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 3 Jun 2025 17:06:56 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v2]
In-Reply-To: <j7FHh_sHOfwI73QMWpIf1afkcmTlvlDTL370O7S7pk8=.849dd5cd-6297-4ca6-b33a-c9e1aafc58b1@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <lOmNXUnYvOECIgfnhj7JNL1MZ6sVT_1-vGYYSm2zp_M=.4c371ac4-fd07-4b21-a651-5f6d83b7a39e@github.com>
 <ibBdoSG9K09rqwu23ESkLq95c4n1aAmlrCnoMap57PU=.bd4f86e1-1f5f-47ca-a93d-2fa5cac95644@github.com>
 <j7FHh_sHOfwI73QMWpIf1afkcmTlvlDTL370O7S7pk8=.849dd5cd-6297-4ca6-b33a-c9e1aafc58b1@github.com>
Message-ID: <rNUMfhHMh2BUXFGbUu4Pq78hIcnEH_illdPsQkGA2Lo=.9bd08df0-c0e7-429c-acbd-05765ea5dcb0@github.com>

On Tue, 3 Jun 2025 08:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.hpp line 498:
>> 
>>> 496: 
>>> 497: 
>>> 498:   static const char* NMethodChangeReason_to_string(NMethodChangeReason reason) {
>> 
>> Uh, use a switch:
>> 
>> 
>>  switch(reason) {
>>     case C1_deoptimize: return "C1 deoptimized";
>>     case C1_codepatch:  return "C1 code patch";
>>     ...
>>     default:
>>        assert(false, "Unhandled reason");
>>        return "Unknown";
>>  }
>
> Also, names: `change_reason_to_string(ChangeReason reason)`. Now that enum is scoped to `nmethod`, there is no need for `NMethod` prefix.

Makes sense, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2124446618

From cslucas at openjdk.org  Tue Jun  3 17:52:04 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 3 Jun 2025 17:52:04 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v3]
In-Reply-To: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
Message-ID: <kPsgVFe1rpJdfF_coibJuAtuuVS9G0RttGzzU7Maux4=.975915f7-fe5a-4535-b5fc-c45b151a31d5@github.com>

> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
> 
> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Address PR feedback: more refactoring / renamings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25338/files
  - new: https://git.openjdk.org/jdk/pull/25338/files/b3bb4365..fa77be5c

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

  Stats: 102 lines in 15 files changed: 11 ins; 31 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/25338.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25338/head:pull/25338

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

From shade at openjdk.org  Tue Jun  3 17:52:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 17:52:05 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v3]
In-Reply-To: <kPsgVFe1rpJdfF_coibJuAtuuVS9G0RttGzzU7Maux4=.975915f7-fe5a-4535-b5fc-c45b151a31d5@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <kPsgVFe1rpJdfF_coibJuAtuuVS9G0RttGzzU7Maux4=.975915f7-fe5a-4535-b5fc-c45b151a31d5@github.com>
Message-ID: <195pScH-Kh1H1JvhkwC9xLM_joDJPccyMve95BwIlzk=.22181903-b4af-4ec5-8d57-688a6ee51832@github.com>

On Tue, 3 Jun 2025 17:44:30 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
>> 
>> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feedback: more refactoring / renamings

Almost there, more cosmetics.

src/hotspot/share/code/nmethod.hpp line 500:

> 498:   static const char* change_reason_to_string(ChangeReason change_reason) {
> 499:     switch (change_reason) {
> 500:         case ChangeReason::C1_codepatch:                            return "C1 code patch";

Indenting: should be two spaces everywhere. Also, I think this kind of indenting forces us to re-align the switch for the largest enum label. Let's just break them. Plus, any multi-line blocks should be braced. So, in total:


switch (change_reason) {
  case ChangeReason::C1_codepatch: 
    return "C1 code patch";
  ...
  default: {
    assert(false, "Unhandled reason");
    return "Unknown";
  }
}

src/hotspot/share/code/nmethod.hpp line 691:

> 689:   // another thread performed the transition.
> 690:   bool  make_not_entrant(ChangeReason change_reason);
> 691:   bool  make_not_used()    { return make_not_entrant(ChangeReason::not_used); }

Suggestion:

  bool  make_not_used() { return make_not_entrant(ChangeReason::not_used); }

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

PR Review: https://git.openjdk.org/jdk/pull/25338#pullrequestreview-2893478002
PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2124511959
PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2124514702

From duke at openjdk.org  Tue Jun  3 17:52:30 2025
From: duke at openjdk.org (Tom Shull)
Date: Tue, 3 Jun 2025 17:52:30 GMT
Subject: RFR: 8357660: [JVMCI] Add support for retrieving all
 BootstrapMethodInvocations directly from ConstantPool [v4]
In-Reply-To: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
References: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
Message-ID: <5OVd27HKtqnWu4vn0VnDAWLdWk0iTEstxqhnt9XJ5xU=.efb8b1eb-9998-4caa-844d-e8af7765d3b2@github.com>

> This PR adds support for directly retrieving both all invokedynamic and all condy BootstrapMethodInvocations from a ConstantPool via the new method `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean invokeDynamic)`.
> 
> In addition, two methods are added to the BootstrapMethodInvocations:
> 1. `void resolve()`
> 2. `JavaConstant lookup()`
> 
> The combination of these two features allows one to directly interact with all BSM information of a given ConstantPool without having to iterate through all of the Classfile's methods to find all invokedynamic bytecodes and/or iterate through all Constant Pool entries.

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

 - Merge remote-tracking branch 'origin/master' into JDK-8357660
 - commit to trigger testing
 - commit to trigger testing
 - reviewer feedback and update javadoc formatting
 - complete changes
 - commit review suggestion
   
   Co-authored-by: Douglas Simon <doug.simon at oracle.com>
 - commit review suggestion
   
   Co-authored-by: Douglas Simon <doug.simon at oracle.com>
 - change to allow both indys and condys to be looked up all at once
 - address reviewer feedback
 - style fixes and add testing to TestDynamicConstants.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7bf6d3ed...e0707fb8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25420/files
  - new: https://git.openjdk.org/jdk/pull/25420/files/4d508fc4..e0707fb8

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

  Stats: 63637 lines in 1081 files changed: 34781 ins; 18003 del; 10853 mod
  Patch: https://git.openjdk.org/jdk/pull/25420.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25420/head:pull/25420

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

From duke at openjdk.org  Tue Jun  3 17:52:39 2025
From: duke at openjdk.org (Tom Shull)
Date: Tue, 3 Jun 2025 17:52:39 GMT
Subject: RFR: 8357987: [JVMCI] Add support for retrieving all methods of a
 ResolvedJavaType [v4]
In-Reply-To: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
Message-ID: <zCdDp-h3KvQFjJTkbF1jfKwtCKXBWzxb7-s7ymTT3MA=.96e74cf6-e346-42fd-86f1-fa50c6cd73b8@github.com>

> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
> 
> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.

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

 - Merge remote-tracking branch 'origin/master' into JDK-8357987
 - return List.of() from getAllMethods
 - format javadoc and update test
 - implement getAllMethods
 - address reviewer feedback
 - Add Support for Retrieving All Non-Static Methods of a ResolvedJavaType.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25498/files
  - new: https://git.openjdk.org/jdk/pull/25498/files/ae81d46f..606f3619

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

  Stats: 63826 lines in 1089 files changed: 34970 ins; 18003 del; 10853 mod
  Patch: https://git.openjdk.org/jdk/pull/25498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25498/head:pull/25498

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

From cslucas at openjdk.org  Tue Jun  3 18:52:34 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 3 Jun 2025 18:52:34 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v4]
In-Reply-To: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
Message-ID: <oN_rMARlqx-sEqjEudg-Ot8SDiwx683FCWMCqJg0rio=.e8ee9c31-5cdd-41d7-96c0-0bb0521d3467@github.com>

> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
> 
> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Fix spacing, fix build.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25338/files
  - new: https://git.openjdk.org/jdk/pull/25338/files/fa77be5c..dc3aa2c1

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

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

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

From cslucas at openjdk.org  Tue Jun  3 18:52:35 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 3 Jun 2025 18:52:35 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v3]
In-Reply-To: <195pScH-Kh1H1JvhkwC9xLM_joDJPccyMve95BwIlzk=.22181903-b4af-4ec5-8d57-688a6ee51832@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <kPsgVFe1rpJdfF_coibJuAtuuVS9G0RttGzzU7Maux4=.975915f7-fe5a-4535-b5fc-c45b151a31d5@github.com>
 <195pScH-Kh1H1JvhkwC9xLM_joDJPccyMve95BwIlzk=.22181903-b4af-4ec5-8d57-688a6ee51832@github.com>
Message-ID: <kskRgK0zz0yacnrO6-BochGLZ9MompfUz-FPOlUUfdc=.b2ac0e53-2a31-4864-ab36-1837334b1889@github.com>

On Tue, 3 Jun 2025 17:41:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address PR feedback: more refactoring / renamings
>
> src/hotspot/share/code/nmethod.hpp line 500:
> 
>> 498:   static const char* change_reason_to_string(ChangeReason change_reason) {
>> 499:     switch (change_reason) {
>> 500:         case ChangeReason::C1_codepatch:                            return "C1 code patch";
> 
> Indenting: should be two spaces everywhere. Also, I think this kind of indenting forces us to re-align the switch for the largest enum label. Let's just break them. Plus, any multi-line blocks should be braced. So, in total:
> 
> 
> switch (change_reason) {
>   case ChangeReason::C1_codepatch: 
>     return "C1 code patch";
>   ...
>   default: {
>     assert(false, "Unhandled reason");
>     return "Unknown";
>   }
> }

Done, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2124655548

From shade at openjdk.org  Tue Jun  3 18:55:19 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 18:55:19 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v4]
In-Reply-To: <oN_rMARlqx-sEqjEudg-Ot8SDiwx683FCWMCqJg0rio=.e8ee9c31-5cdd-41d7-96c0-0bb0521d3467@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <oN_rMARlqx-sEqjEudg-Ot8SDiwx683FCWMCqJg0rio=.e8ee9c31-5cdd-41d7-96c0-0bb0521d3467@github.com>
Message-ID: <rAKXhcKXiH0R2U-qlyrJhDcEPe6DF1VlNal3kYTCE2I=.80e126e7-6799-44bf-8687-b362f7b0f420@github.com>

On Tue, 3 Jun 2025 18:52:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
>> 
>> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix spacing, fix build.

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

> 1969:     if (xtty != nullptr) {
> 1970:       ttyLocker ttyl;  // keep the following output all in one block
> 1971:       xtty->begin_elem("make_not_entrant thread='%zu' change_reason='%s'",

Wait, let's not change the actual key here. This is part of XML logging, AFAICS, so this might break some tools.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2124657484

From never at openjdk.org  Tue Jun  3 19:22:22 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 3 Jun 2025 19:22:22 GMT
Subject: RFR: 8357987: [JVMCI] Add support for retrieving all methods of a
 ResolvedJavaType [v4]
In-Reply-To: <zCdDp-h3KvQFjJTkbF1jfKwtCKXBWzxb7-s7ymTT3MA=.96e74cf6-e346-42fd-86f1-fa50c6cd73b8@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
 <zCdDp-h3KvQFjJTkbF1jfKwtCKXBWzxb7-s7ymTT3MA=.96e74cf6-e346-42fd-86f1-fa50c6cd73b8@github.com>
Message-ID: <NtBE35M-Oz7ojdJXUbfCGqfcbEaCa6B9ZvLjmcLA5lw=.98f410b6-8b5e-45d2-aed4-754a428f68e6@github.com>

On Tue, 3 Jun 2025 17:52:39 GMT, Tom Shull <duke at openjdk.org> wrote:

>> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
>> 
>> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.
>
> Tom Shull has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8357987
>  - return List.of() from getAllMethods
>  - format javadoc and update test
>  - implement getAllMethods
>  - address reviewer feedback
>  - Add Support for Retrieving All Non-Static Methods of a ResolvedJavaType.

Looks good.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25498#pullrequestreview-2893798998

From cslucas at openjdk.org  Tue Jun  3 19:33:57 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 3 Jun 2025 19:33:57 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v5]
In-Reply-To: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
Message-ID: <wDZoFLKERlv99jGvsxfslxiPwEGtqxa7MxoAg3BsTng=.be3826bf-c723-487d-8f4c-58f3652f092e@github.com>

> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
> 
> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Revert change to attribute of make_not_entrant element

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25338/files
  - new: https://git.openjdk.org/jdk/pull/25338/files/dc3aa2c1..6af59591

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

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

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

From cslucas at openjdk.org  Tue Jun  3 19:33:57 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 3 Jun 2025 19:33:57 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v4]
In-Reply-To: <rAKXhcKXiH0R2U-qlyrJhDcEPe6DF1VlNal3kYTCE2I=.80e126e7-6799-44bf-8687-b362f7b0f420@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <oN_rMARlqx-sEqjEudg-Ot8SDiwx683FCWMCqJg0rio=.e8ee9c31-5cdd-41d7-96c0-0bb0521d3467@github.com>
 <rAKXhcKXiH0R2U-qlyrJhDcEPe6DF1VlNal3kYTCE2I=.80e126e7-6799-44bf-8687-b362f7b0f420@github.com>
Message-ID: <Yc_Xl-LXsPHqM5-b6IK7y_w3o_XQN3bj1NkF5sFRgrI=.a19ed7e2-7beb-442d-8858-170ed755898e@github.com>

On Tue, 3 Jun 2025 18:47:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix spacing, fix build.
>
> src/hotspot/share/code/nmethod.cpp line 1971:
> 
>> 1969:     if (xtty != nullptr) {
>> 1970:       ttyLocker ttyl;  // keep the following output all in one block
>> 1971:       xtty->begin_elem("make_not_entrant thread='%zu' change_reason='%s'",
> 
> Wait, let's not change the actual key here. This is part of XML logging, AFAICS, so this might break some tools.

Sure, I'll revert that. I thought it would be "fine" to change the key here since it was added not "long ago.."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25338#discussion_r2124736640

From duke at openjdk.org  Tue Jun  3 19:38:19 2025
From: duke at openjdk.org (duke)
Date: Tue, 3 Jun 2025 19:38:19 GMT
Subject: RFR: 8357987: [JVMCI] Add support for retrieving all methods of a
 ResolvedJavaType [v4]
In-Reply-To: <zCdDp-h3KvQFjJTkbF1jfKwtCKXBWzxb7-s7ymTT3MA=.96e74cf6-e346-42fd-86f1-fa50c6cd73b8@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
 <zCdDp-h3KvQFjJTkbF1jfKwtCKXBWzxb7-s7ymTT3MA=.96e74cf6-e346-42fd-86f1-fa50c6cd73b8@github.com>
Message-ID: <pAlwpyLn2jVWNpx4kIR9TyJt5Hqs5YU06zzrPh7gyvI=.83854006-1afb-4419-8f05-683036275b43@github.com>

On Tue, 3 Jun 2025 17:52:39 GMT, Tom Shull <duke at openjdk.org> wrote:

>> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
>> 
>> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.
>
> Tom Shull has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8357987
>  - return List.of() from getAllMethods
>  - format javadoc and update test
>  - implement getAllMethods
>  - address reviewer feedback
>  - Add Support for Retrieving All Non-Static Methods of a ResolvedJavaType.

@teshull 
Your change (at version 606f36196a7bd12abfc76c55b141d712cc613f42) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25498#issuecomment-2936879630

From duke at openjdk.org  Tue Jun  3 19:41:22 2025
From: duke at openjdk.org (Tom Shull)
Date: Tue, 3 Jun 2025 19:41:22 GMT
Subject: Integrated: 8357987: [JVMCI] Add support for retrieving all methods of
 a ResolvedJavaType
In-Reply-To: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
References: <mRzKVfwoUWsIiQoMx2rVRinkLcV9w14P2rSMWz9_m2g=.adb59499-09c3-4085-8464-7e6f75bad624@github.com>
Message-ID: <qY23OYsY-01OhTaHtJW7BO3x9_y8V_Hmh_RZQkTtO90=.28a2e4c7-46a0-4976-a7d4-5de74f79fdad@github.com>

On Wed, 28 May 2025 15:55:39 GMT, Tom Shull <duke at openjdk.org> wrote:

> Currently from ResolvedJavaType one can retrieve all declared methods, static methods, and constructors of the given type. However, internally in HotSpot there are also VM-internal methods, such as overpass methods, associated with a given type which we cannot access via the API.
> 
> To correct this, we should add a new method which enables VM-internal methods, such as overpass methods, to be accessed.

This pull request has now been integrated.

Changeset: e235b61a
Author:    Tom Shull <tom.shull at oracle.com>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e235b61a8bb70462921c09d197adc4b60267d327
Stats:     103 lines in 11 files changed: 102 ins; 0 del; 1 mod

8357987: [JVMCI] Add support for retrieving all methods of a ResolvedJavaType

Reviewed-by: dnsimon, yzheng, never

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

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

From shade at openjdk.org  Tue Jun  3 20:01:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 20:01:29 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v5]
In-Reply-To: <wDZoFLKERlv99jGvsxfslxiPwEGtqxa7MxoAg3BsTng=.be3826bf-c723-487d-8f4c-58f3652f092e@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <wDZoFLKERlv99jGvsxfslxiPwEGtqxa7MxoAg3BsTng=.be3826bf-c723-487d-8f4c-58f3652f092e@github.com>
Message-ID: <VO_weIn_790yqfiHkXNCIKlpqS4DuEUJg6Q1KBFlJP4=.78d2084e-d40b-4402-8733-d732e5267cdd@github.com>

On Tue, 3 Jun 2025 19:33:57 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
>> 
>> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to attribute of make_not_entrant element

Looks good to me. Compiler folks might want to ack as well.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25338#pullrequestreview-2893925727

From duke at openjdk.org  Tue Jun  3 21:52:22 2025
From: duke at openjdk.org (duke)
Date: Tue, 3 Jun 2025 21:52:22 GMT
Subject: Withdrawn: 8344116: C2: remove slice parameter from LoadNode::make
In-Reply-To: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
Message-ID: <fRIZrH2ZE7I8VgwIKyJfmMAigRPBzJEXhGSVY_xa8bI=.e8e1e51c-4793-44bd-b1f3-daf6b6f7245d@github.com>

On Wed, 26 Mar 2025 15:18:25 GMT, Zihao Lin <duke at openjdk.org> wrote:

> This patch remove slice parameter from LoadNode::make
> 
> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
> 
> Hi team, I am new, I'd appreciate any guidance. Thank a lot!

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Wed Jun  4 08:07:40 2025
From: duke at openjdk.org (Tom Shull)
Date: Wed, 4 Jun 2025 08:07:40 GMT
Subject: RFR: 8357660: [JVMCI] Add support for retrieving all
 BootstrapMethodInvocations directly from ConstantPool [v5]
In-Reply-To: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
References: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
Message-ID: <sRzF_MRMr5iU_80N19ZNgCU7jP5QameUhstfBBg-NFw=.f96be25d-3cbe-431d-84ae-5af246c61c6a@github.com>

> This PR adds support for directly retrieving both all invokedynamic and all condy BootstrapMethodInvocations from a ConstantPool via the new method `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean invokeDynamic)`.
> 
> In addition, two methods are added to the BootstrapMethodInvocations:
> 1. `void resolve()`
> 2. `JavaConstant lookup()`
> 
> The combination of these two features allows one to directly interact with all BSM information of a given ConstantPool without having to iterate through all of the Classfile's methods to find all invokedynamic bytecodes and/or iterate through all Constant Pool entries.

Tom Shull 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 'origin/master' into JDK-8357660
 - Merge remote-tracking branch 'origin/master' into JDK-8357660
 - commit to trigger testing
 - commit to trigger testing
 - reviewer feedback and update javadoc formatting
 - complete changes
 - commit review suggestion
   
   Co-authored-by: Douglas Simon <doug.simon at oracle.com>
 - commit review suggestion
   
   Co-authored-by: Douglas Simon <doug.simon at oracle.com>
 - change to allow both indys and condys to be looked up all at once
 - address reviewer feedback
 - ... and 2 more: https://git.openjdk.org/jdk/compare/826fea84...c7f5c1a7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25420/files
  - new: https://git.openjdk.org/jdk/pull/25420/files/e0707fb8..c7f5c1a7

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

  Stats: 3303 lines in 64 files changed: 2485 ins; 442 del; 376 mod
  Patch: https://git.openjdk.org/jdk/pull/25420.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25420/head:pull/25420

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

From yzheng at openjdk.org  Wed Jun  4 13:23:58 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 4 Jun 2025 13:23:58 GMT
Subject: RFR: 8357660: [JVMCI] Add support for retrieving all
 BootstrapMethodInvocations directly from ConstantPool [v5]
In-Reply-To: <sRzF_MRMr5iU_80N19ZNgCU7jP5QameUhstfBBg-NFw=.f96be25d-3cbe-431d-84ae-5af246c61c6a@github.com>
References: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
 <sRzF_MRMr5iU_80N19ZNgCU7jP5QameUhstfBBg-NFw=.f96be25d-3cbe-431d-84ae-5af246c61c6a@github.com>
Message-ID: <d1GJf47bD537AkwMq0agDA6BhkcFGU26E-Z_sjEfHls=.65a7b833-ec48-4c95-9f1c-20346dc7a04a@github.com>

On Wed, 4 Jun 2025 08:07:40 GMT, Tom Shull <duke at openjdk.org> wrote:

>> This PR adds support for directly retrieving both all invokedynamic and all condy BootstrapMethodInvocations from a ConstantPool via the new method `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean invokeDynamic)`.
>> 
>> In addition, two methods are added to the BootstrapMethodInvocations:
>> 1. `void resolve()`
>> 2. `JavaConstant lookup()`
>> 
>> The combination of these two features allows one to directly interact with all BSM information of a given ConstantPool without having to iterate through all of the Classfile's methods to find all invokedynamic bytecodes and/or iterate through all Constant Pool entries.
>
> Tom Shull 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 'origin/master' into JDK-8357660
>  - Merge remote-tracking branch 'origin/master' into JDK-8357660
>  - commit to trigger testing
>  - commit to trigger testing
>  - reviewer feedback and update javadoc formatting
>  - complete changes
>  - commit review suggestion
>    
>    Co-authored-by: Douglas Simon <doug.simon at oracle.com>
>  - commit review suggestion
>    
>    Co-authored-by: Douglas Simon <doug.simon at oracle.com>
>  - change to allow both indys and condys to be looked up all at once
>  - address reviewer feedback
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/2eb99b1a...c7f5c1a7

LGTM

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25420#pullrequestreview-2896717439

From duke at openjdk.org  Wed Jun  4 13:49:59 2025
From: duke at openjdk.org (duke)
Date: Wed, 4 Jun 2025 13:49:59 GMT
Subject: RFR: 8357660: [JVMCI] Add support for retrieving all
 BootstrapMethodInvocations directly from ConstantPool [v5]
In-Reply-To: <sRzF_MRMr5iU_80N19ZNgCU7jP5QameUhstfBBg-NFw=.f96be25d-3cbe-431d-84ae-5af246c61c6a@github.com>
References: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
 <sRzF_MRMr5iU_80N19ZNgCU7jP5QameUhstfBBg-NFw=.f96be25d-3cbe-431d-84ae-5af246c61c6a@github.com>
Message-ID: <4wnk2wbbgb3jbkjwVVvDH6JZH-EkT55XT01HhtXmVAI=.8d87c14e-770f-4a24-99af-5bff3c3fb89b@github.com>

On Wed, 4 Jun 2025 08:07:40 GMT, Tom Shull <duke at openjdk.org> wrote:

>> This PR adds support for directly retrieving both all invokedynamic and all condy BootstrapMethodInvocations from a ConstantPool via the new method `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean invokeDynamic)`.
>> 
>> In addition, two methods are added to the BootstrapMethodInvocations:
>> 1. `void resolve()`
>> 2. `JavaConstant lookup()`
>> 
>> The combination of these two features allows one to directly interact with all BSM information of a given ConstantPool without having to iterate through all of the Classfile's methods to find all invokedynamic bytecodes and/or iterate through all Constant Pool entries.
>
> Tom Shull 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 'origin/master' into JDK-8357660
>  - Merge remote-tracking branch 'origin/master' into JDK-8357660
>  - commit to trigger testing
>  - commit to trigger testing
>  - reviewer feedback and update javadoc formatting
>  - complete changes
>  - commit review suggestion
>    
>    Co-authored-by: Douglas Simon <doug.simon at oracle.com>
>  - commit review suggestion
>    
>    Co-authored-by: Douglas Simon <doug.simon at oracle.com>
>  - change to allow both indys and condys to be looked up all at once
>  - address reviewer feedback
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/865473d8...c7f5c1a7

@teshull 
Your change (at version c7f5c1a79a8ef8fdc7d50ee03b78ebc62b53fc83) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25420#issuecomment-2940109500

From duke at openjdk.org  Wed Jun  4 13:54:00 2025
From: duke at openjdk.org (Tom Shull)
Date: Wed, 4 Jun 2025 13:54:00 GMT
Subject: Integrated: 8357660: [JVMCI] Add support for retrieving all
 BootstrapMethodInvocations directly from ConstantPool
In-Reply-To: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
References: <Lc6lP7En8OrhiQT7Y90xz7av5HpuzXPOLk57MPNYSZU=.cdb8db7e-e3cc-4a6d-9efd-b1c1f902d8a2@github.com>
Message-ID: <A07zdvRZxc5aWeQSr2hBT3K1oP-7RWLW7olc5KUxl1k=.cade5c14-18d5-43de-ae93-23a46b08a94a@github.com>

On Fri, 23 May 2025 17:37:14 GMT, Tom Shull <duke at openjdk.org> wrote:

> This PR adds support for directly retrieving both all invokedynamic and all condy BootstrapMethodInvocations from a ConstantPool via the new method `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean invokeDynamic)`.
> 
> In addition, two methods are added to the BootstrapMethodInvocations:
> 1. `void resolve()`
> 2. `JavaConstant lookup()`
> 
> The combination of these two features allows one to directly interact with all BSM information of a given ConstantPool without having to iterate through all of the Classfile's methods to find all invokedynamic bytecodes and/or iterate through all Constant Pool entries.

This pull request has now been integrated.

Changeset: 0352477f
Author:    Tom Shull <tom.shull at oracle.com>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0352477ff5977b0010e62000adbde88026a49a7e
Stats:     144 lines in 5 files changed: 132 ins; 0 del; 12 mod

8357660: [JVMCI] Add support for retrieving all BootstrapMethodInvocations directly from ConstantPool

Reviewed-by: dnsimon, yzheng

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

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

From mhaessig at openjdk.org  Thu Jun  5 10:43:53 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 5 Jun 2025 10:43:53 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v5]
In-Reply-To: <wDZoFLKERlv99jGvsxfslxiPwEGtqxa7MxoAg3BsTng=.be3826bf-c723-487d-8f4c-58f3652f092e@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <wDZoFLKERlv99jGvsxfslxiPwEGtqxa7MxoAg3BsTng=.be3826bf-c723-487d-8f4c-58f3652f092e@github.com>
Message-ID: <5JATdbvS9tsVNkUXeQX2NIwXr7-gU2wFOuaqmQfX_ZU=.3520a881-7c97-4f81-8f44-f20ba0517b90@github.com>

On Tue, 3 Jun 2025 19:33:57 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
>> 
>> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to attribute of make_not_entrant element

Thank you for addressing the comments. It looks good now.

I ran some additional testing that passed.

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

Marked as reviewed by mhaessig (Author).

PR Review: https://git.openjdk.org/jdk/pull/25338#pullrequestreview-2899791829

From cslucas at openjdk.org  Thu Jun  5 16:36:00 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 5 Jun 2025 16:36:00 GMT
Subject: RFR: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*" [v5]
In-Reply-To: <VO_weIn_790yqfiHkXNCIKlpqS4DuEUJg6Q1KBFlJP4=.78d2084e-d40b-4402-8733-d732e5267cdd@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
 <wDZoFLKERlv99jGvsxfslxiPwEGtqxa7MxoAg3BsTng=.be3826bf-c723-487d-8f4c-58f3652f092e@github.com>
 <VO_weIn_790yqfiHkXNCIKlpqS4DuEUJg6Q1KBFlJP4=.78d2084e-d40b-4402-8733-d732e5267cdd@github.com>
Message-ID: <NGjddKUlpKeYx_w7mbj8vdnPYmXIQehse-rb-PJIYgc=.f633b194-3301-479a-8a21-e5fc3483863b@github.com>

On Tue, 3 Jun 2025 19:58:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change to attribute of make_not_entrant element
>
> Looks good to me. Compiler folks might want to ack as well.

Thank you @shipilev , @mhaessig for reviewing/testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25338#issuecomment-2945182555

From cslucas at openjdk.org  Thu Jun  5 16:48:56 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 5 Jun 2025 16:48:56 GMT
Subject: Integrated: 8357396: Refactor nmethod::make_not_entrant to use Enum
 instead of "const char*"
In-Reply-To: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
References: <OH8p3ETX34bE4gEHkW-TaQrxN9Lkp_blwjxZ9c9rgsw=.3e39bcd5-6499-4e4f-bddc-546bac5663a3@github.com>
Message-ID: <TX5LIrZ4xA90IUc9iIMHbyrPnmpRHdLUXqItKgzkZls=.8b64f0f2-947f-4b4e-9eed-ef91e1fd0fc0@github.com>

On Tue, 20 May 2025 22:08:18 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please review this refactor to transform the reasons for making an nmethod not entrant from `const char*` into enum values.
> 
> Tested on Linux x64 with JTREG tier1-3 in fastdebug and release mode.

This pull request has now been integrated.

Changeset: 62fde687
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62fde687088ce72ef33b94e73babf4bfe1395c17
Stats:     115 lines in 15 files changed: 80 ins; 4 del; 31 mod

8357396: Refactor nmethod::make_not_entrant to use Enum instead of "const char*"

Reviewed-by: mhaessig, shade

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

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

From coleenp at openjdk.org  Fri Jun  6 12:06:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Jun 2025 12:06:28 GMT
Subject: RFR: 8358326: Use oopFactory array allocation
Message-ID: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>

This patch removes cases of direct calls to {type,obj}ArrayKlass->allocate() and calls oopFactory::new_*array instead.  It also renames {type,obj}ArrayKlass->allocate functions to allocate_klass and allocate_instance so it's more clear which allocation it's doing and to match InstanceKlass allocate functions, and makes these functions private with friends for Deoptimization and oopFactory.  For JEP 401, arrays are being extended to support new formats and attributes and this reduces the call sites.
Tested with tier1-7.

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

Commit messages:
 - 8358326: Use oopFactory array allocation

Changes: https://git.openjdk.org/jdk/pull/25590/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25590&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358326
  Stats: 66 lines in 10 files changed: 23 ins; 14 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/25590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25590/head:pull/25590

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

From stefank at openjdk.org  Mon Jun  9 07:41:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Jun 2025 07:41:52 GMT
Subject: RFR: 8358326: Use oopFactory array allocation
In-Reply-To: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>
References: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>
Message-ID: <eZ_0G6p-LRKJ0UUCMZd1dFmTeGuwGo7WqSxa8uXL02A=.ce9f2cd4-d6ea-4ab9-be54-f00c952696af@github.com>

On Mon, 2 Jun 2025 14:07:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This patch removes cases of direct calls to {type,obj}ArrayKlass->allocate() and calls oopFactory::new_*array instead.  It also renames {type,obj}ArrayKlass->allocate functions to allocate_klass and allocate_instance so it's more clear which allocation it's doing and to match InstanceKlass allocate functions, and makes these functions private with friends for Deoptimization and oopFactory.  For JEP 401, arrays are being extended to support new formats and attributes and this reduces the call sites.
> Tested with tier1-7.

This looks good to me. I a few suggestions that you could take if you want to.

src/hotspot/share/oops/objArrayKlass.hpp line 39:

> 37:   friend class JVMCIVMStructs;
> 38:   friend class oopFactory;
> 39:   friend class Deoptimization;

If you want you could consider sorting the friend declarations (here and in the other place where you added it)

src/hotspot/share/oops/objArrayKlass.hpp line 81:

> 79:                                                 int n, Klass* element_klass, TRAPS);
> 80: 
> 81:   objArrayOop allocate(int length, TRAPS);

Do you think `multi_allocate` will need a better name in the future?

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

> 350:     if (type == T_VOID) {
> 351:       THROW_NULL(vmSymbols::java_lang_IllegalArgumentException());
> 352:     }

I was first wondering where this came from but I now see that this was duplicated from `basic_type_mirror_to_arrayklass`. I wonder if this could could be deduplicated by moving this check into `basic_type_mirror_to_basic_type` and then removed from -`basic_type_mirror_to_arrayklass`:


static BasicType basic_type_mirror_to_basic_type(oop basic_type_mirror, TRAPS) {
  assert(java_lang_Class::is_primitive(basic_type_mirror),
    "just checking");
  
  if (type == T_VOID) {
    THROW_NULL(vmSymbols::java_lang_IllegalArgumentException());
  }

  return java_lang_Class::primitive_type(basic_type_mirror);
}

static Klass* basic_type_mirror_to_arrayklass(oop basic_type_mirror, TRAPS) {
  BasicType type = basic_type_mirror_to_basic_type(basic_type_mirror);
  return Universe::typeArrayKlass(type);
}

And then this code could be a two-liner again:

if (java_lang_Class::is_primitive(element_mirror)) {
    BasicType type = basic_type_mirror_to_basic_type(element_mirror);
  return oopFactory::new_typeArray(type, length, CHECK_NULL);
}

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25590#pullrequestreview-2909210112
PR Review Comment: https://git.openjdk.org/jdk/pull/25590#discussion_r2135207589
PR Review Comment: https://git.openjdk.org/jdk/pull/25590#discussion_r2135211890
PR Review Comment: https://git.openjdk.org/jdk/pull/25590#discussion_r2135202824

From coleenp at openjdk.org  Mon Jun  9 13:54:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 13:54:51 GMT
Subject: RFR: 8358326: Use oopFactory array allocation
In-Reply-To: <eZ_0G6p-LRKJ0UUCMZd1dFmTeGuwGo7WqSxa8uXL02A=.ce9f2cd4-d6ea-4ab9-be54-f00c952696af@github.com>
References: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>
 <eZ_0G6p-LRKJ0UUCMZd1dFmTeGuwGo7WqSxa8uXL02A=.ce9f2cd4-d6ea-4ab9-be54-f00c952696af@github.com>
Message-ID: <mexRZ1d4djMFuD6scJgRBSN_UM8Ks2MmYtsVEvp7zTQ=.ee083e01-3be8-4f7e-9bfd-66ae9f9659c8@github.com>

On Mon, 9 Jun 2025 07:36:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This patch removes cases of direct calls to {type,obj}ArrayKlass->allocate() and calls oopFactory::new_*array instead.  It also renames {type,obj}ArrayKlass->allocate functions to allocate_klass and allocate_instance so it's more clear which allocation it's doing and to match InstanceKlass allocate functions, and makes these functions private with friends for Deoptimization and oopFactory.  For JEP 401, arrays are being extended to support new formats and attributes and this reduces the call sites.
>> Tested with tier1-7.
>
> src/hotspot/share/oops/objArrayKlass.hpp line 39:
> 
>> 37:   friend class JVMCIVMStructs;
>> 38:   friend class oopFactory;
>> 39:   friend class Deoptimization;
> 
> If you want you could consider sorting the friend declarations (here and in the other place where you added it)

Do we sort friends? The sorting looks funny since VMStructs is usually at the beginning.

 class ObjArrayKlass : public ArrayKlass {
-  friend class VMStructs;
+  friend class Deoptimization;
   friend class JVMCIVMStructs;
   friend class oopFactory;
-  friend class Deoptimization;
+  friend class VMStructs;

> src/hotspot/share/oops/objArrayKlass.hpp line 81:
> 
>> 79:                                                 int n, Klass* element_klass, TRAPS);
>> 80: 
>> 81:   objArrayOop allocate(int length, TRAPS);
> 
> Do you think `multi_allocate` will need a better name in the future?

I thought if changing multi_allocate_instance so that it's clear that it's an instance, but decided to limit this.  Maybe this would be helpful but the allocate() function was the most confusing to me, that's why I picked that one.

> src/hotspot/share/runtime/reflection.cpp line 352:
> 
>> 350:     if (type == T_VOID) {
>> 351:       THROW_NULL(vmSymbols::java_lang_IllegalArgumentException());
>> 352:     }
> 
> I was first wondering where this came from but I now see that this was duplicated from `basic_type_mirror_to_arrayklass`. I wonder if this could could be deduplicated by moving this check into `basic_type_mirror_to_basic_type` and then removed from -`basic_type_mirror_to_arrayklass`:
> 
> 
> static BasicType basic_type_mirror_to_basic_type(oop basic_type_mirror, TRAPS) {
>   assert(java_lang_Class::is_primitive(basic_type_mirror),
>     "just checking");
>   
>   if (type == T_VOID) {
>     THROW_NULL(vmSymbols::java_lang_IllegalArgumentException());
>   }
> 
>   return java_lang_Class::primitive_type(basic_type_mirror);
> }
> 
> static Klass* basic_type_mirror_to_arrayklass(oop basic_type_mirror, TRAPS) {
>   BasicType type = basic_type_mirror_to_basic_type(basic_type_mirror, CHECK_NULL);
>   return Universe::typeArrayKlass(type);
> }
> 
> And then this code could be a two-liner again:
> 
> if (java_lang_Class::is_primitive(element_mirror)) {
>     BasicType type = basic_type_mirror_to_basic_type(element_mirror, CHECK_NULL);
>   return oopFactory::new_typeArray(type, length, CHECK_NULL);
> }

Unfortunately the caller to basic_type_mirror_to_basic_type() can legitimately return T_VOID for the caller in reflect_method, so that's why I had to duplicate the exception code.  Maybe a future enhancement would be to move these to javaClasses.hpp in java_lang_Class, where it knows all about is_primitive types, and boxing classes, which I guess boxing T_VOID is a thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25590#discussion_r2135760802
PR Review Comment: https://git.openjdk.org/jdk/pull/25590#discussion_r2135763584
PR Review Comment: https://git.openjdk.org/jdk/pull/25590#discussion_r2135758517

From coleenp at openjdk.org  Mon Jun  9 14:16:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 14:16:39 GMT
Subject: RFR: 8358326: Use oopFactory array allocation [v2]
In-Reply-To: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>
References: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>
Message-ID: <dIczmf_TyCZwdpAOJ9_WVs4Ib9dZJhl7ClEimVT5bMI=.0d4a9ed5-be3c-43a9-8697-71d46428d16c@github.com>

> This patch removes cases of direct calls to {type,obj}ArrayKlass->allocate() and calls oopFactory::new_*array instead.  It also renames {type,obj}ArrayKlass->allocate functions to allocate_klass and allocate_instance so it's more clear which allocation it's doing and to match InstanceKlass allocate functions, and makes these functions private with friends for Deoptimization and oopFactory.  For JEP 401, arrays are being extended to support new formats and attributes and this reduces the call sites.
> Tested with tier1-7.

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

  Sort our friends.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25590/files
  - new: https://git.openjdk.org/jdk/pull/25590/files/2da2b11b..2ccaf422

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

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

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

From fparain at openjdk.org  Mon Jun  9 17:19:00 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 9 Jun 2025 17:19:00 GMT
Subject: RFR: 8358326: Use oopFactory array allocation [v2]
In-Reply-To: <dIczmf_TyCZwdpAOJ9_WVs4Ib9dZJhl7ClEimVT5bMI=.0d4a9ed5-be3c-43a9-8697-71d46428d16c@github.com>
References: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>
 <dIczmf_TyCZwdpAOJ9_WVs4Ib9dZJhl7ClEimVT5bMI=.0d4a9ed5-be3c-43a9-8697-71d46428d16c@github.com>
Message-ID: <3YetAk_NA9GY0VmiXbizzYK9ASxuUUGczeQvkE8k798=.2d6ab3b2-6358-4dcc-ab2f-69c8cd100d8e@github.com>

On Mon, 9 Jun 2025 14:16:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch removes cases of direct calls to {type,obj}ArrayKlass->allocate() and calls oopFactory::new_*array instead.  It also renames {type,obj}ArrayKlass->allocate functions to allocate_klass and allocate_instance so it's more clear which allocation it's doing and to match InstanceKlass allocate functions, and makes these functions private with friends for Deoptimization and oopFactory.  For JEP 401, arrays are being extended to support new formats and attributes and this reduces the call sites.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort our friends.

LGTM.
Thank you for this cleanup.

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

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25590#pullrequestreview-2910737057

From coleenp at openjdk.org  Mon Jun  9 18:35:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 18:35:56 GMT
Subject: RFR: 8358326: Use oopFactory array allocation [v2]
In-Reply-To: <dIczmf_TyCZwdpAOJ9_WVs4Ib9dZJhl7ClEimVT5bMI=.0d4a9ed5-be3c-43a9-8697-71d46428d16c@github.com>
References: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>
 <dIczmf_TyCZwdpAOJ9_WVs4Ib9dZJhl7ClEimVT5bMI=.0d4a9ed5-be3c-43a9-8697-71d46428d16c@github.com>
Message-ID: <UyeMb2kbsOoD8T9XwKZN4ghus1Rdhc9Qd2lhU1PHbqY=.032c4909-7011-4ea7-a8c8-6df00d1e4c6a@github.com>

On Mon, 9 Jun 2025 14:16:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch removes cases of direct calls to {type,obj}ArrayKlass->allocate() and calls oopFactory::new_*array instead.  It also renames {type,obj}ArrayKlass->allocate functions to allocate_klass and allocate_instance so it's more clear which allocation it's doing and to match InstanceKlass allocate functions, and makes these functions private with friends for Deoptimization and oopFactory.  For JEP 401, arrays are being extended to support new formats and attributes and this reduces the call sites.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort our friends.

Thanks for reviewing Stefan and Frederic.

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

PR Comment: https://git.openjdk.org/jdk/pull/25590#issuecomment-2956607253

From coleenp at openjdk.org  Mon Jun  9 18:35:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 18:35:57 GMT
Subject: Integrated: 8358326: Use oopFactory array allocation
In-Reply-To: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>
References: <LD-ysG1ATQkT8qNLQM9KD7IKLZ2QlHpuOtZ0YTmlu3w=.53a6d59d-ad91-48f4-8354-4230372843f6@github.com>
Message-ID: <uB3b3h7dxmvFmGf7v0k2cMd7Z6vAMHORb7WCPNeimJo=.69f5f181-c748-489d-ae0c-e9640dab4720@github.com>

On Mon, 2 Jun 2025 14:07:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This patch removes cases of direct calls to {type,obj}ArrayKlass->allocate() and calls oopFactory::new_*array instead.  It also renames {type,obj}ArrayKlass->allocate functions to allocate_klass and allocate_instance so it's more clear which allocation it's doing and to match InstanceKlass allocate functions, and makes these functions private with friends for Deoptimization and oopFactory.  For JEP 401, arrays are being extended to support new formats and attributes and this reduces the call sites.
> Tested with tier1-7.

This pull request has now been integrated.

Changeset: eb256deb
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb256deb8021d5b243ef782eb9e2622472909e97
Stats:     67 lines in 10 files changed: 23 ins; 14 del; 30 mod

8358326: Use oopFactory array allocation

Reviewed-by: fparain, stefank

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

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

From cslucas at openjdk.org  Tue Jun 10 00:03:51 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 10 Jun 2025 00:03:51 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to JVMCI
 client
Message-ID: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>

We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).

This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
). 

Tested on Linux x86_64, ARM with JTREG tier 1-3.

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

Commit messages:
 - Set reason why InstalledCode was changed/installed/changed.

Changes: https://git.openjdk.org/jdk/pull/25706/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359064
  Stats: 143 lines in 18 files changed: 121 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25706/head:pull/25706

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

From mhaessig at openjdk.org  Tue Jun 10 07:48:33 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 10 Jun 2025 07:48:33 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <kNRCQmWW4W43fWWtWvcFaoomLbpZf1lwHv_ysD4N1ck=.89f8522b-5232-4ee2-81bc-b0e9104c2c98@github.com>

On Mon, 9 Jun 2025 23:57:46 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

Thank you for working on this. Now #25338 makes even more sense ? 

A naive question: is it possible to somehow share the enum definition in hotspot with the Java side in JVMCI? If all change reasons were enums, they would be much easier to understand.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2958019012

From dnsimon at openjdk.org  Tue Jun 10 10:37:32 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 10 Jun 2025 10:37:32 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <lbN6_dEZcYepGVPtA3stfGNUokPxS0yJYznO2y2AVHs=.e0889a0d-514d-431d-87a8-07be3608548e@github.com>

On Mon, 9 Jun 2025 23:57:46 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/InstalledCode.java line 127:

> 125:     }
> 126: 
> 127:     public int getChangeReason() {

Please add javadoc to this method as well as `getChangeReasonDescription`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2137514507

From dnsimon at openjdk.org  Tue Jun 10 10:45:47 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 10 Jun 2025 10:45:47 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client
In-Reply-To: <kNRCQmWW4W43fWWtWvcFaoomLbpZf1lwHv_ysD4N1ck=.89f8522b-5232-4ee2-81bc-b0e9104c2c98@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <kNRCQmWW4W43fWWtWvcFaoomLbpZf1lwHv_ysD4N1ck=.89f8522b-5232-4ee2-81bc-b0e9104c2c98@github.com>
Message-ID: <ZQDyXG_ga2Oo13YuoTeUYkipHWfGjAvkEg84_2RNIIs=.09944d78-a9a2-495c-b604-cd429ec4cf11@github.com>

On Tue, 10 Jun 2025 07:45:34 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> A naive question: is it possible to somehow share the enum definition in hotspot with the Java side in JVMCI? If all change reasons were enums, they would be much easier to understand.

Not directly but you can have a mirror enum in JVMCI whose ordinal and message could be kept in sync and initialized from native code. As an example, see [jdk.vm.ci.hotspot.HotSpotCompiledCodeStream.Tag](https://github.com/openjdk/jdk/blob/3ff83ec49e561c44dd99508364b8ba068274b63a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCodeStream.java#L228).

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2958619966

From tschatzl at openjdk.org  Tue Jun 10 13:33:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 10 Jun 2025 13:33:27 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v39]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <dbgVIxaLhZIz3-6qkuM7QOnBwh7k88E00pCXejUGzrE=.68761112-3f5e-4ca0-9d89-d2aa912c021f@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 55 commits:

 - 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
 - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - ... and 45 more: https://git.openjdk.org/jdk/compare/0582bd29...c07a73db

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=38
  Stats: 7085 lines in 111 files changed: 2568 ins; 3599 del; 918 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 cslucas at openjdk.org  Wed Jun 11 00:05:47 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 11 Jun 2025 00:05:47 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v2]
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Address PR feedback: add comments, refactor enum definition in the Java side.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25706/files
  - new: https://git.openjdk.org/jdk/pull/25706/files/9478d1de..5e4b8145

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

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

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

From cslucas at openjdk.org  Wed Jun 11 00:05:47 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 11 Jun 2025 00:05:47 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client
In-Reply-To: <ZQDyXG_ga2Oo13YuoTeUYkipHWfGjAvkEg84_2RNIIs=.09944d78-a9a2-495c-b604-cd429ec4cf11@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <kNRCQmWW4W43fWWtWvcFaoomLbpZf1lwHv_ysD4N1ck=.89f8522b-5232-4ee2-81bc-b0e9104c2c98@github.com>
 <ZQDyXG_ga2Oo13YuoTeUYkipHWfGjAvkEg84_2RNIIs=.09944d78-a9a2-495c-b604-cd429ec4cf11@github.com>
Message-ID: <PU5iNBksdTzW8bJFA_iw6imjuX22z3InjLleHweD1Ws=.1601c1ed-2475-498d-a129-c0cec29dd646@github.com>

On Tue, 10 Jun 2025 10:43:07 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Thank you for working on this. Now #25338 makes even more sense ? 
>> 
>> A naive question: is it possible to somehow share the enum definition in hotspot with the Java side in JVMCI? If all change reasons were enums, they would be much easier to understand.
>
>> A naive question: is it possible to somehow share the enum definition in hotspot with the Java side in JVMCI? If all change reasons were enums, they would be much easier to understand.
> 
> Not directly but you can have a mirror enum in JVMCI whose ordinal and message could be kept in sync and initialized from native code. As an example, see [jdk.vm.ci.hotspot.HotSpotCompiledCodeStream.Tag](https://github.com/openjdk/jdk/blob/3ff83ec49e561c44dd99508364b8ba068274b63a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCodeStream.java#L228).

Thank you for the comments. I added the comments that you asked @dougxc and I did some refactoring around the definition of the ChangeReason enum in the JVMCI API.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2960843655

From dnsimon at openjdk.org  Wed Jun 11 07:53:29 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 11 Jun 2025 07:53:29 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v2]
In-Reply-To: <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
Message-ID: <gHbM75247sDcXFaZYi5GBrCOuuKJ0pYNJTMhsoOwSfc=.6306bc40-f1dd-4a91-b554-4d58b1305f15@github.com>

On Wed, 11 Jun 2025 00:05:47 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feedback: add comments, refactor enum definition in the Java side.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/InstalledCode.java line 152:

> 150:      */
> 151:     public void invalidate() {
> 152:         invalidate(true, 0);

This assigns `ChangeReason::C1_codepatch` to JVMCI invalidations which does not seem right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2139454968

From dnsimon at openjdk.org  Wed Jun 11 08:20:28 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 11 Jun 2025 08:20:28 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v2]
In-Reply-To: <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
Message-ID: <SEBZxEbNWBmR0pwzo1NUiHR7mmPSydK959tnfAxpcCE=.c91ec3c0-94ee-4fc0-83ab-20c6f994964a@github.com>

On Wed, 11 Jun 2025 00:05:47 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feedback: add comments, refactor enum definition in the Java side.

While the new ChangeReason JVMCI enum looks nice, I don't quite get how/where it is (or should be) used? It seems disconnected from the `InstalledCode.changeReason` field.

In general, I don't find the name ChangeReason quite models the concept properly - wouldn't "InvalidationReason" be more accurate? "change" is a very broad concept.

I think all JVMCI Java level tracking of change (or invalidation) reasons should be confined to `HotSpotNmethod` as it doesn't make much sense in the other `InstalledCode` (sub)classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2961675374
PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2961676448
PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2961682020

From mchevalier at openjdk.org  Wed Jun 11 13:02:42 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 11 Jun 2025 13:02:42 GMT
Subject: RFR: 8359121: C2: Region added by vectorizedMismatch intrinsic can
 survive as a dead node after IGVN
Message-ID: <_wCd8NCYihFG3Sh7XRHPv4tYAQeMgbII-VXkDCNwoNE=.aafa7afa-49fd-48bb-aa87-0fc70a91c7bf@github.com>

In `bool LibraryCallKit::inline_vectorizedMismatch()` the region created at:

https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/library_call.cpp#L6502

may have only one input, and be a copy (that is no self-loop) and a single input. It is thus safe to remove. Yet, in the reproducer case, the node is short-circuited, but stays in the graph after IGVN.

Left, after Parsing/before IGVN; right, after IGVN:
<img src="https://github.com/user-attachments/assets/2fc0e817-ccf5-4586-81dc-ea9daef21274" width="400">  <img src="https://github.com/user-attachments/assets/6032f54e-75ba-49a1-b00e-ac8053d9f592" width="400">
On the left, the ? is there because the Region doesn't have a self loop, which is expected for copies. On the right, it still doesn't have a self-loop, but IGV is also complaining the Region has no successor.

This transformation comes from `IfNode::Ideal`, that calls `IfNode::Ideal_common`, that calls `Node::remove_dead_region`,  that shortcuts a trivial Region input:
https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/node.cpp#L1480-L1484

Yet, the Region node is never enqueued for IGVN, so stays in the graph.  This is not nice because it gives both:
- a control node (50 Proj) has 2 successors,
- a control node (46 Region) has 0 successors.

While at the end of IGVN, we could expect the graph to be cleaned up. There are couple ways of doing, each being enough by itself:
1. explicitly record for IGVN the region node in `LibraryCallKit::inline_vectorizedMismatch`, and not hoping it would be collected by another consequence
2. change `Node::remove_dead_region` to use `set_req_X` instead of `set_req`, so that if the Region goes dead, it will be removed.
3. not introduce the region node in `LibraryCallKit::inline_vectorizedMismatch` if we are going to have only one path, and thus avoid the problem entirely.

The solution 3. is really not easy and would require quite some code restructuring for simply saving removing a node. After discussing with @chhagedorn, we concluded that the solution 1. was probably the best:
- usually, functions similar to `inline_vectorizedMismatch` call `record_for_igvn` themselves,
- unlike what I assumed at first seeing `remove_dead_region`, it's not a general problem at all: I couldn't find another case without using `inline_vectorizedMismatch` where the Region is put aside, and not entirely disconnected quickly after, but the Region is always processed in the same IGVN when `remove_dead_region` makes it dead.

And then, we find that:
<img src="https://github.com/user-attachments/assets/32f4d934-6849-43bf-915f-0710436a22c5" width="400">

This was found because it makes a check of JDK-8350864 to fail. My plan is to add this structural invariant check to the test once the flag is integrated, as for now, the test need manual inspection to see a difference. It's also not really possible to write an IR test with it: the Region node is not reachable by under (use to def traversal from Root), so the printout of the graph doesn't show the Region node, even if the `50 Proj` above is indeed printed to have 2 outputs, only the `57 If` is actually printed.

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

Commit messages:
 - Add test
 - Record region and co for IGVN in inline_vectorizedMismatch

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

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

From thartmann at openjdk.org  Wed Jun 11 13:27:30 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 11 Jun 2025 13:27:30 GMT
Subject: RFR: 8359121: C2: Region added by vectorizedMismatch intrinsic can
 survive as a dead node after IGVN
In-Reply-To: <_wCd8NCYihFG3Sh7XRHPv4tYAQeMgbII-VXkDCNwoNE=.aafa7afa-49fd-48bb-aa87-0fc70a91c7bf@github.com>
References: <_wCd8NCYihFG3Sh7XRHPv4tYAQeMgbII-VXkDCNwoNE=.aafa7afa-49fd-48bb-aa87-0fc70a91c7bf@github.com>
Message-ID: <gS0jXt26-2X9EXBLgpB-esC88mgGcFEHxQREHXcGico=.ca889197-bb1a-458c-b1c3-9cacdf044fc6@github.com>

On Wed, 11 Jun 2025 11:35:28 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> In `bool LibraryCallKit::inline_vectorizedMismatch()` the region created at:
> 
> https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/library_call.cpp#L6502
> 
> may have only one input, and be a copy (that is no self-loop) and a single input. It is thus safe to remove. Yet, in the reproducer case, the node is short-circuited, but stays in the graph after IGVN.
> 
> Left, after Parsing/before IGVN; right, after IGVN:
> <img src="https://github.com/user-attachments/assets/2fc0e817-ccf5-4586-81dc-ea9daef21274" width="400">  <img src="https://github.com/user-attachments/assets/6032f54e-75ba-49a1-b00e-ac8053d9f592" width="400">
> On the left, the ? is there because the Region doesn't have a self loop, which is expected for copies. On the right, it still doesn't have a self-loop, but IGV is also complaining the Region has no successor.
> 
> This transformation comes from `IfNode::Ideal`, that calls `IfNode::Ideal_common`, that calls `Node::remove_dead_region`,  that shortcuts a trivial Region input:
> https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/node.cpp#L1480-L1484
> 
> Yet, the Region node is never enqueued for IGVN, so stays in the graph.  This is not nice because it gives both:
> - a control node (50 Proj) has 2 successors,
> - a control node (46 Region) has 0 successors.
> 
> While at the end of IGVN, we could expect the graph to be cleaned up. There are couple ways of doing, each being enough by itself:
> 1. explicitly record for IGVN the region node in `LibraryCallKit::inline_vectorizedMismatch`, and not hoping it would be collected by another consequence
> 2. change `Node::remove_dead_region` to use `set_req_X` instead of `set_req`, so that if the Region goes dead, it will be removed.
> 3. not introduce the region node in `LibraryCallKit::inline_vectorizedMismatch` if we are going to have only one path, and thus avoid the problem entirely.
> 
> The solution 3. is really not easy and would require quite some code restructuring for simply saving removing a node. After discussing with @chhagedorn, we concluded that the solution 1. was probably the best:
> - usually, functions similar to `inline_vectorizedMismatch` call `record_for_igvn` themselves,
> - unlike what I assumed at first seeing `remove_dead_region`, it's not a general problem at all: I couldn't find another case without using `inline_vectorizedMismatch` where the Region is put aside, and not entirely disconnected quickly after, but the Regi...

Nice analysis Marc. I also prefer solution (1) and the fix looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25749#pullrequestreview-2917146779

From chagedorn at openjdk.org  Wed Jun 11 13:37:29 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 11 Jun 2025 13:37:29 GMT
Subject: RFR: 8359121: C2: Region added by vectorizedMismatch intrinsic can
 survive as a dead node after IGVN
In-Reply-To: <_wCd8NCYihFG3Sh7XRHPv4tYAQeMgbII-VXkDCNwoNE=.aafa7afa-49fd-48bb-aa87-0fc70a91c7bf@github.com>
References: <_wCd8NCYihFG3Sh7XRHPv4tYAQeMgbII-VXkDCNwoNE=.aafa7afa-49fd-48bb-aa87-0fc70a91c7bf@github.com>
Message-ID: <PvgReoVebSAFxTwW99sIHoNWwM6xVRbm4uxxGy6WNCU=.9b0e7ff0-e2dd-4692-ae3a-fe27614aaaee@github.com>

On Wed, 11 Jun 2025 11:35:28 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> In `bool LibraryCallKit::inline_vectorizedMismatch()` the region created at:
> 
> https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/library_call.cpp#L6502
> 
> may have only one input, and be a copy (that is no self-loop) and a single input. It is thus safe to remove. Yet, in the reproducer case, the node is short-circuited, but stays in the graph after IGVN.
> 
> Left, after Parsing/before IGVN; right, after IGVN:
> <img src="https://github.com/user-attachments/assets/2fc0e817-ccf5-4586-81dc-ea9daef21274" width="400">  <img src="https://github.com/user-attachments/assets/6032f54e-75ba-49a1-b00e-ac8053d9f592" width="400">
> On the left, the ? is there because the Region doesn't have a self loop, which is expected for copies. On the right, it still doesn't have a self-loop, but IGV is also complaining the Region has no successor.
> 
> This transformation comes from `IfNode::Ideal`, that calls `IfNode::Ideal_common`, that calls `Node::remove_dead_region`,  that shortcuts a trivial Region input:
> https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/node.cpp#L1480-L1484
> 
> Yet, the Region node is never enqueued for IGVN, so stays in the graph.  This is not nice because it gives both:
> - a control node (50 Proj) has 2 successors,
> - a control node (46 Region) has 0 successors.
> 
> While at the end of IGVN, we could expect the graph to be cleaned up. There are couple ways of doing, each being enough by itself:
> 1. explicitly record for IGVN the region node in `LibraryCallKit::inline_vectorizedMismatch`, and not hoping it would be collected by another consequence
> 2. change `Node::remove_dead_region` to use `set_req_X` instead of `set_req`, so that if the Region goes dead, it will be removed.
> 3. not introduce the region node in `LibraryCallKit::inline_vectorizedMismatch` if we are going to have only one path, and thus avoid the problem entirely.
> 
> The solution 3. is really not easy and would require quite some code restructuring for simply saving removing a node. After discussing with @chhagedorn, we concluded that the solution 1. was probably the best:
> - usually, functions similar to `inline_vectorizedMismatch` call `record_for_igvn` themselves,
> - unlike what I assumed at first seeing `remove_dead_region`, it's not a general problem at all: I couldn't find another case without using `inline_vectorizedMismatch` where the Region is put aside, and not entirely disconnected quickly after, but the Regi...

Nice analysis and summary! As you've already mentioned in the description, we found solution 1 to be the best fit.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25749#pullrequestreview-2917191481

From mchevalier at openjdk.org  Wed Jun 11 16:18:38 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 11 Jun 2025 16:18:38 GMT
Subject: Withdrawn: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <FDC4kftsSAqf2FB3mxOABGMgWhr_qty0_BktGUiuTuE=.060b5943-74c3-461d-8806-b6da1722c207@github.com>
References: <FDC4kftsSAqf2FB3mxOABGMgWhr_qty0_BktGUiuTuE=.060b5943-74c3-461d-8806-b6da1722c207@github.com>
Message-ID: <ZCeE8H3hSkrss9iBlT4vyucReGp419W9sQO06FoGzYo=.1aee1a68-9250-41dd-91c0-88f06ab27e47@github.com>

On Wed, 30 Apr 2025 13:18:33 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> A first part toward a better support of pure functions.
> 
> ## 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 macro nodes later expanded into other, 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 that are expanded into regular calls during macro expansion. This also allows the removal of `ModD` and `ModF` nodes that have their pure equivalent now. They are surprisingly hard to unify with other floating point functions from an implementation point of view!
> 
> IR framework and IGV needed a little bit of fixing.
> 
> Thanks,
> Marc

This pull request has been closed without being integrated.

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

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

From mchevalier at openjdk.org  Wed Jun 11 16:18:37 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 11 Jun 2025 16:18:37 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <VyhWEgB7ogn67Vk1EFEyT-FlFGtUJQbyiAbrL3lUsoI=.29192455-8cf7-450a-a136-d736e2333660@github.com>
References: <FDC4kftsSAqf2FB3mxOABGMgWhr_qty0_BktGUiuTuE=.060b5943-74c3-461d-8806-b6da1722c207@github.com>
 <VyhWEgB7ogn67Vk1EFEyT-FlFGtUJQbyiAbrL3lUsoI=.29192455-8cf7-450a-a136-d736e2333660@github.com>
Message-ID: <SyZkryx2vQ4gbNBjsYZS18MajWXR9EYBRdxjkLvwne4=.0ed5e186-ed7f-432f-859b-d20c9ef1c547@github.com>

On Tue, 20 May 2025 03:26:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> A first part toward a better support of pure functions.
>> 
>> ## 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 macro nodes later expanded into other, 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 that are expanded into regular calls during macro expansion. This also allows the removal of `ModD` and `ModF` nodes that have their pure equivalent now. They are surprisingly hard to unify with other floating point functions from an implementation point of view!
>> 
>> IR framework and IGV needed a little bit of fixing.
>> 
>> Thanks,
>> Marc
>
> I'm just pointing out that delaying lowering decision till matching phase neither makes scheduling easier nor makes implementation simpler.
> 
> For loop opts it is important to know when loops contain calls and act accordingly (by trying to hoist relevant nodes out of loops and disabling some optimizations when the calls are still there).
> 
> The difference between CFG nodes effectively pinned AT some point and non-CFG nodes with control dependency (effectively pushing them UNDER their control input) becomes insignificant once CFG nodes depend solely on control. In other words, once a call node doesn't consume/produce memory and I/O states, it becomes straightforward to move it around in CFG when desired (between it's inputs and users). 
> 
> Speaking of scheduling, would default scheduling heuristics do a good job? The case of expensive nodes exemplifies the need of custom scheduling heuristics for such nodes. 
> 
> Implementation-wise, lowering during matching becomes platform-specific and requires each platform to introduce `effect(CALL)`  AD instructions. Moreover, each call shape (determined by arity and argument kinds) has to be explicitly handled with a dedicated AD instruction. And it doesn't benefit from existing support of call nodes every platform already has.
> 
> 
>> Ideally, what we want to do with expensive data nodes is to common them aggressively like any other data node. Then, during code motion, we can clone them if it is beneficial.
> 
> The current implementation of expensive nodes can definitely be improved, but the nice property it has is that it only decreases the number of nodes through careful commoning during loop opts. Once cloning is allowed, there's a new problem to care about: the case of too many clones. 
> 
> A simple incremental improvement would be to teach `PhaseIdealLoop::process_expensive_nodes()` to push expensive nodes closer to their users if they are on less frequent code paths. Then it can be taught (how and when) to clone expensive nodes between multiple users.

After patient guidance from @iwanowww, I came to a new version whose implementation has very little to do with this one. I'll close it and open a fresh one. Nevertheless, thanks to everyone who looked at it!

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

PR Comment: https://git.openjdk.org/jdk/pull/24966#issuecomment-2963437324

From mchevalier at openjdk.org  Wed Jun 11 16:26:58 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 11 Jun 2025 16:26:58 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
Message-ID: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@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

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

Commit messages:
 - Eliminate pure function calls

Changes: https://git.openjdk.org/jdk/pull/25760/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25760&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347901
  Stats: 196 lines in 15 files changed: 132 ins; 33 del; 31 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 yzheng at openjdk.org  Wed Jun 11 16:49:53 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 11 Jun 2025 16:49:53 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v5]
In-Reply-To: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
Message-ID: <mdcQ1CDIbBeJ64UmxS6r-RNuU3lrXkkXP1GmSVM2vtY=.c61cc0c5-b79b-4c13-808d-b31805b33e2b@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 six additional commits since the last revision:

 - 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25356/files
  - new: https://git.openjdk.org/jdk/pull/25356/files/b72213ae..57fe5307

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

  Stats: 123326 lines in 1943 files changed: 80552 ins; 28041 del; 14733 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 mdoerr at openjdk.org  Wed Jun 11 16:52:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 11 Jun 2025 16:52:30 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
Message-ID: <TTJI7zqw-q7HzEdxn1hnk83_UqoZxPY86riWFzULEQM=.728334f0-8fbd-4b21-9e63-1a5bbc416bbe@github.com>

On Wed, 11 Jun 2025 16:18:41 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

Just a side comment: "Integer division is not pure as dividing by zero is throwing." is only true for some platforms. See [JDK-8299857](https://bugs.openjdk.org/browse/JDK-8299857).

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

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

From yzheng at openjdk.org  Wed Jun 11 16:56:28 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 11 Jun 2025 16:56:28 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v4]
In-Reply-To: <ATJVh-zOQP0TKBATn8hw_kEtbfuLS81RuRiIik90rUk=.3f1221af-4825-4a09-b377-8abd03fc396e@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <jV_EaLvJc6R7LOqAvuY4xjBuB9z7p0fL31Hk0A0bGp8=.7e480681-b385-4bbc-b0ab-33c77eee6e7a@github.com>
 <ATJVh-zOQP0TKBATn8hw_kEtbfuLS81RuRiIik90rUk=.3f1221af-4825-4a09-b377-8abd03fc396e@github.com>
Message-ID: <ck591oiwl9CB9W9RKL0-LGuExMbSdeLdD7GpumlyypE=.629adf04-828b-40af-b186-b35698082296@github.com>

On Tue, 27 May 2025 17:30:09 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address comments
>
> I think there are two levels of counters that we might want to disable.  We definitely want to stop deopts and recompilations from marking the method not compilable which the current change does.  Additionally JVMCIRuntime::register_method will perform this logic if validate_compile_task_dependencies fails and I don't think we want that.  I think the new `!is_default` guard idiom should be in a helper like `nmethod::is_jvmci_hosted`.  Do we use the hosted language elsewhere?
> 
> The second level is to stop all counter updates in hosted compiles, for similar reasons.  Those updates won't lead to disabling compilation but they will quickly lead to saturating of all the counters which is fairly pointless but probably benign.  This would be done by setting `update_trap_state` to false for hosted nmethods.  That also has the effect of keeping `inc_recompile_count` false.  I think that's the right thing to do but I'd want to make sure that we test truffle workloads with those changes before making that change to make sure there isn't some subtle problem with that change.

@tkrodriguez by `stop all counter updates in hosted compiles` you mean the trap-related counters, right?

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

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

From mchevalier at openjdk.org  Wed Jun 11 16:57:30 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 11 Jun 2025 16:57:30 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
Message-ID: <XoYsqRbW8Tg0Sji0lHlj597F0BOW3hXBwpq38nzgnFA=.46fe88f7-ccbc-48c1-bf99-2e1a70182eb6@github.com>

On Wed, 11 Jun 2025 16:18:41 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

Right. Yet, it's safe to consider it as non-pure, as an over-approximation, but it could be refined.

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

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

From never at openjdk.org  Wed Jun 11 17:18:47 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 11 Jun 2025 17:18:47 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v5]
In-Reply-To: <mdcQ1CDIbBeJ64UmxS6r-RNuU3lrXkkXP1GmSVM2vtY=.c61cc0c5-b79b-4c13-808d-b31805b33e2b@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <mdcQ1CDIbBeJ64UmxS6r-RNuU3lrXkkXP1GmSVM2vtY=.c61cc0c5-b79b-4c13-808d-b31805b33e2b@github.com>
Message-ID: <0g305fzs1X2bbkjCduwcEC8XHf6hVsWXuDpfW5Hq9TI=.878a8aaf-e376-4fae-a559-c0b60bba7d4b@github.com>

On Wed, 11 Jun 2025 16:49:53 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 six additional commits since the last revision:
> 
>  - 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

Yes.  Any update to the MDO for hosted compiles doesn't seem useful I think.

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

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

From yzheng at openjdk.org  Wed Jun 11 17:18:44 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 11 Jun 2025 17:18:44 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v6]
In-Reply-To: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
Message-ID: <3VLvf-Aw_4Xbqf4EIs29YKxTamuA21D6pNRs9UkAWAM=.06906268-6067-412f-922a-3c3a3ec896e4@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:

  fix compilation error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25356/files
  - new: https://git.openjdk.org/jdk/pull/25356/files/57fe5307..9d24428e

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

  Stats: 7 lines in 2 files changed: 4 ins; 2 del; 1 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 cslucas at openjdk.org  Wed Jun 11 19:04:29 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 11 Jun 2025 19:04:29 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v2]
In-Reply-To: <gHbM75247sDcXFaZYi5GBrCOuuKJ0pYNJTMhsoOwSfc=.6306bc40-f1dd-4a91-b554-4d58b1305f15@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
 <gHbM75247sDcXFaZYi5GBrCOuuKJ0pYNJTMhsoOwSfc=.6306bc40-f1dd-4a91-b554-4d58b1305f15@github.com>
Message-ID: <XvFYnYHlUY_btcxLj21G7ZvCBvP6THIp4Z_re4MdIIA=.4da6ed29-9082-40ed-ab45-1f8ecbdb7d44@github.com>

On Wed, 11 Jun 2025 07:50:43 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address PR feedback: add comments, refactor enum definition in the Java side.
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/InstalledCode.java line 152:
> 
>> 150:      */
>> 151:     public void invalidate() {
>> 152:         invalidate(true, 0);
> 
> This assigns `ChangeReason::C1_codepatch` to JVMCI invalidations which does not seem right.

I believe zero is mapped to `UNKNOWN` in the ChangeReason enum, if I'm not very mistaken here?!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2140876714

From dnsimon at openjdk.org  Wed Jun 11 19:17:32 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 11 Jun 2025 19:17:32 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v2]
In-Reply-To: <XvFYnYHlUY_btcxLj21G7ZvCBvP6THIp4Z_re4MdIIA=.4da6ed29-9082-40ed-ab45-1f8ecbdb7d44@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
 <gHbM75247sDcXFaZYi5GBrCOuuKJ0pYNJTMhsoOwSfc=.6306bc40-f1dd-4a91-b554-4d58b1305f15@github.com>
 <XvFYnYHlUY_btcxLj21G7ZvCBvP6THIp4Z_re4MdIIA=.4da6ed29-9082-40ed-ab45-1f8ecbdb7d44@github.com>
Message-ID: <ZFngKJtI3inv3wmrI23K-Px2ReiQiJxb-qV9fBFsPJM=.6359f726-5777-4138-ba08-5d993152dae2@github.com>

On Wed, 11 Jun 2025 19:01:22 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/InstalledCode.java line 152:
>> 
>>> 150:      */
>>> 151:     public void invalidate() {
>>> 152:         invalidate(true, 0);
>> 
>> This assigns `ChangeReason::C1_codepatch` to JVMCI invalidations which does not seem right.
>
> I believe zero is mapped to `UNKNOWN` in the ChangeReason enum, if I'm not very mistaken here?!

Sorry, I was looking at nmethod.hpp in my local source without the changes in this PR. That said, it should probably map to `ChangeReason::JVMCI_invalidate_nmethod` right?
BTW, seems like `ChangeReason::JVMCI_invalidate_nmethod_mirror` is unused and could be deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2140896474

From cslucas at openjdk.org  Wed Jun 11 19:30:28 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 11 Jun 2025 19:30:28 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v2]
In-Reply-To: <SEBZxEbNWBmR0pwzo1NUiHR7mmPSydK959tnfAxpcCE=.c91ec3c0-94ee-4fc0-83ab-20c6f994964a@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
 <SEBZxEbNWBmR0pwzo1NUiHR7mmPSydK959tnfAxpcCE=.c91ec3c0-94ee-4fc0-83ab-20c6f994964a@github.com>
Message-ID: <CMXKp_ajXNmk14dhzSad4VIzA2VZqmV5FPO6qynhVWg=.0a001430-f508-4423-9f15-8debd44760b2@github.com>

On Wed, 11 Jun 2025 08:15:52 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> While the new ChangeReason JVMCI enum looks nice, I don't quite get how/where it is (or should be) used? It seems disconnected from the `InstalledCode.changeReason` field.

I agree, I also have that feeling because the type of the field is not the enum. I'll refactor that. The end goal here mainly (but not only) is to be able to use this "change or invalidation reason" to reset Truffle CallTarget profiles when its installed code was evicted from the code cache because it was "cold". See this [draft PR](https://github.com/JohnTortugo/graal/pull/2/files#diff-1f5e4cd4034f7f7571d9a021272192501800c9b19a41101bc26aaaeebaf14e15) that I'm preparing for Truffle - it contains some spurious changes right now.

> In general, I don't find the name ChangeReason quite models the concept properly - wouldn't "InvalidationReason" be more accurate? "change" is a very broad concept.

I agree that "change" is broad, but is it a bad thing in this context? Shouldn't both sides of JVMCI (if they want to) be able to "monitor" any change that the other side did to an installed code? "invalidationReason" may not be great as well because the field will be also set when the code is installed.

> I think all JVMCI Java level tracking of change (or invalidation) reasons should be confined to HotSpotNmethod as it doesn't make much sense in the other InstalledCode (sub)classes.

IMHO it seemed right to add the field in the "InstalledCode" class because having a simple way to communicate back-and-forth that a change occurred, and why it occurred, felt like a good thing to have overall. I understand that not all users of JVMCI may use it. If you feel strongly about this I can move the field to HotSpotNmethod.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2963924270

From dnsimon at openjdk.org  Wed Jun 11 20:03:28 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 11 Jun 2025 20:03:28 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v2]
In-Reply-To: <CMXKp_ajXNmk14dhzSad4VIzA2VZqmV5FPO6qynhVWg=.0a001430-f508-4423-9f15-8debd44760b2@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
 <SEBZxEbNWBmR0pwzo1NUiHR7mmPSydK959tnfAxpcCE=.c91ec3c0-94ee-4fc0-83ab-20c6f994964a@github.com>
 <CMXKp_ajXNmk14dhzSad4VIzA2VZqmV5FPO6qynhVWg=.0a001430-f508-4423-9f15-8debd44760b2@github.com>
Message-ID: <TivHe8GcBwLAt-XryQh2Mz5sMxEGTA8YtEs1yDriVxk=.68c10521-8525-4d3a-9dcf-2f11cb0e7335@github.com>

On Wed, 11 Jun 2025 19:27:38 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> I agree that "change" is broad, but is it a bad thing in this context? Shouldn't both sides of JVMCI (if they want to) be able to "monitor" any change that the other side did to an installed code? "invalidationReason" may not be great as well because the field will be also set when the code is installed.

The only change we're talking about is invalidation via `nmethod::make_not_entrant` right? If so, then it really is *only* an invalidation reason.

Why will the field be set when the code is installed? Do you mean it will be initialized to the default `int` value of 0? Then it should be initialized to `-1` to denote that no invalidation has occurred.

All the current reasons are HotSpot specific and the very notion of "change" is exactly tied to `nmethod::make_not_entrant` so I still think this should all be confined to HotSpotNmethod until we have a good use case for lifting it up to InstalledCode. We've learnt through painful experience that making API too broad, too early almost always comes back to bite us. I would also drop the enum on the Java side. It really doesn't add any extra value as shown by `installedCode.getChangeReason() == HotSpotNmethod.ChangeReason.GC_UNLINKING_COLD.ordinal()` [here](https://github.com/JohnTortugo/graal/pull/2/files#diff-1f5e4cd4034f7f7571d9a021272192501800c9b19a41101bc26aaaeebaf14e15R189). That is, if you're using the ordinal of an enum, then the enum is probably just an unnecessary box for an `int`. While you could make the `HotSpotNmethod.invalidationReason` field itself be an enum, that makes setting the field in `JVMCINMethodData::invalidate_nmethod_mirror` significantly more complicated.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2963996747

From cslucas at openjdk.org  Wed Jun 11 22:46:27 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 11 Jun 2025 22:46:27 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v2]
In-Reply-To: <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <TsIwcgEg9IAhMFOpGeBnZULZkUbLL5l5SEmuiUIcIOk=.f06a9996-5fac-4a1a-8dfe-65ab3ceb3507@github.com>
Message-ID: <5Zja0OdYDsycdWBaGsSt6oJWf7ByTRukZ84WaqX3dRs=.32ba25ba-acc1-46b3-b047-9d08f2fc137d@github.com>

On Wed, 11 Jun 2025 00:05:47 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feedback: add comments, refactor enum definition in the Java side.

> The only change we're talking about is invalidation via `nmethod::make_not_entrant` right? If so, then it really is _only_ an invalidation reason.
> Why will the field be set when the code is installed? Do you mean it will be initialized to the default int value of 0? Then it should be initialized to -1 to denote that no invalidation has occurred.

I was referring to the change made in `jvmciEnv.cpp` in this PR. 

> All the current reasons are HotSpot specific and the very notion of "change" is exactly tied to nmethod::make_not_entrant so I still think this should all be confined to HotSpotNmethod until we have a good use case for lifting it up to InstalledCode. We've learnt through painful experience that making API too broad, too early almost always comes back to bite us. I would also drop the enum on the Java side. It really doesn't add any extra value as shown by installedCode.getChangeReason() == HotSpotNmethod.ChangeReason.GC_UNLINKING_COLD.ordinal() [here](https://github.com/JohnTortugo/graal/pull/2/files#diff-1f5e4cd4034f7f7571d9a021272192501800c9b19a41101bc26aaaeebaf14e15R189). That is, if you're using the ordinal of an enum, then the enum is probably just an unnecessary box for an int. While you could make the HotSpotNmethod.invalidationReason field itself be an enum, that makes setting the field in JVMCINMethodData::invalidate_nmethod_mirror significantly more complicated.

Sounds good to me. I'll rename the field to `invalidatedReason`, move it to `HotSpotNmethod` and remove the enum from Java side.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2964471872

From cslucas at openjdk.org  Thu Jun 12 00:27:55 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 12 Jun 2025 00:27:55 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v3]
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <2ATJAQCD4VUVZ02RO2czrh4D40N0y4TR7XDRAhQ-PWE=.1bc8747d-0e2d-435c-a647-a8c718f6fcdc@github.com>

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Refactoring: move changes to HotSpotNmethod class; remove enum on Java side; rename field to invalidationReason

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25706/files
  - new: https://git.openjdk.org/jdk/pull/25706/files/5e4b8145..fcf838bd

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

  Stats: 138 lines in 15 files changed: 29 ins; 75 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/25706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25706/head:pull/25706

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

From cslucas at openjdk.org  Thu Jun 12 01:05:13 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 12 Jun 2025 01:05:13 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v4]
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <OQa02unGTW0eyKwYI5jO2ivNmJ4bknGlEWRfOqLc6hk=.566223ef-3a74-4585-a33c-85d95f3d9cc9@github.com>

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Some clean up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25706/files
  - new: https://git.openjdk.org/jdk/pull/25706/files/fcf838bd..1f3c2598

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

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

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

From dnsimon at openjdk.org  Thu Jun 12 10:58:32 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 12 Jun 2025 10:58:32 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v3]
In-Reply-To: <2ATJAQCD4VUVZ02RO2czrh4D40N0y4TR7XDRAhQ-PWE=.1bc8747d-0e2d-435c-a647-a8c718f6fcdc@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <2ATJAQCD4VUVZ02RO2czrh4D40N0y4TR7XDRAhQ-PWE=.1bc8747d-0e2d-435c-a647-a8c718f6fcdc@github.com>
Message-ID: <5SD6o4fpHcmxJnegKO-tp8H3N86_2DHJy0uvA5URD_o=.7f6a3999-cda0-497a-8dcf-a2548e46fada@github.com>

On Thu, 12 Jun 2025 00:27:55 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring: move changes to HotSpotNmethod class; remove enum on Java side; rename field to invalidationReason

src/hotspot/share/jvmci/jvmciEnv.cpp line 1747:

> 1745:   }
> 1746:   set_InstalledCode_address(installed_code, (jlong) cb);
> 1747:   set_HotSpotNmethod_invalidationReason(installed_code, static_cast<int>(nmethod::ChangeReason::unknown));

Remove this - just let the `HotSpotNmethod` constructor do the right thing.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotNmethod.java line 81:

> 79: 
> 80:     /**
> 81:      * Identify the reason that caused this nmethod to be invalidated.

Update doc to note that the field will be `-1` until the nmethod is invalidated.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotNmethod.java line 91:

> 89:         boolean inOopsTable = !IS_IN_NATIVE_IMAGE && !isDefault;
> 90:         this.compileIdSnapshot = inOopsTable ? 0L : compileId;
> 91:         this.invalidationReason = 0;

It should be initialized to `-1` as we will never install invalid code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2142352178
PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2142348968
PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2142347083

From dnsimon at openjdk.org  Thu Jun 12 11:03:32 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 12 Jun 2025 11:03:32 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v3]
In-Reply-To: <2ATJAQCD4VUVZ02RO2czrh4D40N0y4TR7XDRAhQ-PWE=.1bc8747d-0e2d-435c-a647-a8c718f6fcdc@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <2ATJAQCD4VUVZ02RO2czrh4D40N0y4TR7XDRAhQ-PWE=.1bc8747d-0e2d-435c-a647-a8c718f6fcdc@github.com>
Message-ID: <JxyLKvyYZN7XyZHs1AIEnd1Y0e24waEMsbC3d3OPkcg=.727c7b63-845e-45b4-81c8-15c5384bff51@github.com>

On Thu, 12 Jun 2025 00:27:55 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring: move changes to HotSpotNmethod class; remove enum on Java side; rename field to invalidationReason

src/hotspot/share/code/nmethod.hpp line 476:

> 474:   // If you change anything in this enum please patch
> 475:   // vmStructs_jvmci.cpp accordingly.
> 476:   enum class ChangeReason : u1 {

I would also suggest this enum be changed to `InvalidationReason` but that can be considered as a potential follow up.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotNmethod.java line 213:

> 211:      * @return a String describing the reason why this nmethod was invalidated.
> 212:      */
> 213:     public String getInvalidationReasonString() {

I would have stuck with getInvalidationReasonDescription but can live with getInvalidationReasonString.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2142359399
PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2142360949

From mchevalier at openjdk.org  Thu Jun 12 11:43:42 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 12 Jun 2025 11:43:42 GMT
Subject: RFR: 8359121: C2: Region added by vectorizedMismatch intrinsic can
 survive as a dead node after IGVN
In-Reply-To: <_wCd8NCYihFG3Sh7XRHPv4tYAQeMgbII-VXkDCNwoNE=.aafa7afa-49fd-48bb-aa87-0fc70a91c7bf@github.com>
References: <_wCd8NCYihFG3Sh7XRHPv4tYAQeMgbII-VXkDCNwoNE=.aafa7afa-49fd-48bb-aa87-0fc70a91c7bf@github.com>
Message-ID: <0RLmkluz50j7V3Qiv_lI13vLt_UuuYhVGf_JerIW96g=.9e374b92-a7b2-4240-853e-9fd9116e39bb@github.com>

On Wed, 11 Jun 2025 11:35:28 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> In `bool LibraryCallKit::inline_vectorizedMismatch()` the region created at:
> 
> https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/library_call.cpp#L6502
> 
> may have only one input, and be a copy (that is no self-loop) and a single input. It is thus safe to remove. Yet, in the reproducer case, the node is short-circuited, but stays in the graph after IGVN.
> 
> Left, after Parsing/before IGVN; right, after IGVN:
> <img src="https://github.com/user-attachments/assets/2fc0e817-ccf5-4586-81dc-ea9daef21274" width="400">  <img src="https://github.com/user-attachments/assets/6032f54e-75ba-49a1-b00e-ac8053d9f592" width="400">
> On the left, the ? is there because the Region doesn't have a self loop, which is expected for copies. On the right, it still doesn't have a self-loop, but IGV is also complaining the Region has no successor.
> 
> This transformation comes from `IfNode::Ideal`, that calls `IfNode::Ideal_common`, that calls `Node::remove_dead_region`,  that shortcuts a trivial Region input:
> https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/node.cpp#L1480-L1484
> 
> Yet, the Region node is never enqueued for IGVN, so stays in the graph.  This is not nice because it gives both:
> - a control node (50 Proj) has 2 successors,
> - a control node (46 Region) has 0 successors.
> 
> While at the end of IGVN, we could expect the graph to be cleaned up. There are couple ways of doing, each being enough by itself:
> 1. explicitly record for IGVN the region node in `LibraryCallKit::inline_vectorizedMismatch`, and not hoping it would be collected by another consequence
> 2. change `Node::remove_dead_region` to use `set_req_X` instead of `set_req`, so that if the Region goes dead, it will be removed.
> 3. not introduce the region node in `LibraryCallKit::inline_vectorizedMismatch` if we are going to have only one path, and thus avoid the problem entirely.
> 
> The solution 3. is really not easy and would require quite some code restructuring for simply saving removing a node. After discussing with @chhagedorn, we concluded that the solution 1. was probably the best:
> - usually, functions similar to `inline_vectorizedMismatch` call `record_for_igvn` themselves,
> - unlike what I assumed at first seeing `remove_dead_region`, it's not a general problem at all: I couldn't find another case without using `inline_vectorizedMismatch` where the Region is put aside, and not entirely disconnected quickly after, but the Regi...

Thanks both for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25749#issuecomment-2966312178

From mchevalier at openjdk.org  Thu Jun 12 11:43:43 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 12 Jun 2025 11:43:43 GMT
Subject: Integrated: 8359121: C2: Region added by vectorizedMismatch intrinsic
 can survive as a dead node after IGVN
In-Reply-To: <_wCd8NCYihFG3Sh7XRHPv4tYAQeMgbII-VXkDCNwoNE=.aafa7afa-49fd-48bb-aa87-0fc70a91c7bf@github.com>
References: <_wCd8NCYihFG3Sh7XRHPv4tYAQeMgbII-VXkDCNwoNE=.aafa7afa-49fd-48bb-aa87-0fc70a91c7bf@github.com>
Message-ID: <nGxnZnSoUgG2EuFJZfGjDbayIqgcIGhDUqJx3mJ7YCI=.e0bcdda7-9074-448b-b1ee-be5c3fa529c7@github.com>

On Wed, 11 Jun 2025 11:35:28 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> In `bool LibraryCallKit::inline_vectorizedMismatch()` the region created at:
> 
> https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/library_call.cpp#L6502
> 
> may have only one input, and be a copy (that is no self-loop) and a single input. It is thus safe to remove. Yet, in the reproducer case, the node is short-circuited, but stays in the graph after IGVN.
> 
> Left, after Parsing/before IGVN; right, after IGVN:
> <img src="https://github.com/user-attachments/assets/2fc0e817-ccf5-4586-81dc-ea9daef21274" width="400">  <img src="https://github.com/user-attachments/assets/6032f54e-75ba-49a1-b00e-ac8053d9f592" width="400">
> On the left, the ? is there because the Region doesn't have a self loop, which is expected for copies. On the right, it still doesn't have a self-loop, but IGV is also complaining the Region has no successor.
> 
> This transformation comes from `IfNode::Ideal`, that calls `IfNode::Ideal_common`, that calls `Node::remove_dead_region`,  that shortcuts a trivial Region input:
> https://github.com/openjdk/jdk/blob/0582bd290d5a8b6344ae7ada36492cc2f33df050/src/hotspot/share/opto/node.cpp#L1480-L1484
> 
> Yet, the Region node is never enqueued for IGVN, so stays in the graph.  This is not nice because it gives both:
> - a control node (50 Proj) has 2 successors,
> - a control node (46 Region) has 0 successors.
> 
> While at the end of IGVN, we could expect the graph to be cleaned up. There are couple ways of doing, each being enough by itself:
> 1. explicitly record for IGVN the region node in `LibraryCallKit::inline_vectorizedMismatch`, and not hoping it would be collected by another consequence
> 2. change `Node::remove_dead_region` to use `set_req_X` instead of `set_req`, so that if the Region goes dead, it will be removed.
> 3. not introduce the region node in `LibraryCallKit::inline_vectorizedMismatch` if we are going to have only one path, and thus avoid the problem entirely.
> 
> The solution 3. is really not easy and would require quite some code restructuring for simply saving removing a node. After discussing with @chhagedorn, we concluded that the solution 1. was probably the best:
> - usually, functions similar to `inline_vectorizedMismatch` call `record_for_igvn` themselves,
> - unlike what I assumed at first seeing `remove_dead_region`, it's not a general problem at all: I couldn't find another case without using `inline_vectorizedMismatch` where the Region is put aside, and not entirely disconnected quickly after, but the Regi...

This pull request has now been integrated.

Changeset: b6ec93b0
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6ec93b038c411d0c49be671c3b44dd231d01305
Stats:     58 lines in 2 files changed: 58 ins; 0 del; 0 mod

8359121: C2: Region added by vectorizedMismatch intrinsic can survive as a dead node after IGVN

Reviewed-by: thartmann, chagedorn

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

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

From cslucas at openjdk.org  Thu Jun 12 19:40:13 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 12 Jun 2025 19:40:13 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v5]
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <ETXn9YJlObKWMbW4_5kxCAHjyNeKoAl71ZUnTJiPGx4=.d2b1f01f-8e76-4609-884a-5f87a259685f@github.com>

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Rename 'reasons' enum. Adjust default value for invalidationReason.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25706/files
  - new: https://git.openjdk.org/jdk/pull/25706/files/1f3c2598..831ba2f0

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

  Stats: 121 lines in 22 files changed: 1 ins; 2 del; 118 mod
  Patch: https://git.openjdk.org/jdk/pull/25706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25706/head:pull/25706

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

From dnsimon at openjdk.org  Thu Jun 12 19:55:31 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 12 Jun 2025 19:55:31 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v5]
In-Reply-To: <ETXn9YJlObKWMbW4_5kxCAHjyNeKoAl71ZUnTJiPGx4=.d2b1f01f-8e76-4609-884a-5f87a259685f@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <ETXn9YJlObKWMbW4_5kxCAHjyNeKoAl71ZUnTJiPGx4=.d2b1f01f-8e76-4609-884a-5f87a259685f@github.com>
Message-ID: <-Xsyt7584x_m5CmbjFaE9zfnoFbYBnbVBpNIqH_QoZM=.81acb204-1e37-4eff-ba26-7f6b993e7883@github.com>

On Thu, 12 Jun 2025 19:40:13 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename 'reasons' enum. Adjust default value for invalidationReason.

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

> 223: 
> 224:     private static int unknownInvalidationReason() {
> 225:         return HotSpotJVMCIRuntime.runtime().config.getConstant("nmethod::ChangeReason::Unknown", Integer.class);

`unknownInvalidationReason` -> `jvmciInvalidationReason`
`"nmethod::ChangeReason::Unknown"` -> `"nmethod::InvalidationReason::JVMCI_INVALIDATE"`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2143540862

From cslucas at openjdk.org  Thu Jun 12 20:18:10 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 12 Jun 2025 20:18:10 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Fix some remaining renames.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25706/files
  - new: https://git.openjdk.org/jdk/pull/25706/files/831ba2f0..6f6d129b

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

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

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

From dnsimon at openjdk.org  Thu Jun 12 20:38:29 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 12 Jun 2025 20:38:29 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
Message-ID: <2j19nj-UatNbeMCtCNwGZWijYFZYgEZQ-VbvcAulwBI=.b2edd200-063c-4b58-905d-76f31f3d8e97@github.com>

On Thu, 12 Jun 2025 20:18:10 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some remaining renames.

Looks good to me now - thanks for all the changes.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25706#pullrequestreview-2922585106

From cslucas at openjdk.org  Thu Jun 12 20:44:29 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 12 Jun 2025 20:44:29 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
Message-ID: <S-rjjzwiVJic7ERrz3NmKyYDiklnGwUiEQgM7Dy9gRQ=.a9862bfd-7efc-4f78-ba48-a39527deacef@github.com>

On Thu, 12 Jun 2025 20:18:10 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some remaining renames.

Thank you for reviewing and all the suggestions!

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2968103752

From kbarrett at openjdk.org  Fri Jun 13 07:04:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Jun 2025 07:04:46 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t
Message-ID: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>

Please review this change that makes the various code cache/heap size options
consistently be of type size_t.

The shared declarations for these options were all uintx. These options all
may have platform-defined values. Some of those platform-specific definitions
were uintx, some were size_t, and some were intx(!). This change makes them
all consistently size_t.

More details in the first comment.

Testing: mach5 tier1-6
GHA testing in-progress

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

Commit messages:
 - fix whitebox access to code cache size configs
 - VMPageSizeConstraintFunc
 - CodeCacheMinBlockLength
 - CodeCacheExpansionSize
 - various CodeHeapSize options
 - CodeCacheMinimumUseSpace
 - Initial/ReservedCodeCacheSize
 - CodeCacheSegmentSize

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

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

From kbarrett at openjdk.org  Fri Jun 13 07:04:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Jun 2025 07:04:46 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t
In-Reply-To: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
Message-ID: <m79XjsgB-QcErSKsUPbUqzCoTYc1I_ujFCx6WRZidlk=.097b91fa-c196-4da9-92ef-94c901089e4d@github.com>

On Fri, 13 Jun 2025 06:57:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that makes the various code cache/heap size options
> consistently be of type size_t.
> 
> The shared declarations for these options were all uintx. These options all
> may have platform-defined values. Some of those platform-specific definitions
> were uintx, some were size_t, and some were intx(!). This change makes them
> all consistently size_t.
> 
> More details in the first comment.
> 
> Testing: mach5 tier1-6
> GHA testing in-progress

In addition to adjusting the types, there are some code changes to deal with
some inconsistencies, benefit from the change (mostly in the form of removal
of some casts), or address issues discovered while examining uses of the
options. The changes in the PR are broken up into a series of commits, mostly
by option or a couple of closely related options. It might be easier to review
parts of the change by looking at some of those individual commits, in order
to more easily see the code changes related to specific options.

One change in particular to note is the change in compilationPolicy.cpp. The
calculation of max_count, depending on explicit option values and such, could
potentially overflow its prior int type, effectively having a random value.
There is still a possibility of a nonsense result if ReservedCodeCacheSize and
CodeCacheMinimumUseSpace are poorly chosen. I'm leaving that pre-existing
issue to the compiler team to deal with.

The reason for my looking at these options in the first place is the incorrect
format strings for error messages in CompilerConfig::check_args_consistency.
They weren't previously noticed because the messages are printed using
jio_fprintf. It might be these should be using UL warnings, but I'm leaving
that to the compiler team to decide.

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

PR Comment: https://git.openjdk.org/jdk/pull/25791#issuecomment-2969303712

From mhaessig at openjdk.org  Fri Jun 13 12:54:35 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 13 Jun 2025 12:54:35 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t
In-Reply-To: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
Message-ID: <3sJTUKOONMnjRHYKl-M6Dcx4ZDrbbOYPD5DTbgp7UuI=.0d870e8c-fe60-48ed-9f54-aab2786fe77f@github.com>

On Fri, 13 Jun 2025 06:57:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that makes the various code cache/heap size options
> consistently be of type size_t.
> 
> The shared declarations for these options were all uintx. These options all
> may have platform-defined values. Some of those platform-specific definitions
> were uintx, some were size_t, and some were intx(!). This change makes them
> all consistently size_t.
> 
> More details in the first comment.
> 
> Testing: mach5 tier1-6
> GHA testing in-progress

Thank you for working on this, @kimbarrett. Good to see more consistent types here.

The changes overall look good to me. I only have a question and some minor suggestions.

>One change in particular to note is the change in compilationPolicy.cpp. The
calculation of max_count, depending on explicit option values and such, could
potentially overflow its prior int type, effectively having a random value.
There is still a possibility of a nonsense result if ReservedCodeCacheSize and
CodeCacheMinimumUseSpace are poorly chosen. I'm leaving that pre-existing
issue to the compiler team to deal with.

Thank you for pointing this out. I'm currently looking at that part of the code in #25770 and will fix it there.

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 61:

> 59: 
> 60: #include <type_traits>
> 61: 

Is this related to this change? I cannot find any usages from this header in the diff.

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 550:

> 548: #define ADD_SIZE_T_FLAG(name) ADD_FLAG(size_t, name, BOXED_LONG)
> 549: #define ADD_INTX_FLAG(name)   ADD_FLAG(intx, name, BOXED_LONG)
> 550: #define ADD_UINTX_FLAG(name)  ADD_FLAG(uintx, name, BOXED_LONG)

Suggestion:

#define ADD_BOOL_FLAG(name)   ADD_FLAG(bool,   name, BOXED_BOOLEAN)
#define ADD_INT_FLAG(name)    ADD_FLAG(int,    name, BOXED_LONG)
#define ADD_SIZE_T_FLAG(name) ADD_FLAG(size_t, name, BOXED_LONG)
#define ADD_INTX_FLAG(name)   ADD_FLAG(intx,   name, BOXED_LONG)
#define ADD_UINTX_FLAG(name)  ADD_FLAG(uintx,  name, BOXED_LONG)

Feel free to ignore, but since you are already touching this, we might as well align it.

src/hotspot/share/runtime/arguments.cpp line 2451:

> 2449:         return JNI_EINVAL;
> 2450:       }
> 2451:       if (FLAG_SET_CMDLINE(ReservedCodeCacheSize, (size_t)long_ReservedCodeCacheSize) != JVMFlag::SUCCESS) {

Is this cast correct on a 32-bit platform, where `size_t` is not the same as `uint64_t`?

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

PR Review: https://git.openjdk.org/jdk/pull/25791#pullrequestreview-2924643009
PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2144994525
PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2144997094
PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2145007538

From yzheng at openjdk.org  Fri Jun 13 16:29:17 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Fri, 13 Jun 2025 16:29:17 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v7]
In-Reply-To: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
Message-ID: <jK9lKheluCp0kBQUfIw0aOeLrtosIrBW3DtWoSStTEM=.f312343e-05d1-4a21-b0ea-bf8179599218@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 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25356/files
  - new: https://git.openjdk.org/jdk/pull/25356/files/9d24428e..f253c0a8

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

  Stats: 3428 lines in 81 files changed: 1704 ins; 1413 del; 311 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 cslucas at openjdk.org  Fri Jun 13 17:35:36 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 13 Jun 2025 17:35:36 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
Message-ID: <7bjdVQUAb1lGw-G0tICDh8GB-g_u-VqISmBAyzTwSj8=.8e5afe75-14cc-44f1-b46d-e62a4ffa0586@github.com>

On Thu, 12 Jun 2025 20:18:10 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some remaining renames.

@shipilev , @vnkozlov - do you want take a look on this / any comment?

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2971069243

From kbarrett at openjdk.org  Fri Jun 13 18:46:58 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Jun 2025 18:46:58 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v2]
In-Reply-To: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
Message-ID: <gbcGZMbOZiml80mFn7PwGGx4nRt4ZH25l3hHprvtDfg=.2566acbd-8544-4735-804e-1391cf697cec@github.com>

> Please review this change that makes the various code cache/heap size options
> consistently be of type size_t.
> 
> The shared declarations for these options were all uintx. These options all
> may have platform-defined values. Some of those platform-specific definitions
> were uintx, some were size_t, and some were intx(!). This change makes them
> all consistently size_t.
> 
> More details in the first comment.
> 
> Testing: mach5 tier1-6
> GHA testing in-progress

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - update copyrights
 - remove leftover <type_traits> include

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25791/files
  - new: https://git.openjdk.org/jdk/pull/25791/files/9b96ebd1..bd1923f6

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

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

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

From never at openjdk.org  Fri Jun 13 19:00:28 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 13 Jun 2025 19:00:28 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
Message-ID: <vu76lwi45Tw5i-fQPnkJ7lbKI-g1wBabDKe50OxbwRQ=.9f321471-39e0-45ad-85dc-fbba9cb2f940@github.com>

On Thu, 12 Jun 2025 20:18:10 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some remaining renames.

This seems like a very complicated way for Truffle to tell itself that it invalidated some installed code.  Couldn't this be done with bookkeeping purely on the Truffle side?  A weak map of InstalledCode instances that were invalidated because they were cold would be completely sufficient, wouldn't it?

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2971335423

From never at openjdk.org  Fri Jun 13 19:08:29 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 13 Jun 2025 19:08:29 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
Message-ID: <M5_ER4MBckv9s6esLJULj7_-uXFQ5R9MufU8CZJ-yaY=.c096f404-c705-475e-aad8-6c8250a14e54@github.com>

On Thu, 12 Jun 2025 20:18:10 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some remaining renames.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1409:

> 1407: C2V_VMENTRY(void, invalidateHotSpotNmethod, (JNIEnv* env, jobject, jobject hs_nmethod, jboolean deoptimize, jint invalidation_reason))
> 1408:   JVMCIObject nmethod_mirror = JVMCIENV->wrap(hs_nmethod);
> 1409:   JVMCIENV->invalidate_nmethod_mirror(nmethod_mirror, deoptimize, static_cast<nmethod::InvalidationReason>(invalidation_reason), JVMCI_CHECK);

There should probably be a check here that `invalidation_reason` is in the range of `nmethod::InvalidationReason`.

src/hotspot/share/jvmci/jvmciRuntime.cpp line 818:

> 816:       HotSpotJVMCI::InstalledCode::set_address(jvmciEnv, nmethod_mirror, 0);
> 817:       HotSpotJVMCI::InstalledCode::set_entryPoint(jvmciEnv, nmethod_mirror, 0);
> 818:       HotSpotJVMCI::HotSpotNmethod::set_invalidationReason(jvmciEnv, nmethod_mirror, static_cast<int>(invalidation_reason));

I think you're in danger of overwriting the invalidationReason here.  `invalidate_nmethod_mirror` can be called for unloaded nmethods after they have been made not entrant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2145899316
PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2145896972

From cslucas at openjdk.org  Fri Jun 13 19:19:31 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 13 Jun 2025 19:19:31 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <vu76lwi45Tw5i-fQPnkJ7lbKI-g1wBabDKe50OxbwRQ=.9f321471-39e0-45ad-85dc-fbba9cb2f940@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
 <vu76lwi45Tw5i-fQPnkJ7lbKI-g1wBabDKe50OxbwRQ=.9f321471-39e0-45ad-85dc-fbba9cb2f940@github.com>
Message-ID: <uCpJn6xZISFJOKRXpRH08pbOZDc_ZRw6Ud1Lo0HdACw=.d40ae850-3d72-4ff7-a7a9-b2b1f501e9a5@github.com>

On Fri, 13 Jun 2025 18:57:43 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some remaining renames.
>
> This seems like a very complicated way for Truffle to tell itself that it invalidated some installed code.  Couldn't this be done with bookkeeping purely on the Truffle side?  A weak map of InstalledCode instances that were invalidated because they were cold would be completely sufficient, wouldn't it?

Thank you for commenting @tkrodriguez .

> This seems like a very complicated way for Truffle to tell itself that it invalidated some installed code. 

If by "it" you mean Truffle then the answer is no. The main point of this change is to communicate to Truffle when something in the HotSpot side invalidated the code, _in particular_ [I'm interested](https://github.com/oracle/graal/issues/11045) in the situation when the heuristics that monitor the code cache caused the eviction of a nmethod because it considered it _cold_. Truffle itself uses a different concept of hot/cold method...

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2971400634

From never at openjdk.org  Fri Jun 13 20:07:58 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 13 Jun 2025 20:07:58 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
Message-ID: <ZALJTptxBZ8LjoX9uSDrBeqzgVDqtVUIFgyiqzusLHQ=.300f87a5-bf00-4780-a100-72f318bbcd25@github.com>

On Thu, 12 Jun 2025 20:18:10 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some remaining renames.

Sorry for the confusion on my part.  The lack of a PR that's consuming these changes makes it harder to know which parts are the important ones.

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

> 2123:   JVMCINMethodData* nmethod_data = jvmci_nmethod_data();
> 2124:   if (nmethod_data != nullptr) {
> 2125:     nmethod_data->invalidate_nmethod_mirror(this, is_cold() ? nmethod::InvalidationReason::GC_UNLINKING_COLD : nmethod::InvalidationReason::GC_UNLINKING);

So then this is the heart of what you're after?  Maybe `GC_UNLINKING_COLD` should be `COLD_UNLOADING`?  GC is doing it but it's not for GC reasons.  `GC_UNLINKING` might better be `GC_UNLOADING`.  I don't think the `nmethod::unlink` name is a good one to propagate into enum names.

`is_cold` isn't completely reliable here as an method could both have dead oops and be cold.  I guess that probably doesn't matter though.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2971527074
PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2146005973

From cslucas at openjdk.org  Fri Jun 13 20:41:33 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 13 Jun 2025 20:41:33 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <ZALJTptxBZ8LjoX9uSDrBeqzgVDqtVUIFgyiqzusLHQ=.300f87a5-bf00-4780-a100-72f318bbcd25@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
 <ZALJTptxBZ8LjoX9uSDrBeqzgVDqtVUIFgyiqzusLHQ=.300f87a5-bf00-4780-a100-72f318bbcd25@github.com>
Message-ID: <G6SF9I0HSxhlTAkE3LJaSTCQL0mvjT_F0_dW79o5U9s=.a274c468-3382-4353-8a7b-933296a91afe@github.com>

On Fri, 13 Jun 2025 20:02:58 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some remaining renames.
>
> src/hotspot/share/code/nmethod.cpp line 2125:
> 
>> 2123:   JVMCINMethodData* nmethod_data = jvmci_nmethod_data();
>> 2124:   if (nmethod_data != nullptr) {
>> 2125:     nmethod_data->invalidate_nmethod_mirror(this, is_cold() ? nmethod::InvalidationReason::GC_UNLINKING_COLD : nmethod::InvalidationReason::GC_UNLINKING);
> 
> So then this is the heart of what you're after?  Maybe `GC_UNLINKING_COLD` should be `COLD_UNLOADING`?  GC is doing it but it's not for GC reasons.  `GC_UNLINKING` might better be `GC_UNLOADING`.  I don't think the `nmethod::unlink` name is a good one to propagate into enum names.
> 
> `is_cold` isn't completely reliable here as an method could both have dead oops and be cold.  I guess that probably doesn't matter though.

I'll do the renaming, good point there.

> is_cold isn't completely reliable here as an method could both have dead oops and be cold. I guess that probably doesn't matter though.

I don't think that matter because since the nmethod is cold right now it could have been eliminated for that reason at any moment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2146059210

From dnsimon at openjdk.org  Fri Jun 13 21:01:59 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 13 Jun 2025 21:01:59 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v7]
In-Reply-To: <jK9lKheluCp0kBQUfIw0aOeLrtosIrBW3DtWoSStTEM=.f312343e-05d1-4a21-b0ea-bf8179599218@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <jK9lKheluCp0kBQUfIw0aOeLrtosIrBW3DtWoSStTEM=.f312343e-05d1-4a21-b0ea-bf8179599218@github.com>
Message-ID: <Y_CBG-Cq-k1SvYWgzDR4I5-qP3yk9BR9dGUH5QgZrpM=.a0c9d62b-cb23-47c2-ad43-90547630b712@github.com>

On Fri, 13 Jun 2025 16:29:17 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 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.

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

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

From kbarrett at openjdk.org  Fri Jun 13 21:14:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Jun 2025 21:14:35 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v2]
In-Reply-To: <3sJTUKOONMnjRHYKl-M6Dcx4ZDrbbOYPD5DTbgp7UuI=.0d870e8c-fe60-48ed-9f54-aab2786fe77f@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <3sJTUKOONMnjRHYKl-M6Dcx4ZDrbbOYPD5DTbgp7UuI=.0d870e8c-fe60-48ed-9f54-aab2786fe77f@github.com>
Message-ID: <2RxFDNlbqvjX0IGueBW0KIK0J6nRII4D0nIc7TaI1AM=.e2ccb3ec-d0e0-4a05-bac2-9450ff69b539@github.com>

On Fri, 13 Jun 2025 12:29:59 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyrights
>>  - remove leftover <type_traits> include
>
> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 61:
> 
>> 59: 
>> 60: #include <type_traits>
>> 61: 
> 
> Is this related to this change? I cannot find any usages from this header in the diff.

Oops. Leftover from an abandoned idea. Removed now.

> src/hotspot/share/runtime/arguments.cpp line 2451:
> 
>> 2449:         return JNI_EINVAL;
>> 2450:       }
>> 2451:       if (FLAG_SET_CMDLINE(ReservedCodeCacheSize, (size_t)long_ReservedCodeCacheSize) != JVMFlag::SUCCESS) {
> 
> Is this cast correct on a 32-bit platform, where `size_t` is not the same as `uint64_t`?

This isn't any different from the previous code, as uintx is also a 32/64 bit
type on 32/64 bit platforms. And it's fine, as the default for the maximum
value for parse_memory_size is max_uintx.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2146097179
PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2146097889

From syan at openjdk.org  Sat Jun 14 00:55:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 14 Jun 2025 00:55:36 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v2]
In-Reply-To: <gbcGZMbOZiml80mFn7PwGGx4nRt4ZH25l3hHprvtDfg=.2566acbd-8544-4735-804e-1391cf697cec@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <gbcGZMbOZiml80mFn7PwGGx4nRt4ZH25l3hHprvtDfg=.2566acbd-8544-4735-804e-1391cf697cec@github.com>
Message-ID: <o__eijDoCnJSnVE65Fu-naJnYyobgRVFRD6sXoHbiRw=.ee07fd89-3fcc-4e68-863e-87c4a72aef1b@github.com>

On Fri, 13 Jun 2025 18:46:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that makes the various code cache/heap size options
>> consistently be of type size_t.
>> 
>> The shared declarations for these options were all uintx. These options all
>> may have platform-defined values. Some of those platform-specific definitions
>> were uintx, some were size_t, and some were intx(!). This change makes them
>> all consistently size_t.
>> 
>> More details in the first comment.
>> 
>> Testing: mach5 tier1-6
>> GHA testing in-progress
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update copyrights
>  - remove leftover <type_traits> include

test/lib-test/jdk/test/whitebox/vm_flags/UintxTest.java line 40:

> 38: public class UintxTest {
> 39:     private static final String FLAG_NAME = "VerifyGCStartAt";
> 40:     private static final String FLAG_DEBUG_NAME = "StopInterpreterAt";

Hi, Does this change is a mistake. Why do we change the `FLAG_DEBUG_NAME`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2146323772

From kbarrett at openjdk.org  Sat Jun 14 11:10:34 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 14 Jun 2025 11:10:34 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v2]
In-Reply-To: <o__eijDoCnJSnVE65Fu-naJnYyobgRVFRD6sXoHbiRw=.ee07fd89-3fcc-4e68-863e-87c4a72aef1b@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <gbcGZMbOZiml80mFn7PwGGx4nRt4ZH25l3hHprvtDfg=.2566acbd-8544-4735-804e-1391cf697cec@github.com>
 <o__eijDoCnJSnVE65Fu-naJnYyobgRVFRD6sXoHbiRw=.ee07fd89-3fcc-4e68-863e-87c4a72aef1b@github.com>
Message-ID: <3VU2OGqP1oQpC2eKsNRur-VZgalWp9J7lpiUZrk2xB4=.fde060bd-0f96-46ca-b333-c2f463641e8d@github.com>

On Sat, 14 Jun 2025 00:53:18 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyrights
>>  - remove leftover <type_traits> include
>
> test/lib-test/jdk/test/whitebox/vm_flags/UintxTest.java line 40:
> 
>> 38: public class UintxTest {
>> 39:     private static final String FLAG_NAME = "VerifyGCStartAt";
>> 40:     private static final String FLAG_DEBUG_NAME = "StopInterpreterAt";
> 
> Hi, Does this change is a mistake. Why do we change the `FLAG_DEBUG_NAME`

Because CodeCacheMinimumUseSpace is no longer uintx-typed, it's now size_t. So the test needs to use
some other uintx-typed option.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2146426018

From cslucas at openjdk.org  Sun Jun 15 01:00:33 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Sun, 15 Jun 2025 01:00:33 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <M5_ER4MBckv9s6esLJULj7_-uXFQ5R9MufU8CZJ-yaY=.c096f404-c705-475e-aad8-6c8250a14e54@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
 <M5_ER4MBckv9s6esLJULj7_-uXFQ5R9MufU8CZJ-yaY=.c096f404-c705-475e-aad8-6c8250a14e54@github.com>
Message-ID: <ySgwO7zNBy5kzS0LqQt9weyt77SAaSd_VmmZODDmH2w=.6b9512f3-5770-4037-bfc5-0e0fd178e4b5@github.com>

On Fri, 13 Jun 2025 19:03:54 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some remaining renames.
>
> src/hotspot/share/jvmci/jvmciRuntime.cpp line 818:
> 
>> 816:       HotSpotJVMCI::InstalledCode::set_address(jvmciEnv, nmethod_mirror, 0);
>> 817:       HotSpotJVMCI::InstalledCode::set_entryPoint(jvmciEnv, nmethod_mirror, 0);
>> 818:       HotSpotJVMCI::HotSpotNmethod::set_invalidationReason(jvmciEnv, nmethod_mirror, static_cast<int>(invalidation_reason));
> 
> I think you're in danger of overwriting the invalidationReason here.  `invalidate_nmethod_mirror` can be called for unloaded nmethods after they have been made not entrant.

I see, thank you for the catch! I'm not sure how I can detect this case. My first idea was to just check if the "invalidationReason" field is already set or not, but looks like in order to do that I'd need to wrap the `nmethod_mirror` in a `JVMCIObject`. Unfortunately, there is a comment just a few lines above this change saying to _not_ do this wrapping. I'm not quite familiar with all nmethod state transitions. Would it be sufficient to just add a check for whether the nmethod is already non-entrant on line 818?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2147389125

From never at openjdk.org  Mon Jun 16 17:04:16 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 16 Jun 2025 17:04:16 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <ySgwO7zNBy5kzS0LqQt9weyt77SAaSd_VmmZODDmH2w=.6b9512f3-5770-4037-bfc5-0e0fd178e4b5@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
 <M5_ER4MBckv9s6esLJULj7_-uXFQ5R9MufU8CZJ-yaY=.c096f404-c705-475e-aad8-6c8250a14e54@github.com>
 <ySgwO7zNBy5kzS0LqQt9weyt77SAaSd_VmmZODDmH2w=.6b9512f3-5770-4037-bfc5-0e0fd178e4b5@github.com>
Message-ID: <36Lioxk5dWw3HwSMEy7ZXUjaUkm_3jNuD2zU2eULEi4=.62a4e77d-f18b-47a3-82f8-e2c735b65acb@github.com>

On Sun, 15 Jun 2025 00:57:55 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciRuntime.cpp line 818:
>> 
>>> 816:       HotSpotJVMCI::InstalledCode::set_address(jvmciEnv, nmethod_mirror, 0);
>>> 817:       HotSpotJVMCI::InstalledCode::set_entryPoint(jvmciEnv, nmethod_mirror, 0);
>>> 818:       HotSpotJVMCI::HotSpotNmethod::set_invalidationReason(jvmciEnv, nmethod_mirror, static_cast<int>(invalidation_reason));
>> 
>> I think you're in danger of overwriting the invalidationReason here.  `invalidate_nmethod_mirror` can be called for unloaded nmethods after they have been made not entrant.
>
> I see, thank you for the catch! I'm not sure how I can detect this case. My first idea was to just check if the "invalidationReason" field is already set or not, but looks like in order to do that I'd need to wrap the `nmethod_mirror` in a `JVMCIObject`. Unfortunately, there is a comment just a few lines above this change saying to _not_ do this wrapping. I'm not quite familiar with all nmethod state transitions. Would it be sufficient to just add a check for whether the nmethod is already non-entrant on line 818?

You should be able to use `HotSpotJVMCI::HotSpotNmethod::get_invalidationReason`.  JVMCIObject handles dispatching if you don't know which runtime you are attached to but we know we are talking to HotSpot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2150464134

From kbarrett at openjdk.org  Mon Jun 16 18:52:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 16 Jun 2025 18:52:35 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v2]
In-Reply-To: <3sJTUKOONMnjRHYKl-M6Dcx4ZDrbbOYPD5DTbgp7UuI=.0d870e8c-fe60-48ed-9f54-aab2786fe77f@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <3sJTUKOONMnjRHYKl-M6Dcx4ZDrbbOYPD5DTbgp7UuI=.0d870e8c-fe60-48ed-9f54-aab2786fe77f@github.com>
Message-ID: <dFrwpczsdyKucuiRgLh6y1fvYYGMSZN3bKD9PMJK07s=.ec754024-4397-403d-8348-9de5b689af99@github.com>

On Fri, 13 Jun 2025 12:31:44 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyrights
>>  - remove leftover <type_traits> include
>
> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 550:
> 
>> 548: #define ADD_SIZE_T_FLAG(name) ADD_FLAG(size_t, name, BOXED_LONG)
>> 549: #define ADD_INTX_FLAG(name)   ADD_FLAG(intx, name, BOXED_LONG)
>> 550: #define ADD_UINTX_FLAG(name)  ADD_FLAG(uintx, name, BOXED_LONG)
> 
> Suggestion:
> 
> #define ADD_BOOL_FLAG(name)   ADD_FLAG(bool,   name, BOXED_BOOLEAN)
> #define ADD_INT_FLAG(name)    ADD_FLAG(int,    name, BOXED_LONG)
> #define ADD_SIZE_T_FLAG(name) ADD_FLAG(size_t, name, BOXED_LONG)
> #define ADD_INTX_FLAG(name)   ADD_FLAG(intx,   name, BOXED_LONG)
> #define ADD_UINTX_FLAG(name)  ADD_FLAG(uintx,  name, BOXED_LONG)
> 
> Feel free to ignore, but since you are already touching this, we might as well align it.

I'd rather not. I'm not a fan of this kind of formatting. I moved the `ADD_FLAG` calls over to
maintain the pre-existing formatting after adding the longer than anything else `ADD_SIZE_T_FLAG`,
but the `ADD_FLAG` arguments were not lined up and I'd just as soon leave them that way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2150643858

From duke at openjdk.org  Mon Jun 16 19:07:30 2025
From: duke at openjdk.org (Larry Cable)
Date: Mon, 16 Jun 2025 19:07:30 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v2]
In-Reply-To: <dFrwpczsdyKucuiRgLh6y1fvYYGMSZN3bKD9PMJK07s=.ec754024-4397-403d-8348-9de5b689af99@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <3sJTUKOONMnjRHYKl-M6Dcx4ZDrbbOYPD5DTbgp7UuI=.0d870e8c-fe60-48ed-9f54-aab2786fe77f@github.com>
 <dFrwpczsdyKucuiRgLh6y1fvYYGMSZN3bKD9PMJK07s=.ec754024-4397-403d-8348-9de5b689af99@github.com>
Message-ID: <TIgOiYHhX4EmbT_ZKQSDCKqRf0dl53QVMkRy1WBeXd8=.98551e21-ecd9-4c18-a894-5dd412009180@github.com>

On Mon, 16 Jun 2025 18:49:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 550:
>> 
>>> 548: #define ADD_SIZE_T_FLAG(name) ADD_FLAG(size_t, name, BOXED_LONG)
>>> 549: #define ADD_INTX_FLAG(name)   ADD_FLAG(intx, name, BOXED_LONG)
>>> 550: #define ADD_UINTX_FLAG(name)  ADD_FLAG(uintx, name, BOXED_LONG)
>> 
>> Suggestion:
>> 
>> #define ADD_BOOL_FLAG(name)   ADD_FLAG(bool,   name, BOXED_BOOLEAN)
>> #define ADD_INT_FLAG(name)    ADD_FLAG(int,    name, BOXED_LONG)
>> #define ADD_SIZE_T_FLAG(name) ADD_FLAG(size_t, name, BOXED_LONG)
>> #define ADD_INTX_FLAG(name)   ADD_FLAG(intx,   name, BOXED_LONG)
>> #define ADD_UINTX_FLAG(name)  ADD_FLAG(uintx,  name, BOXED_LONG)
>> 
>> Feel free to ignore, but since you are already touching this, we might as well align it.
>
> I'd rather not. I'm not a fan of this kind of formatting. I moved the `ADD_FLAG` calls over to
> maintain the pre-existing formatting after adding the longer than anything else `ADD_SIZE_T_FLAG`,
> but the `ADD_FLAG` arguments were not lined up and I'd just as soon leave them that way.

not sure being a fan or not is sufficient reason...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2150671231

From kbarrett at openjdk.org  Mon Jun 16 19:55:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 16 Jun 2025 19:55:28 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v2]
In-Reply-To: <TIgOiYHhX4EmbT_ZKQSDCKqRf0dl53QVMkRy1WBeXd8=.98551e21-ecd9-4c18-a894-5dd412009180@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <3sJTUKOONMnjRHYKl-M6Dcx4ZDrbbOYPD5DTbgp7UuI=.0d870e8c-fe60-48ed-9f54-aab2786fe77f@github.com>
 <dFrwpczsdyKucuiRgLh6y1fvYYGMSZN3bKD9PMJK07s=.ec754024-4397-403d-8348-9de5b689af99@github.com>
 <TIgOiYHhX4EmbT_ZKQSDCKqRf0dl53QVMkRy1WBeXd8=.98551e21-ecd9-4c18-a894-5dd412009180@github.com>
Message-ID: <ToEKGLYFbjyFaiMi4vhAwbW3OZnRv6PJM09ASXwSXgE=.acd4a978-5734-4f71-b04a-45b0466496a1@github.com>

On Mon, 16 Jun 2025 19:05:12 GMT, Larry Cable <duke at openjdk.org> wrote:

>> I'd rather not. I'm not a fan of this kind of formatting. I moved the `ADD_FLAG` calls over to
>> maintain the pre-existing formatting after adding the longer than anything else `ADD_SIZE_T_FLAG`,
>> but the `ADD_FLAG` arguments were not lined up and I'd just as soon leave them that way.
>
> not sure being a fan or not is sufficient reason...

Leaving it as is maintains the status quo. I'm not proposing to delete the extra whitespace in front of
`ADD_FLAG`, which would be my preferred layout. And the comment does say "feel free to ignore".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25791#discussion_r2150756646

From cslucas at openjdk.org  Mon Jun 16 22:22:48 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 16 Jun 2025 22:22:48 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v7]
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <QVRh-FmctAK7ru7bGdrv8PanHGHyfB3ce52rsCDUnhs=.937be914-93c5-4c60-8e3d-3533ee14be4b@github.com>

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Prevent overriding invalidation reason.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25706/files
  - new: https://git.openjdk.org/jdk/pull/25706/files/6f6d129b..c0e970f1

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

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

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

From cslucas at openjdk.org  Mon Jun 16 22:22:48 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 16 Jun 2025 22:22:48 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <36Lioxk5dWw3HwSMEy7ZXUjaUkm_3jNuD2zU2eULEi4=.62a4e77d-f18b-47a3-82f8-e2c735b65acb@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
 <M5_ER4MBckv9s6esLJULj7_-uXFQ5R9MufU8CZJ-yaY=.c096f404-c705-475e-aad8-6c8250a14e54@github.com>
 <ySgwO7zNBy5kzS0LqQt9weyt77SAaSd_VmmZODDmH2w=.6b9512f3-5770-4037-bfc5-0e0fd178e4b5@github.com>
 <36Lioxk5dWw3HwSMEy7ZXUjaUkm_3jNuD2zU2eULEi4=.62a4e77d-f18b-47a3-82f8-e2c735b65acb@github.com>
Message-ID: <NI_6v2WgoGg51cQwh9ZaewEvmGaGzs7ibgjC23jsDH4=.7d20b26b-a151-4eeb-ad96-5d852002f0e2@github.com>

On Mon, 16 Jun 2025 17:00:49 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> I see, thank you for the catch! I'm not sure how I can detect this case. My first idea was to just check if the "invalidationReason" field is already set or not, but looks like in order to do that I'd need to wrap the `nmethod_mirror` in a `JVMCIObject`. Unfortunately, there is a comment just a few lines above this change saying to _not_ do this wrapping. I'm not quite familiar with all nmethod state transitions. Would it be sufficient to just add a check for whether the nmethod is already non-entrant on line 818?
>
> You should be able to use `HotSpotJVMCI::HotSpotNmethod::get_invalidationReason`.  JVMCIObject handles dispatching if you don't know which runtime you are attached to but we know we are talking to HotSpot.

Thank you for clarifying. I just pushed a change addressing your comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2150991011

From cslucas at openjdk.org  Tue Jun 17 00:39:54 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 17 Jun 2025 00:39:54 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v8]
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <XwVqrxQIB-hOVlDGS2Fh-_O_UjKr9v87-pCD5-MYqEM=.d170124c-35c0-421f-abb4-7ff01d83d4f0@github.com>

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25706/files
  - new: https://git.openjdk.org/jdk/pull/25706/files/c0e970f1..68271c7a

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

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

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

From cslucas at openjdk.org  Tue Jun 17 17:09:33 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 17 Jun 2025 17:09:33 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v7]
In-Reply-To: <jK9lKheluCp0kBQUfIw0aOeLrtosIrBW3DtWoSStTEM=.f312343e-05d1-4a21-b0ea-bf8179599218@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <jK9lKheluCp0kBQUfIw0aOeLrtosIrBW3DtWoSStTEM=.f312343e-05d1-4a21-b0ea-bf8179599218@github.com>
Message-ID: <kTQsJam-H-l24jhzIztbGbn7V0Lf2TxpI5eYTk6SKIE=.c2f32a12-ef80-4d7f-8edd-0959bc717470@github.com>

On Fri, 13 Jun 2025 16:29:17 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 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.

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

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

From mhaessig at openjdk.org  Wed Jun 18 10:36:29 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 18 Jun 2025 10:36:29 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v2]
In-Reply-To: <gbcGZMbOZiml80mFn7PwGGx4nRt4ZH25l3hHprvtDfg=.2566acbd-8544-4735-804e-1391cf697cec@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <gbcGZMbOZiml80mFn7PwGGx4nRt4ZH25l3hHprvtDfg=.2566acbd-8544-4735-804e-1391cf697cec@github.com>
Message-ID: <H5ehvjbdJjskRLr7LZD54o5RUXId95BETDG-jPlHexU=.68f1d283-0b31-4011-9891-b4c1be195c47@github.com>

On Fri, 13 Jun 2025 18:46:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that makes the various code cache/heap size options
>> consistently be of type size_t.
>> 
>> The shared declarations for these options were all uintx. These options all
>> may have platform-defined values. Some of those platform-specific definitions
>> were uintx, some were size_t, and some were intx(!). This change makes them
>> all consistently size_t.
>> 
>> More details in the first comment.
>> 
>> Testing: mach5 tier1-6
>> GHA testing in-progress
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update copyrights
>  - remove leftover <type_traits> include

Thank you for addressing the comments. Looks good to me!

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

Marked as reviewed by mhaessig (Author).

PR Review: https://git.openjdk.org/jdk/pull/25791#pullrequestreview-2938683405

From tschatzl at openjdk.org  Wed Jun 18 11:13:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 18 Jun 2025 11:13:28 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v2]
In-Reply-To: <gbcGZMbOZiml80mFn7PwGGx4nRt4ZH25l3hHprvtDfg=.2566acbd-8544-4735-804e-1391cf697cec@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <gbcGZMbOZiml80mFn7PwGGx4nRt4ZH25l3hHprvtDfg=.2566acbd-8544-4735-804e-1391cf697cec@github.com>
Message-ID: <PpMWvkRaGJMZf8u8bQMOcCc9fnyS571weyN8KQkrBHY=.82cd313e-3ede-4a61-af98-a3536998e829@github.com>

On Fri, 13 Jun 2025 18:46:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that makes the various code cache/heap size options
>> consistently be of type size_t.
>> 
>> The shared declarations for these options were all uintx. These options all
>> may have platform-defined values. Some of those platform-specific definitions
>> were uintx, some were size_t, and some were intx(!). This change makes them
>> all consistently size_t.
>> 
>> More details in the first comment.
>> 
>> Testing: mach5 tier1-6
>> GHA testing in-progress
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update copyrights
>  - remove leftover <type_traits> include

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25791#pullrequestreview-2938784260

From epeter at openjdk.org  Wed Jun 18 14:51:38 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Jun 2025 14:51:38 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
Message-ID: <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>

On Wed, 11 Jun 2025 16:18:41 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 Nice work!

I have a first set of qestions / suggestions :)

src/hotspot/share/opto/callnode.cpp line 1306:

> 1304: 
> 1305: //=============================================================================
> 1306: bool CallLeafPureNode::is_unused() const {

Can you add a quick comment why this check implies that the node is not used, i.e. what that means?

src/hotspot/share/opto/callnode.cpp line 1309:

> 1307:   return proj_out_or_null(TypeFunc::Parms) == nullptr;
> 1308: }
> 1309: // We make a tuple of the global input state + TOP for the output values.

Suggestion:

}

// We make a tuple of the global input state + TOP for the output values.

Nit: there should be a newline between the methods.

src/hotspot/share/opto/callnode.cpp line 1335:

> 1333:   if (can_reshape && is_unused()) {
> 1334:     return make_tuple_of_input_state_and_top_return_values(phase->C);
> 1335:   }

Can you add a code comment what this does?

src/hotspot/share/opto/compile.cpp line 3302:

> 3300:     break;
> 3301:   case Op_CallLeafPure: {
> 3302:     if (!Matcher::match_rule_supported(Op_CallLeafPure)) {

Suggestion:

    // If the pure call is not supported, then lower to a CallLeaf.
    if (!Matcher::match_rule_supported(Op_CallLeafPure)) {

src/hotspot/share/opto/compile.cpp line 3313:

> 3311:       for (unsigned int i = 0; i < call->tf()->domain()->cnt() - TypeFunc::Parms; i++) {
> 3312:         new_call->init_req(TypeFunc::Parms + i, call->in(TypeFunc::Parms + i));
> 3313:       }

The `TypeFunc::Parms` offsets are a bit confusing / unnecessary. Why not:
Suggestion:

      // Copy all <something>.
      for (unsigned int i = TypeFunc::Parms; i < call->tf()->domain()->cnt(); i++) {
        new_call->init_req(i, call->in(i));
      }

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

> 1521:     return nullptr;
> 1522:   }
> 1523:   if (proj_out_or_null(TypeFunc::Control) == nullptr) { // dead node

Interesting. You have extracted a method for `is_unused`, which you use multiple times. But you did not do it for this check which you also use multiple times. You could also wrap this in some method like `is_dead`.

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

> 1528: 
> 1529:   if (is_unused()) {
> 1530:     return make_tuple_of_input_state_and_top_return_values(igvn->C);

What does this do? Add a short comment :)

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

> 1640:   }
> 1641:   assert(projs.catchall_ioproj == nullptr, "no exceptions from floating mod");
> 1642:   assert(projs.catchall_catchproj == nullptr, "no exceptions from floating mod");

Why were you able to remove this?

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

> 1914:   if (call->is_CallLeafPure()) {
> 1915:     return;
> 1916:   }

Suggestion:

  if (call->is_CallLeafPure()) {
    // <your comment why you exit here>
    return;
  }

src/hotspot/share/opto/multnode.cpp line 126:

> 124:       // Jumping over Tuples: the i-th projection of a Tuple is the i-th input of the Tuple.
> 125:       ctrl = ctrl->in(_con);
> 126:     }

Do you need to special-case this here? Why does the `ProjNode::Identity` not suffice? Are there potentially other locations where we now would need this special logic?

src/hotspot/share/opto/multnode.cpp line 177:

> 175:   }
> 176:   return this;
> 177: }

What would happen if we miss to do this optimization? I suppose we would have a Tuple left in the graph and get a bad AD file assert / deopt in product?

src/hotspot/share/opto/multnode.hpp line 109:

> 107: };
> 108: 
> 109: //------------------------------TupleNode---------------------------------------

These lines are rather unnecessary. More useful would be a description of what this Tuple is, and what it is used for. Are there any invariants about it? When do we expect them to appear or disappear?

src/hotspot/share/opto/multnode.hpp line 113:

> 111:   const TypeTuple* _tf;
> 112: 
> 113:   template <typename... NN>

Does this need to be a template? Or would a type like `Node*` or `Node` suffice?

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25760#pullrequestreview-2938357614
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154786291
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154059786
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154386828
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154770330
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154767905
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154784765
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154788329
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154790934
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154795672
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154804710
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154806581
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154808639
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2154812833

From epeter at openjdk.org  Wed Jun 18 14:51:38 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Jun 2025 14:51:38 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
Message-ID: <pVlfH315MFbDNQ_JnVz6dOjVMDr0T-Wh_66w7Ei-2PI=.364233cc-2791-472a-a5f2-f29d7b89191f@github.com>

On Wed, 18 Jun 2025 09:00:06 GMT, Emanuel Peter <epeter 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
>
> src/hotspot/share/opto/callnode.cpp line 1309:
> 
>> 1307:   return proj_out_or_null(TypeFunc::Parms) == nullptr;
>> 1308: }
>> 1309: // We make a tuple of the global input state + TOP for the output values.
> 
> Suggestion:
> 
> }
> 
> // We make a tuple of the global input state + TOP for the output values.
> 
> Nit: there should be a newline between the methods.

Also: the comment says exactly what the method name says ... I'd suggest deleting the comment or writing something with additional information.

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

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

From epeter at openjdk.org  Wed Jun 18 14:51:39 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Jun 2025 14:51:39 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <pVlfH315MFbDNQ_JnVz6dOjVMDr0T-Wh_66w7Ei-2PI=.364233cc-2791-472a-a5f2-f29d7b89191f@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <pVlfH315MFbDNQ_JnVz6dOjVMDr0T-Wh_66w7Ei-2PI=.364233cc-2791-472a-a5f2-f29d7b89191f@github.com>
Message-ID: <i_KcWBZqMV20mWCiHZ9IfmhOIUFZ-njqIVl_zY60jPs=.1530c715-6465-4235-8729-417d228c7960@github.com>

On Wed, 18 Jun 2025 11:36:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/callnode.cpp line 1309:
>> 
>>> 1307:   return proj_out_or_null(TypeFunc::Parms) == nullptr;
>>> 1308: }
>>> 1309: // We make a tuple of the global input state + TOP for the output values.
>> 
>> Suggestion:
>> 
>> }
>> 
>> // We make a tuple of the global input state + TOP for the output values.
>> 
>> Nit: there should be a newline between the methods.
>
> Also: the comment says exactly what the method name says ... I'd suggest deleting the comment or writing something with additional information.

For example: why do you put TOP for the return values?

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

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

From kbarrett at openjdk.org  Wed Jun 18 15:52:09 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Jun 2025 15:52:09 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v3]
In-Reply-To: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
Message-ID: <zv97I_gVRJcM0tQznJHWUHo0nCrf15USShFVm0BYflI=.0146fa24-d930-4a06-9d82-d6116ee94294@github.com>

> Please review this change that makes the various code cache/heap size options
> consistently be of type size_t.
> 
> The shared declarations for these options were all uintx. These options all
> may have platform-defined values. Some of those platform-specific definitions
> were uintx, some were size_t, and some were intx(!). This change makes them
> all consistently size_t.
> 
> More details in the first comment.
> 
> Testing: mach5 tier1-6
> GHA testing in-progress

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into code-cache-sizes
 - update copyrights
 - remove leftover <type_traits> include
 - fix whitebox access to code cache size configs
 - VMPageSizeConstraintFunc
 - CodeCacheMinBlockLength
 - CodeCacheExpansionSize
 - various CodeHeapSize options
 - CodeCacheMinimumUseSpace
 - Initial/ReservedCodeCacheSize
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ba32b78b...78f1f7b9

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

Changes: https://git.openjdk.org/jdk/pull/25791/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25791&range=02
  Stats: 190 lines in 40 files changed: 1 ins; 0 del; 189 mod
  Patch: https://git.openjdk.org/jdk/pull/25791.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25791/head:pull/25791

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

From kbarrett at openjdk.org  Wed Jun 18 15:55:34 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Jun 2025 15:55:34 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v3]
In-Reply-To: <zv97I_gVRJcM0tQznJHWUHo0nCrf15USShFVm0BYflI=.0146fa24-d930-4a06-9d82-d6116ee94294@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <zv97I_gVRJcM0tQznJHWUHo0nCrf15USShFVm0BYflI=.0146fa24-d930-4a06-9d82-d6116ee94294@github.com>
Message-ID: <WVtzE71lVxoR3epXbOpR8tzTV0eT__3aCtHXMmVhdc8=.f9780ce9-3139-4a5e-8a9d-7aee434e754a@github.com>

On Wed, 18 Jun 2025 15:52:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that makes the various code cache/heap size options
>> consistently be of type size_t.
>> 
>> The shared declarations for these options were all uintx. These options all
>> may have platform-defined values. Some of those platform-specific definitions
>> were uintx, some were size_t, and some were intx(!). This change makes them
>> all consistently size_t.
>> 
>> More details in the first comment.
>> 
>> Testing: mach5 tier1-6
>> GHA testing in-progress
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into code-cache-sizes
>  - update copyrights
>  - remove leftover <type_traits> include
>  - fix whitebox access to code cache size configs
>  - VMPageSizeConstraintFunc
>  - CodeCacheMinBlockLength
>  - CodeCacheExpansionSize
>  - various CodeHeapSize options
>  - CodeCacheMinimumUseSpace
>  - Initial/ReservedCodeCacheSize
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/ba32b78b...78f1f7b9

Sigh, there are new merge conflicts after the one I just pushed a fix for.

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

PR Comment: https://git.openjdk.org/jdk/pull/25791#issuecomment-2984799914

From cslucas at openjdk.org  Wed Jun 18 16:46:34 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 18 Jun 2025 16:46:34 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <ZALJTptxBZ8LjoX9uSDrBeqzgVDqtVUIFgyiqzusLHQ=.300f87a5-bf00-4780-a100-72f318bbcd25@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
 <ZALJTptxBZ8LjoX9uSDrBeqzgVDqtVUIFgyiqzusLHQ=.300f87a5-bf00-4780-a100-72f318bbcd25@github.com>
Message-ID: <nsIQP_pmbAkgmFGmoQ1AW-uNQVq-q7sFwK5Z4-9irgI=.6869ce14-5730-4007-973f-1634eaad05de@github.com>

On Fri, 13 Jun 2025 20:05:20 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some remaining renames.
>
> Sorry for the confusion on my part.  The lack of a PR that's consuming these changes makes it harder to know which parts are the important ones.

@tkrodriguez , @dougxc - are you OK with the latest changes I pushed?

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2984979703

From dnsimon at openjdk.org  Wed Jun 18 16:56:36 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 18 Jun 2025 16:56:36 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v7]
In-Reply-To: <QVRh-FmctAK7ru7bGdrv8PanHGHyfB3ce52rsCDUnhs=.937be914-93c5-4c60-8e3d-3533ee14be4b@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <QVRh-FmctAK7ru7bGdrv8PanHGHyfB3ce52rsCDUnhs=.937be914-93c5-4c60-8e3d-3533ee14be4b@github.com>
Message-ID: <CBG1yKEJJn4VVsg4CELmAR5e7hJvrG1KE6RqkLB4hSc=.5ceb74dd-f1ff-498e-8450-ea150197cb3e@github.com>

On Mon, 16 Jun 2025 22:22:48 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent overriding invalidation reason.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1408:

> 1406: 
> 1407: C2V_VMENTRY(void, invalidateHotSpotNmethod, (JNIEnv* env, jobject, jobject hs_nmethod, jboolean deoptimize, jint invalidation_reason))
> 1408: #ifdef ASSERT

We prefer runtime checks and throwing Java exceptions than assertions in this JVMCI code:

  int first = static_cast<int>(nmethod::InvalidationReason::UNKNOWN);
  int last = static_cast<int>(nmethod::InvalidationReason::LAST_REASON);
  if (invalidation_reason < first || invalidation_reason >= last) {
    JVMCI_THROW_MSG(IllegalArgumentException, err_msg("Invalid invalidation_reason: %d", invalidation_reason ));
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2155092025

From dnsimon at openjdk.org  Wed Jun 18 16:59:33 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 18 Jun 2025 16:59:33 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v8]
In-Reply-To: <XwVqrxQIB-hOVlDGS2Fh-_O_UjKr9v87-pCD5-MYqEM=.d170124c-35c0-421f-abb4-7ff01d83d4f0@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <XwVqrxQIB-hOVlDGS2Fh-_O_UjKr9v87-pCD5-MYqEM=.d170124c-35c0-421f-abb4-7ff01d83d4f0@github.com>
Message-ID: <NHtrOhfi_0_9EOKoXjbKtTsaq3CmQGZI_vruRq_bnIw=.8209eca3-eed3-478b-a7c7-01527a558b10@github.com>

On Tue, 17 Jun 2025 00:39:54 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra space

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25706#pullrequestreview-2940038030

From dnsimon at openjdk.org  Wed Jun 18 16:59:34 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 18 Jun 2025 16:59:34 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <ZALJTptxBZ8LjoX9uSDrBeqzgVDqtVUIFgyiqzusLHQ=.300f87a5-bf00-4780-a100-72f318bbcd25@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
 <ZALJTptxBZ8LjoX9uSDrBeqzgVDqtVUIFgyiqzusLHQ=.300f87a5-bf00-4780-a100-72f318bbcd25@github.com>
Message-ID: <QULvEKu3VgsLbYygeMMHxRMMGN4LAY4cLrr5kYFOYIY=.c93183b5-46bc-4f8a-ab90-49b8081018d3@github.com>

On Fri, 13 Jun 2025 20:05:20 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some remaining renames.
>
> Sorry for the confusion on my part.  The lack of a PR that's consuming these changes makes it harder to know which parts are the important ones.

> @tkrodriguez , @dougxc - are you OK with the latest changes I pushed?

Modulo the comment I just made, these changes now look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2985042984

From kbarrett at openjdk.org  Wed Jun 18 17:05:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Jun 2025 17:05:48 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v4]
In-Reply-To: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
Message-ID: <1TwILxUixcdyTvD3KiI_tZwLiFAVHknRWlab7zxntxE=.0c1fad26-0980-43fc-9125-de686a9ad196@github.com>

> Please review this change that makes the various code cache/heap size options
> consistently be of type size_t.
> 
> The shared declarations for these options were all uintx. These options all
> may have platform-defined values. Some of those platform-specific definitions
> were uintx, some were size_t, and some were intx(!). This change makes them
> all consistently size_t.
> 
> More details in the first comment.
> 
> Testing: mach5 tier1-6
> GHA testing in-progress

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into code-cache-sizes
 - Merge branch 'master' into code-cache-sizes
 - update copyrights
 - remove leftover <type_traits> include
 - fix whitebox access to code cache size configs
 - VMPageSizeConstraintFunc
 - CodeCacheMinBlockLength
 - CodeCacheExpansionSize
 - various CodeHeapSize options
 - CodeCacheMinimumUseSpace
 - ... and 2 more: https://git.openjdk.org/jdk/compare/984d7f9c...56471cc9

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

Changes: https://git.openjdk.org/jdk/pull/25791/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25791&range=03
  Stats: 190 lines in 40 files changed: 1 ins; 0 del; 189 mod
  Patch: https://git.openjdk.org/jdk/pull/25791.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25791/head:pull/25791

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

From kbarrett at openjdk.org  Wed Jun 18 17:05:49 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Jun 2025 17:05:49 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v3]
In-Reply-To: <zv97I_gVRJcM0tQznJHWUHo0nCrf15USShFVm0BYflI=.0146fa24-d930-4a06-9d82-d6116ee94294@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <zv97I_gVRJcM0tQznJHWUHo0nCrf15USShFVm0BYflI=.0146fa24-d930-4a06-9d82-d6116ee94294@github.com>
Message-ID: <1Xar9J1Key5fMJQYreKsIGnifrHsiXdCRN8p4SyLE60=.8c7accda-34c5-424d-9b75-16f0538e95c5@github.com>

On Wed, 18 Jun 2025 15:52:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that makes the various code cache/heap size options
>> consistently be of type size_t.
>> 
>> The shared declarations for these options were all uintx. These options all
>> may have platform-defined values. Some of those platform-specific definitions
>> were uintx, some were size_t, and some were intx(!). This change makes them
>> all consistently size_t.
>> 
>> More details in the first comment.
>> 
>> Testing: mach5 tier1-6
>> GHA testing in-progress
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into code-cache-sizes
>  - update copyrights
>  - remove leftover <type_traits> include
>  - fix whitebox access to code cache size configs
>  - VMPageSizeConstraintFunc
>  - CodeCacheMinBlockLength
>  - CodeCacheExpansionSize
>  - various CodeHeapSize options
>  - CodeCacheMinimumUseSpace
>  - Initial/ReservedCodeCacheSize
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/ba32b78b...78f1f7b9

Sorry to request re-review, but there was a merge conflict, which I fixed, and
then another merge conflict appeared while I was testing that one.  Sigh :(

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

PR Comment: https://git.openjdk.org/jdk/pull/25791#issuecomment-2985056595

From never at openjdk.org  Wed Jun 18 17:11:31 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 18 Jun 2025 17:11:31 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v8]
In-Reply-To: <XwVqrxQIB-hOVlDGS2Fh-_O_UjKr9v87-pCD5-MYqEM=.d170124c-35c0-421f-abb4-7ff01d83d4f0@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <XwVqrxQIB-hOVlDGS2Fh-_O_UjKr9v87-pCD5-MYqEM=.d170124c-35c0-421f-abb4-7ff01d83d4f0@github.com>
Message-ID: <lR4rQX3QL6halvVCNoocrX6yQkPIgZGLqH4_icz59WM=.63c397d4-b97d-48f3-91fb-ec03654487c3@github.com>

On Tue, 17 Jun 2025 00:39:54 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra space

src/hotspot/share/code/nmethod.hpp line 500:

> 498:     WHITEBOX_DEOPTIMIZATION,
> 499:     ZOMBIE,
> 500:     LAST_REASON

This isn't really the last reason, since it's not actually a reason.  So either `LAST_REASON = ZOMBIE` with adjustments to the range check or maybe `REASON_COUNT`?  Why do we need `UNKNOWN` since it seems unused?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2155117063

From tschatzl at openjdk.org  Wed Jun 18 17:25:32 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 18 Jun 2025 17:25:32 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v4]
In-Reply-To: <1TwILxUixcdyTvD3KiI_tZwLiFAVHknRWlab7zxntxE=.0c1fad26-0980-43fc-9125-de686a9ad196@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <1TwILxUixcdyTvD3KiI_tZwLiFAVHknRWlab7zxntxE=.0c1fad26-0980-43fc-9125-de686a9ad196@github.com>
Message-ID: <73djG5ff1jz5aqEiJ-LuYcpdUrpUJIbG0KEU6bEg4XE=.3816144f-12ca-4ca0-ad63-57dd1de84188@github.com>

On Wed, 18 Jun 2025 17:05:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that makes the various code cache/heap size options
>> consistently be of type size_t.
>> 
>> The shared declarations for these options were all uintx. These options all
>> may have platform-defined values. Some of those platform-specific definitions
>> were uintx, some were size_t, and some were intx(!). This change makes them
>> all consistently size_t.
>> 
>> More details in the first comment.
>> 
>> Testing: mach5 tier1-6
>> GHA testing in-progress
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into code-cache-sizes
>  - Merge branch 'master' into code-cache-sizes
>  - update copyrights
>  - remove leftover <type_traits> include
>  - fix whitebox access to code cache size configs
>  - VMPageSizeConstraintFunc
>  - CodeCacheMinBlockLength
>  - CodeCacheExpansionSize
>  - various CodeHeapSize options
>  - CodeCacheMinimumUseSpace
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/984d7f9c...56471cc9

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25791#pullrequestreview-2940105073

From mhaessig at openjdk.org  Wed Jun 18 17:31:30 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 18 Jun 2025 17:31:30 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v4]
In-Reply-To: <1TwILxUixcdyTvD3KiI_tZwLiFAVHknRWlab7zxntxE=.0c1fad26-0980-43fc-9125-de686a9ad196@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <1TwILxUixcdyTvD3KiI_tZwLiFAVHknRWlab7zxntxE=.0c1fad26-0980-43fc-9125-de686a9ad196@github.com>
Message-ID: <2t4FoYTdMjLMiVoacfLjNtgyBdPw7SxPNiDfSakE-OA=.c89fe100-8516-4928-894a-15abdbbea2d0@github.com>

On Wed, 18 Jun 2025 17:05:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that makes the various code cache/heap size options
>> consistently be of type size_t.
>> 
>> The shared declarations for these options were all uintx. These options all
>> may have platform-defined values. Some of those platform-specific definitions
>> were uintx, some were size_t, and some were intx(!). This change makes them
>> all consistently size_t.
>> 
>> More details in the first comment.
>> 
>> Testing: mach5 tier1-6
>> GHA testing in-progress
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into code-cache-sizes
>  - Merge branch 'master' into code-cache-sizes
>  - update copyrights
>  - remove leftover <type_traits> include
>  - fix whitebox access to code cache size configs
>  - VMPageSizeConstraintFunc
>  - CodeCacheMinBlockLength
>  - CodeCacheExpansionSize
>  - various CodeHeapSize options
>  - CodeCacheMinimumUseSpace
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/984d7f9c...56471cc9

Marked as reviewed by mhaessig (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/25791#pullrequestreview-2940118176

From cslucas at openjdk.org  Wed Jun 18 17:32:31 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 18 Jun 2025 17:32:31 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v8]
In-Reply-To: <lR4rQX3QL6halvVCNoocrX6yQkPIgZGLqH4_icz59WM=.63c397d4-b97d-48f3-91fb-ec03654487c3@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <XwVqrxQIB-hOVlDGS2Fh-_O_UjKr9v87-pCD5-MYqEM=.d170124c-35c0-421f-abb4-7ff01d83d4f0@github.com>
 <lR4rQX3QL6halvVCNoocrX6yQkPIgZGLqH4_icz59WM=.63c397d4-b97d-48f3-91fb-ec03654487c3@github.com>
Message-ID: <0A26Svhs-4CaN398WfEGErGcuMuABx1u3p1fpN7sEM8=.48068df8-1da3-4d9c-93e5-3b5197f7407b@github.com>

On Wed, 18 Jun 2025 17:09:12 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extra space
>
> src/hotspot/share/code/nmethod.hpp line 500:
> 
>> 498:     WHITEBOX_DEOPTIMIZATION,
>> 499:     ZOMBIE,
>> 500:     LAST_REASON
> 
> This isn't really the last reason, since it's not actually a reason.  So either `LAST_REASON = ZOMBIE` with adjustments to the range check or maybe `REASON_COUNT`?  Why do we need `UNKNOWN` since it seems unused?

I'll looked other enums in HotSpot and there was a mixed of `*_COUNT`, `LAST_*`, etc. I opted to use `LAST_*` for no particular 'reason'. I'll change to `REASON_COUNT` as you suggest.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2155150431

From cslucas at openjdk.org  Wed Jun 18 17:32:32 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 18 Jun 2025 17:32:32 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v7]
In-Reply-To: <CBG1yKEJJn4VVsg4CELmAR5e7hJvrG1KE6RqkLB4hSc=.5ceb74dd-f1ff-498e-8450-ea150197cb3e@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <QVRh-FmctAK7ru7bGdrv8PanHGHyfB3ce52rsCDUnhs=.937be914-93c5-4c60-8e3d-3533ee14be4b@github.com>
 <CBG1yKEJJn4VVsg4CELmAR5e7hJvrG1KE6RqkLB4hSc=.5ceb74dd-f1ff-498e-8450-ea150197cb3e@github.com>
Message-ID: <_qRG1S3LrM0U6mN9wNbHBPPiQTcy2i7BWwaxerbeOx8=.40b2352c-5844-41f9-a03c-3cb095cedc1b@github.com>

On Wed, 18 Jun 2025 16:53:51 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prevent overriding invalidation reason.
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1408:
> 
>> 1406: 
>> 1407: C2V_VMENTRY(void, invalidateHotSpotNmethod, (JNIEnv* env, jobject, jobject hs_nmethod, jboolean deoptimize, jint invalidation_reason))
>> 1408: #ifdef ASSERT
> 
> We prefer runtime checks and throwing Java exceptions than assertions in this JVMCI code:
> 
>   int first = static_cast<int>(nmethod::InvalidationReason::UNKNOWN);
>   int last = static_cast<int>(nmethod::InvalidationReason::LAST_REASON);
>   if (invalidation_reason < first || invalidation_reason >= last) {
>     JVMCI_THROW_MSG(IllegalArgumentException, err_msg("Invalid invalidation_reason: %d", invalidation_reason ));
>   }

Got it. I'll patch the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2155147173

From never at openjdk.org  Wed Jun 18 18:03:37 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 18 Jun 2025 18:03:37 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v8]
In-Reply-To: <0A26Svhs-4CaN398WfEGErGcuMuABx1u3p1fpN7sEM8=.48068df8-1da3-4d9c-93e5-3b5197f7407b@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <XwVqrxQIB-hOVlDGS2Fh-_O_UjKr9v87-pCD5-MYqEM=.d170124c-35c0-421f-abb4-7ff01d83d4f0@github.com>
 <lR4rQX3QL6halvVCNoocrX6yQkPIgZGLqH4_icz59WM=.63c397d4-b97d-48f3-91fb-ec03654487c3@github.com>
 <0A26Svhs-4CaN398WfEGErGcuMuABx1u3p1fpN7sEM8=.48068df8-1da3-4d9c-93e5-3b5197f7407b@github.com>
Message-ID: <Ewp_8uPgqf_2mGRntruNxyWHMeEjaaYSX3jdt4nn4vg=.82fb68de-1526-4626-b41c-d50763d6cbe1@github.com>

On Wed, 18 Jun 2025 17:29:45 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.hpp line 500:
>> 
>>> 498:     WHITEBOX_DEOPTIMIZATION,
>>> 499:     ZOMBIE,
>>> 500:     LAST_REASON
>> 
>> This isn't really the last reason, since it's not actually a reason.  So either `LAST_REASON = ZOMBIE` with adjustments to the range check or maybe `REASON_COUNT`?  Why do we need `UNKNOWN` since it seems unused?
>
> I'll looked other enums in HotSpot and there was a mixed of `*_COUNT`, `LAST_*`, etc. I opted to use `LAST_*` for no particular 'reason'. I'll change to `REASON_COUNT` as you suggest.

Yes it's kind of a messy mix of idioms.  The first/last pattern is usually for aliases for other values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2155199944

From kbarrett at openjdk.org  Wed Jun 18 18:08:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Jun 2025 18:08:38 GMT
Subject: Integrated: 8359227: Code cache/heap size options should be size_t
In-Reply-To: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
Message-ID: <ka_FeMUU7bgckssEDyuOaXiCcsLFM7ckF4xCTUSz6Ro=.50f72dfc-4c02-44cd-8025-0aad08c37d3d@github.com>

On Fri, 13 Jun 2025 06:57:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that makes the various code cache/heap size options
> consistently be of type size_t.
> 
> The shared declarations for these options were all uintx. These options all
> may have platform-defined values. Some of those platform-specific definitions
> were uintx, some were size_t, and some were intx(!). This change makes them
> all consistently size_t.
> 
> More details in the first comment.
> 
> Testing: mach5 tier1-6
> GHA testing in-progress

This pull request has now been integrated.

Changeset: 7bc0d824
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7bc0d82450e210b14c9f89687582d78a0a50ee54
Stats:     190 lines in 40 files changed: 1 ins; 0 del; 189 mod

8359227: Code cache/heap size options should be size_t

Reviewed-by: mhaessig, tschatzl

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

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

From kbarrett at openjdk.org  Wed Jun 18 18:08:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Jun 2025 18:08:38 GMT
Subject: RFR: 8359227: Code cache/heap size options should be size_t [v4]
In-Reply-To: <2t4FoYTdMjLMiVoacfLjNtgyBdPw7SxPNiDfSakE-OA=.c89fe100-8516-4928-894a-15abdbbea2d0@github.com>
References: <gMQvFzJfAomN1dm7CJn11dmYETSaxLr1ff1BYQ5bD4g=.6619c281-97d0-49a4-9d20-e97d73d9e635@github.com>
 <1TwILxUixcdyTvD3KiI_tZwLiFAVHknRWlab7zxntxE=.0c1fad26-0980-43fc-9125-de686a9ad196@github.com>
 <2t4FoYTdMjLMiVoacfLjNtgyBdPw7SxPNiDfSakE-OA=.c89fe100-8516-4928-894a-15abdbbea2d0@github.com>
Message-ID: <_xv1ASkK38AMhxbRvFFOUUDMQa_nDUB3_pr8GMBq2Jc=.6ca5ef0f-fd83-4d05-83eb-dd8be2ca41a4@github.com>

On Wed, 18 Jun 2025 17:28:31 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge branch 'master' into code-cache-sizes
>>  - Merge branch 'master' into code-cache-sizes
>>  - update copyrights
>>  - remove leftover <type_traits> include
>>  - fix whitebox access to code cache size configs
>>  - VMPageSizeConstraintFunc
>>  - CodeCacheMinBlockLength
>>  - CodeCacheExpansionSize
>>  - various CodeHeapSize options
>>  - CodeCacheMinimumUseSpace
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/984d7f9c...56471cc9
>
> Marked as reviewed by mhaessig (Author).

Thanks for reviews @mhaessig and @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/25791#issuecomment-2985241813

From never at openjdk.org  Wed Jun 18 20:20:34 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 18 Jun 2025 20:20:34 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v8]
In-Reply-To: <XwVqrxQIB-hOVlDGS2Fh-_O_UjKr9v87-pCD5-MYqEM=.d170124c-35c0-421f-abb4-7ff01d83d4f0@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <XwVqrxQIB-hOVlDGS2Fh-_O_UjKr9v87-pCD5-MYqEM=.d170124c-35c0-421f-abb4-7ff01d83d4f0@github.com>
Message-ID: <TAUdsTi_OvbdeYSqfVFeeZJ7n3RyT2yATZWUwbsdlk0=.d377cec0-2ae3-4a7d-bd95-71a1abe5bc02@github.com>

On Tue, 17 Jun 2025 00:39:54 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra space

Module my comments about the enum it looks good to me.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25706#pullrequestreview-2940549880

From cslucas at openjdk.org  Wed Jun 18 21:14:22 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 18 Jun 2025 21:14:22 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v9]
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <JrPkCvO3lLDLYI_gBzm8ai0JbdPSr5DTKiefT8oODos=.4ea02662-ef6a-43e2-9741-c9d387aaa01d@github.com>

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Rename last invalidation placeholder.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25706/files
  - new: https://git.openjdk.org/jdk/pull/25706/files/68271c7a..fcfa0730

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

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

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

From dnsimon at openjdk.org  Thu Jun 19 07:54:38 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 19 Jun 2025 07:54:38 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v9]
In-Reply-To: <JrPkCvO3lLDLYI_gBzm8ai0JbdPSr5DTKiefT8oODos=.4ea02662-ef6a-43e2-9741-c9d387aaa01d@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <JrPkCvO3lLDLYI_gBzm8ai0JbdPSr5DTKiefT8oODos=.4ea02662-ef6a-43e2-9741-c9d387aaa01d@github.com>
Message-ID: <ar7rlIa6ZXjqyoCgufZAmWTIjZ8yPBXcQBeu812xtM4=.1e8da98d-d309-4e37-87e4-42264d673b32@github.com>

On Wed, 18 Jun 2025 21:14:22 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename last invalidation placeholder.

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25706#pullrequestreview-2941973799

From never at openjdk.org  Thu Jun 19 15:48:31 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 19 Jun 2025 15:48:31 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v9]
In-Reply-To: <JrPkCvO3lLDLYI_gBzm8ai0JbdPSr5DTKiefT8oODos=.4ea02662-ef6a-43e2-9741-c9d387aaa01d@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <JrPkCvO3lLDLYI_gBzm8ai0JbdPSr5DTKiefT8oODos=.4ea02662-ef6a-43e2-9741-c9d387aaa01d@github.com>
Message-ID: <kMj3flOXxMaL-75WxuP1msHk-df35Qa0IxlvdDxZEls=.465293ad-3916-437e-8558-5a076014f74f@github.com>

On Wed, 18 Jun 2025 21:14:22 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename last invalidation placeholder.

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25706#pullrequestreview-2943496440

From cslucas at openjdk.org  Thu Jun 19 18:05:36 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 19 Jun 2025 18:05:36 GMT
Subject: Integrated: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client
In-Reply-To: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
Message-ID: <-FhUFx2PeaAm7XTgKRj_GXQ82kzfhV2e4FvtRT3mP-s=.220619a8-7730-41b6-b156-242f81243720@github.com>

On Mon, 9 Jun 2025 23:57:46 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
> 
> This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as `not entrant`. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this [RFE in Truffle](https://github.com/oracle/graal/issues/11045
> ). 
> 
> Tested on Linux x86_64, ARM with JTREG tier 1-3.

This pull request has now been integrated.

Changeset: 2fe12984
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2fe12984474656a08c4525c04a351d85be73f658
Stats:     278 lines in 25 files changed: 177 ins; 7 del; 94 mod

8359064: Expose reason for marking nmethod non-entrant to JVMCI client

Reviewed-by: dnsimon, never

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

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

From dholmes at openjdk.org  Thu Jun 19 22:39:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jun 2025 22:39:35 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <nsIQP_pmbAkgmFGmoQ1AW-uNQVq-q7sFwK5Z4-9irgI=.6869ce14-5730-4007-973f-1634eaad05de@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
 <ZALJTptxBZ8LjoX9uSDrBeqzgVDqtVUIFgyiqzusLHQ=.300f87a5-bf00-4780-a100-72f318bbcd25@github.com>
 <nsIQP_pmbAkgmFGmoQ1AW-uNQVq-q7sFwK5Z4-9irgI=.6869ce14-5730-4007-973f-1634eaad05de@github.com>
Message-ID: <59wcJYQHvtQ3VI6fJWRjzxNirtxQuGgEACFVr2lJrYw=.1066c5fd-8c62-4bf3-ab0c-48b962994df0@github.com>

On Wed, 18 Jun 2025 16:44:13 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Sorry for the confusion on my part.  The lack of a PR that's consuming these changes makes it harder to know which parts are the important ones.
>
> @tkrodriguez , @dougxc - are you OK with the latest changes I pushed?

@JohnTortugo the new test is failing in our CI - please see https://bugs.openjdk.org/browse/JDK-8360049

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2989277745

From mchevalier at openjdk.org  Fri Jun 20 07:40:28 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 20 Jun 2025 07:40:28 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
Message-ID: <wJrnPQShUnKJ3CIXMabkRzp8opdM9pTRUlDrw05o8cY=.0c0625ab-6477-4077-9dd9-fc1483b72d32@github.com>

On Wed, 18 Jun 2025 11:42:05 GMT, Emanuel Peter <epeter 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
>
> src/hotspot/share/opto/callnode.cpp line 1335:
> 
>> 1333:   if (can_reshape && is_unused()) {
>> 1334:     return make_tuple_of_input_state_and_top_return_values(phase->C);
>> 1335:   }
> 
> Can you add a code comment what this does?

It's better commented at the definition of `make_tuple_of_input_state_and_top_return_values` now. Let's not bloat the each call site with the same wall of text again.

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

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

From mchevalier at openjdk.org  Fri Jun 20 07:48:27 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 20 Jun 2025 07:48:27 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
Message-ID: <Un4ihnAeqh6yjS6JH3LkdKBvTtw_TxZJM6CLT2CaJR0=.e74e02fd-d524-41de-8f28-7837a652e57e@github.com>

On Wed, 18 Jun 2025 14:38:07 GMT, Emanuel Peter <epeter 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
>
> src/hotspot/share/opto/callnode.cpp line 1306:
> 
>> 1304: 
>> 1305: //=============================================================================
>> 1306: bool CallLeafPureNode::is_unused() const {
> 
> Can you add a quick comment why this check implies that the node is not used, i.e. what that means?

I think i'll need you to explain to me what is unclear at the moment. When I read the function, I see:
"A CallLeafPure is unused iff there is no output result projection."

I don't see what else to add that is not covered by "if we don't use the result, the pure call is unused", which is exactly the code. Is there any untold hypothesis lurking somewhere that I don't see? It seems to me it uses just very common concepts of C2.

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

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

From mchevalier at openjdk.org  Fri Jun 20 07:53:30 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 20 Jun 2025 07:53:30 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
Message-ID: <unTZCf5FBCMOiK3hMUxhiSLrsHjWzcU8_5yNvDQFMIw=.5c04ee79-4ce4-488b-8549-6588d30889b5@github.com>

On Wed, 18 Jun 2025 14:40:07 GMT, Emanuel Peter <epeter 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
>
> src/hotspot/share/opto/divnode.cpp line 1642:
> 
>> 1640:   }
>> 1641:   assert(projs.catchall_ioproj == nullptr, "no exceptions from floating mod");
>> 1642:   assert(projs.catchall_catchproj == nullptr, "no exceptions from floating mod");
> 
> Why were you able to remove this?

Pure functions have only control input, data inputs (1 or 2 in practice, so far), control output and data output: they can't alter the memory, they can't throw etc since they are pure. All these output were already unnecessary (which I noticed when working on removing modulo a few months ago), and are now simply not present, so the rewiring is useless.

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

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

From mchevalier at openjdk.org  Fri Jun 20 07:57:34 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 20 Jun 2025 07:57:34 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
In-Reply-To: <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
Message-ID: <5ic5YfZ-YLE0Xl0RaB2ON64eY8JE8uZ0Qqfach6DHII=.d0d86f8c-7aa7-435d-866a-f7b1c8efbbd0@github.com>

On Wed, 18 Jun 2025 14:45:14 GMT, Emanuel Peter <epeter 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
>
> src/hotspot/share/opto/multnode.cpp line 177:
> 
>> 175:   }
>> 176:   return this;
>> 177: }
> 
> What would happen if we miss to do this optimization? I suppose we would have a Tuple left in the graph and get a bad AD file assert / deopt in product?

Exactly. Bad AD file. I don't think it's possible at the moment because when we return a tuple node during IGVN instead of a call, the user (all projections) are added to the worklist and they will all skip the tuple. As used for now, a Tuple should appear and disappear in the same IGVN.

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

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

From mchevalier at openjdk.org  Fri Jun 20 08:16:11 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 20 Jun 2025 08:16:11 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
Message-ID: <DKGEzb3d3sEt1PgrKM7n9aHn6s_oAh1k9QC-7XHm8aM=.dbd0f2b4-9621-4a3b-97b7-8b22c0fd24a9@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:

  Mostly comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25760/files
  - new: https://git.openjdk.org/jdk/pull/25760/files/ff0a6b6a..34fd5e9a

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

  Stats: 43 lines in 6 files changed: 36 ins; 0 del; 7 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  Fri Jun 20 08:16:11 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 20 Jun 2025 08:16:11 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
Message-ID: <2BVVfe4S925G10VAJBu7KV_Y87aPxByXyfl5AxVJU8o=.5df2a49c-d9dd-4010-b0bc-283698e9e1ec@github.com>

On Wed, 18 Jun 2025 14:30:53 GMT, Emanuel Peter <epeter 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/compile.cpp line 3313:
> 
>> 3311:       for (unsigned int i = 0; i < call->tf()->domain()->cnt() - TypeFunc::Parms; i++) {
>> 3312:         new_call->init_req(TypeFunc::Parms + i, call->in(TypeFunc::Parms + i));
>> 3313:       }
> 
> The `TypeFunc::Parms` offsets are a bit confusing / unnecessary. Why not:
> Suggestion:
> 
>       // Copy all <something>.
>       for (unsigned int i = TypeFunc::Parms; i < call->tf()->domain()->cnt(); i++) {
>         new_call->init_req(i, call->in(i));
>       }

Fine with me! Looks perfectly identical to me. Comment seems superfluous to me: the code is very simple, let's not distract the reader.

> src/hotspot/share/opto/divnode.cpp line 1530:
> 
>> 1528: 
>> 1529:   if (is_unused()) {
>> 1530:     return make_tuple_of_input_state_and_top_return_values(igvn->C);
> 
> What does this do? Add a short comment :)

Same as above: better commented on definition than bloating every single callsite of a function. If I wonder, I go see the definition, if I don't, I don't have useless stuff on my screen.

> src/hotspot/share/opto/multnode.hpp line 113:
> 
>> 111:   const TypeTuple* _tf;
>> 112: 
>> 113:   template <typename... NN>
> 
> Does this need to be a template? Or would a type like `Node*` or `Node` suffice?

The point is that it's a variadic template. Of course, ideally, I'd like it to be a pack of `Node*` but there isn't a simple way to write that. The upside is that one can write `TupleNode::make(some_type, input1, input2, input3, input4)` with how many input you want in a single construction. I prefer hiding the not nice here, to have compact and readable usages of TupleNode, rather than having every usage look like

TupleNode* tuple = new TupleNode(some_type);
tuple.set_req(0, input1);
tuple.set_req(1, input2);
tuple.set_req(2, input3);
tuple.set_req(3, input4);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2158312752
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2158313274
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2158310606

From mhaessig at openjdk.org  Fri Jun 20 08:22:03 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 20 Jun 2025 08:22:03 GMT
Subject: RFR: 8355276: Sort C2 includes
Message-ID: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>

This PR sorts the includes in `hotspot/share/opto` using `test/hotspot/jtreg/sources/SortIncludes.java` and enforces sorted includes for C2 sources in `sources/TestIncludesAreSorted.java`.

Testing:
 - [ ] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15773777177)
 - [ ] tier1,tier2 plus Oracle internal testing on Oracle supported platforms

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

Commit messages:
 - Enforce sorted includes in hotspot/share/opto
 - Sort includes in C2 sources

Changes: https://git.openjdk.org/jdk/pull/25910/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25910&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355276
  Stats: 119 lines in 40 files changed: 57 ins; 55 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25910.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25910/head:pull/25910

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

From dnsimon at openjdk.org  Fri Jun 20 08:58:37 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 20 Jun 2025 08:58:37 GMT
Subject: RFR: 8359064: Expose reason for marking nmethod non-entrant to
 JVMCI client [v6]
In-Reply-To: <nsIQP_pmbAkgmFGmoQ1AW-uNQVq-q7sFwK5Z4-9irgI=.6869ce14-5730-4007-973f-1634eaad05de@github.com>
References: <vQJPGvnHFqxc0CQDkvVaA3Tou5QTPVpNrdgmqZsoNIU=.4eddf36b-f137-42e1-8db1-29c0918cefe7@github.com>
 <zPYqJ5OpYGyiPfYtePEFUs0YMu89w4U_wSTnqZ2NyaQ=.6f0f630f-cc35-477d-801c-225f1c5c25e7@github.com>
 <ZALJTptxBZ8LjoX9uSDrBeqzgVDqtVUIFgyiqzusLHQ=.300f87a5-bf00-4780-a100-72f318bbcd25@github.com>
 <nsIQP_pmbAkgmFGmoQ1AW-uNQVq-q7sFwK5Z4-9irgI=.6869ce14-5730-4007-973f-1634eaad05de@github.com>
Message-ID: <cDh1o0sm8cNXBIYCW--d70DHeyj9U7l5mY-Sy11PSS4=.687098b8-da0e-47eb-891c-944089d27d8b@github.com>

On Wed, 18 Jun 2025 16:44:13 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Sorry for the confusion on my part.  The lack of a PR that's consuming these changes makes it harder to know which parts are the important ones.
>
> @tkrodriguez , @dougxc - are you OK with the latest changes I pushed?

> @JohnTortugo the new test is failing in our CI - please see https://bugs.openjdk.org/browse/JDK-8360049

It is being fixed by https://github.com/openjdk/jdk/pull/25911. This is my fault for not having run the internal CI on this change before approving.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2990336864

From shade at openjdk.org  Fri Jun 20 09:02:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 20 Jun 2025 09:02:35 GMT
Subject: RFR: 8355276: Sort C2 includes
In-Reply-To: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
References: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
Message-ID: <Oq8FhXICvzY-yfVWZ1RamrtcM6X1ZNzmYZIhw7akI4k=.0e135e50-447f-47c3-896e-5967ed01f4ff@github.com>

On Fri, 20 Jun 2025 08:17:24 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/opto` using `test/hotspot/jtreg/sources/SortIncludes.java` and enforces sorted includes for C2 sources in `sources/TestIncludesAreSorted.java`.
> 
> Testing:
>  - [ ] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15773777177)
>  - [ ] tier1,tier2 plus Oracle internal testing on Oracle supported platforms

Oh, great, Windows GHA is apparently failing out with MSVC `14.43` and new runner image. I guess there is no choice but to switch to `14.44` now :) https://github.com/openjdk/jdk/pull/25912. Wait until GHA is stable again, so to check that MSVC accepts the include order correctly?

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

PR Comment: https://git.openjdk.org/jdk/pull/25910#issuecomment-2990352921

From mhaessig at openjdk.org  Fri Jun 20 09:24:27 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 20 Jun 2025 09:24:27 GMT
Subject: RFR: 8355276: Sort C2 includes
In-Reply-To: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
References: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
Message-ID: <6H_d8i7V8XogoQzHuA-8V_K2loXUR7YRfYLkNu2jsuA=.0c2f7df8-ff01-4ac8-9137-e4fd025400a9@github.com>

On Fri, 20 Jun 2025 08:17:24 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/opto` using `test/hotspot/jtreg/sources/SortIncludes.java` and enforces sorted includes for C2 sources in `sources/TestIncludesAreSorted.java`.
> 
> Testing:
>  - [ ] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15773777177)
>  - [x] tier1,tier2 plus Oracle internal testing on Oracle supported platforms

On our internal testing, Windows built and tested fine. I just kicked GHA to rerun the failed Windows builds, which fixed the problem for other runs yesterday.

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

PR Comment: https://git.openjdk.org/jdk/pull/25910#issuecomment-2990444473

From mchevalier at openjdk.org  Fri Jun 20 12:03:32 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 20 Jun 2025 12:03:32 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
Message-ID: <sZY0SthfHG6CKDnVCUGCopgp9wSaSuo160mFjKGdODY=.77417f21-e447-4e40-8c9a-d6d3f5d73635@github.com>

On Wed, 18 Jun 2025 14:44:26 GMT, Emanuel Peter <epeter 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/multnode.cpp line 126:
> 
>> 124:       // Jumping over Tuples: the i-th projection of a Tuple is the i-th input of the Tuple.
>> 125:       ctrl = ctrl->in(_con);
>> 126:     }
> 
> Do you need to special-case this here? Why does the `ProjNode::Identity` not suffice? Are there potentially other locations where we now would need this special logic?

That is a good question. That is something I picked from Vladimir's implementation and it seemed legitimate. But now you say it, is it needed? Not sure. I'm trying to find that out. Would `::Identity` be enough? It's tempting to say so, right! I'd say it can be not enough if we need `adr_type` before idealizing the `ProjNode` (no idea if that happens). Is there any other places to adapt? One could think so, but actually, I can't find such an example. Other methods of `ProjNode` for instance rely on the type of the input (which is correctly handled in `TupleNode`), and so should already work fine.

I'm trying to understand what happens if we don't have that. But maybe @iwanowww would have some helpful insight?

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

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

From mhaessig at openjdk.org  Fri Jun 20 12:06:27 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 20 Jun 2025 12:06:27 GMT
Subject: RFR: 8355276: Sort C2 includes
In-Reply-To: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
References: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
Message-ID: <QBPELYyAWIptnDd44E27i1gAZToeV2e-42Co69jO1pE=.3279d8f5-89fa-4165-a614-d52e97be0cd2@github.com>

On Fri, 20 Jun 2025 08:17:24 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/opto` using `test/hotspot/jtreg/sources/SortIncludes.java` and enforces sorted includes for C2 sources in `sources/TestIncludesAreSorted.java`.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15773777177)
>  - [x] tier1,tier2 plus Oracle internal testing on Oracle supported platforms

Everything passed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25910#issuecomment-2991271080

From epeter at openjdk.org  Fri Jun 20 13:45:32 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 20 Jun 2025 13:45:32 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <unTZCf5FBCMOiK3hMUxhiSLrsHjWzcU8_5yNvDQFMIw=.5c04ee79-4ce4-488b-8549-6588d30889b5@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <unTZCf5FBCMOiK3hMUxhiSLrsHjWzcU8_5yNvDQFMIw=.5c04ee79-4ce4-488b-8549-6588d30889b5@github.com>
Message-ID: <Zw-1Ay-xVD0KUyIgxZg-MNsjuwFVXYCoiljXQlT08e8=.4326f7b4-ef1b-4f16-ba86-b262f8ef171d@github.com>

On Fri, 20 Jun 2025 07:50:54 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/divnode.cpp line 1642:
>> 
>>> 1640:   }
>>> 1641:   assert(projs.catchall_ioproj == nullptr, "no exceptions from floating mod");
>>> 1642:   assert(projs.catchall_catchproj == nullptr, "no exceptions from floating mod");
>> 
>> Why were you able to remove this?
>
> Pure functions have only control input, data inputs (1 or 2 in practice, so far), control output and data output: they can't alter the memory, they can't throw etc since they are pure. All these output were already unnecessary (which I noticed when working on removing modulo a few months ago), and are now simply not present, so the rewiring is useless.

Great! When I remove code like that, then I often just leave a "info" code comment, just to help the reviewers - you don't need to do that, it's just an idea ;)

>> src/hotspot/share/opto/multnode.cpp line 177:
>> 
>>> 175:   }
>>> 176:   return this;
>>> 177: }
>> 
>> What would happen if we miss to do this optimization? I suppose we would have a Tuple left in the graph and get a bad AD file assert / deopt in product?
>
> Exactly. Bad AD file. I don't think it's possible at the moment because when we return a tuple node during IGVN instead of a call, the user (all projections) are added to the worklist and they will all skip the tuple. As used for now, a Tuple should appear and disappear in the same IGVN.

Yes, I think it is safe. And if we did indeed forget to remove it at some point, we would deopt at the "bad AD file", and that's not horrible. And we would catch it with the corresponding assert. Reasonable :)

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

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

From epeter at openjdk.org  Fri Jun 20 13:48:31 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 20 Jun 2025 13:48:31 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <2BVVfe4S925G10VAJBu7KV_Y87aPxByXyfl5AxVJU8o=.5df2a49c-d9dd-4010-b0bc-283698e9e1ec@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <2BVVfe4S925G10VAJBu7KV_Y87aPxByXyfl5AxVJU8o=.5df2a49c-d9dd-4010-b0bc-283698e9e1ec@github.com>
Message-ID: <CTT45c91TOyURk2GCEQH9_4fv8lHF059HvK_EbtI4Ls=.12f8f3b8-699d-4c61-8052-eb4eb9231121@github.com>

On Fri, 20 Jun 2025 08:10:54 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/multnode.hpp line 113:
>> 
>>> 111:   const TypeTuple* _tf;
>>> 112: 
>>> 113:   template <typename... NN>
>> 
>> Does this need to be a template? Or would a type like `Node*` or `Node` suffice?
>
> The point is that it's a variadic template. Of course, ideally, I'd like it to be a pack of `Node*` but there isn't a simple way to write that. The upside is that one can write `TupleNode::make(some_type, input1, input2, input3, input4)` with how many input you want in a single construction. I prefer hiding the not nice here, to have compact and readable usages of TupleNode, rather than having every usage look like
> 
> TupleNode* tuple = new TupleNode(some_type);
> tuple.set_req(0, input1);
> tuple.set_req(1, input2);
> tuple.set_req(2, input3);
> tuple.set_req(3, input4);

Yes, it looks good enough :)

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

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

From kvn at openjdk.org  Fri Jun 20 14:50:27 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 20 Jun 2025 14:50:27 GMT
Subject: RFR: 8355276: Sort C2 includes
In-Reply-To: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
References: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
Message-ID: <elewl8Fn1zh4ST8IyxIWy8IpgQU_j5H4zfvkw3p0SZo=.d3307ac8-95b6-448c-a872-118b897eed68@github.com>

On Fri, 20 Jun 2025 08:17:24 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/opto` using `test/hotspot/jtreg/sources/SortIncludes.java` and enforces sorted includes for C2 sources in `sources/TestIncludesAreSorted.java`.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15773777177)
>  - [x] tier1,tier2 plus Oracle internal testing on Oracle supported platforms

Looks good.

Marked as reviewed by kvn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25910#pullrequestreview-2946438361
PR Review: https://git.openjdk.org/jdk/pull/25910#pullrequestreview-2946438776

From epeter at openjdk.org  Fri Jun 20 15:37:31 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 20 Jun 2025 15:37:31 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <Un4ihnAeqh6yjS6JH3LkdKBvTtw_TxZJM6CLT2CaJR0=.e74e02fd-d524-41de-8f28-7837a652e57e@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <Un4ihnAeqh6yjS6JH3LkdKBvTtw_TxZJM6CLT2CaJR0=.e74e02fd-d524-41de-8f28-7837a652e57e@github.com>
Message-ID: <EFBnNL_RAJzuhbILQxUKO1ZMBFkV4XsRQvD3PyUVeng=.bda369f6-51a5-41e1-8387-0249b3f68a17@github.com>

On Fri, 20 Jun 2025 07:45:30 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/callnode.cpp line 1306:
>> 
>>> 1304: 
>>> 1305: //=============================================================================
>>> 1306: bool CallLeafPureNode::is_unused() const {
>> 
>> Can you add a quick comment why this check implies that the node is not used, i.e. what that means?
>
> I think i'll need you to explain to me what is unclear at the moment. When I read the function, I see:
> "A CallLeafPure is unused iff there is no output result projection."
> 
> I don't see what else to add that is not covered by "if we don't use the result, the pure call is unused", which is exactly the code. Is there any untold hypothesis lurking somewhere that I don't see? It seems to me it uses just very common concepts of C2.

The call could have other uses for other projections. Why does this projection make it unused?

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

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

From epeter at openjdk.org  Fri Jun 20 15:37:31 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 20 Jun 2025 15:37:31 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <EFBnNL_RAJzuhbILQxUKO1ZMBFkV4XsRQvD3PyUVeng=.bda369f6-51a5-41e1-8387-0249b3f68a17@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <Un4ihnAeqh6yjS6JH3LkdKBvTtw_TxZJM6CLT2CaJR0=.e74e02fd-d524-41de-8f28-7837a652e57e@github.com>
 <EFBnNL_RAJzuhbILQxUKO1ZMBFkV4XsRQvD3PyUVeng=.bda369f6-51a5-41e1-8387-0249b3f68a17@github.com>
Message-ID: <IAFJxPEHB3haeIrng3Zp675LvTaNhs8RClWxPV-3JyA=.5ef9202a-6148-421a-8a4b-57b174daf747@github.com>

On Fri, 20 Jun 2025 15:34:03 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> I think i'll need you to explain to me what is unclear at the moment. When I read the function, I see:
>> "A CallLeafPure is unused iff there is no output result projection."
>> 
>> I don't see what else to add that is not covered by "if we don't use the result, the pure call is unused", which is exactly the code. Is there any untold hypothesis lurking somewhere that I don't see? It seems to me it uses just very common concepts of C2.
>
> The call could have other uses for other projections. Why does this projection make it unused?

I suppose I was not aware that `TypeFunc::Parms` stands for result projection.... the name does not make it immediately apparent.

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

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

From epeter at openjdk.org  Fri Jun 20 15:57:34 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 20 Jun 2025 15:57:34 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <DKGEzb3d3sEt1PgrKM7n9aHn6s_oAh1k9QC-7XHm8aM=.dbd0f2b4-9621-4a3b-97b7-8b22c0fd24a9@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <DKGEzb3d3sEt1PgrKM7n9aHn6s_oAh1k9QC-7XHm8aM=.dbd0f2b4-9621-4a3b-97b7-8b22c0fd24a9@github.com>
Message-ID: <I56YK3ODh6kGEqtzBmhfB7I4RVd2jKfBbyS80Wl817o=.d37e2c62-8080-4951-bc81-ee73ba4da87e@github.com>

On Fri, 20 Jun 2025 08:16:11 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

@marc-chevalier Thanks for addressing my comments! I now have a few more for you :)

src/hotspot/share/opto/callnode.cpp line 1318:

> 1316:  * such a tuple, we let output Proj's idealization pick the corresponding input of the
> 1317:  * pure call, so jumping over it, and effectively, removing the call from the graph.
> 1318:  * This avoids doing the graph surgery manually, but leave that to IGVN

Suggestion:

 * This avoids doing the graph surgery manually, but leaves that to IGVN

src/hotspot/share/opto/callnode.cpp line 1341:

> 1339: }
> 1340: 
> 1341: Node* CallLeafPureNode::Ideal(PhaseGVN* phase, bool can_reshape) {

Did you make sure that this method is called from all its subclasses?

It seems to me that you just copied the code to the subclasses, rather than calling this method, am I right?

src/hotspot/share/opto/callnode.cpp line 1342:

> 1340: 
> 1341: Node* CallLeafPureNode::Ideal(PhaseGVN* phase, bool can_reshape) {
> 1342:   if (is_dead()) { // dead node

Suggestion:

  if (is_dead()) {

The comment seemed redundant. You could say who else is responsible of cleaning up the dead node though.

What would happen if the `CallLeafPureNode` loses  its control projection, but not the other uses? I don't even know if that is possible. What do you think?

src/hotspot/share/opto/callnode.hpp line 916:

> 914: };
> 915: 
> 916: class CallLeafPureNode : public CallLeafNode {

You need a short description about what this node is for. What are the assumptions about it?

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

> 1520:   if (!can_reshape) {
> 1521:     return nullptr;
> 1522:   }

Would this prevent us from doing the `make_tuple_of_input_state_and_top_return_values` trick? Because it seems to me that we do not need to reshape the node for that, right? Maybe you  should reorder things for that?

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25760#pullrequestreview-2946648813
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159274378
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159292773
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159277636
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159287237
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159289092

From mchevalier at openjdk.org  Fri Jun 20 15:57:36 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 20 Jun 2025 15:57:36 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <IAFJxPEHB3haeIrng3Zp675LvTaNhs8RClWxPV-3JyA=.5ef9202a-6148-421a-8a4b-57b174daf747@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <Un4ihnAeqh6yjS6JH3LkdKBvTtw_TxZJM6CLT2CaJR0=.e74e02fd-d524-41de-8f28-7837a652e57e@github.com>
 <EFBnNL_RAJzuhbILQxUKO1ZMBFkV4XsRQvD3PyUVeng=.bda369f6-51a5-41e1-8387-0249b3f68a17@github.com>
 <IAFJxPEHB3haeIrng3Zp675LvTaNhs8RClWxPV-3JyA=.5ef9202a-6148-421a-8a4b-57b174daf747@github.com>
Message-ID: <Pna9z_W5bwJWpof4oE9vBaSk6NlQUBlSStEvscjve9E=.91f4cdfb-2525-4c04-9b62-7cbbf4d472ee@github.com>

On Fri, 20 Jun 2025 15:35:04 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> The call could have other uses for other projections. Why does this projection make it unused?
>
> I suppose I was not aware that `TypeFunc::Parms` stands for result projection.... the name does not make it immediately apparent.

I see. I think I'd be better to comment on the declaration of the class then. Something saying that CallLeafPureNode represents calls that are pure: they only have data input and output data (and control for practical reasons for now), no exceptions, no memory, no safepoint... They can be freely be moved around, duplicated or, if the result isn't used, removed. Then that explains... a lot of what we are doing, not just `is_unused`.

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

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

From epeter at openjdk.org  Fri Jun 20 15:57:37 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 20 Jun 2025 15:57:37 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <wJrnPQShUnKJ3CIXMabkRzp8opdM9pTRUlDrw05o8cY=.0c0625ab-6477-4077-9dd9-fc1483b72d32@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <wJrnPQShUnKJ3CIXMabkRzp8opdM9pTRUlDrw05o8cY=.0c0625ab-6477-4077-9dd9-fc1483b72d32@github.com>
Message-ID: <7m83zrjdB-g0fkfOUN_8MtvbUV4XEAl_d0ErDFXo9To=.a5aff34c-192c-41ee-9a41-ca23bc10e73c@github.com>

On Fri, 20 Jun 2025 07:37:31 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/callnode.cpp line 1335:
>> 
>>> 1333:   if (can_reshape && is_unused()) {
>>> 1334:     return make_tuple_of_input_state_and_top_return_values(phase->C);
>>> 1335:   }
>> 
>> Can you add a code comment what this does?
>
> It's better commented at the definition of `make_tuple_of_input_state_and_top_return_values` now. Let's not bloat the each call site with the same wall of text again.

Suggestion:

  if (can_reshape && is_unused()) {
    // The result is not used. We remove the call by replacing it with a tuple, that
    // is later desintegrated by the projections.
    return make_tuple_of_input_state_and_top_return_values(phase->C);
  }

I suggest this. It is short,  and allows you to quickly understand what is happening without having to go to the other side.

Alternatively, you could also rename `make_tuple_of_input_state_and_top_return_values`.

Maybe: `make_tuple_for_delayed_desintegration` ? Maybe someone has an even better idea.

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

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

From epeter at openjdk.org  Fri Jun 20 15:57:38 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 20 Jun 2025 15:57:38 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <I56YK3ODh6kGEqtzBmhfB7I4RVd2jKfBbyS80Wl817o=.d37e2c62-8080-4951-bc81-ee73ba4da87e@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <DKGEzb3d3sEt1PgrKM7n9aHn6s_oAh1k9QC-7XHm8aM=.dbd0f2b4-9621-4a3b-97b7-8b22c0fd24a9@github.com>
 <I56YK3ODh6kGEqtzBmhfB7I4RVd2jKfBbyS80Wl817o=.d37e2c62-8080-4951-bc81-ee73ba4da87e@github.com>
Message-ID: <I8Qh5LWn8BVCtXNLjnV2p4qyqTzkQlmVUdDJ4BO-jRc=.25fc1ae6-2f05-42b0-bd2d-5fec33a00fa2@github.com>

On Fri, 20 Jun 2025 15:50:46 GMT, Emanuel Peter <epeter 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:   if (!can_reshape) {
>> 1521:     return nullptr;
>> 1522:   }
> 
> Would this prevent us from doing the `make_tuple_of_input_state_and_top_return_values` trick? Because it seems to me that we do not need to reshape the node for that, right? Maybe you  should reorder things for that?

Also, you should probably call `CallLeafPureNode::Ideal` instead of duplicating its logic here and in other subclasses.

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

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

From epeter at openjdk.org  Fri Jun 20 16:01:51 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 20 Jun 2025 16:01:51 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <Pna9z_W5bwJWpof4oE9vBaSk6NlQUBlSStEvscjve9E=.91f4cdfb-2525-4c04-9b62-7cbbf4d472ee@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <Un4ihnAeqh6yjS6JH3LkdKBvTtw_TxZJM6CLT2CaJR0=.e74e02fd-d524-41de-8f28-7837a652e57e@github.com>
 <EFBnNL_RAJzuhbILQxUKO1ZMBFkV4XsRQvD3PyUVeng=.bda369f6-51a5-41e1-8387-0249b3f68a17@github.com>
 <IAFJxPEHB3haeIrng3Zp675LvTaNhs8RClWxPV-3JyA=.5ef9202a-6148-421a-8a4b-57b174daf747@github.com>
 <Pna9z_W5bwJWpof4oE9vBaSk6NlQUBlSStEvscjve9E=.91f4cdfb-2525-4c04-9b62-7cbbf4d472ee@github.com>
Message-ID: <Mgoe18W7rZymbm7BR9_qsSP0_CyFzT3UA8N_kf1t4A8=.debb2c64-a0b5-4f37-9ece-7bb60317c16d@github.com>

On Fri, 20 Jun 2025 15:54:20 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> I suppose I was not aware that `TypeFunc::Parms` stands for result projection.... the name does not make it immediately apparent.
>
> I see. I think I'd be better to comment on the declaration of the class then. Something saying that CallLeafPureNode represents calls that are pure: they only have data input and output data (and control for practical reasons for now), no exceptions, no memory, no safepoint... They can be freely be moved around, duplicated or, if the result isn't used, removed. Then that explains... a lot of what we are doing, not just `is_unused`.

I think I was really just confused about the `Parms`. I thought that means parameters .. and not results :rofl:

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

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

From mchevalier at openjdk.org  Fri Jun 20 16:06:32 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 20 Jun 2025 16:06:32 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <Mgoe18W7rZymbm7BR9_qsSP0_CyFzT3UA8N_kf1t4A8=.debb2c64-a0b5-4f37-9ece-7bb60317c16d@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <Un4ihnAeqh6yjS6JH3LkdKBvTtw_TxZJM6CLT2CaJR0=.e74e02fd-d524-41de-8f28-7837a652e57e@github.com>
 <EFBnNL_RAJzuhbILQxUKO1ZMBFkV4XsRQvD3PyUVeng=.bda369f6-51a5-41e1-8387-0249b3f68a17@github.com>
 <IAFJxPEHB3haeIrng3Zp675LvTaNhs8RClWxPV-3JyA=.5ef9202a-6148-421a-8a4b-57b174daf747@github.com>
 <Pna9z_W5bwJWpof4oE9vBaSk6NlQUBlSStEvscjve9E=.91f4cdfb-2525-4c04-9b62-7cbbf4d472ee@github.com>
 <Mgoe18W7rZymbm7BR9_qsSP0_CyFzT3UA8N_kf1t4A8=.debb2c64-a0b5-4f37-9ece-7bb60317c16d@github.com>
Message-ID: <h603Q6XDI-4d8LQytRbE_h-JCnGstAZy__JYUVGVhXE=.d93444e5-b87d-4d55-8ea6-4338b6dc7a67@github.com>

On Fri, 20 Jun 2025 15:58:26 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> I see. I think I'd be better to comment on the declaration of the class then. Something saying that CallLeafPureNode represents calls that are pure: they only have data input and output data (and control for practical reasons for now), no exceptions, no memory, no safepoint... They can be freely be moved around, duplicated or, if the result isn't used, removed. Then that explains... a lot of what we are doing, not just `is_unused`.
>
> I think I was really just confused about the `Parms`. I thought that means parameters .. and not results :rofl:

It's actually both. For functions, the parameters are starting at `Parms`, and the results too. Before that, it's all the special stuff: control, memory, io...

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

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

From vlivanov at openjdk.org  Fri Jun 20 19:16:29 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 20 Jun 2025 19:16:29 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <sZY0SthfHG6CKDnVCUGCopgp9wSaSuo160mFjKGdODY=.77417f21-e447-4e40-8c9a-d6d3f5d73635@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <sZY0SthfHG6CKDnVCUGCopgp9wSaSuo160mFjKGdODY=.77417f21-e447-4e40-8c9a-d6d3f5d73635@github.com>
Message-ID: <7I4F9dJkYX6b66vnJfhJLvvjnC-aw0xA3X2eimh8kBg=.0d11e624-4c82-4d7e-8392-e3274a76478a@github.com>

On Fri, 20 Jun 2025 12:00:52 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/multnode.cpp line 126:
>> 
>>> 124:       // Jumping over Tuples: the i-th projection of a Tuple is the i-th input of the Tuple.
>>> 125:       ctrl = ctrl->in(_con);
>>> 126:     }
>> 
>> Do you need to special-case this here? Why does the `ProjNode::Identity` not suffice? Are there potentially other locations where we now would need this special logic?
>
> That is a good question. That is something I picked from Vladimir's implementation and it seemed legitimate. But now you say it, is it needed? Not sure. I'm trying to find that out. Would `::Identity` be enough? It's tempting to say so, right! I'd say it can be not enough if we need `adr_type` before idealizing the `ProjNode` (no idea if that happens). Is there any other places to adapt? One could think so, but actually, I can't find such an example. Other methods of `ProjNode` for instance rely on the type of the input (which is correctly handled in `TupleNode`), and so should already work fine.
> 
> I'm trying to understand what happens if we don't have that. But maybe @iwanowww would have some helpful insight?

I don't remember all the details now, but there were some problems when `ProjNode::adr_type()` encounters `TupleNode`.

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

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

From dzhang at openjdk.org  Sun Jun 22 07:01:48 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Sun, 22 Jun 2025 07:01:48 GMT
Subject: RFR: 8360169: Problem list CodeInvalidationReasonTest.java on
 linux-riscv64 until JDK-8360168 is fixed
Message-ID: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>

Hi all,
As described in the [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) issue, the case failed on linux-riscv64. We put the failed test
case into the Problem list until [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) is fixed.

Please take a look and have some reviews. Thanks a lot.

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

Commit messages:
 - 8360169: Problem list CodeInvalidationReasonTest.java on linux-riscv64 until JDK-8360168 is fixed

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

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

From fyang at openjdk.org  Mon Jun 23 00:47:35 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 23 Jun 2025 00:47:35 GMT
Subject: RFR: 8360169: Problem list CodeInvalidationReasonTest.java on
 linux-riscv64 until JDK-8360168 is fixed
In-Reply-To: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
References: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
Message-ID: <OFZFq3LKbMLSAThBYcDEbBwFP7bKSjGiVSo-wLMWjw4=.054e1c4b-7598-4a77-89b5-f89abb22e9a5@github.com>

On Sat, 21 Jun 2025 14:45:13 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi all,
> As described in the [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) issue, the case failed on linux-riscv64. We put the failed test
> case into the Problem list until [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) is fixed.
> 
> Please take a look and have some reviews. Thanks a lot.

Marked as reviewed by fyang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25924#pullrequestreview-2948413524

From fjiang at openjdk.org  Mon Jun 23 01:12:42 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 23 Jun 2025 01:12:42 GMT
Subject: RFR: 8360169: Problem list CodeInvalidationReasonTest.java on
 linux-riscv64 until JDK-8360168 is fixed
In-Reply-To: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
References: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
Message-ID: <wQefc5bBJlmVEn_UNTPjAPrEcaxb4VYz0KO0esBwr3s=.75a5ace3-b632-4002-b87f-e41d15ab931f@github.com>

On Sat, 21 Jun 2025 14:45:13 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi all,
> As described in the [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) issue, the case failed on linux-riscv64. We put the failed test
> case into the Problem list until [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) is fixed.
> 
> Please take a look and have some reviews. Thanks a lot.

Marked as reviewed by fjiang (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25924#pullrequestreview-2948430770

From syan at openjdk.org  Mon Jun 23 05:45:32 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 23 Jun 2025 05:45:32 GMT
Subject: RFR: 8360169: Problem list CodeInvalidationReasonTest.java on
 linux-riscv64 until JDK-8360168 is fixed
In-Reply-To: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
References: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
Message-ID: <DWLP_KozxRT_XW5FPpzo0TbuCErbAsk31DAt9O9Uo1s=.8caf9cc2-bdd4-4d2d-9f96-2bbfbb94568e@github.com>

On Sat, 21 Jun 2025 14:45:13 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi all,
> As described in the [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) issue, the case failed on linux-riscv64. We put the failed test
> case into the Problem list until [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) is fixed.
> 
> Please take a look and have some reviews. Thanks a lot.

Marked as reviewed by syan (Committer).

GHA report configure fails 'Could not find a C compiler' on windows-x64 and windows-aarch64, I think it's unrelated to this PR.

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

PR Review: https://git.openjdk.org/jdk/pull/25924#pullrequestreview-2948725218
PR Comment: https://git.openjdk.org/jdk/pull/25924#issuecomment-2995004052

From mchevalier at openjdk.org  Mon Jun 23 06:43:31 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 23 Jun 2025 06:43:31 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <7I4F9dJkYX6b66vnJfhJLvvjnC-aw0xA3X2eimh8kBg=.0d11e624-4c82-4d7e-8392-e3274a76478a@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <2f8GCEXnY2mwaz9N9dQK_APi0A31z8Y7CM6YPms4Pp0=.a0651468-def0-4101-94bb-8fabd6d79b1b@github.com>
 <sZY0SthfHG6CKDnVCUGCopgp9wSaSuo160mFjKGdODY=.77417f21-e447-4e40-8c9a-d6d3f5d73635@github.com>
 <7I4F9dJkYX6b66vnJfhJLvvjnC-aw0xA3X2eimh8kBg=.0d11e624-4c82-4d7e-8392-e3274a76478a@github.com>
Message-ID: <VOfKwH7fMb7QB8CN1UaDRjcj07KpjimfzFCmcoKY2jk=.0a4ba731-0933-469c-a815-801fcd33d4d8@github.com>

On Fri, 20 Jun 2025 19:14:05 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> That is a good question. That is something I picked from Vladimir's implementation and it seemed legitimate. But now you say it, is it needed? Not sure. I'm trying to find that out. Would `::Identity` be enough? It's tempting to say so, right! I'd say it can be not enough if we need `adr_type` before idealizing the `ProjNode` (no idea if that happens). Is there any other places to adapt? One could think so, but actually, I can't find such an example. Other methods of `ProjNode` for instance rely on the type of the input (which is correctly handled in `TupleNode`), and so should already work fine.
>> 
>> I'm trying to understand what happens if we don't have that. But maybe @iwanowww would have some helpful insight?
>
> I don't remember all the details now, but there were some problems when `ProjNode::adr_type()` encounters `TupleNode`.

I've run some test without this special handling and I couldn't see nothing more failing. Maybe it was more necessary in Vladimir's original usecase (reachability). In my case, maybe I don't need `adr_type` to handle nicely `TupleNode`s, but let's not set a trap for the future.

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

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

From thartmann at openjdk.org  Mon Jun 23 06:52:37 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 23 Jun 2025 06:52:37 GMT
Subject: RFR: 8355276: Sort C2 includes
In-Reply-To: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
References: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
Message-ID: <_r9O6tLaOT6j05Pz-EqQZrkdCsYasmRtAzHLPfS8iAs=.eefcfa03-4c05-4319-ae38-f12530394ef0@github.com>

On Fri, 20 Jun 2025 08:17:24 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/opto` using `test/hotspot/jtreg/sources/SortIncludes.java` and enforces sorted includes for C2 sources in `sources/TestIncludesAreSorted.java`.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15773777177)
>  - [x] tier1,tier2 plus Oracle internal testing on Oracle supported platforms

Looks good to me. Thanks for fixing this!

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25910#pullrequestreview-2948856227

From mhaessig at openjdk.org  Mon Jun 23 06:52:37 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 23 Jun 2025 06:52:37 GMT
Subject: RFR: 8355276: Sort C2 includes
In-Reply-To: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
References: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
Message-ID: <o36awEybV0IiqxPZxObDIyxU9h8etS29-9dzhCQNc8w=.c8137472-582c-469a-b823-339d9c20ffda@github.com>

On Fri, 20 Jun 2025 08:17:24 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/opto` using `test/hotspot/jtreg/sources/SortIncludes.java` and enforces sorted includes for C2 sources in `sources/TestIncludesAreSorted.java`.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15773777177)
>  - [x] tier1,tier2 plus Oracle internal testing on Oracle supported platforms

Thank you for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25910#issuecomment-2995152988

From duke at openjdk.org  Mon Jun 23 06:52:38 2025
From: duke at openjdk.org (duke)
Date: Mon, 23 Jun 2025 06:52:38 GMT
Subject: RFR: 8355276: Sort C2 includes
In-Reply-To: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
References: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
Message-ID: <us90WgZZqy_93eisvBPDQBmDBxKZbHbPAoBaaZ1jCws=.2eef3663-4f81-41e3-a718-434be710f22a@github.com>

On Fri, 20 Jun 2025 08:17:24 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/opto` using `test/hotspot/jtreg/sources/SortIncludes.java` and enforces sorted includes for C2 sources in `sources/TestIncludesAreSorted.java`.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15773777177)
>  - [x] tier1,tier2 plus Oracle internal testing on Oracle supported platforms

@mhaessig 
Your change (at version 83e2a186a0f925cdce26f4610ddadbd41b679c89) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25910#issuecomment-2995154173

From mchevalier at openjdk.org  Mon Jun 23 07:39:32 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 23 Jun 2025 07:39:32 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <I56YK3ODh6kGEqtzBmhfB7I4RVd2jKfBbyS80Wl817o=.d37e2c62-8080-4951-bc81-ee73ba4da87e@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <DKGEzb3d3sEt1PgrKM7n9aHn6s_oAh1k9QC-7XHm8aM=.dbd0f2b4-9621-4a3b-97b7-8b22c0fd24a9@github.com>
 <I56YK3ODh6kGEqtzBmhfB7I4RVd2jKfBbyS80Wl817o=.d37e2c62-8080-4951-bc81-ee73ba4da87e@github.com>
Message-ID: <7MJVRaO_nQSfwpl874EU71b63Du-sNvU4X034Jml6IY=.3bfdbe0a-4e8c-4e6a-b5b3-8ee02939a878@github.com>

On Fri, 20 Jun 2025 15:42:53 GMT, Emanuel Peter <epeter 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/callnode.cpp line 1342:
> 
>> 1340: 
>> 1341: Node* CallLeafPureNode::Ideal(PhaseGVN* phase, bool can_reshape) {
>> 1342:   if (is_dead()) { // dead node
> 
> Suggestion:
> 
>   if (is_dead()) {
> 
> The comment seemed redundant. You could say who else is responsible of cleaning up the dead node though.
> 
> What would happen if the `CallLeafPureNode` loses  its control projection, but not the other uses? I don't even know if that is possible. What do you think?

IGVN takes care of removing a node without output.

This was motivated by https://bugs.openjdk.org/browse/JDK-8353341 I think @TobiHartmann told me it's common not to touch dead nodes during idealization.

I think it is possible to lose control projection but not data because data was already found dead, but data wasn't yet (but should happen shortly after). As soon as the data projection disappear, the node should be removed. `remove_dead_node` (used in IGVN) is aggressively removing a dead node and all the usages that become recursively dead.  It's the classic constraint of having to find that both data and control are top when one is.

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

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

From dnsimon at openjdk.org  Mon Jun 23 07:47:33 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 23 Jun 2025 07:47:33 GMT
Subject: RFR: 8360169: Problem list CodeInvalidationReasonTest.java on
 linux-riscv64 until JDK-8360168 is fixed
In-Reply-To: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
References: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
Message-ID: <YaBarDu5-5s9l-bAWoy9A8W_9E92KbVrDNn_2OxAEmI=.3c6ce688-a075-46cf-9005-ebe4aa60a5a4@github.com>

On Sat, 21 Jun 2025 14:45:13 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi all,
> As described in the [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) issue, the case failed on linux-riscv64. We put the failed test
> case into the Problem list until [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) is fixed.
> 
> Please take a look and have some reviews. Thanks a lot.

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25924#pullrequestreview-2949010465

From mhaessig at openjdk.org  Mon Jun 23 07:50:35 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 23 Jun 2025 07:50:35 GMT
Subject: Integrated: 8355276: Sort C2 includes
In-Reply-To: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
References: <_ab90h2O6v67rorpT12dUxMO2mv7GscLEMo37dLJkhA=.c645e9e0-8b99-49f8-8aa5-80a623b541d6@github.com>
Message-ID: <MsQi3LOY4ML_xniYYgn5qmyfaiHHl0W4q-LcQ-kY6GM=.726992f0-1d0b-46be-92ad-3cf96ee3a479@github.com>

On Fri, 20 Jun 2025 08:17:24 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/opto` using `test/hotspot/jtreg/sources/SortIncludes.java` and enforces sorted includes for C2 sources in `sources/TestIncludesAreSorted.java`.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15773777177)
>  - [x] tier1,tier2 plus Oracle internal testing on Oracle supported platforms

This pull request has now been integrated.

Changeset: 9ae39b62
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ae39b62b91ffacc6473534d96679f3282c612cc
Stats:     119 lines in 40 files changed: 57 ins; 55 del; 7 mod

8355276: Sort C2 includes

Reviewed-by: kvn, thartmann

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

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

From mchevalier at openjdk.org  Mon Jun 23 07:59:33 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 23 Jun 2025 07:59:33 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <I8Qh5LWn8BVCtXNLjnV2p4qyqTzkQlmVUdDJ4BO-jRc=.25fc1ae6-2f05-42b0-bd2d-5fec33a00fa2@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <DKGEzb3d3sEt1PgrKM7n9aHn6s_oAh1k9QC-7XHm8aM=.dbd0f2b4-9621-4a3b-97b7-8b22c0fd24a9@github.com>
 <I56YK3ODh6kGEqtzBmhfB7I4RVd2jKfBbyS80Wl817o=.d37e2c62-8080-4951-bc81-ee73ba4da87e@github.com>
 <I8Qh5LWn8BVCtXNLjnV2p4qyqTzkQlmVUdDJ4BO-jRc=.25fc1ae6-2f05-42b0-bd2d-5fec33a00fa2@github.com>
Message-ID: <99-WvIy2CRk9L3nYq_zIenWde1_cxvu3F-9ftYIrdh8=.d9ce6642-276a-40dc-a9ca-044d24160952@github.com>

On Fri, 20 Jun 2025 15:53:59 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/divnode.cpp line 1522:
>> 
>>> 1520:   if (!can_reshape) {
>>> 1521:     return nullptr;
>>> 1522:   }
>> 
>> Would this prevent us from doing the `make_tuple_of_input_state_and_top_return_values` trick? Because it seems to me that we do not need to reshape the node for that, right? Maybe you  should reorder things for that?
>
> Also, you should probably call `CallLeafPureNode::Ideal` instead of duplicating its logic here and in other subclasses.

In an earlier issue ([JDK-8349523](https://bugs.openjdk.org/browse/JDK-8349523)), I tried to remove these nodes during parsing. It didn't work well. The problem is that it's transformed by GVN before setting any output projection, so of course, the node is removing itself before having the opportunity of being used. We wait until usages have been set before we try to remove the node (or replace it with a tuple).

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

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

From dzhang at openjdk.org  Mon Jun 23 08:02:28 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 23 Jun 2025 08:02:28 GMT
Subject: RFR: 8360169: Problem list CodeInvalidationReasonTest.java on
 linux-riscv64 until JDK-8360168 is fixed
In-Reply-To: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
References: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
Message-ID: <UdpYsfR6aJhivfEfrcHVxfZCNve1seR6Y6Of4gH0vWY=.c27cd0eb-caeb-4582-83ae-aa9f555fea21@github.com>

On Sat, 21 Jun 2025 14:45:13 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi all,
> As described in the [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) issue, the case failed on linux-riscv64. We put the failed test
> case into the Problem list until [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) is fixed.
> 
> Please take a look and have some reviews. Thanks a lot.

Thanks all for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25924#issuecomment-2995354320

From duke at openjdk.org  Mon Jun 23 08:02:29 2025
From: duke at openjdk.org (duke)
Date: Mon, 23 Jun 2025 08:02:29 GMT
Subject: RFR: 8360169: Problem list CodeInvalidationReasonTest.java on
 linux-riscv64 until JDK-8360168 is fixed
In-Reply-To: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
References: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
Message-ID: <MaNWNSV3-tEVFThP-HSakPVuRg92FU2hP0LkcP88aCA=.72dbf9bf-c6e6-4da1-a400-5cbf6f674892@github.com>

On Sat, 21 Jun 2025 14:45:13 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi all,
> As described in the [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) issue, the case failed on linux-riscv64. We put the failed test
> case into the Problem list until [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) is fixed.
> 
> Please take a look and have some reviews. Thanks a lot.

@DingliZhang 
Your change (at version f2d474b558b559e5cb53b0fc79086a87a9dd2003) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25924#issuecomment-2995359778

From dzhang at openjdk.org  Mon Jun 23 08:05:35 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 23 Jun 2025 08:05:35 GMT
Subject: Integrated: 8360169: Problem list CodeInvalidationReasonTest.java on
 linux-riscv64 until JDK-8360168 is fixed
In-Reply-To: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
References: <S1W_AvlhkEX2DX4gEP148gaegule2N5M3-h0N8X6Sgc=.2a101727-9c48-44db-8af6-9437f85b19e8@github.com>
Message-ID: <s4ODN2cnE1ppwBVSY-Sq_CCnH8fYYRuLjqmmDHLL274=.23603093-bcff-4de9-8c3b-80d974900df0@github.com>

On Sat, 21 Jun 2025 14:45:13 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi all,
> As described in the [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) issue, the case failed on linux-riscv64. We put the failed test
> case into the Problem list until [JDK-8360168](https://bugs.openjdk.org/browse/JDK-8360168) is fixed.
> 
> Please take a look and have some reviews. Thanks a lot.

This pull request has now been integrated.

Changeset: ad1033d6
Author:    Dingli Zhang <dzhang at openjdk.org>
Committer: Feilong Jiang <fjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad1033d68f4dd030cad27f9868d4fa83b5080bcd
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8360169: Problem list CodeInvalidationReasonTest.java on linux-riscv64 until JDK-8360168 is fixed

Reviewed-by: fyang, fjiang, syan, dnsimon

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

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

From epeter at openjdk.org  Mon Jun 23 09:22:31 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 23 Jun 2025 09:22:31 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <99-WvIy2CRk9L3nYq_zIenWde1_cxvu3F-9ftYIrdh8=.d9ce6642-276a-40dc-a9ca-044d24160952@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <DKGEzb3d3sEt1PgrKM7n9aHn6s_oAh1k9QC-7XHm8aM=.dbd0f2b4-9621-4a3b-97b7-8b22c0fd24a9@github.com>
 <I56YK3ODh6kGEqtzBmhfB7I4RVd2jKfBbyS80Wl817o=.d37e2c62-8080-4951-bc81-ee73ba4da87e@github.com>
 <I8Qh5LWn8BVCtXNLjnV2p4qyqTzkQlmVUdDJ4BO-jRc=.25fc1ae6-2f05-42b0-bd2d-5fec33a00fa2@github.com>
 <99-WvIy2CRk9L3nYq_zIenWde1_cxvu3F-9ftYIrdh8=.d9ce6642-276a-40dc-a9ca-044d24160952@github.com>
Message-ID: <9Oc_2z4n0h8cU825_70Vr6eMLLk6qz6hELGSeujGPsU=.a82e717f-e566-43fa-8da2-a609d4dc37a8@github.com>

On Mon, 23 Jun 2025 07:56:25 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Also, you should probably call `CallLeafPureNode::Ideal` instead of duplicating its logic here and in other subclasses.
>
> In an earlier issue ([JDK-8349523](https://bugs.openjdk.org/browse/JDK-8349523)), I tried to remove these nodes during parsing. It didn't work well. The problem is that it's transformed by GVN before setting any output projection, so of course, the node is removing itself before having the opportunity of being used. We wait until usages have been set before we try to remove the node (or replace it with a tuple).

That sounds like a bug at the use-site... don't you think?

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

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

From mchevalier at openjdk.org  Mon Jun 23 12:39:23 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 23 Jun 2025 12:39:23 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v3]
In-Reply-To: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
Message-ID: <t-WWJRfr_KRT3rdpGLzeBvTcevqNBfZIULYL_RaA1kg=.14cebf50-4194-4e21-9c74-54ae81c212d2@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:

  mostly comments

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

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

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

  Stats: 35 lines in 3 files changed: 19 ins; 8 del; 8 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  Mon Jun 23 12:41:30 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 23 Jun 2025 12:41:30 GMT
Subject: RFR: 8347901: C2 should remove unused leaf / pure runtime calls
 [v2]
In-Reply-To: <9Oc_2z4n0h8cU825_70Vr6eMLLk6qz6hELGSeujGPsU=.a82e717f-e566-43fa-8da2-a609d4dc37a8@github.com>
References: <DvcjlRlYi9b3VZuiOOHYPLw8PV7zBhmZ0KyJg_KeANQ=.b3d54d2e-5cd1-4e96-a0f9-f523ef237484@github.com>
 <DKGEzb3d3sEt1PgrKM7n9aHn6s_oAh1k9QC-7XHm8aM=.dbd0f2b4-9621-4a3b-97b7-8b22c0fd24a9@github.com>
 <I56YK3ODh6kGEqtzBmhfB7I4RVd2jKfBbyS80Wl817o=.d37e2c62-8080-4951-bc81-ee73ba4da87e@github.com>
 <I8Qh5LWn8BVCtXNLjnV2p4qyqTzkQlmVUdDJ4BO-jRc=.25fc1ae6-2f05-42b0-bd2d-5fec33a00fa2@github.com>
 <99-WvIy2CRk9L3nYq_zIenWde1_cxvu3F-9ftYIrdh8=.d9ce6642-276a-40dc-a9ca-044d24160952@github.com>
 <9Oc_2z4n0h8cU825_70Vr6eMLLk6qz6hELGSeujGPsU=.a82e717f-e566-43fa-8da2-a609d4dc37a8@github.com>
Message-ID: <SFyrs2sGZO9cBxigNARygzOMa3UlEzJ5ojNMePOUBPg=.f6ab99e8-ba8f-4598-9b0d-dd2d14d80905@github.com>

On Mon, 23 Jun 2025 09:20:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> In an earlier issue ([JDK-8349523](https://bugs.openjdk.org/browse/JDK-8349523)), I tried to remove these nodes during parsing. It didn't work well. The problem is that it's transformed by GVN before setting any output projection, so of course, the node is removing itself before having the opportunity of being used. We wait until usages have been set before we try to remove the node (or replace it with a tuple).
>
> That sounds like a bug at the use-site... don't you think?

As discussed offline, it's relatively normal. Adding a comment to explain.

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

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

From mchevalier at openjdk.org  Tue Jun 24 07:38:21 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 24 Jun 2025 07:38:21 GMT
Subject: RFR: 8359344: C2: Malformed control flow after intrinsic bailout
Message-ID: <CuKBI4IpisHrBWU8LHpnV8oFNxdHk0nbh9iyN_jntrg=.d5d5067e-90de-4265-9265-07bf76c7488e@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
- after bailing out, we need the map of the `jvms` to be where it was, so that the graph construction can continue where it was.
- if the intrinsic tried building some control flow, but we don't need it, we should remove it.

So... let's do that!

When a intrinsic bails out and regret its choice, we need to have remembered the old `JVMState`, set the map of it correctly, set the `jvms` of the map of it correctly, restore the map and sp of the `LibraryCallKit` as it was done before. On top of that, we remember control nodes that existed under our `control()` before trying to intrinsify: new control nodes that is not the (new) current map(= the clone of the map before) are disconnected to leave a nice CFG.

This has 2 interesting consequences:
- in the case of `compiler/intrinsics/VectorIntoArrayInvalidControlFlow.java`, compilation used to bailout because of malformed CFG on Aarch64. I'm adding a test that reproduced on x64 and Aarch64 and make the compilation bailout into a crash. The graph is now correctly shape on intrinsic bailout.
- in the case of `compiler/unsafe/OpaqueAccesses.java`, the whole (useless) structure introduced by the bailing out intrinsic is now removed. The call is now connected to where the intrinsic started, not where it ended (as shown under). I've adapted this test to check we don't have both a call and intrinsic leftover. Some of these cases are being intrinsiced, some are left as a call, and I don't want to be too strict about which must be which, as long as they are not both at the same time.

![3 after-intrinsic-bailout-during-parsing](https://github.com/user-attachments/assets/26652b49-4875-4953-aea5-6fa549f06822)

Thanks,
Marc

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

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359344
  Stats: 373 lines in 7 files changed: 277 ins; 50 del; 46 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